From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 2A1kKbTZzmDkBgEAgWs5BA (envelope-from ) for ; Sun, 20 Jun 2021 08:01:24 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id sP7RJLTZzmCVYwAA1q6Kng (envelope-from ) for ; Sun, 20 Jun 2021 06:01:24 +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 102038093 for ; Sun, 20 Jun 2021 08:01:23 +0200 (CEST) Received: from localhost ([::1]:60516 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1luqWI-0004sz-Aj for larch@yhetil.org; Sun, 20 Jun 2021 02:01:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49082) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1luqW5-0004so-Rl for guix-devel@gnu.org; Sun, 20 Jun 2021 02:01:09 -0400 Received: from imta-36.everyone.net ([216.200.145.36]:35532 helo=imta-38.everyone.net) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1luqW0-0003he-QD for guix-devel@gnu.org; Sun, 20 Jun 2021 02:01:09 -0400 Received: from pps.filterd (omta002.sj2.proofpoint.com [127.0.0.1]) by imta-38.everyone.net (8.16.0.43/8.16.0.43) with SMTP id 15K5wsUK018476; Sat, 19 Jun 2021 23:00:55 -0700 X-Eon-Originating-Account: VJQfOI2Ivlq9sEBDmvxJ2D9bnr6SqnddC4M4TD0HcNY X-Eon-Dm: m0116952.ppops.net Received: by m0116952.mta.everyone.net (EON-AUTHRELAY2 - 5a81df73) id m0116952.60b70713.164bed; Sat, 19 Jun 2021 23:00:53 -0700 X-Eon-Sig: AQMHrIJgztmV8kRIAQIAAAAE,d6a3069b662c2892911144acd3f9889a X-Eip: dldMEdpwmb5n9yoTtyzvYG9x7KElNyrKv-t_-g0USzM Date: Sun, 20 Jun 2021 08:00:45 +0200 From: Bengt Richter To: Stefan Subject: Re: Supporting *multiple* bootloaders for arm64 on a single install? Message-ID: <20210620060045.GA10542@LionPure> References: <87y2bmznak.fsf@ponder> <20210619140050.0715df69@scratchpost.org> <6577B35F-1261-4EFF-81E4-E531A3FD6930@vodafonemail.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6577B35F-1261-4EFF-81E4-E531A3FD6930@vodafonemail.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-Proofpoint-GUID: ElMytvS2GkCE18yzgjNe2-PWLdboz4Tp X-Proofpoint-ORIG-GUID: ElMytvS2GkCE18yzgjNe2-PWLdboz4Tp X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-19_14:2021-06-18, 2021-06-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 lowpriorityscore=0 spamscore=0 bulkscore=0 adultscore=0 mlxscore=0 suspectscore=0 mlxlogscore=999 clxscore=1034 impostorscore=0 malwarescore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106200039 Received-SPF: pass client-ip=216.200.145.36; envelope-from=bokr@oz.net; helo=imta-38.everyone.net X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Bengt Richter Cc: Vagrant Cascadian , guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1624168884; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=J8gS2MypwnheiWS7dzcp4cbukjAUaE8vU8sawGVWESg=; b=Cj+MxlHYieF1DRBqXYWlsBBp7YXzjKoM3R2J14W8+ZjcMoU992Jxgxa3VqPaMnuerw38GM q1h9CsviVg1Co1UHTvZTK/6zruTuOymzpsqqgAKI/WnbC2XgyvRoVxPIHJoobkukRcZ3wp +sZCQOh4hToSIs1dP0CZHC+b4gRRDcaRga6wTAbe/J52I2J2ipkjp2PoST8xWfbMtS65Om e8bHA7gfGsDx4Ey76exnnJxwYeGHUHR7BfQuHk3V9jR2VFV0gkGkT9N9rnAwp0dlJskDAC 9SLdU8coTK5yPfvD3LPaGeSu02RYOZoryuqza0X1Ty1w3BTYaXGeVlSD3TI/eA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1624168884; a=rsa-sha256; cv=none; b=PRNuojytSYn1w9mUwSAfk/Vt3x1pvZpAxg4xusGziBcxIlHdA1F8gC+O7wNCYYwtr+Pt5n 70qfyFcpzSljyQbj8h67GeA+7qTRGU6pDOmeePkcU8QjXml9xaxYhnB/dC4x7pQ/X1YlQP 28IX9P7nSyKoULyVkIkKLGOAP8zmgjKzJ/16ZDv8VR/Id5MYiV/8acaLQD48FYVaSkS54t jmTC4Wmmr9F2Y4A0PFmlgjdr7xQPYtgBLFTSLmFscNCLAug+jKm9BHJkbTDPTG3HQ1lzTE AwGrjtYTE/Wvr3l5bkFFew7JW2coLrusapNM/wFtkvFpf9ZlLFSQ1nwmVfd5uQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -0.92 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 102038093 X-Spam-Score: -0.92 X-Migadu-Scanner: scn0.migadu.com X-TUID: P1IM0oYGvogH Hi Stefan, et al, On +2021-06-19 17:11:45 +0200, Stefan wrote: > Hi! > > >> But as I understand it, guix only supports a single bootloader entry. > > > > That is correct. > > > >> To support all of the above, I would need three separate bootloader > >> instances... one for Pinebook, one for Pinebook Pro, and lastly a > >> grub-efi bootloader. > > > > Stefan wrote a Guix chain bootloader that is in master--but it's meant > > to be only used for bootloaders where there is a primary "bare-metal-loaded" > > bootloader and the others are chain-loaded one-after-another from ONE filesystem > > (for example Raspberry Pi and/or EFI bootloaders). > > > > (It's currently used in order to use an EFI bootloader hosted on NFS--which > > is an awesome way to manage embedded boards) > > > > The chain bootloader itself is one Guix bootloader. > > > > I advise you to search for mails by Stefan on the guix-devel mailing list--those > > are very illuminating. > > By the way, there is since a month meanwhile, which now makes the support for the Raspberry Pi complete. The same bootloader can be used for an NFS root installation and an installation on micro SD card or an USB drive by just changing the mount point of the root file-system. > > Danny, I’d appreciate your review very much. This time you can apply the patches and just use the gnu/system/examples/raspberry-pi-64.tmpl with guix system init. :-) > > >> And somewhere along the way I've lost track of how we get to > >> install-pinebook-pro-rk3399-u-boot… > > The same happened to me. I’ll first wait for the patch #48314 to be accepted, before I’ll look again into creating a disk image for the Raspberry Pi. > > > If you do want to chainload grub-efi eventually, that's supported in Guix master, > > see "efi-bootloader-chain". It's meant for the end user to be able to use. > > Referring to the patch #48314, the efi-bootloader-chain got simplified. It basically prepares a profile with all files to be copied as is, no special “collection” folder any more. And the installer of the grub-efi-netboot-(removable-)bootloader is now merely a simple “(copy-recursively bootloader-profile)“ procedure. > > >> A related idea would be to generate an EFI bootable image with > >> sufficient emtpy space before the first partition (16MB) and then one > >> could manually install the appropriate u-boot, maybe with some helper > >> scripts to avoid having to do it completely manually... > > > > Yeah, that's possible right now. After all, you don't have to load the generated > > guix system disk image on bare metal. Just boot it in qemu and install u-boot > > there for example. Or even edit the image manually by using dd. (unfortunately, > > on almost every ARM system I set up Guix on so far, one or both of those were > > necessary) > > I believe that the ARM future is UEFI, like on PCs. A lot of distributions already chainload U-Boot and GRUB an arm systems. There is a specification for ARM servers which demands UEFI¹. And there is even the choice between U-Boot and TianoCore/EDK II. > > I think meanwhile that it would be beneficial, if, beside a bootloader field, Guix would accept an optional firmware field. Then the U-Boot or TianoCore/EDK II (or coreboot) could become some board specific firmware, and the actual bootloader would be grub-efi installed on an EFI System Partition. For systems like the Raspberry, which require their firmware on a FAT partition, there is the already working efi-bootloader-chain solution. > > The firmware could only be installed on explicit request. It's not expected to see frequent changes – every re-installation is a risk to brick the system. (For my taste the bootloader is re-installed too often already.) > What form would a "firmware field" take? On principle, I am against boundless _incorporation_ of new dangerous capabilities into a piece of software, as opposed to incoporating the ability to chain-load or otherwise encapsulate execution of a single-purpose, minimal-source-for-better-inspection-and-exclusion-of-attacks-piece-of-software that does something dangerous. ISTM UEFI is way more complicated than booting needs to be. What does the boot process need to do besides (after post) identify a series of untrusted(!) block stream sources to try, load the first image whose secure hash either matches a white list -- or securely display the hash of the unrecognized image and ask authorized operator for ok + hash nickname for inclusion in the whitelist or reject? If ok, jump into boot image as normal. If a developer I trust says (in a securely communicated way) that I can safely load something with a hash of whatever, I think that is more trustworthy than pretty much anything else I can think of. And on a forum, someone else can say, "Don't trust that thing with hash xxx...zzz, it blew up for me," and I can hold off until there's a consensus. WDYT? BTW, why not build multiple installer ISOs targeted for different architectures, and specialized needs? (for smaller ISOs and other benefits). I assume one could already do this with guix, but why not leave the whole ball-of-wax to git clone, and let people with common architectures have less to download and less irrelevant-to-them choices? > > Bye > > Stefan > > > ¹ -- Regards, Bengt Richter