From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id DB6F4158041 for ; Fri, 23 Feb 2024 12:07:17 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E1077E2A19; Fri, 23 Feb 2024 12:07:09 +0000 (UTC) Received: from bumble.maple.relay.mailchannels.net (bumble.maple.relay.mailchannels.net [23.83.214.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CC530E29FF for ; Fri, 23 Feb 2024 12:07:08 +0000 (UTC) X-Sender-Id: thundermail|x-authsender|confabulate@kintzios.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 95FE5903016 for ; Fri, 23 Feb 2024 12:07:07 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1708690026; a=rsa-sha256; cv=none; b=O+M0JlSAw/WPC/FrcAcwco+DlwfmppNFz4HAwHBxYqeQevNX6f7T7c24TlMXz7v52NWgK6 2D6/hXUJTv1AsXr+ngmfGcNR/sz2a8XcS1nuBlpCWlagLnoAWw+MLKgQ9FsbaOVVYoq3Cu wfZh1JchGJ+hZv0zrfNg//FSHHQjYGPJjlCd7uZxBet5IzwzK8AYWfU1+TmYuVDZ7jy6CF p7jFMnaapzdw0My/gE9Zb2WyxQmUd1AD6nlTY68gAlAThXkjsR4DINtjFnLMXWRdL8PZLD atq+990eCa7YzCFUwUcj+ob4RaOg+Ial+Mm+FOC8H+SYHy9K1hhAMcAWUR9Wnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1708690026; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:dkim-signature; bh=4wVCMysWtDa9nNTVxhZJhKNpiUVgQW4QrypjBhwYTmw=; b=f0V6/rVMuxI6AfXUFb3gvJrRX5JodlKl1sSCHBesvYYByAyIlX7luoGg60WTaKpa0eoeJD T8KBkeu7lrfmb5h29EhDIzKpnMDZI2d27EGfxYkFV/81DBJAWvY9ZEfM9WJTatRar70axr kUAZxaHHZh4OlpnEjdrsYQzu6h4JSszAjKYCr99WFgcthG37CQw8LFx/0+jH7iVmYPwzan Q9PtWFLbjcGSyHVUcisRmyoc6/PmJ+cGkns8hhhAqj4Pmg+F9qNoiX4Vhe/r5gGpOf1UhL Veid+HiBfJWlhFHGuW/Z71W2n/WDzGDmBwZXpNt62CTO6ARTETDActc28x0F1A== ARC-Authentication-Results: i=1; rspamd-6bdc45795d-kh9tz; auth=pass smtp.auth=thundermail smtp.mailfrom=confabulate@kintzios.com X-Sender-Id: thundermail|x-authsender|confabulate@kintzios.com X-MC-Relay: Neutral X-MailChannels-SenderId: thundermail|x-authsender|confabulate@kintzios.com X-MailChannels-Auth-Id: thundermail X-Power-Attack: 7f3ea9df70f69ef8_1708690027093_1417271919 X-MC-Loop-Signature: 1708690027093:1792009955 X-MC-Ingress-Time: 1708690027092 Received: from mailclean11.thundermail.uk (mailclean11.thundermail.uk [149.255.60.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.119.153.122 (trex/6.9.2); Fri, 23 Feb 2024 12:07:07 +0000 Received: from cloud220.unlimitedwebhosting.co.uk (cloud220.unlimitedwebhosting.co.uk [149.255.60.183]) by mailclean11.thundermail.uk (Postfix) with ESMTPS id 466F44025F for ; Fri, 23 Feb 2024 12:07:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kintzios.com; s=default; t=1708690021; bh=4wVCMysWtDa9nNTVxhZJhKNpiUVgQW4QrypjBhwYTmw=; h=From:To:Subject; b=JrVmARaAt4nd9YiQUhg9dD3WRB2OhucsL803rKdZ30bW4ndKdmvxSvRQKWwH1BE6f u8URjmuoe0GvpBDE7XO7OZhr5xJacg0iMpJQmz5BNfakjzS0Ee8DQ7AmA1feBr0de3 Tu9hyeDmfXYrtC/LhT/fEbVc8NHZk5qHIV7B+8ik= From: Michael To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: How to set up drive with many Linux distros? Date: Fri, 23 Feb 2024 12:06:44 +0000 Message-ID: <2797401.BEx9A2HvPv@rogueboard> In-Reply-To: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart15126574.tv2OnDr8pf"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-PPP-Message-ID: <170869002170.45171.10286730215487127943@cloud220.unlimitedwebhosting.co.uk> X-PPP-Vhost: kintzios.com X-Rspamd-Queue-Id: 466F44025F X-Rspamd-Server: mailclean11 X-Spamd-Result: default: False [-0.61 / 999.00]; SIGNED_PGP(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_NOT_FQDN(0.50)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; ONCE_RECEIVED(0.10)[]; MX_GOOD(-0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_POLICY_ALLOW(0.00)[kintzios.com,none]; FROM_HAS_DN(0.00)[]; R_DKIM_ALLOW(0.00)[kintzios.com:s=default]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FUZZY_BLOCKED(0.00)[rspamd.com]; DKIM_TRACE(0.00)[kintzios.com:+]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_NONE(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[gentoo-user@lists.gentoo.org]; R_SPF_ALLOW(0.00)[+mx]; NEURAL_HAM(-0.00)[-0.987]; ASN(0.00)[asn:34931, ipnet:149.255.60.0/22, country:GB]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[confabulate@kintzios.com] X-Rspamd-Action: no action X-Archives-Salt: d92e65e8-2233-4732-8e75-b3ce653e19c9 X-Archives-Hash: 91365864d8af99feaec13b6e5cecebcb --nextPart15126574.tv2OnDr8pf Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Michael To: gentoo-user@lists.gentoo.org Reply-To: confabulate@kintzios.com Date: Fri, 23 Feb 2024 12:06:44 +0000 Message-ID: <2797401.BEx9A2HvPv@rogueboard> In-Reply-To: MIME-Version: 1.0 On Friday, 23 February 2024 00:28:59 GMT Grant Edwards wrote: > On 2024-02-22, Wol wrote: > > On 22/02/2024 21:45, Grant Edwards wrote: > >> I've been reading up on UEFI, and it doesn't seem to be any > >> better. People complain about distro's stomping on each other's files > >> in the ESP partiton and multiple distro's using the same name in the > >> boot slots stored in NVM. And then the boot choice order changes > >> (though it may not be apparent to the naked eye) when one of the > >> distros decides to update/reinstall its boot stuff. > > > > At least if you use UEFI *as* your bootloader, then that won't > > happen. That assumes you're using UEFI, though! > > According to what I've read UEFI isn't a bootloader. It's a boot > manager which can load and run EFI bootloaders (of which there can be > multiple installed). The UEFI firmware of the MoBo contains its own bootloader and a boot manager with its own boot menu, initialised and running from the MoBo's EEPROM. Unlike conventional/legacy bootloaders stored in the first sector of a disk (MBR), the UEFI firmware is stored in the MoBo's EEPROM, a larger equivalent to the old CMOS. However, this comes with the caveat the UEFI 'bootloader' can only load .efi executables which have already been placed in the FAT32 formatted EFI System Partition (ESP). Unlike GRUB's MBR Stage 1 bootloader code, the UEFI firmware is large enough to contain its own fs driver to be able to read the ESP fs content and identify and run all .efi applications. Kernel images which have been built with the EFI stub and therefore masquerade as .efi compatible files can be loaded directly by the UEFI firmware without the need of an additional bootloader. > > In which case, 's bootloader doesn't get a look-in. > > Yes, AFAICT, it does (sometimes?). When you install under > UEFI it installs EFI bootloader files (either kernels wrapped in EFI > bootloader executables or the grub EFI bootloader) in the EFI Systgem > Partition (ESP), and then adds one or more entries in the EFI NVM that > points to those files (or something like that). The Linux UEFI > systems I have all still use grub2 (which gets written to the ESP). Legacy GRUB on an MBR partitioned disk, writes its Stage 1 bootloader code in the first sector and Stage 1.5 with the fs drivers in sector 34, before the first partition. GRUB2 on a UEFI system installs the file /efi//grubx64.efi in the ESP, an equivalent of the Stage 1 and Stage 1.5 of legacy GRUB. The Stage 2 /boot/ grub/ files can be installed either in the ESP, or on a different partition. > It's entirely possible for one distro to overwrite files in the ESP > that belong to other distros. I've read multiple complaints about > exactly that when trying to do multi-boot with UEFI. In practice it's > just like the fight over who owns the MBR and the DOS disklable gap. It doesn't really matter if the grubx64.efi executable is overwritten, as long as the OS_PROBER is not disabled in /etc/default/grub. Re-running grub- mkconfig will re-scan the ESP and any drive/partitions, pick up any OS kernel images known by GRUB and add them to GRUB's boot menu. The problem starts if/when kernel images are overwritten by successive Linux OS distros. This is likely when derivatives of the same main distros e.g. Ubuntu all create a directory called /EFI/ubuntu/ in the ESP and drop their kernels & initrd images in there potentially overwriting other distro's files. > One recipe I read about for doing what I wanted to do with UEFI > involved installing a Linux distro (didn't really matter which), then > installing rEFInd. After that, some manual renaming and deleting of > the files in the ESP was required. Then he started installing various > distros. After each distro installation, the author had to re-install > rEFInd, and after many of them he had to manually remove or rename > files in the ESP (or adjust the rEFInd config file). > > And in the end, he ended up with multiple menu entries (for different > installations) that had identical names. The concept of one bootloader/manager ruling them all is broadly the same whether you use rEFInd or GRUB, as are the hoops you have to jump through to accommodate distros' automated/hardcoded installation scripts. When using a distro's installer menu on a legacy BIOS MoBo you can select a partition (PBR) to install GRUB, but GRUB will complain and suggest you could use blocklists but it is unreliable. Last time I received an error like this, I installed grub in a PBR manually with the '--force' option, without using the installer GUI. After that, whenever I updated GRUB it complained again about blocklists, but it worked fine. > It was more complicated and difficult than my current scheme. > > > As for "'s obviously superior bootloader", well > > is using the exact same boot-loader, and when IT installs, how is it > > going to be able to boot if it can't call 's boot > > loader because it's just trashed it by overwriting it? > > In my experience, 's bootloader does not boot other > installations by calling other bootloaders. It does so by rummaging > through all of the other partitions looking for kernel images, intird > files, grub.cfg files, etc. It then adds menu entries to the config > file for 's bootloader which, when selected, directly load the > kernel image and initrd from those other partitions. Sometimes, it > works -- at least until those other installations get updated without > the knowlege of the distro that currently "owns" the MBR's bootloader > config. Then it stops working until you tell that bootloader to re-do > it's rummaging about routine. > > > To me, you seem to be describing the *default* installer setup, that's > > been there for ever. Last I installed SUSE, iirc I had to specify > > "advanced bootloader installation", most of who's options I didn't even > > understand!, but it did do what I told it to (apart from not recognising > > my weird disk stack!). > > So SuSe still allows you to install grub to a partition instead of > MBR? That's encouraging. RH and Ubuntu used to allow that, but AFAIK, > now they do not. > > > If you can find, and understand!, that advanced options, I think > > you'll find you can do what you want. > > I'd welcome pointers to where those advanced options are in the RH and > Ubunutu installers -- I've searched everywhere I can think of. Various > things Google has found lead me to believe that they no longer support > installing grub in a partition. Try using '--force' to make GRUB install its image in some distro's boot/root partition PBR instead of the disk MBR, but you'll probably have to perform this outside the installer script. I've done this with VMs. > I guess I'll stick with my current setup. > > Or perhaps I'll switch from a DOS disklabel to a GPT disklabel. > Instead of backing up and restoring the MBR and the gap, I would > backup and restore the MBR and the BIOS boot partition. And I could > use UUIDs and partition labels. These days I use disks with GPT even on MoBos with legacy BIOS. Instead of backing up and restoring the MBR/BIOS Boot Partition you could just reinstall grub and run grub-mkconfig, as long as the latter involves fewer key-presses. ;-) It goes without saying a backup before messing up with GRUB will save the day in case files are inadvertently overwritten. --nextPart15126574.tv2OnDr8pf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmXYilQACgkQseqq9sKV ZxmJ8hAAg8xdBLbqlFRH79sL4FJhzuSfNax3sisYZwPQ6xuYXwrfG1vcNO5hibdd c7hwaiDkgwoAwGnDD9qXER1o8BLDfGLuBmlshivI0QR74dycbzpqFS0GoyG8JiTB xo0I0ry97O8DUuVubtF9vMVnMKppCCoN+kztEXaa4WI/CYMhXAHel1PAhbm9McRs MfGgWb45U3QYtD75ecqarXskZ2IttWm/r3C3vnzJBjeUXTx0i3Zk4LhIP2OTV66/ ldyk1W4PImubFnqlFAxcyYw0okyKm5B7Bpd3O5HlPF90QTMxuiQPhlvFGTHuhaIj swDLzL/jj+gre6pfR/RCVThiNhlzwC+Mx3GUegcQybQU213CUALhjgqY0lCt0aDW iSbLpy1B1osE+R7nW6JaBGIuxCJ2bgCfJH+nbBIK32QeBNXNPm/yo+yaoFM4WGdt QIHHeiksy8fmW/O+9bhCtNVlQePIRHbFRe7RQ6+cVD7i0J2hCo8AjRIpl2C38ZIS DzvuF+n5GLalMrZPtecaczpCOIRl1jj7IvKQBUmv3piiYR6sHoaEFz2joBfloJcy Ccp7QtixW2dphUuO9m+tlDhx/RPy5Y6qgfZxLRKihI/bn9ljRP+5lkK5YbwKMket rXmMqCEJqu86ecHEs0QN265Bu4A3BnjJhs9fwYPMm3XVJFa2G2Q= =1AJL -----END PGP SIGNATURE----- --nextPart15126574.tv2OnDr8pf--