GNU bug report logs - #48172
support split /boot partition

Previous Next

To reply to this bug, email your comments to 48172 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: Joshua Branson <jbranso <at> dismail.de>, Vladilen Kozin
 <vladilen.kozin <at> gmail.com>
Cc: help-guix <at> gnu.org
Subject: support split /boot partition
Date: Sun, 02 May 2021 14:16:24 -0700

[Message part 1 (text/plain, inline)]

On 2021-04-30, Joshua Branson wrote:
> Vladilen Kozin <vladilen.kozin <at> gmail.com> writes:
>> Is there a way out of this predicament? I can see two options.
>> (1) can some Linux distro/bootloader do the FreeBSD trick: start on
>> USB but then chain-boot Guix off that SSD? IIUC grub's chain-boot is
>> of no help here, cause it simply won't even see that drive;
>> (2) install and run Guix off USB but somehow ensure that "IO heavy"
>> bits are mounted from that SSD. There's gotta be some (file-systems
>> ...) combined with the way I `guix system init config.scm /mnt` (or
>> rather what else I mount under /mnt where) that would achieve this?
...
> I think number 1 is your "best" bet.  I've no idea how to do that.
>
> Number 2 is probably your "easiest" option.  /boot/ should be put on the
> usb, and I suppose that the / should be on the SSD...You would install
> this way.  That's probably how I'd do it.  Or rather that is how I would
> try to do it.  :)

Unfortunately, guix doesn't currently support booting off of a separate
/boot partition, since the kernel and initrd are in /gnu/store; your
bootloader needs to be able to mount the partition that /gnu/store is
located on.

The workaround would be to manually copy all files mentioned in grub.cfg
(kernel, initrd, possibly others) into a partition somewhere on boot
media, and tweak the grub.cfg appropriately...


There are several cases where this sort of thing would be desireable:

* The above scenario; the system does not expose an NVMe drive from EFI
  or BIOS.

* Using u-boot and you want root on lvm, raid, encryption, etc. which
  u-boot does not support


I've been meaning to file a bug on this for ages; I have BCCed bug-guix
now which will hopefully work. :)


Another more complicated option would be to use kexec; where you boot
one kernel and maybe a minimal rootfs, and load a new kernel and initrd
into ram, which uses the kernel drivers and then runs "kexec" to switch
to the newly loaded kernel... not sure how reliable that is, but it is
possible.


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: bug-guix <at> gnu.org
Subject: Re: support split /boot partition
Date: Sun, 02 May 2021 14:48:12 -0700

[Message part 1 (text/plain, inline)]

On 2021-04-30, Joshua Branson wrote:
> Vladilen Kozin <vladilen.kozin <at> gmail.com> writes:
>> Is there a way out of this predicament? I can see two options.
>> (1) can some Linux distro/bootloader do the FreeBSD trick: start on
>> USB but then chain-boot Guix off that SSD? IIUC grub's chain-boot is
>> of no help here, cause it simply won't even see that drive;
>> (2) install and run Guix off USB but somehow ensure that "IO heavy"
>> bits are mounted from that SSD. There's gotta be some (file-systems
>> ...) combined with the way I `guix system init config.scm /mnt` (or
>> rather what else I mount under /mnt where) that would achieve this?
...
> I think number 1 is your "best" bet.  I've no idea how to do that.
>
> Number 2 is probably your "easiest" option.  /boot/ should be put on the
> usb, and I suppose that the / should be on the SSD...You would install
> this way.  That's probably how I'd do it.  Or rather that is how I would
> try to do it.  :)

Unfortunately, guix doesn't currently support booting off of a separate
/boot partition, since the kernel and initrd are in /gnu/store; your
bootloader needs to be able to mount the partition that /gnu/store is
located on.

The workaround would be to manually copy all files mentioned in grub.cfg
(kernel, initrd, possibly others) into a partition somewhere on boot
media, and tweak the grub.cfg appropriately...


There are several cases where this sort of thing would be desireable:

* The above scenario; the system does not expose an NVMe drive from EFI
  or BIOS.

* Using u-boot and you want root on lvm, raid, encryption, etc. which
  u-boot does not support


I've been meaning to file a bug on this for ages; I have BCCed bug-guix
now which will hopefully work. :)


Another more complicated option would be to use kexec; where you boot
one kernel and maybe a minimal rootfs, and load a new kernel and initrd
into ram, which uses the kernel drivers and then runs "kexec" to switch
to the newly loaded kernel... not sure how reliable that is, but it is
possible.


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #13 received at 48172 <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: 48172 <at> debbugs.gnu.org
Subject: Re: support split /boot partition
Date: Sat, 22 May 2021 14:02:14 -0700

[Message part 1 (text/plain, inline)]

On 2021-05-02, Vagrant Cascadian wrote:
> Unfortunately, guix doesn't currently support booting off of a separate
> /boot partition, since the kernel and initrd are in /gnu/store; your
> bootloader needs to be able to mount the partition that /gnu/store is
> located on.
>
> The workaround would be to manually copy all files mentioned in grub.cfg
> (kernel, initrd, possibly others) into a partition somewhere on boot
> media, and tweak the grub.cfg appropriately...
>
>
> There are several cases where this sort of thing would be desireable:
>
> * The above scenario; the system does not expose an NVMe drive from EFI
>   or BIOS.
>
> * Using u-boot and you want root on lvm, raid, encryption, etc. which
>   u-boot does not support

  * Using luks1 format for /boot and luks2 format for / (unless grub2
    learns how to read luks2 already/soon)

live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #16 received at 48172 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: 48172 <at> debbugs.gnu.org
Subject: Re: bug#48172: support split /boot partition
Date: Wed, 08 Jun 2022 14:46:23 -0400

Hi Vagrant,

Vagrant Cascadian <vagrant <at> debian.org> writes:

> On 2021-05-02, Vagrant Cascadian wrote:
>> Unfortunately, guix doesn't currently support booting off of a separate
>> /boot partition, since the kernel and initrd are in /gnu/store; your
>> bootloader needs to be able to mount the partition that /gnu/store is
>> located on.
>>
>> The workaround would be to manually copy all files mentioned in grub.cfg
>> (kernel, initrd, possibly others) into a partition somewhere on boot
>> media, and tweak the grub.cfg appropriately...
>>
>>
>> There are several cases where this sort of thing would be desireable:
>>
>> * The above scenario; the system does not expose an NVMe drive from EFI
>>   or BIOS.
>>
>> * Using u-boot and you want root on lvm, raid, encryption, etc. which
>>   u-boot does not support
>
>   * Using luks1 format for /boot and luks2 format for / (unless grub2
>     learns how to read luks2 already/soon)

On top of the above use cases, I'll add one I found recently, after
upgrading my disk array to 2.5 TiB on my aging BIOS desktop:

* Keep boot files under the maximum 2 TiB addressable sector on BIOS
  (non-UEFI) systems using > 2 TiB drives.

The problem would manifest itself by this cryptic GRUB error:

"error: attempt to read or write outside of disk `proc'"

The solution was to have a separate *and* standalone boot partition.
The separate part is easy; just create a new partition and mount it as
/boot in your config file system definitions.

The second "standalone" part is not taken care by Guix System yet; with
the help of Tobias I devised the following script that copies the
minimum (init RAM disks and kernel images) to /boot and strips the
prefixes on these paths, if any (I use Btrfs subvolumes):

--8<---------------cut here---------------start------------->8---
#!/usr/bin/env bash
set -e

# Copy kernel and initrd images to /boot
images=$(grep -E '^  (linux|initrd) ' /boot/grub/grub.cfg \
    | awk '{ print $2 }' | sed 's|.*/gnu|/gnu|g' | sort | uniq)

for image in $images; do
    mkdir -p /boot$(dirname $image)
    if [ ! -e /boot$image ] || ! cmp -s $image /boot$image; then
        echo copying cp $image to /boot$image... > /dev/error
        cp $image /boot$image
    fi
done

# Adjust /boot/grub/grub.cfg.
sed -E -e 's/.*search.*--set.*//' \
    -e 's/^insmod luks.*//' \
    -e 's/^cryptomount.*//' \
    -e 's,^(  (linux|initrd) )[^ ]*(/gnu/[^ ]* ?),\1\3,' \
  -i.bak /boot/grub/grub.cfg
--8<---------------cut here---------------end--------------->8---

It's on my TODO to address this properly in Guix when I'll have the
bandwidth.

I hope that helps,

Thanks!

Maxim

Message #19 received at 48172 <at> debbugs.gnu.org (full text, mbox):

From: Distopico Vegan <distopico <at> riseup.net>
To: 48172 <at> debbugs.gnu.org
Subject: support split /boot partition
Date: Sat, 03 Jun 2023 09:25:55 -0500

[Message part 1 (text/plain, inline)]

Currently I have this similar use case, I have a PCI-E NVMe that is not
detected by BIOS (KGPE-D16 motherboard) so my plan was had a partition
for /boot in my SSD and the root system in the NVMe, so could be great
have support to that user case that I think is pretty common in old
board that doen's have NVMe and you want extend your system.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.