Cure found for kernel updates

[Lennart Poettering]

On Wed, 14.05.14 20:39, Matthew Garrett (mjg59 at srcf.ucam.org) wrote:

> On Wed, May 14, 2014 at 10:27:36PM +0300, Elad Alfassa wrote:
> > On Wed, May 14, 2014 at 10:03 PM, Matthew Garrett <mjg59 at srcf.ucam.org>wrote:
> > > Remove the requirement that the ESP be $BOOT. The downside of that is
> > > that we'll then have *yet another* partition (/boot, because we want
> > > kernels stored on a filesystem that supports xattrs, /boot/efi for the
> > > ESP, /boot/whatever for storing the config fragments) which isn't a huge
> > > issue for GPT but would be annoying with MBR.
> > >
> > 
> > Can't we store those fragments in the same filesystem /boot is on?
> 
> We can, but the spec requires that it be VFAT, and it's not reasonable 
> for us to make /boot VFAT (no selinux labelling, for instance).

Well, the entirety of /boot should get the same selinux label, which is
perfectly suppported by the vfat kernel support.

It's just a question of whether /boot should be managed by RPM. I am
pretty sure it shouldn't. Instead the kernels should be placed somewhere
in /usr/lib, next to the kernel modules, and then only copied to /boot
when the initrd, and the drop-in is generated there, too. Or in other
words: initrd, kernel and initrd should always be placed there together,
or not at all, and be managed by the same kernel install script.

Similar, the boot loader tools should copy their stuff there when the
boot loader is installed or updated, but RPM should leave its fingers of
the dir...

I'd really prefer this behaviour since it nicely decouples the boot
loader from the rest of the operating system. This allows having
multiple operating systems around, or even multiple /usr instances
shared between multiple boot images and so on. (think: NFS /usr with
offline updates, that would finally work...)

Lennart

-- 
Lennart Poettering, Red Hat