On Wed, 14.05.14 16:16, Josh Boyer (jwboyer(a)fedoraproject.org) wrote:
On Wed, May 14, 2014 at 4:06 PM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
> On Wed, 14.05.14 20:39, Matthew Garrett (mjg59(a)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(a)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?
No. I simply think it would be a better choice to make RPM install the
kernel into /usr/lib/, in some place that is near the kernel modules.
the kernel-install script should then do three things:
1) copy the kernel from /usr/lib to /boot
2) generate the initrd in /boot, from the modules and other stuff in /usr
3) generate a BLS snippet in /boot, to bind initrd and kernel together
This nicely decouples the booting logic from the OS (which is then
/usr), and allows easily installing a boot loader on a local disk from a
shared NFS /usr, since all vendor bits always stay in a fully consistent
state in /usr. And /var, /etc, /boot are only secondary partitions with
local configuration, state and loader info.
Currently, the script only does 2+3, but the kernel is directly
installed in /boot by RPM, which means sharing /usr always means /boot
needs also be shared. Wich sucks, since boot loaders tend to be something one
wants to keep more local, while /usr is something one would like to
share...
Hope that makes some sense...
(In the long run I want to come to a system where /usr is sufficient to
bring the system up, and /var, /etc, /boot can be flushed out if
necessary, and be fully reconstructed from /usr. I want this for user
appliances, and the same way as for OS containers)
Lennart
--
Lennart Poettering, Red Hat