From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Mathieu Othacehe <othacehe@gnu.org>
Cc: 44353@debbugs.gnu.org, Jesse Gibbons <jgibbons2357@gmail.com>
Subject: bug#44353: guix system disk-image -t raw fails with grub-efi-bootloader
Date: Sat, 07 Nov 2020 15:32:49 -0500 [thread overview]
Message-ID: <877dqwucum.fsf@gmail.com> (raw)
In-Reply-To: <875z6hmt4b.fsf@gnu.org> (Mathieu Othacehe's message of "Sat, 07 Nov 2020 10:08:36 +0100")
Hello Mathieu!
Mathieu Othacehe <othacehe@gnu.org> writes:
> 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.
Thank you for the clarifications!
> You can test it with:
>
> qemu-system-x86_64 -m 1024 -bios $(guix build
> ovmf)/share/firmware/ovmf_x64.bin -hda disk.img
Thank you! I hadn't realized that the default SeaBIOS BIOS used by QEMU
wasn't EFI-capable! The image now boots, but fails bringing up its file
systems for some reason. Perhaps I'm supposed to edit the file system
definitions of the template before use?
Here's how I tested it:
$ time ./pre-inst-env guix system disk-image
gnu/system/examples/lightweight-desktop.tmpl --verbosity=2 --no-offload
That took 38 minutes on my system and produced /gnu/store/...-disk-image.
$ cp /gnu/store/...-disk-image /tmp/lightweight-desktop.img
$ chmod +rw /tmp/lightweight-desktop.img
Then I tried running it with the suggested command:
$ qemu-system-x86_64 -m 1024 -bios $(guix build
ovmf)/share/firmware/ovmf_x64.bin -hda /tmp/lightweight-desktop.img
>> + ;; 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.
I pondered about such solution, but when I verified the bootloaders
under gnu/bootloaders, it appeared that *only* the install-grub
procedure supported being passed #f as its mount point; the others would
fail because of the unexpected #f boolean value.
For example, the install-extlinux procedure from (gnu bootloaders
extlinux):
--8<---------------cut here---------------start------------->8---
(define (install-extlinux mbr)
#~(lambda (bootloader device mount-point)
(let ((extlinux (string-append bootloader "/sbin/extlinux"))
(install-dir (string-append mount-point "/boot/extlinux"))
(syslinux-dir (string-append bootloader "/share/syslinux")))
(for-each (lambda (file)
(install-file file install-dir))
(find-files syslinux-dir "\\.c32$"))
(invoke/quiet extlinux "--install" install-dir)
(write-file-on-device (string-append syslinux-dir "/" #$mbr)
440 device 0))))
--8<---------------cut here---------------end--------------->8---
Would break if device was set to #f, as is done in (guix build image)'s
initialize-efi-partition:
--8<---------------cut here---------------start------------->8---
(when bootloader-installer
(display "installing bootloader...\n")
(bootloader-installer bootloader-package #f root))
--8<---------------cut here---------------end--------------->8---
Is my analysis correct? If so, the patch I sent yesterday would fix the
problem more thoroughly.
Thank you,
Maxim
next prev parent reply other threads:[~2020-11-07 20:33 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
2020-11-07 20:32 ` Maxim Cournoyer [this message]
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=877dqwucum.fsf@gmail.com \
--to=maxim.cournoyer@gmail.com \
--cc=44353@debbugs.gnu.org \
--cc=jgibbons2357@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).