Comments

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
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
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(+)

Hello Arnout,
On Tue, 16 Oct 2012 17:11:42 +0200, Arnout Vandecappelle
(Essensium/Mind) wrote:
> 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.
> 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?
> 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.
> 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?
> +# --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

On 16/10/12 19:40, Thomas Petazzoni wrote:
> Hello Arnout,>> On Tue, 16 Oct 2012 17:11:42 +0200, Arnout Vandecappelle> (Essensium/Mind) wrote:
[snip]
>> 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?
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.
>> 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.
D'oh, stupid me, I added the host-syslinux myself :-)
> 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 ?
> 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...
>> 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".
>> +# --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