Re:Ubuntu LTS updating failing all over the world
by scintill76 on Friday May 20, 2016 @05:08AM
(#11736451)
How necessary is it to have a separate /boot partition these days though? I have one because my root is LUKS-encrypted, but I think Grub could handle booting from an unencrypted ext4 root. I guess it would still fill up eventually, but maybe not before a re-install for other reasons.
[ Parent
| on HN ]
Re:Ubuntu LTS updating failing all over the world
by mrsteveman1 on Friday May 20, 2016 @10:44AM
(#11738179)
Grub can actually handle booting from an encrypted ext4 root as well, no /boot needed. You do end up entering the password twice by default, but that can be dealt with by using a key file.
Lots of blog posts out there with instructions to convert existing installations, for example http://dustymabe.com/2015/07/06/encrypting-more-boot-joins-t...
Re:Ubuntu LTS updating failing all over the world
by cyphar on Friday May 20, 2016 @06:35AM
(#11736784)
On UEFI systems, the /boot partition needs to be FAT32. So there's that. :P
Re:Ubuntu LTS updating failing all over the world
by yrro on Friday May 20, 2016 @06:42AM
(#11736810)
The UEFI system partition is mounted at /boot/efi. /boot itself can be a regular filesystem, or part of the root filesystem if you have no unusual requirements.
Re:Ubuntu LTS updating failing all over the world
by cyphar on Friday May 20, 2016 @10:11AM
(#11737896)
Depends what bootloader you use. Gummiboot (thus systemd-boot) can't handle having the EFI loader and the kernels on different partitions (thus having /boot and /boot/efi separate has questionable benefits). Not to mention that full disk encryption causes problems with /boot.
Re:Ubuntu LTS updating failing all over the world
by yrro on Friday May 20, 2016 @02:41PM
(#11740380)
That isn't necessarily a problem; Debian handles this by means of a kernel postinst hook that copies the newly-installed kernel from its installed location in /boot to /boot/efi/EFI/DEBIAN (or wherever gummiboot expects to find the kernel, I can't remember off the top of my head).
That systemd refuses to support anything other then EFI at /boot puts it into opposition with existing practice (as seen in Debian, Ubuntu, Fedora and SUSE).