diff options
author | Francis Rowe <info@gluglug.org.uk> | 2015-02-04 09:14:49 +0000 |
---|---|---|
committer | Francis Rowe <info@gluglug.org.uk> | 2015-02-04 09:14:49 +0000 |
commit | 4c3d46238022f0c9955ae7e8b10c9f1716dd871a (patch) | |
tree | 8639e21d93df6493d952bda5f324efbe4d89447f /docs/gnulinux/grub_cbfs.html | |
parent | 5b6f5884280657c8554035503ee2bde5d84a276c (diff) | |
download | librebootfr-4c3d46238022f0c9955ae7e8b10c9f1716dd871a.tar.gz librebootfr-4c3d46238022f0c9955ae7e8b10c9f1716dd871a.zip |
Documentation: implement theme, drastically improve readability
Diffstat (limited to 'docs/gnulinux/grub_cbfs.html')
-rw-r--r-- | docs/gnulinux/grub_cbfs.html | 751 |
1 files changed, 387 insertions, 364 deletions
diff --git a/docs/gnulinux/grub_cbfs.html b/docs/gnulinux/grub_cbfs.html index c22d71d9..73cce0cf 100644 --- a/docs/gnulinux/grub_cbfs.html +++ b/docs/gnulinux/grub_cbfs.html @@ -12,444 +12,467 @@ </head> <body> - <header> + <div class="section"> <h1 id="pagetop">How to change your default GRUB menu</h1> - <aside>Or <a href="index.html">back to main index</a></aside> - </header> - - <p> - Libreboot uses the GRUB <a href="http://www.coreboot.org/Payloads#GRUB_2">payload</a> - by default, which means that the GRUB configuration file - (where your GRUB menu comes from) is stored directly alongside libreboot - and it's GRUB payload executable, inside - the flash chip. In context, this means that installing distributions and managing them - is handled slightly differently compared to traditional BIOS systems. - </p> - - <p> - A libreboot (or coreboot) ROM image is not simply "flat"; there is an actual - filesystem inside called CBFS (coreboot filesystem). A utility called 'cbfstool' - allows you to change the contents of the ROM image. In this case, libreboot is configured - such that the 'grub.cfg' and 'grubtest.cfg' files exists directly inside CBFS instead of - inside the GRUB payload 'memdisk' (which is itself stored in CBFS). - </p> - <p> - You can either modify - the GRUB configuration stored in the flash chip, or you can modify a GRUB configuration - file on the main storage which the libreboot GRUB payload will automatically search for. - </p> - - <p> - Here is an excellent writeup about CBFS (coreboot filesystem): - <a href="http://lennartb.home.xs4all.nl/coreboot/col5.html">http://lennartb.home.xs4all.nl/coreboot/col5.html</a>. - </p> - -<hr/> - - <h2>Table of Contents</h2> - - <ul> - <li><a href="#getting_started">Getting started</a></li> - <li><a href="#libreboot_grub_config_ondisk">Don't want to flash a new ROM image?</a></li> - <li><a href="#build_cbfstool">Build 'cbfstool' from source</a></li> - <li><a href="#which_rom">Which ROM image should I use?</a></li> - <li><a href="#extract_grubtest">Extract grubtest from the ROM image</a> - <li> - <a href="#example_modifications">Example modifications for <i>grubtest.cfg</i></a> - <ul> - <li><a href="#example_modifications_trisquel">Trisquel GNU/Linux-libre</a></li> - <li><a href="#example_modifications_parabola">Parabola GNU/Linux-libre</a></li> - </ul> - </li> - <li><a href="#reinsert_modified_grubtest">Re-insert the modified grubtest.cfg into the ROM image</a></li> - <li><a href="#test_it">Test it!</a> - <li><a href="#final_steps">Final steps</a></li> - <li><a href="#troubleshooting">Troubleshooting</a></li> - </ul> - -<hr/> - - <h2 id="getting_started">Getting started</h2> + <p> + Libreboot uses the GRUB <a href="http://www.coreboot.org/Payloads#GRUB_2">payload</a> + by default, which means that the GRUB configuration file + (where your GRUB menu comes from) is stored directly alongside libreboot + and it's GRUB payload executable, inside + the flash chip. In context, this means that installing distributions and managing them + is handled slightly differently compared to traditional BIOS systems. + </p> + <p> + A libreboot (or coreboot) ROM image is not simply "flat"; there is an actual + filesystem inside called CBFS (coreboot filesystem). A utility called 'cbfstool' + allows you to change the contents of the ROM image. In this case, libreboot is configured + such that the 'grub.cfg' and 'grubtest.cfg' files exists directly inside CBFS instead of + inside the GRUB payload 'memdisk' (which is itself stored in CBFS). + </p> + <p> + You can either modify + the GRUB configuration stored in the flash chip, or you can modify a GRUB configuration + file on the main storage which the libreboot GRUB payload will automatically search for. + </p> + <p> + Here is an excellent writeup about CBFS (coreboot filesystem): + <a href="http://lennartb.home.xs4all.nl/coreboot/col5.html">http://lennartb.home.xs4all.nl/coreboot/col5.html</a>. + </p> + <p> + <a href="index.html">Back to previous index</a> + </p> + </div> - <p> - Download the latest release from - <a href="http://libreboot.org/">http://libreboot.org/</a> - <br/><b>If you downloaded from git, refer to - <a href="../git/index.html#build_meta">../git/index.html#build_meta</a> before continuing.</b> - </p> + <div class="section"> + + <h1>Table of Contents</h1> + + <ul> + <li><a href="#getting_started">Getting started</a></li> + <li><a href="#libreboot_grub_config_ondisk">Don't want to flash a new ROM image?</a></li> + <li><a href="#build_cbfstool">Build 'cbfstool' from source</a></li> + <li><a href="#which_rom">Which ROM image should I use?</a></li> + <li><a href="#extract_grubtest">Extract grubtest from the ROM image</a> + <li> + <a href="#example_modifications">Example modifications for <i>grubtest.cfg</i></a> + <ul> + <li><a href="#example_modifications_trisquel">Trisquel GNU/Linux-libre</a></li> + <li><a href="#example_modifications_parabola">Parabola GNU/Linux-libre</a></li> + </ul> + </li> + <li><a href="#reinsert_modified_grubtest">Re-insert the modified grubtest.cfg into the ROM image</a></li> + <li><a href="#test_it">Test it!</a> + <li><a href="#final_steps">Final steps</a></li> + <li><a href="#troubleshooting">Troubleshooting</a></li> + </ul> + + </div> - <p> - <a href="../git/index.html#build_dependencies">Install the build dependencies</a>. - </p> + <div class="section"> - <p> - <a href="#pagetop">Back to top of page.</a> - </p> + <h2 id="getting_started">Getting started</h2> -<hr/> - - <h2 id="libreboot_grub_config_ondisk">Don't want to flash a new ROM image?</h2> + <p> + Download the latest release from + <a href="http://libreboot.org/">http://libreboot.org/</a> + <br/><b>If you downloaded from git, refer to + <a href="../git/index.html#build_meta">../git/index.html#build_meta</a> before continuing.</b> + </p> - <p> - There are several advantages to modifying the GRUB configuration stored in CBFS, but - this also means that you have to flash a new libreboot ROM image on your machine (some users - feel intimidated by this, to say the least). - Doing so can be risky if not handled correctly, because it can result in a bricked - machine (recovery is easy if you have the <a href="../install/bbb_setup.html">equipment</a> - for it, but most people don't). If you aren't up to that then don't worry; it is possible - to use a custom GRUB menu without flashing a new image, by loading a GRUB configuration - from a partition on the main storage instead. - </p> + <p> + <a href="../git/index.html#build_dependencies">Install the build dependencies</a>. + </p> - <p> - By default, GRUB in libreboot is configured to scan all partitions on the main storage - for /boot/grub/libreboot_grub.cfg or /grub/libreboot_grub.cfg(for systems where /boot - is on a dedicated partition), and then use it automatically. - </p> - <p> - Simply create your custom GRUB configuration and save it to <b>/boot/grub/libreboot_grub.cfg</b> - on the running system. The next time you boot, GRUB (in libreboot) will automatically switch to - this configuration file. <b>This means that you do not have to re-flash, recompile or otherwise - modify libreboot at all!</b> - </p> + <p> + <a href="#pagetop">Back to top of page.</a> + </p> + + </div> - <p> - Ideally, your distribution should automatically generate a libreboot_grub.cfg file that is written - specifically under the assumption that it will be read and used on a libreboot system that uses - GRUB as a payload. If your distribution does not do this, then you can try to add that feature - yourself or politely ask someone involved with or otherwise knowledgeable about the distribution - to do it for you. The libreboot_grub.cfg could either contain the full configuration, or it could - chainload another GRUB ELF executable (built to be used as a coreboot payload) that is located in - a partition on the main storage. - </p> + <div class="section"> - <p> - If you want to adapt a copy of the existing <i>libreboot</i> GRUB configuration and use that for the libreboot_grub.cfg file, then - follow <a href="#build_cbfstool">#build_cbfstool</a>, <a href="#which_rom">#which_rom</a> and - <a href="#extract_grubtest">#extract_grubtest</a> to get the <b><i>grubtest.cfg</i></b>. - Rename <b><i>grubtest.cfg</i></b> to <b><i>libreboot_grub.cfg</i></b> and save it to <b><i>/boot/grub/</i></b> - on the running system where it is intended to be used. Modify the file at that location however you see fit, - and then stop reading this guide (the rest of this page is irrelevant to you); <b>in libreboot_grub.cfg on disk, - if you are adapting it based on grub.cfg from CBFS then remove the check for libreboot_grub.cfg otherwise it will loop.</b>. - </p> - - <p> - <a href="#pagetop">Back to top of page.</a> - </p> - -<hr/> + <h2 id="libreboot_grub_config_ondisk">Don't want to flash a new ROM image?</h2> - <h2 id="build_cbfstool">Build 'cbfstool' from source</h2> - - <p> - If you are working with libreboot_src, then you can run <b><i>make</i></b> command in - libreboot_src/coreboot/util/cbfstool to build the <b><i>cbfstool</i></b> and <b><i>rmodtool</i></b> - executable. - </p> - <p> - Alternatively if you are working with libreboot_bin, you will find binaries under ./cbfstool/ - </p> + <p> + There are several advantages to modifying the GRUB configuration stored in CBFS, but + this also means that you have to flash a new libreboot ROM image on your machine (some users + feel intimidated by this, to say the least). + Doing so can be risky if not handled correctly, because it can result in a bricked + machine (recovery is easy if you have the <a href="../install/bbb_setup.html">equipment</a> + for it, but most people don't). If you aren't up to that then don't worry; it is possible + to use a custom GRUB menu without flashing a new image, by loading a GRUB configuration + from a partition on the main storage instead. + </p> - <p> - <a href="#pagetop">Back to top of page.</a> - </p> + <p> + By default, GRUB in libreboot is configured to scan all partitions on the main storage + for /boot/grub/libreboot_grub.cfg or /grub/libreboot_grub.cfg(for systems where /boot + is on a dedicated partition), and then use it automatically. + </p> + <p> + Simply create your custom GRUB configuration and save it to <b>/boot/grub/libreboot_grub.cfg</b> + on the running system. The next time you boot, GRUB (in libreboot) will automatically switch to + this configuration file. <b>This means that you do not have to re-flash, recompile or otherwise + modify libreboot at all!</b> + </p> -<hr/> + <p> + Ideally, your distribution should automatically generate a libreboot_grub.cfg file that is written + specifically under the assumption that it will be read and used on a libreboot system that uses + GRUB as a payload. If your distribution does not do this, then you can try to add that feature + yourself or politely ask someone involved with or otherwise knowledgeable about the distribution + to do it for you. The libreboot_grub.cfg could either contain the full configuration, or it could + chainload another GRUB ELF executable (built to be used as a coreboot payload) that is located in + a partition on the main storage. + </p> + + <p> + If you want to adapt a copy of the existing <i>libreboot</i> GRUB configuration and use that for the libreboot_grub.cfg file, then + follow <a href="#build_cbfstool">#build_cbfstool</a>, <a href="#which_rom">#which_rom</a> and + <a href="#extract_grubtest">#extract_grubtest</a> to get the <b><i>grubtest.cfg</i></b>. + Rename <b><i>grubtest.cfg</i></b> to <b><i>libreboot_grub.cfg</i></b> and save it to <b><i>/boot/grub/</i></b> + on the running system where it is intended to be used. Modify the file at that location however you see fit, + and then stop reading this guide (the rest of this page is irrelevant to you); <b>in libreboot_grub.cfg on disk, + if you are adapting it based on grub.cfg from CBFS then remove the check for libreboot_grub.cfg otherwise it will loop.</b>. + </p> - <h2 id="which_rom">Which ROM image should I use?</h2> + <p> + <a href="#pagetop">Back to top of page.</a> + </p> + + </div> - <p> - You can work directly with one of the ROM images already included in the libreboot ROM archives. For the purpose of - this tutorial it is assumed that your ROM image file is named <i>libreboot.rom</i>, so please make sure to adapt. - </p> + <div class="section"> - <p> - If you want to re-use the ROM that you currently have flashed (and running) then see - <a href="../git/index.html#build_flashrom">../git/index.html#build_flashrom</a> - and then run:<br/> - <b>$ sudo ./flashrom -p internal -r libreboot.rom</b><br/> - Notice that this is using <b>"-r"</b> (read) instead of <b>"-w"</b> (write). - This will create a dump (copy) of your current firmware and name it <b>libreboot.rom</b>. - You need to take ownership of the file. For example:<br/> - <b>$ sudo chown yourusername:yourusername libreboot.rom</b><br/> - <b># chown yourusername:yourusername libreboot.rom</b> - </p> + <h2 id="build_cbfstool">Build 'cbfstool' from source</h2> - <p> - If you currently have flashed a ROM image from an older version, it is recommended to update first: - basically, modify one of the latest ROM images and then flash it. - </p> + <p> + If you are working with libreboot_src, then you can run <b><i>make</i></b> command in + libreboot_src/coreboot/util/cbfstool to build the <b><i>cbfstool</i></b> and <b><i>rmodtool</i></b> + executable. + </p> + <p> + Alternatively if you are working with libreboot_bin, you will find binaries under ./cbfstool/ + </p> - <p> - <a href="#pagetop">Back to top of page.</a> - </p> + <p> + <a href="#pagetop">Back to top of page.</a> + </p> + + </div> -<hr/> + <div class="section"> - <h2 id="extract_grubtest">Extract grubtest.cfg from the ROM image</h2> + <h2 id="which_rom">Which ROM image should I use?</h2> - <p> - Display contents of ROM:<br/> - <b>$ ./cbfstool libreboot.rom print</b> - </p> + <p> + You can work directly with one of the ROM images already included in the libreboot ROM archives. For the purpose of + this tutorial it is assumed that your ROM image file is named <i>libreboot.rom</i>, so please make sure to adapt. + </p> - <p> - The libreboot.rom file contains your <i>grub.cfg</i> and <i>grubtest.cfg</i> files. - You should extract, modify and re-insert the copy first. grub.cfg will load first, - but it has a menu entry for switching to the copy (grubtest.cfg). - This reduces your chance of making a mistake that could make your machine unbootable (or very hard to boot). - </p> + <p> + If you want to re-use the ROM that you currently have flashed (and running) then see + <a href="../git/index.html#build_flashrom">../git/index.html#build_flashrom</a> + and then run:<br/> + <b>$ sudo ./flashrom -p internal -r libreboot.rom</b><br/> + Notice that this is using <b>"-r"</b> (read) instead of <b>"-w"</b> (write). + This will create a dump (copy) of your current firmware and name it <b>libreboot.rom</b>. + You need to take ownership of the file. For example:<br/> + <b>$ sudo chown yourusername:yourusername libreboot.rom</b><br/> + <b># chown yourusername:yourusername libreboot.rom</b> + </p> - <p> - Extract grubtest.cfg from the ROM image:<br/> - <b>$ ./cbfstool libreboot.rom extract -n grubtest.cfg -f grubtest.cfg</b> - </p> + <p> + If you currently have flashed a ROM image from an older version, it is recommended to update first: + basically, modify one of the latest ROM images and then flash it. + </p> - <p> - Now you have a grubtest.cfg in cbfstool directory. Edit it however you wish. - </p> + <p> + <a href="#pagetop">Back to top of page.</a> + </p> + + </div> - <p> - <a href="#pagetop">Back to top of page.</a> - </p> + <div class="section"> -<hr/> + <h2 id="extract_grubtest">Extract grubtest.cfg from the ROM image</h2> - <div class="important"> + <p> + Display contents of ROM:<br/> + <b>$ ./cbfstool libreboot.rom print</b> + </p> - <h2 id="example_modifications">Example modifications for <i>grubtest.cfg</i></h2> + <p> + The libreboot.rom file contains your <i>grub.cfg</i> and <i>grubtest.cfg</i> files. + You should extract, modify and re-insert the copy first. grub.cfg will load first, + but it has a menu entry for switching to the copy (grubtest.cfg). + This reduces your chance of making a mistake that could make your machine unbootable (or very hard to boot). + </p> <p> - These are some common examples of ways in which the grubtest.cfg file can be modified. + Extract grubtest.cfg from the ROM image:<br/> + <b>$ ./cbfstool libreboot.rom extract -n grubtest.cfg -f grubtest.cfg</b> </p> - <h3 id="example_modifications_trisquel">Trisquel GNU/Linux-libre</h3> + <p> + Now you have a grubtest.cfg in cbfstool directory. Edit it however you wish. + </p> - <p> - As an example, on my test system in /boot/grub/grub.cfg (on the HDD/SSD) I see for the main menu entry: - </p> - <ul> - <li><b>linux /boot/vmlinuz-3.15.1-gnu.nonpae root=UUID=3a008e14-4871-497b-95e5-fb180f277951 ro crashkernel=384M-2G:64M,2G-:128M quiet splash $vt_handoff</b></li> - <li><b>initrd /boot/initrd.img-3.15.1-gnu.nonpae</b></li> - </ul> + <p> + <a href="#pagetop">Back to top of page.</a> + </p> + + </div> - <p> - <b>ro</b>, <b>quiet</b>, <b>splash</b>, <b>crashkernel=384M-2G:64M,2G-:128M</b> and - <b>$vt_handoff</b> can be safely ignored. - </p> + <div class="section"> - <p> - I use this to get my partition layout:<br/> - $ <b>lsblk</b> - </p> + <div class="subsection"> - <p> - In my case, I have no /boot partition, instead /boot is on the same partition as / on sda1. - Yours might be different. In GRUB terms, sda means ahci0. 1 means msdos1, or gpt1, depending - on whether I am using MBR or GPT partitioning. Thus, /dev/sda1 is GRUB is (ahci0,msdos1) or - (ahci0,gpt1). In my case, I use MBR partitioning so it's (ahci0,msdos1). - 'msdos' is a GRUB name simply because this partitioning type is traditionally used by MS-DOS. - It doesn't mean that you have a proprietary OS. - </p> + <h2 id="example_modifications">Example modifications for <i>grubtest.cfg</i></h2> <p> - Trisquel doesn't keep the filenames of kernels consistent, instead it keeps old kernels and - new kernel updates are provided with the version in the filename. This can make GRUB payload - a bit tricky. Fortunately, there are symlinks /vmlinuz and /initrd.img - so if your /boot and / are on the same partition, you can set GRUB to boot from that. - These are also updated automatically when installing kernel updates from your distributions - apt-get repositories. - <b> - Note: when using <a href="http://jxself.org/linux-libre">jxself kernel releases</a>, - these are not updated at all and you have to update them manually. - </b> + These are some common examples of ways in which the grubtest.cfg file can be modified. </p> - <p> - For the GRUB payload grubtest.cfg (in the 'Load Operating System' menu entry), we therefore have (in this example):<br/> - <b>set root='ahci0,msdos1'</b><br/> - <b>linux /vmlinuz root=UUID=3a008e14-4871-497b-95e5-fb180f277951</b><br/> - <b>initrd /initrd.img</b> - </p> + <h3 id="example_modifications_trisquel">Trisquel GNU/Linux-libre</h3> + + <p> + As an example, on my test system in /boot/grub/grub.cfg (on the HDD/SSD) I see for the main menu entry: + </p> + <ul> + <li><b>linux /boot/vmlinuz-3.15.1-gnu.nonpae root=UUID=3a008e14-4871-497b-95e5-fb180f277951 ro crashkernel=384M-2G:64M,2G-:128M quiet splash $vt_handoff</b></li> + <li><b>initrd /boot/initrd.img-3.15.1-gnu.nonpae</b></li> + </ul> + + <p> + <b>ro</b>, <b>quiet</b>, <b>splash</b>, <b>crashkernel=384M-2G:64M,2G-:128M</b> and + <b>$vt_handoff</b> can be safely ignored. + </p> + + <p> + I use this to get my partition layout:<br/> + $ <b>lsblk</b> + </p> + + <p> + In my case, I have no /boot partition, instead /boot is on the same partition as / on sda1. + Yours might be different. In GRUB terms, sda means ahci0. 1 means msdos1, or gpt1, depending + on whether I am using MBR or GPT partitioning. Thus, /dev/sda1 is GRUB is (ahci0,msdos1) or + (ahci0,gpt1). In my case, I use MBR partitioning so it's (ahci0,msdos1). + 'msdos' is a GRUB name simply because this partitioning type is traditionally used by MS-DOS. + It doesn't mean that you have a proprietary OS. + </p> + + <p> + Trisquel doesn't keep the filenames of kernels consistent, instead it keeps old kernels and + new kernel updates are provided with the version in the filename. This can make GRUB payload + a bit tricky. Fortunately, there are symlinks /vmlinuz and /initrd.img + so if your /boot and / are on the same partition, you can set GRUB to boot from that. + These are also updated automatically when installing kernel updates from your distributions + apt-get repositories. + <b> + Note: when using <a href="http://jxself.org/linux-libre">jxself kernel releases</a>, + these are not updated at all and you have to update them manually. + </b> + </p> + + <p> + For the GRUB payload grubtest.cfg (in the 'Load Operating System' menu entry), we therefore have (in this example):<br/> + <b>set root='ahci0,msdos1'</b><br/> + <b>linux /vmlinuz root=UUID=3a008e14-4871-497b-95e5-fb180f277951</b><br/> + <b>initrd /initrd.img</b> + </p> + + <p> + Optionally, you can convert the UUID to its real device name, for example /dev/sda1 in this case. + sdX naming isn't very reliable, though, which is why UUID is used for most distributions. + </p> + + <p> + Alternatively, if your /boot is on a separate partition then you cannot rely on the /vmlinuz and /initrd.img symlinks. + Instead, go into /boot and create your own symlinks (update them manually when you install a new kernel update).<br/> + $ <b>sudo -s</b><br/> + # <b>cd /boot/</b><br/> + # <b>rm -rf vmlinuz initrd.img</b><br/> + # <b>ln -s <u>kernel</u> ksym</b><br/> + # <b>ln -s <u>initrd</u> isym</b><br/> + # <b>exit</b> + </p> + + <p> + Replace the underlined <b>kernel</b> and <b>initrd</b> filenames above with the actual filenames, of course. + </p> + + <p> + Then your grubtest.cfg menu entry (for payload) becomes like that, for example if / was on sda2 and /boot was on sda1:<br/> + <b>set root='ahci0,msdos1'</b><br/> + <b>linux /ksym root=/dev/sda2</b><br/> + <b>initrd /isym</b> + </p> + + <p> + There are lots of possible variations so please try to adapt. + </p> + + <h3 id="example_modifications_parabola">Parabola GNU/Linux-libre</h3> + + <p> + You can basically adapt the above. Note however that Parabola does not keep old kernels still installed, and the file names + are always consistent, so you don't need to boot from symlinks, you can just use the real thing directly. + </p> + + </div> - <p> - Optionally, you can convert the UUID to its real device name, for example /dev/sda1 in this case. - sdX naming isn't very reliable, though, which is why UUID is used for most distributions. - </p> + <p> + <a href="#pagetop">Back to top of page.</a> + </p> + + </div> - <p> - Alternatively, if your /boot is on a separate partition then you cannot rely on the /vmlinuz and /initrd.img symlinks. - Instead, go into /boot and create your own symlinks (update them manually when you install a new kernel update).<br/> - $ <b>sudo -s</b><br/> - # <b>cd /boot/</b><br/> - # <b>rm -rf vmlinuz initrd.img</b><br/> - # <b>ln -s <u>kernel</u> ksym</b><br/> - # <b>ln -s <u>initrd</u> isym</b><br/> - # <b>exit</b> - </p> + <div class="section"> - <p> - Replace the underlined <b>kernel</b> and <b>initrd</b> filenames above with the actual filenames, of course. - </p> + <h2 id="reinsert_modified_grubtest">Re-insert the modified grubtest.cfg into the ROM image</h2> - <p> - Then your grubtest.cfg menu entry (for payload) becomes like that, for example if / was on sda2 and /boot was on sda1:<br/> - <b>set root='ahci0,msdos1'</b><br/> - <b>linux /ksym root=/dev/sda2</b><br/> - <b>initrd /isym</b> - </p> + <p> + Delete the grubtest.cfg that remained inside the ROM:<br/> + <b>$ ./cbfstool libreboot.rom remove -n grubtest.cfg</b> + </p> - <p> - There are lots of possible variations so please try to adapt. - </p> + <p> + Display ROM contents and now you see grubtest.cfg no longer exists there:<br/> + <b>$ ./cbfstool libreboot.rom print</b> + </p> - <h3 id="example_modifications_parabola">Parabola GNU/Linux-libre</h3> + <p> + Add the modified version that you just made:<br/> + <b>$ ./cbfstool libreboot.rom add -n grubtest.cfg -f grubtest.cfg -t raw</b> + </p> - <p> - You can basically adapt the above. Note however that Parabola does not keep old kernels still installed, and the file names - are always consistent, so you don't need to boot from symlinks, you can just use the real thing directly. - </p> + <p> + Now display ROM contents again and see that it exists again:<br/> + <b>$ ./cbfstool libreboot.rom print</b> + </p> + <p> + <a href="#pagetop">Back to top of page.</a> + </p> + </div> - <p> - <a href="#pagetop">Back to top of page.</a> - </p> + <div class="section"> -<hr/> - - <h2 id="reinsert_modified_grubtest">Re-insert the modified grubtest.cfg into the ROM image</h2> - - <p> - Delete the grubtest.cfg that remained inside the ROM:<br/> - <b>$ ./cbfstool libreboot.rom remove -n grubtest.cfg</b> - </p> - - <p> - Display ROM contents and now you see grubtest.cfg no longer exists there:<br/> - <b>$ ./cbfstool libreboot.rom print</b> - </p> + <h2 id="test_it">Test it!</h2> - <p> - Add the modified version that you just made:<br/> - <b>$ ./cbfstool libreboot.rom add -n grubtest.cfg -f grubtest.cfg -t raw</b> - </p> - - <p> - Now display ROM contents again and see that it exists again:<br/> - <b>$ ./cbfstool libreboot.rom print</b> - </p> - - <p> - <a href="#pagetop">Back to top of page.</a> - </p> + <p> + <b> + Now you have a modified ROM. Refer back to <a href="../install/index.html#flashrom">../install/index.html#flashrom</a> for information + on how to flash it. Once you have done that, shut down and then boot up with your new test configuration. + </b> + </p> -<hr/> + <p> + Choose (in GRUB) the menu entry that switches to grubtest.cfg. If it works, then your config is safe and you can continue below. + </p> - <h2 id="test_it">Test it!</h2> + <p> + <b> + If it does not work like you want it to, if you are unsure or sceptical in any way, + then re-do the steps above until you get it right! Do *not* proceed past this point + unless you are 100% sure that your new configuration is safe (or desirable) to use. + </b> + </p> - <p> - <b> - Now you have a modified ROM. Refer back to <a href="../install/index.html#flashrom">../install/index.html#flashrom</a> for information - on how to flash it. Once you have done that, shut down and then boot up with your new test configuration. - </b> - </p> + <p> + <a href="#pagetop">Back to top of page.</a> + </p> + + </div> - <p> - Choose (in GRUB) the menu entry that switches to grubtest.cfg. If it works, then your config is safe and you can continue below. - </p> + <div class="section"> - <p> - <b> - If it does not work like you want it to, if you are unsure or sceptical in any way, - then re-do the steps above until you get it right! Do *not* proceed past this point - unless you are 100% sure that your new configuration is safe (or desirable) to use. - </b> - </p> + <h2 id="final_steps">Final steps</h2> - <p> - <a href="#pagetop">Back to top of page.</a> - </p> + <p> + Create a copy of grubtest.cfg, called grub.cfg, which is the same except for one difference: + change the menuentry 'Switch to grub.cfg' to 'Switch to grubtest.cfg' and inside it, + change all instances of grub.cfg to grubtest.cfg. This is so that the main config still + links (in the menu) to grubtest.cfg, so that you don't have to manually switch to it, in + case you ever want to follow this guide again in the future (modifying the already modified config)<br/> + $ <b>sed -e 's:(cbfsdisk)/grub.cfg:(cbfsdisk)/grubtest.cfg:g' -e 's:Switch to grub.cfg:Switch to grubtest.cfg:g' < grubtest.cfg > grub.cfg</b><br/> + </p> -<hr/> + <p> + Delete the grub.cfg that remained inside the ROM:<br/> + <b>$ ./cbfstool libreboot.rom remove -n grub.cfg</b> + </p> - <h2 id="final_steps">Final steps</h2> + <p> + Display ROM contents and now you see grub.cfg no longer exists there:<br/> + <b>$ ./cbfstool libreboot.rom print</b> + </p> - <p> - Create a copy of grubtest.cfg, called grub.cfg, which is the same except for one difference: - change the menuentry 'Switch to grub.cfg' to 'Switch to grubtest.cfg' and inside it, - change all instances of grub.cfg to grubtest.cfg. This is so that the main config still - links (in the menu) to grubtest.cfg, so that you don't have to manually switch to it, in - case you ever want to follow this guide again in the future (modifying the already modified config)<br/> - $ <b>sed -e 's:(cbfsdisk)/grub.cfg:(cbfsdisk)/grubtest.cfg:g' -e 's:Switch to grub.cfg:Switch to grubtest.cfg:g' < grubtest.cfg > grub.cfg</b><br/> - </p> + <p> + Add the modified version that you just made:<br/> + <b>$ ./cbfstool libreboot.rom add -n grub.cfg -f grub.cfg -t raw</b> + </p> - <p> - Delete the grub.cfg that remained inside the ROM:<br/> - <b>$ ./cbfstool libreboot.rom remove -n grub.cfg</b> - </p> + <p> + Now display ROM contents again and see that it exists again:<br/> + <b>$ ./cbfstool libreboot.rom print</b> + </p> - <p> - Display ROM contents and now you see grub.cfg no longer exists there:<br/> - <b>$ ./cbfstool libreboot.rom print</b> - </p> + <p> + <b> + Now you have a modified ROM. Refer back to <a href="../install/index.html#flashrom">../install/index.html#flashrom</a> for information + on how to flash it. Once you have done that, shut down and then boot up with your new configuration. + </b> + </p> - <p> - Add the modified version that you just made:<br/> - <b>$ ./cbfstool libreboot.rom add -n grub.cfg -f grub.cfg -t raw</b> - </p> + <p> + <a href="#pagetop">Back to top of page.</a> + </p> + + </div> - <p> - Now display ROM contents again and see that it exists again:<br/> - <b>$ ./cbfstool libreboot.rom print</b> - </p> + <div class="section"> - <p> - <b> - Now you have a modified ROM. Refer back to <a href="../install/index.html#flashrom">../install/index.html#flashrom</a> for information - on how to flash it. Once you have done that, shut down and then boot up with your new configuration. - </b> - </p> + <h2 id="troubleshooting">Troubleshooting</h2> - <p> - <a href="#pagetop">Back to top of page.</a> - </p> + <p> + A user reported that segmentation faults occur with cbfstool + when using this procedure depending on the size of the grub.cfg being re-insterted. + In his case, a minimum size of 857 bytes was required. This could (at the time of + this release) be a bug in cbfstool that should be investigated with the coreboot + community. If cbfstool segfaults, then keep this in mind. 'strace' (or gdb? clang?) + could be used for debugging. This was in libreboot 5th release (based on coreboot + from late 2013), and I'm not sure if the issue persists in the current releases. + I have not been able to reproduce it. strace (from that user) is here: + <a href="cbfstool_libreboot5_strace">cbfstool_libreboot5_strace</a>. + The issue has been reported by a few users, so it does not happen all the time: + this bug (if it still exists) could (should) be reproduced. + </p> -<hr/> + <p> + <a href="#pagetop">Back to top of page.</a> + </p> + + </div> - <h2 id="troubleshooting">Troubleshooting</h2> + <div class="section"> <p> - A user reported that segmentation faults occur with cbfstool - when using this procedure depending on the size of the grub.cfg being re-insterted. - In his case, a minimum size of 857 bytes was required. This could (at the time of - this release) be a bug in cbfstool that should be investigated with the coreboot - community. If cbfstool segfaults, then keep this in mind. 'strace' (or gdb? clang?) - could be used for debugging. This was in libreboot 5th release (based on coreboot - from late 2013), and I'm not sure if the issue persists in the current releases. - I have not been able to reproduce it. strace (from that user) is here: - <a href="cbfstool_libreboot5_strace">cbfstool_libreboot5_strace</a>. - The issue has been reported by a few users, so it does not happen all the time: - this bug (if it still exists) could (should) be reproduced. + Copyright © 2014, 2015 Francis Rowe <info@gluglug.org.uk><br/> + This document is released under the Creative Commons Attribution-ShareAlike 4.0 International Public License and all future versions. + A copy of the license can be found at <a href="../license.txt">../license.txt</a>. </p> <p> - <a href="#pagetop">Back to top of page.</a> + This document is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See <a href="../license.txt">../license.txt</a> for more information. </p> - -<hr/> - - <p> - Copyright © 2014, 2015 Francis Rowe <info@gluglug.org.uk><br/> - This document is released under the Creative Commons Attribution-ShareAlike 4.0 International Public License and all future versions. - A copy of the license can be found at <a href="../license.txt">../license.txt</a>. - </p> - - <p> - This document is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See <a href="../license.txt">../license.txt</a> for more information. - </p> + + </div> </body> </html> |