Kernel marking files in /boot as %ghost

Dear list,

I've stumbled upon a serious issue that has not been discussed before. Somewhere around May 2015 kernel files was moved to /usr/lib/modules/<kernelver>, which are then copied to /boot in post scriptlets [1]. The issue is that such files are marked with %ghost because they don't exist initially and are being copied when installed. Now because of that rpm (rpm -qV) can't verify the files attributes correctly and heck even doesn't point out if they don't exist at all as it is the case if dnf fails in the middle of transaction. Because of that I've opened a bug report [2], but it was closed because that was supposedly intended, but looking at mailing list archive, I don't see this particular issue being raised and frankly in my opinion marking files that are responsible to boot the system as %ghost should not happen. %ghost should be used only when there is not any other option left in case when files truly doesn't exist and its integrity could not be verified in advance.

[1] <a href="" title=""></a>
[2] <a href="" title=""></a>


Re: Kernel marking files in /boot as %ghost

By =?utf-8?q?Samue... at 03/03/2018 - 01:57

Not having initramfs or grub updated because of scriptlets not executing is expected, kernel image and configuration files etc. are however not. I am hoping for a discussion on how to potentially do this better without working around important rpm features.

Stating the obvious, but why not install files to /boot in the first place as it was before. It seems the only logical thing to do until grub and other utilities learn how to read from other places.

Also it seems like I am not the right person to answer that question since I still don't understand what are the benefits of having these files installed to /usr/lib/modules and also having them installed by default? If I understand correctly the only purpose they serve is to copy them back to /boot from some kind of /usr system image when restoring the system. This doesn't seem to me as a reason to install them by default in /usr in the first place.

How about installing the files to /boot by default and making an optional subpackage named something like "kernel-stateless" with copies of these files. That way whatever needs its presence can depend on this subpackage.

Re: Kernel marking files in /boot as %ghost

By Josh Boyer at 03/02/2018 - 10:28

On Fri, Mar 2, 2018 at 1:11 AM, Samuel Rakitničan
< ... at fedoraproject dot org> wrote:
What is the result you expect from this email? You filed a bug, it
was closed because the packaging was done intentionally and there is
no other solution when considering the original reasons for the
change. I'm not sure if you want the original change reverted
entirely or what you would like to see, but "I don't like this" isn't
really productive. Also, using rpm -qV as an indication that kernel
installation is correct and bootable is simply never going to work
anyway. The initramfs is generated at kernel installation time, and
therefore has to be marked as %ghost. If that is missing, your
machine doesn't boot with that kernel. If the grub config file
doesn't get updated, your machine doesn't boot with that kernel.

What suggestion do you have for a solution?


Re: Kernel marking files in /boot as %ghost

By =?utf-8?q?Samue... at 03/06/2018 - 04:27

But what are the original reasons exactly? Seems like those files are used by rpm-ostree. Fedora until this date still uses rpm as a default package manager and I don't see why they need to be present by default. Especially because:

1. Wasting space when installed
2. Breaking rpm feature

And I don't see the benefits of doing so.

Re: Kernel marking files in /boot as %ghost

By Colin Walters at 03/06/2018 - 10:03

The `/usr` files are also copied by grubby. And while it's true *today*
that rpm-ostree adapted to the /usr/lib/modules change, in fact the
rpm-ostree maintainers were never consulted or notified about this
change and we only found out when things broke in Fedora.
<a href="" title=""></a>

And there's been a number of followups since then:
<a href=";q=is%3Apr+is%3Aclosed+kernel" title=";q=is%3Apr+is%3Aclosed+kernel">;q=is%3A...</a>

You're not the first to say or imply "rpm-ostree" is not "rpm based",
but I still find it funny. It's right there in the name of the project!
It's just *also* ostree based. More about this
<a href="" title=""></a>
and in my recent talk: <a href="" title=""></a>

Hm, it's a bit surprising to me that the `20-grubby.install` doesn't
pass `--reflink=auto` to `cp`, or actually try to use hardlinks.
That'd probably be an easy patch.
If you have /boot as the same partition, at least ostree does both of those
so you won't actually duplicate space.

As far as `rpm -V`, on ostree-based systems that's spelled `ostree fsck`,
although you still *can* run `rpm -V`.

In practice though honestly rpm-ostree today *doesn't* require "kernel in usr/lib/modules"
because since
<a href="" title=""></a>
we effectively enforce it, regardless of what the kernel.rpm does. (We need
this for RHEL7 which hasn't made this change, and our dynamic path translation
on import also allows us to e.g. fix up everything for UsrMove, etc.)

So if someone were to try to revert this I wouldn't care too much either way.

But of course I have to say: if you want a fully transactional update system for your host, so you're
never worried about interrupted updates and trying to `rpm -V` your kernel, that's
what rpm-ostree is today.