From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 6DZXOZGEpl+dKgAA0tVLHw (envelope-from ) for ; Sat, 07 Nov 2020 11:27:13 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id oFIZNZGEpl/aTwAAB5/wlQ (envelope-from ) for ; Sat, 07 Nov 2020 11:27:13 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 78F1C940415 for ; Sat, 7 Nov 2020 11:27:13 +0000 (UTC) Received: from localhost ([::1]:45204 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kbMND-0003dE-8P for larch@yhetil.org; Sat, 07 Nov 2020 06:27:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42160) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kbMN4-0003d1-J6 for bug-guix@gnu.org; Sat, 07 Nov 2020 06:27:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:46467) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kbMN4-0007pp-9g for bug-guix@gnu.org; Sat, 07 Nov 2020 06:27:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kbMN4-0000bs-4R for bug-guix@gnu.org; Sat, 07 Nov 2020 06:27:02 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#44353: guix system disk-image -t raw fails with grub-efi-bootloader Resent-From: Bengt Richter Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 07 Nov 2020 11:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44353 X-GNU-PR-Package: guix X-GNU-PR-Keywords: patch To: Mathieu Othacehe Received: via spool by 44353-submit@debbugs.gnu.org id=B44353.16047483932310 (code B ref 44353); Sat, 07 Nov 2020 11:27:02 +0000 Received: (at 44353) by debbugs.gnu.org; 7 Nov 2020 11:26:33 +0000 Received: from localhost ([127.0.0.1]:58013 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kbMMb-0000bB-An for submit@debbugs.gnu.org; Sat, 07 Nov 2020 06:26:33 -0500 Received: from imta-35.everyone.net ([216.200.145.35]:42178 helo=imta-38.everyone.net) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kbMMY-0000b0-Q3 for 44353@debbugs.gnu.org; Sat, 07 Nov 2020 06:26:31 -0500 Received: from pps.filterd (m0004961.ppops.net [127.0.0.1]) by imta-38.everyone.net (8.16.0.43/8.16.0.43) with SMTP id 0A7BNIHf007045; Sat, 7 Nov 2020 03:26:29 -0800 X-Eon-Originating-Account: fiUT2joAYjUzXTAaTB-qmLr3EftolQn-JjN6imnY_yg X-Eon-Dm: m0116952.ppops.net Received: by m0116952.mta.everyone.net (EON-AUTHRELAY2 - 5a81d734) id m0116952.5f8a0279.40ccae; Sat, 7 Nov 2020 03:26:28 -0800 X-Eon-Sig: AQMHrIJfpoRkNV5LJQIAAAAE,c7fe6215c83ccf5adc1636fab38e444e X-Eip: QqnzLoCV_-wcll0pc2Ah_rlu2vDYpIWN0KE7F-OgQTo Date: Sat, 7 Nov 2020 12:26:17 +0100 From: Bengt Richter Message-ID: <20201107112617.GA2716@LionPure> References: <1e589f3b-47f8-fd53-b750-d2beff8d91f5@gmail.com> <87lffdtzh1.fsf@gmail.com> <875z6hmt4b.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <875z6hmt4b.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-07_04:2020-11-05, 2020-11-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 mlxlogscore=999 spamscore=0 phishscore=0 mlxscore=0 suspectscore=0 bulkscore=0 priorityscore=1501 impostorscore=0 clxscore=1034 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011070075 X-Spam-Score: -0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.4 (-) X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Bengt Richter Cc: 44353@debbugs.gnu.org, Jesse Gibbons , Maxim Cournoyer Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Spam-Score: 0.99 X-TUID: 8oTdNRwuXw5y 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