Cure found for kernel updates

[Josh Boyer]

On Wed, May 14, 2014 at 4:06 PM, Lennart Poettering
<mzerqung at 0pointer.de> wrote:
> 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.

I'm confused.  That's what currently already happens.  It just happens
to be that RPM is the mechanism for doing all the copying, not some
other tool after the fact.

kernel RPM is installed -> %post calls kernel-install ->
kernel-install calls dracut to generate the initramfs in /boot and
then updates the bootloader config.

So which part of that are you objecting to?  The fact that RPM keeps
track of it in the rpmdb, or?

josh