support split /boot partition

Open

Details

4 participants

Distopico Vegan
Maxim Cournoyer
Glenn Morris
Vagrant Cascadian

Owner: unassigned

Submitted by: Vagrant Cascadian

Severity: normal

Vagrant Cascadian wrote on 2 May 2021 23:16

Recipients:(address . help-guix@gnu.org)

Message-ID:871raovntj.fsf@yucca

On 2021-04-30, Joshua Branson wrote:

Toggle quote (9 lines)> Vladilen Kozin <vladilen.kozin@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?

...

Toggle quote (7 lines)

> 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

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYI8WqQAKCRDcUY/If5cW

qpJZAQD4uj8gLq8Nq5e+6CKX7iiRyYtAIDdK7WOnwxN5RlX1FQEAmoK3Euaps0Dr

v+yNp/04w1G9Ud0WRn5mtmhw7cBONQs=

=1vBT

-----END PGP SIGNATURE-----

Vagrant Cascadian wrote on 2 May 2021 23:48

Recipients:(address . bug-guix@gnu.org)

Message-ID:87pmy8u7s3.fsf@yucca

On 2021-04-30, Joshua Branson wrote:

Toggle quote (9 lines)> Vladilen Kozin <vladilen.kozin@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?

...

Toggle quote (7 lines)

> 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

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYI8eHAAKCRDcUY/If5cW

qia5AQC6wZJTxvDFdIrr+XfIDLirm7gusFVaIAbYJZBJJV2a4wD/RCGdsmHygQJz

ymHa9q+wxmhpQO7xTDqh84aCx+vvyQ0=

=4uIW

-----END PGP SIGNATURE-----

Glenn Morris wrote on 4 May 2021 04:56

control message for bug 48172

Recipients:(address . control@debbugs.gnu.org)

Message-ID:E1ldlF1-0005W6-RK@fencepost.gnu.org

reassign 48172 guix

Vagrant Cascadian wrote on 22 May 2021 23:02

Re: support split /boot partition

Recipients:(address . 48172@debbugs.gnu.org)

Message-ID:87zgwmlbxl.fsf@yucca

On 2021-05-02, Vagrant Cascadian wrote:

Toggle quote (18 lines)> 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

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYKlxVgAKCRDcUY/If5cW

qr1CAP9j91jpSYGditfU0ManqC3/qqfIraVBBZm04fdz0qlYWAD/YIm95VCTp0Nf

72cvCf8tYKu/ZN9tclu+lQCgFKNi1wg=

=nTvr

-----END PGP SIGNATURE-----

Maxim Cournoyer wrote on 8 Jun 2022 20:46

Re: bug#48172: support split /boot partition

Recipients:(name . Vagrant Cascadian)(address . vagrant@debian.org)(address . 48172@debbugs.gnu.org)

Message-ID:87r13zj8n4.fsf@gmail.com

Hi Vagrant,

Vagrant Cascadian <vagrant@debian.org> writes:

Toggle quote (22 lines)> 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):

Toggle snippet (23 lines)

#!/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

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

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

bandwidth.

I hope that helps,

Thanks!

Maxim

Distopico Vegan wrote on 3 Jun 2023 16:25

support split /boot partition

Recipients:(address . 48172@debbugs.gnu.org)

Message-ID:87zg5gr53s.fsf@riseup.net

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.

Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 48172@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 48172

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date