unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Bengt Richter <bokr@bokr.com>
To: Mathieu Othacehe <othacehe@gnu.org>
Cc: 44353@debbugs.gnu.org, Jesse Gibbons <jgibbons2357@gmail.com>,
	Maxim Cournoyer <maxim.cournoyer@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	[thread overview]
Message-ID: <20201107112617.GA2716@LionPure> (raw)
In-Reply-To: <875z6hmt4b.fsf@gnu.org>

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




  reply	other threads:[~2020-11-07 11:27 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-31 16:47 bug#44353: guix system disk-image -t raw fails with grub-efi-bootloader Jesse Gibbons
2020-11-07  7:09 ` Maxim Cournoyer
2020-11-07  9:08   ` Mathieu Othacehe
2020-11-07 11:26     ` Bengt Richter [this message]
2020-11-07 20:32     ` Maxim Cournoyer
2020-11-08 11:04       ` Mathieu Othacehe
2020-11-12  3:57         ` bug#44353: [PATCH version-1.2.0 v2 1/3] image: Remove conflicting user-provided EFI file system Maxim Cournoyer
2020-11-12  3:57           ` bug#44353: [PATCH version-1.2.0 v2 2/3] bootloader: grub: Skip install-grub-efi when producing a disk image Maxim Cournoyer
2020-11-12  8:42             ` Mathieu Othacehe
2020-11-17 18:29               ` Maxim Cournoyer
2020-11-12  3:57           ` bug#44353: [PATCH version-1.2.0 v2 3/3] doc: Detail which bootloader get used with disk-image or vm-image Maxim Cournoyer
2020-11-12  8:45             ` Mathieu Othacehe
2020-11-12 21:16               ` Ludovic Courtès
2020-11-12  8:39           ` bug#44353: [PATCH version-1.2.0 v2 1/3] image: Remove conflicting user-provided EFI file system Mathieu Othacehe
2020-11-17 18:37             ` Maxim Cournoyer
2020-11-12  7:09         ` bug#44353: [PATCH version-1.2.0 v2] guix: system: Add a new '--non-volatile' option for disk-image Maxim Cournoyer
2020-11-12  8:36           ` Mathieu Othacehe
2020-11-12 14:59             ` Maxim Cournoyer
2020-11-12 17:06               ` Mathieu Othacehe
2020-11-17 14:44                 ` Maxim Cournoyer
2020-11-12 21:18             ` Ludovic Courtès
2020-11-16  2:48               ` Maxim Cournoyer
2020-11-15 21:45           ` Ludovic Courtès
2020-11-16  3:47             ` Maxim Cournoyer
2020-11-16  9:23             ` Mathieu Othacehe
2020-11-16 13:09               ` Ludovic Courtès
2020-11-16 13:34                 ` Mathieu Othacehe
2020-11-17 20:21                   ` Maxim Cournoyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201107112617.GA2716@LionPure \
    --to=bokr@bokr.com \
    --cc=44353@debbugs.gnu.org \
    --cc=jgibbons2357@gmail.com \
    --cc=maxim.cournoyer@gmail.com \
    --cc=othacehe@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).