Hi,
Mathieu Othacehe <[email protected]> writes:
> Hello,
>
>>> It solves the situation where /boot is unencrypted, but /gnu/store is
>>> encrypted. In this case, you will not need to unlock the partition with
>>> /gnu/store when you copy the kernel and initrd over.
>>>
>>> It's for example what NixOS is doing.
>>
>> I see. Since the original question was about full disk encryption, I
>> did not expect non-encrypted /boot to be an option. Sure, in that case
>> the copy would help. I just hope the copy will be optional, and
>> encrypted /boot will stay a possibility.
>>
>>>
>>>> GRUB already has access to /gnu/store after you unlock the root for the
>>>> first time.
>
> OK, thank you both for your feedback. Regarding the /boot copy proposal,
> on my current system, I have:
>
> /dev/nvme0n1p1 256M 24M 233M 10% /boot/efi
Here you have /boot/efi...
>
>
> and the current system generation contains:
>
> mathieu@meije ~$ ls -lh
> /gnu/store/sd4pj878yipc45wa97lmb4i6db7ym7jj-linux-6.17.12/bzImage
> -r--r--r-- 2 root root 16M Jan 1 1970
> /gnu/store/sd4pj878yipc45wa97lmb4i6db7ym7jj-linux-6.17.12/bzImage
>
> mathieu@meije ~$ ls -lh
> /gnu/store/rp2fpd47raw0jvr869dsynbl4dxwg2ci-combined-initrd/initrd.img
> -r--r--r-- 2 root root 29M Jan 1 1970
> /gnu/store/rp2fpd47raw0jvr869dsynbl4dxwg2ci-combined-initrd/initrd.img
>
>
> So having the kernel + initrd in /boot would already take 45M, out of
> the 256M of my /boot partition. That would mean that for users with
> quite full /boot partitions because of multiple systems, or with many
> Guix System generations, size would definitely be an issue.
>
> When using auto-partitioning, the installer is keeping the existing
> ESP /boot partition if any. It means that we do not have control over
> the /boot size. Maybe we could do the following:
... and here you are talking about /boot. I am not familiar with the
installer and how it partitions things. Is the 256M /boot/efi *also*
mounted as /boot (since you talk about ESP /boot partition)? Or is
/boot a separate partition (or, more likely, just a directory on root
volume)?
>
> 1. No ESP partition : an ESP partition is created and the current
> default size is bumped from 550MB to something bigger like 5GB.
Well, my ESP partition is 64MB and I like it. Do we really need to
stuff all these things into the ESP? Would it not be better to put them
into a non-joke file-system (anything not FAT32)?
>
> 2. Existing ESP partition : the ESP partition is kept but resized to
> 5GB.
If you have an existing partitioning layout, you cannot reasonably
resize it, because next partition will likely be right behind it on the
disk. There is nowhere to resize to.
>
> then, when performing a system installation, kernel and initrd are
> copied over the /boot partition and the GRUB configuration file is
> modified to point to the /boot copies instead of the /gnu/store files.
>
> The copy could be performed only if a flag is set, something like:
>
> (bootloader (bootloader-configuration
> (bootloader grub-efi-bootloader)
> (targets '("/boot/efi"))
> (keyboard-layout keyboard-layout)
> (copy-boot-files? #t)) ;copy kernel+initrd to /boot
>
> It can also be that instead of storing kernel + initrd for every system
> generation in /boot, we pack them into UKIs[1], so that we have
> something like:
>
> /EFI/Guix/generations/{system-203.efi, system-204.efi}
>
> [1]: https://wiki.archlinux.org/title/Unified_kernel_image
With the UKIs, would the idea be to skip GRUB all together and boot it
directly?
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
