summaryrefslogtreecommitdiffstats
path: root/docs/gnulinux/grub_cbfs.html
diff options
context:
space:
mode:
authorFrancis Rowe <info@gluglug.org.uk>2015-02-04 04:14:49 (EST)
committer Francis Rowe <info@gluglug.org.uk>2015-02-04 04:14:49 (EST)
commit4c3d46238022f0c9955ae7e8b10c9f1716dd871a (patch)
tree8639e21d93df6493d952bda5f324efbe4d89447f /docs/gnulinux/grub_cbfs.html
parent5b6f5884280657c8554035503ee2bde5d84a276c (diff)
downloadlibreboot-4c3d46238022f0c9955ae7e8b10c9f1716dd871a.zip
libreboot-4c3d46238022f0c9955ae7e8b10c9f1716dd871a.tar.gz
libreboot-4c3d46238022f0c9955ae7e8b10c9f1716dd871a.tar.bz2
Documentation: implement theme, drastically improve readability
Diffstat (limited to 'docs/gnulinux/grub_cbfs.html')
-rw-r--r--docs/gnulinux/grub_cbfs.html751
1 files changed, 387 insertions, 364 deletions
diff --git a/docs/gnulinux/grub_cbfs.html b/docs/gnulinux/grub_cbfs.html
index c22d71d..73cce0c 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 &quot;flat&quot;; 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 &quot;flat&quot;; 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>&quot;-r&quot;</b> (read) instead of <b>&quot;-w&quot;</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>&quot;-r&quot;</b> (read) instead of <b>&quot;-w&quot;</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' &lt; grubtest.cfg &gt; 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' &lt; grubtest.cfg &gt; 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 &copy; 2014, 2015 Francis Rowe &lt;info@gluglug.org.uk&gt;<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 &copy; 2014, 2015 Francis Rowe &lt;info@gluglug.org.uk&gt;<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>