[PATCH 0/4] Make both EFI and non-EFI systems boot our disk images.

This is an alternative implementation of bug# 27695 without extra Guix-side

bootloader. It just extends grub-efi with a few files.

I've also added all the patches needed for it to actually work into the same

patchset.

I've tested it again with disk-image, disk-image -t iso9660, qemu with UEFI

BIOS and without UEFI BIOS. Furthermore, I tested the ISO-9660 image both

as CD and as HDD (in qemu). It all worked.

Danny Milosavljevic (4):

gnu: grub-efi: Add mtools input.

build: Allow mounting of entire disks.

gnu: grub-efi: Add grub.

install: Use grub-efi.

gnu/build/file-systems.scm | 13 ++++++++-----

gnu/packages/bootloaders.scm | 25 +++++++++++++++++++++++++

gnu/system/install.scm | 3 ++-

3 files changed, 35 insertions(+), 6 deletions(-)

(grub-efi)[inputs]: Add mtools.

[arguments]: Add phase "use-absolute-mtools-path".

---

gnu/packages/bootloaders.scm | 16 +++++++++++++++-

1 file changed, 15 insertions(+), 1 deletion(-)

---

gnu/build/file-systems.scm | 13 ++++++++-----

1 file changed, 8 insertions(+), 5 deletions(-)

[arguments]: Add phase "install-non-efi".

---

gnu/packages/bootloaders.scm | 13 ++++++++++++-

1 file changed, 12 insertions(+), 1 deletion(-)

---

gnu/system/install.scm | 3 ++-

1 file changed, 2 insertions(+), 1 deletion(-)

Hmm, what happens on non-x86 architectures that nonetheless use grub-efi (there are apparently such).

Danny Milosavljevic <dannym@scratchpost.org> writes:

[...]

Since we take machine-specific code from it, I think it must be a

regular input.

However...

I don't think we should do this in 'grub-efi'. Now users can not be

certain whether they have EFI boot or not, since grub will happily "fall

back" to i386-pc if it does not detect a UEFI system. It's a regression

of sorts.

However... The 'grub-hybrid' approach seems okay to me (although

building grub-efi again is unnecessary :)). If it works well, maybe we

could deprecate the other two GRUB packages.

FWIW Gentoo has taken the 'hybrid' approach for many years (building

once for each target platform and consolidating out/lib/grub). But it

would be good to know whether this configuration is supported upstream.

This makes the system disk-image use grub-efi all the time, also for non-ISO9660.

But I've successfully tested booting this non-ISO9660 image (which uses grub-efi) as well on a non-UEFI non-Libreboot x86.

Hi Marius,

On Mon, 17 Jul 2017 23:26:06 +0200

Marius Bakke <mbakke@fastmail.com> wrote:

No, it's not unnecessary. When you do not use this approach (for example when you create a new package which has "grub" and "grub-efi" as input) then the resulting executables (for example grub-efi's grub-mkrescue) will not find the platform support files - because the search path for multiple platforms is being hardcoded at build time.

Doesn't work:

+(define-public grub-hybrid

+ (package

+ (name "grub-hybrid")

+ (version (package-version grub-efi))

+ (inputs

+ `(("grub-efi" ,grub-efi) ; keep as first (preferred) entry

+ ("grub" ,grub)))

+ (build-system trivial-build-system)

+ (arguments

+ '(#:modules ((guix build union))

+ #:builder (begin

+ (use-modules (ice-9 match)

+ (guix build union))

+ (match %build-inputs

+ (((names . directories) ...)

+ ;; Take "lib/grub/i386-pc" from grub, the remainder

+ ;; from grub-efi.

+ (union-build (assoc-ref %outputs "out")

+ directories))))))

+ (home-page "https://www.gnu.org/software/grub/")

+ (synopsis "GRand Unified Boot loader (Hybrid version)")

+ (description "This version of GRUB tries the @code{grub-efi} and

+then the traditional @code{grub}.")))

+

I'm using it for grub-mkrescue and, there, it's definitely supported in the sense of there's explicit case analysis in the source code for it and also big structures to enable this kind of using multiple platforms.

For other uses I don't know.

I've successfully tested it using:

$ qemu-system-x86_64 -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin -m 1G -enable-kvm -cdrom Z -serial stdio

$ qemu-system-x86_64 -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin -m 1G -enable-kvm -hda Z -serial stdio

$ qemu-system-x86_64 -m 1G -enable-kvm -cdrom Z -serial stdio

$ qemu-system-x86_64 -m 1G -enable-kvm -hda Z -serial stdio

Danny Milosavljevic (4):

gnu: grub-efi: Add mtools input.

build: Allow mounting of entire disks.

gnu: Add grub-hybrid.

vm: Use grub-hybrid's grub-mkrescue.

gnu/build/file-systems.scm | 13 ++++++++-----

gnu/packages/bootloaders.scm | 36 +++++++++++++++++++++++++++++++++++-

gnu/system/vm.scm | 2 +-

3 files changed, 44 insertions(+), 7 deletions(-)

(grub-efi)[inputs]: Add mtools.

[arguments]: Add phase "use-absolute-mtools-path".

---

gnu/packages/bootloaders.scm | 16 +++++++++++++++-

1 file changed, 15 insertions(+), 1 deletion(-)

---

gnu/build/file-systems.scm | 13 ++++++++-----

1 file changed, 8 insertions(+), 5 deletions(-)

---

gnu/packages/bootloaders.scm | 20 ++++++++++++++++++++

1 file changed, 20 insertions(+)

---

gnu/system/vm.scm | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

I've successfully tested it using:

$ qemu-system-x86_64 -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin -m 1G -enable-kvm -cdrom Z -serial stdio

$ qemu-system-x86_64 -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin -m 1G -enable-kvm -hda Z -serial stdio

$ qemu-system-x86_64 -m 1G -enable-kvm -cdrom Z -serial stdio

$ qemu-system-x86_64 -m 1G -enable-kvm -hda Z -serial stdio

Danny Milosavljevic (4):

gnu: grub-efi: Add mtools input.

build: Allow mounting of entire disks.

gnu: Add grub-hybrid.

vm: Use grub-hybrid's grub-mkrescue.

gnu/build/file-systems.scm | 13 ++++++++-----

gnu/packages/bootloaders.scm | 40 +++++++++++++++++++++++++++++++++++++++-

gnu/system/vm.scm | 2 +-

3 files changed, 48 insertions(+), 7 deletions(-)

(grub-efi)[inputs]: Add mtools.

[arguments]: Add phase "use-absolute-mtools-path".

---

gnu/packages/bootloaders.scm | 16 +++++++++++++++-

1 file changed, 15 insertions(+), 1 deletion(-)

---

gnu/build/file-systems.scm | 13 ++++++++-----

1 file changed, 8 insertions(+), 5 deletions(-)

---

gnu/packages/bootloaders.scm | 24 ++++++++++++++++++++++++

1 file changed, 24 insertions(+)

---

gnu/system/vm.scm | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

(grub-efi)[inputs]: Add mtools.

[arguments]: Add phase "use-absolute-mtools-path".

---

gnu/packages/bootloaders.scm | 16 +++++++++++++++-

1 file changed, 15 insertions(+), 1 deletion(-)

---

gnu/packages/bootloaders.scm | 24 ++++++++++++++++++++++++

1 file changed, 24 insertions(+)

---

gnu/build/file-systems.scm | 13 ++++++++-----

1 file changed, 8 insertions(+), 5 deletions(-)

I've successfully tested it using:

$ qemu-system-x86_64 -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin -m 1G -enable-kvm -cdrom Z -serial stdio

$ qemu-system-x86_64 -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin -m 1G -enable-kvm -hda Z -serial stdio

$ qemu-system-x86_64 -m 1G -enable-kvm -cdrom Z -serial stdio

$ qemu-system-x86_64 -m 1G -enable-kvm -hda Z -serial stdio

Danny Milosavljevic (4):

gnu: grub-efi: Add mtools input.

build: Allow mounting of entire disks.

gnu: Add grub-hybrid.

vm: Use grub-hybrid's grub-mkrescue.

gnu/bootloader/grub.scm | 6 ++++++

gnu/build/file-systems.scm | 13 ++++++++-----

gnu/packages/bootloaders.scm | 40 +++++++++++++++++++++++++++++++++++++++-

gnu/system/vm.scm | 7 +++++++

4 files changed, 60 insertions(+), 6 deletions(-)

---

gnu/bootloader/grub.scm | 6 ++++++

gnu/system/vm.scm | 7 +++++++

2 files changed, 13 insertions(+)

Applied only this patch to master as 444f9dccc24138acf833f6fea17a8b47a776ba2b.

Pushed this patch (with minimal changes) to master as dd4b7476ec2c8c1d790f1366173a15bd6042eeee.

Pushed this patch to master as ba4de3b3ef07a95f8a610cdc5354de554b7a4a6b.

This means that these work now:

$ cp `guix system disk-image -t iso9660 gnu/system/install.scm` Z

$ qemu-system-x86_64 -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin -m 1G -enable-kvm -cdrom Z -serial stdio

$ qemu-system-x86_64 -m 1G -enable-kvm -cdrom Z -serial stdio

And these don't work (as in: guest kernel crashes because it can't find the root):

$ cp `guix system disk-image -t iso9660 gnu/system/install.scm` Z

$ chmod +w Z

$ qemu-system-x86_64 -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin -m 1G -enable-kvm -hda Z -serial stdio

$ qemu-system-x86_64 -m 1G -enable-kvm -hda Z -serial stdio

That's because "[PATCH v4 2/4] build: Allow mounting of entire disks" is not applied. What do we do about it? Should we apply it, too?

Okay I'm risking it. A big reason for magic numbers in all the common superblock types and also in the partition table is that this usecase of optional partition tables works.

I've also excessively tested it.

So I think the risk of breakage is low enough and I've pushed a variant of this patch to master as 9833bcfc08ef009b9e8b4398baa481ef65c80ad7.

I'll be obsessively checking the Guix mailing lists through the next few days - and if it causes problems I'll revert. Should I be too slow, feel free to revert 9833bcfc08ef009b9e8b4398baa481ef65c80ad7 (only; the other patches of the patchset are independent and aren't a cause of concern).

Since the modified code is part of the system generation one can select the older generation in the Grub boot menu should the new one not work.

close 27705

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Thanks for moving forward on this front!

Ludo’.