grub2: new boot loader
RFC PATCH 1/1 grub2: new boot loader
The difference between grub 0.97 and grub 2.00 is so large that it doesn't make much sense to use the same package infrastructure. In addition, this is still a bit experimental so we may not want to remove grub 0.97 right away. Therefore, grub2 is created as a new package. If it stabilizes enough before it's merged, I'll rename it to grub and remove the old grub.
Since this is not a simple version bump, I'm first posting an RFC.
This RFC only works for i386/x86_64 BIOS platforms; for the final version, the intention is to add a few other platforms as well.
There are a few FIXME/TODO items in comments.
One major controversial item is that there is a host and a target version. The host version creates the bootloader binaries for the target, but the grub installer binaries for the host. The target version also creates the bootloader binaries for the target, and the grub installer binaries for the target as well. This makes it possible to re-run grub-setup on the target.
Because the pkg-infra doesn't really support host/target split for boot loaders, I created it as a normal package instead of a bootloader. The Config.in is still included from the bootloader menu, though.
The grub2-0001-grub-setup-make-it-possible-to-specify-the-root-devi patch isn't strictly required to build grub, but it is to make it useful in the typical buildroot use case. Without it, you need root privileges to be able to install grub, even when writing to an image file.
Still todo:
- build-test with different cross toolchains
- test build on 32-bit host
- add config options for the relevant features
- review grub.200-fix_mbr_handling.patch from old grub
- review grub.300-honor_UCLIBC_HAS_LFS.patch from old grub
--- boot/Config.in | 1 + package/Config.in | 1 + package/grub2/Config.in | 10 ++ package/grub2/Config.in.host | 10 ++ ...make-it-possible-to-specify-the-root-devi.patch | 183 ++++++++++++++++++++ package/grub2/grub2.mk | 95 ++++++++++ 6 files changed, 300 insertions(+)
boot/Config.in +1 -0
@@ -5,6 +5,7 @@ source "boot/at91bootstrap3/Config.in" source "boot/at91dataflashboot/Config.in" source "boot/barebox/Config.in" source "boot/grub/Config.in" +source "package/grub2/Config.in.host" source "boot/lpc32xxcdl/Config.in" source "boot/mxs-bootlets/Config.in" source "boot/syslinux/Config.in"
package/Config.in +1 -0
@@ -206,6 +206,7 @@ source "package/fmtools/Config.in" source "package/gadgetfs-test/Config.in" source "package/gdisk/Config.in" source "package/gpsd/Config.in" +source "package/grub2/Config.in" source "package/gvfs/Config.in" if BR2_PACKAGE_BUSYBOX_SHOW_OTHERS source "package/hdparm/Config.in"
package/grub2/Config.in new file +10 -0
@@ -0,0 +1,10 @@ +config BR2_PACKAGE_GRUB2 + bool "grub2" + depends on BR2_i386 || BR2_x86_64 + help + The GRand Unified Bootloader for x86 systems. + This creates the installers that run on the target and install + into the target. Select this if you want to be able to re-install + grub on the target itself. + + http://www.gnu.org/software/grub/
package/grub2/Config.in.host new file +10 -0
@@ -0,0 +1,10 @@ +config BR2_PACKAGE_HOST_GRUB2 + bool "grub2" + depends on BR2_i386 || BR2_x86_64 + help + The GRand Unified Bootloader for x86 systems. + This creates the installers that run on the host and create a + boot loader for the target. Select this if you want to create + a bootable image on your host. + + http://www.gnu.org/software/grub/
package/grub2/grub2-0001-grub-setup-make-it-possible-to-specify-the-root-devi.patch new file +183 -0
183 lines not on this page · raw message
package/grub2/grub2.mk new file +95 -0
95 lines not on this page · raw message
Signature · 1 line
tg: (2ce5da6..) t/grub2 (depends on: master)
RFC PATCH 1/1 grub2: new boot loader
Hello Arnout,
Quoted 6 lines · Arnout Vandecappelle (Essensium/Mind)
The difference between grub 0.97 and grub 2.00 is so large that it doesn't make much sense to use the same package infrastructure. In addition, this is still a bit experimental so we may not want to remove grub 0.97 right away. Therefore, grub2 is created as a new package. If it stabilizes enough before it's merged, I'll rename it to grub and remove the old grub.
Great! Nice to see some work around Grub2. We have been lacking support for this in Buildroot since a while.
I /think/ that for now grub2 should be integrated as a separate package, as you did. We probably want to keep the legacy grub around for a while, even if we have support for grub2.
Quoted 6 lines
One major controversial item is that there is a host and a target version. The host version creates the bootloader binaries for the target, but the grub installer binaries for the host. The target version also creates the bootloader binaries for the target, and the grub installer binaries for the target as well. This makes it possible to re-run grub-setup on the target.
This looks ok, but isn't possible to make it more similar to what we have for U-Boot, i.e:
* A host package that only builds the host utilities (and not the target images)
* A target package that builds the target utilities and the target images?
Quoted 3 lines
Because the pkg-infra doesn't really support host/target split for boot loaders, I created it as a normal package instead of a bootloader. The Config.in is still included from the bootloader menu, though.
Well, the pkg-infra perfectly support host/target split for boot loaders. See package/syslinux/syslinux.mk for example.
So I would suggest to move your package in boot/grub2/, and then have boot/grub2/Config.in sourced by boot/Config.in, and boot/grub2/Config.in.host sourced by package/Config.in.host.
Or alternatively, do it like we do for U-Boot and have two completely separate things (boot/grub2 for the target images only, package/grub2-tools for the tools only), but that will duplicate some code between the two .mk file.
Quoted 5 lines
The grub2-0001-grub-setup-make-it-possible-to-specify-the-root-devi patch isn't strictly required to build grub, but it is to make it useful in the typical buildroot use case. Without it, you need root privileges to be able to install grub, even when writing to an image file.
Ok, sounds good. Any chance of getting things merged upstream, at some point?
package/grub2/grub2.mk line 73
Quoted 8 lines
package/grub2/grub2.mk new file +8
-0+# --with-platform=$(BR2_TARGET_GRUB2_PLATFORM) +# i386-efi) ;; +# x86_64-efi) ;; +# i386-pc) ;; +# i386-multiboot) ;; +# i386-coreboot) ;; +# i386-ieee1275) ;; +# i386-qemu) ;; Requires unifont in /usr!
Just curious, what does "requires unifont in /usr" means?
Other than my general comments, I don't have any others, this looks good.
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
RFC PATCH 1/1 grub2: new boot loader
Quoted 4 lines · Thomas Petazzoni
Hello Arnout,
On Tue, 16 Oct 2012 17:11:42 +0200, Arnout Vandecappelle (Essensium/Mind) wrote:
[snip]
Quoted 7 lines
Quoted 6 lines
One major controversial item is that there is a host and a target version. The host version creates the bootloader binaries for the target, but the grub installer binaries for the host. The target version also creates the bootloader binaries for the target, and the grub installer binaries for the target as well. This makes it possible to re-run grub-setup on the target.
Quoted 8 lines
This looks ok, but isn't possible to make it more similar to what we have for U-Boot, i.e:
* A host package that only builds the host utilities (and not the target images)
* A target package that builds the target utilities and the target images?
But the target images are pretty much useless without an installer
(at least for BIOS): the stage1 has to be embedded in the MBR, and IIRC stage1.5 also has to be installed somewhere outside of the filesystem. Maybe with uefi you can do something with the .img files, but I doubt it.
Also, if you build the installer, you don't necessarily want the
grub modules in the target filesystem. For instance, for an initramfs, they're useless. Or the grub stuff could be in a different partition from the rootfs (my use case).
It would be possible to split it in three parts: host installer,
target installer, and modules. At this moment, the modules are built twice. However, I don't think the build time that is saved by building the modules only once warrants the additional complexity of splitting it into three separate parts.
Quoted 6 lines
Quoted 3 lines
Because the pkg-infra doesn't really support host/target split for boot loaders, I created it as a normal package instead of a bootloader. The Config.in is still included from the bootloader menu, though.
Well, the pkg-infra perfectly support host/target split for boot loaders. See
package/syslinux/syslinux.mkfor example.
D'oh, stupid me, I added the host-syslinux myself :-)
Quoted 3 lines
So I would suggest to move your package in boot/grub2/, and then have boot/grub2/Config.in sourced by boot/Config.in, and boot/grub2/Config.in.host sourced by package/Config.in.host.
It would be boot/grub2/Config.in.host sourced by boot/Config.in, and
boot/grub2/Config.in sourced by package/Config.in.
Note that neither would install anything in $(IMAGES_DIR). Or maybe
I should put the modules dir in $(IMAGES_DIR)/grub ?
Quoted 4 lines
Or alternatively, do it like we do for U-Boot and have two completely separate things (boot/grub2 for the target images only, package/grub2-tools for the tools only), but that will duplicate some code between the two .mk file.
*That* I want to avoid. I actually would like to un-split
uboot-tools... Now you can specify a u-boot from git, and uboot-tools will be a completely different version. Not so nice if you make modifications to mkimage...
Quoted 8 lines
Quoted 5 lines
The grub2-0001-grub-setup-make-it-possible-to-specify-the-root-devi patch isn't strictly required to build grub, but it is to make it useful in the typical buildroot use case. Without it, you need root privileges to be able to install grub, even when writing to an image file.
Ok, sounds good. Any chance of getting things merged upstream, at some point?
I'll try again. The comment I got on the mailing list was:
"use grub-mkrescue".
Quoted 10 lines
package/grub2/grub2.mk line 73
Quoted 8 lines
package/grub2/grub2.mk new file +8
-0+# --with-platform=$(BR2_TARGET_GRUB2_PLATFORM) +# i386-efi) ;; +# x86_64-efi) ;; +# i386-pc) ;; +# i386-multiboot) ;; +# i386-coreboot) ;; +# i386-ieee1275) ;; +# i386-qemu) ;; Requires unifont in /usr!Just curious, what does "requires unifont in /usr" means?
It's a reminder to look at potential issues with unifont when
building that backend. (I.e., I don't remember :-)
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F