bug#44353: guix system disk-image -t raw fails with grub-efi-bootloader

[Bengt Richter]

Hi Mathieu,

On +2020-11-07 10:08:36 +0100, Mathieu Othacehe wrote:
> 
> Hello Maxim,
> 
> Thanks for your patch! It's hard to provide a reliable abstraction on
> top of all the exotic bootloader installation methods existing.
> 
> Currently, each bootloader implements two methods:
> 
> * bootloader-installer
> * bootloader-disk-image-installer
> 
> The first one is dedicated to the installation of the bootloader on a
> mounted directory, while the second one is meant to work on a disk
> device such as "/dev/sda" or directly on a disk-image.
> 
> When producing a disk-image with the "raw" type, we are always creating
> and populating an ESP partition (see raw-image-type), regardless of the
> selected bootloader. In fact, "raw" should be renamed to "hybrid-efi".
> 
> The produced image can work on machines with legacy mbr boot or with EFI
> boot. Hence, calling "install-grub-efi" like it's done while building
> the lightweight-desktop operating-system is useless and fails. The
> attached patch fixes it.
> 
> You can test it with:
> 
> --8<---------------cut here---------------start------------->8---
> qemu-system-x86_64 -m 1024 -bios $(guix build 
> ovmf)/share/firmware/ovmf_x64.bin -hda disk.img
> --8<---------------cut here---------------end--------------->8---
> 
> > +                              ;; Special case: most bootloaders can be 
> > copied
> > +                              ;; directly at some fixed location on the 
> > image
> > +                              ;; disk, but when installed to the master 
> > boot
> > +                              ;; record (MBR), GRUB requires support files
> > +                              ;; present under /boot/grub, which is 
> > handled by
> > +                              ;; its 'installer' procedure.
> >                                #:bootloader-installer
> > -                              #+(bootloader-installer bootloader)
> > +                              #+(if (eq? 'grub (bootloader-name 
> > bootloader))
> > +                                    (bootloader-installer bootloader)
> > +                                    #f)
> 
> That would prevent other bootloaders relying on this procedure to work,
> such as extlinux.
> 
> Thanks,
> 
> Mathieu

Given that writing to "raw" disks is something the dd command is often used for,
how much trouble would it be to provide an option for 
bootloader-disk-image-installer
to output a shell script with the necessary dd commands, instead of doing the 
raw writing itself?

I am imagining a tarball with separate binary block-sequence file images for 
the GPT or MBR
header blocks, the embedded boot loader or UEFI partition image, and root 
partition
etc..

I think the block-sequence images can be sliced out of the backing file of a 
loopback mount that
fdisk and mkfs.* can format as desired, unless I'm missing something.

I would like the script to use lsblk -o model,serial to identify the raw disk 
to write to,
so there is no shooting the wrong foot ;)

This is sketchy on the details, but ISTM a tarball like this would make it easy 
to prepare
a USB-accessible disk using any laptop that was in a state where it was trusted 
to do
sudo dd ... right.

If the laptop didn't have all the tools, perhaps a minimal static busybox could 
be included
in the tarball to guarantee existence of the dd and lsblk tools etc.

There might be some file content that needs to be written with file i/o after 
dd has written
the content-initialized monolith file system images. This could be interactive 
choices of alternate
hostname, passwords, or whatever.

Remember, this script is not burning a bootable installer (though it could), it 
is burning
the bootable system an installer would install.

The point of this is that it happens as the script with the dd commands 
executes on an arbitrary
laptop with a raw USB disk attached, not as initialization dialog on first boot 
of the system
whose image is being written to the USB disk.

Obviously all files should be verifiable one way or another.

Hopefully it would also make it easier to share/generate system images for 
raspberries or RISC-V ARM, etc.

I guess you could call this a shell-script derivation, meant to talk to bash/dd 
instead of the guix daemon.

Has anyone done this kind of factoring already?

TIA for comment :)
-- 
Regards,
Bengt Richter