support split /boot partition

  • Open
  • quality assurance status badge
Details
4 participants
  • Distopico Vegan
  • Maxim Cournoyer
  • Glenn Morris
  • Vagrant Cascadian
Owner
unassigned
Submitted by
Vagrant Cascadian
Severity
normal
V
V
Vagrant Cascadian wrote on 2 May 2021 23:16
(address . help-guix@gnu.org)
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-----

V
V
Vagrant Cascadian wrote on 2 May 2021 23:48
(address . bug-guix@gnu.org)
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-----

G
G
Glenn Morris wrote on 4 May 2021 04:56
control message for bug 48172
(address . control@debbugs.gnu.org)
E1ldlF1-0005W6-RK@fencepost.gnu.org
reassign 48172 guix
V
V
Vagrant Cascadian wrote on 22 May 2021 23:02
Re: support split /boot partition
(address . 48172@debbugs.gnu.org)
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-----

M
M
Maxim Cournoyer wrote on 8 Jun 2022 20:46
Re: bug#48172: support split /boot partition
(name . Vagrant Cascadian)(address . vagrant@debian.org)(address . 48172@debbugs.gnu.org)
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
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

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

I hope that helps,

Thanks!

Maxim
D
D
Distopico Vegan wrote on 3 Jun 2023 16:25
support split /boot partition
(address . 48172@debbugs.gnu.org)
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.
-----BEGIN PGP SIGNATURE-----

iQFJBAEBCAAzFiEEvYwofabWO6y953lVmAk6gHJUa/MFAmR7TmcVHGRpc3RvcGlj
b0ByaXNldXAubmV0AAoJEJgJOoByVGvzo1AH/igTAaVZI+Mx9To0YJUGZodBfvLI
Eb8Pdv+ukHX/eXdqt52I7IzdT8IA4Fhy6PL4pKEm0PcffIMRPOhJSiDPSJDJjv4k
ypHaE3UCU/tCAQmzys5FvHRPEBpab5trg2EQReH+iy4PDng4mY+YRb0URTxfp8cU
xV6/t9oGRgJDko2DlDwilU9Fng3OvSksEHCrcjtDV/uoG+tk4ZC7kpVlf5XL7XpP
aMtsDd5rvYTFMyur/dlMruZawBF5pFjAZ70U4imXmMozsqZHPqWd5azv5rCQ3qKC
LUqWQ9qG1f1ZyHIw8TyommRKxS/P6TN1VDR+ncF6YhdgymTHwMW6QaOWLdI=
=DxlV
-----END PGP SIGNATURE-----

?
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