On Wed, 14.05.14 16:16, Josh Boyer (jwboyer@xxxxxxxxxxxxxxxxx) wrote:
> On Wed, May 14, 2014 at 4:06 PM, Lennart Poettering
> <mzerqung@xxxxxxxxxxx> wrote:
> > On Wed, 14.05.14 20:39, Matthew Garrett (mjg59@xxxxxxxxxxxxx) 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@xxxxxxxxxxxxx>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
--
desktop mailing list
desktop@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/desktop
