GNU bug report logs - #44353
guix system disk-image -t raw fails with grub-efi-bootloader

Previous Next

Full log

View this message in rfc822 format

From: Bengt Richter <bokr <at> bokr.com>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: 44353 <at> debbugs.gnu.org, Jesse Gibbons <jgibbons2357 <at> gmail.com>, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: bug#44353: guix system disk-image -t raw fails with grub-efi-bootloader
Date: Sat, 7 Nov 2020 12:26:17 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.