elitak / nixos-infect

[GPLv3+] install nixos over the existing OS in a DigitalOcean droplet (and others with minor modifications)
GNU General Public License v3.0
1.37k stars 221 forks source link

fix: do not move ESP to /boot. Instead leave it at /boot/efi. #145

Closed winny- closed 7 months ago

winny- commented 1 year ago

This seems to be a safer approach for infecting UEFI-based hosts. Test case:

  1. Set up a OCI Instance with Oracle or Ubuntu i) Notice it has a 100 MB ESP partition ii) OOTB nixos-infect takes this partition over and remounts it at /boot iii) A single kernel/initramfs pair takes up most of this space iv) Further use of the "nixos-infect"-ed system will likely lead to breakages due to running out of kernel/initramfs storage space.

To work around this, this PR uses the ESP partition strictly for ESP activities. Kernels and initramfs instead live on /boot within the rootfs. This should eliminate the space constraints on small ESP partitions that were being repurposed for kernel/initramfs.

Kukkerem commented 1 year ago

I'm currently dealing with this. The 100MB partition blocked all of my upgrades... I'm using your repo temporarily, which is working great; thanks!

ykis-0-0 commented 1 year ago

IMHO to introduce a new environment variable would be a better idea, as it allows compatibility for clouds and images that does have a ESP at /boot:

 mv -v /boot /boot.bak || { cp -a /boot /boot.bak ; rm -rf /boot/* ; umount /boot ; }
 if isEFI; then
-  mkdir -p /boot
-  mount "$esp" /boot
-  find /boot -depth ! -path /boot -exec rm -rf {} +
+  INFECT_EFI_PATH=${INFECT_EFI_PATH:-/boot}
+  mkdir -p $INFECT_EFI_PATH
+  mount "$esp" $INFECT_EFI_PATH
+  find $INFECT_EFI_PATH -depth ! -path $INFECT_EFI_PATH -exec rm -rf {} +
 fi
winny- commented 1 year ago

Here's my understanding of how this works:

  1. Prior to this PR /boot was always discarded, except in the case that EFI is being used to boot the system. In this case /boot was being taken over for ESP and storing kernels.
  2. This PR ensures kernels are always stored in /, thereby ensuring there is free space for kernels, regardless of the original /boot size.
  3. In all cases, this PR discards /boot. If EFI is needed, this partition is repurposed. Otherwise it's just an unused partition.

Based on this understanding, is there still a use case for an environment variable? Is there a cloud hosting provider that doesn't work with this PR?

elitak commented 7 months ago

Maybe I'm not fully getting the problem or solution, or maybe I'm just biased towards using /boot and not /boot/efi as the mount point, but I'm reticent to have this change affect all providers. If it's rewritten to take effect on only the providers that need it, I'll merge it.

winny- commented 7 months ago

Hi there, I've been spending less time on NixOS projects and this is one of those places I've been reducing involvement. If anybody else wants to create a new PR based off this work, please feel free to reuse my work in any capacity.

Best, Winny