Bug 2133294 - [systemd-boot] kernel-install don't call /etc/kernel/postinst.d/* if grubby is not installed
Summary: [systemd-boot] kernel-install don't call /etc/kernel/postinst.d/* if grubby i...
Keywords:
Status: CLOSED DUPLICATE of bug 2133293
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 36
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-10-09 15:57 UTC by Harald Reindl
Modified: 2022-10-25 16:28 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-10-25 16:28:51 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Harald Reindl 2022-10-09 15:57:49 UTC
with uefi you can no longer have everything needed for boot on a RAID and so i would like to rsync /efi to /efi-bkp which is the same partition on the second disk containing the OS RAID

"/etc/kernel/postinst.d" isn't referred in "/usr/bin/kernel-install" at all and "/etc/kernel/install.d" seems to depend on "/etc/kernel/install.conf" at likely would be exectued too early anaways

bash scripts in "/etc/kernel/postinst.d/" should get executed after kernel updates/installs/removedments

Comment 1 David Tardon 2022-10-19 14:43:52 UTC
/etc/kernel/postinst.d (and /etc/kernel/prerm.d) hooks are executed by /lib/kernel/install.d/95-kernel-hooks.install , which is a part of grubby . Based on your bug 2133293, I guess you've removed grubby? Anyway, 95-kernel-hooks.install doesn't do anything grubby-specific, so it probably should be moved to systemd.

Comment 2 Harald Reindl 2022-10-19 14:51:59 UTC Comment hidden (abuse)
Comment 3 David Tardon 2022-10-21 11:17:02 UTC
(In reply to Harald Reindl from comment #2)
> [root@srv-rhsoft:~]$ rpm -qa | grep grub
> grub2-common-2.06-54.fc36.noarch
> grub2-tools-minimal-2.06-54.fc36.x86_64
> grub2-tools-2.06-54.fc36.x86_64
> 
> why do we need these packages because otherwise all you get is a initrd
> after a kernel update?

Because grub2 is the only officially supported boot loader on Fedora and nobody has done the work to get systemd-boot support to the same level?

> and why in the world is "kernel-install" and "bootctl" in the systemd-udev
> subpackage?

For historical reasons. The package should really be called systemd-extras or systemd-other-tools or systemd-kitchen-sink. It contains stuff that's neither important enough to be in the main package nor big enough to deserve a subpackage of its own.

> "kernel-install" should be in the "systemd" main package

No, it should not. There's no need for kernel-install in containers, for example.

> and all boothctl
> relevant in a subpackage which get installed by default using
> soft-dependencies

A pull request--or a patch--welcome.

Comment 4 Harald Reindl 2022-10-21 11:51:02 UTC
> No, it should not. There's no need for kernel-install in containers

/usr/bin/kernel-install is 6,5K while you blow /usr/lib/systemd/boot/efi with 280K and bootctl with 86K on VMs using grub2
on the other hand the fact that "kernel-install" and "systemd-boot" can't walk alone pulling 16,5M undesired grub2-deps 

strange weighting and the main question remains what someone thought by throwing a lot of things in systemd-udev which nobody would expect there in context of "neither important enough to be in the main package nor big enough to deserve a subpackage of its own"

Comment 5 David Tardon 2022-10-24 08:51:58 UTC
(In reply to Harald Reindl from comment #4)
> the main question remains what someone thought by
> throwing a lot of things in systemd-udev which nobody would expect there

That's package evolution in practice... systemd-udev only contained udevadm and udev rules originally. Then, I assume, a small utility needed to be packaged, not worthy of a separate subpackage, so it was added into systemd-udev. Then it happened again... and again... and then it's become a rule. Also, as nobody has complained about the name during all these years, there hasn't been any incentive to think about it. Currently there are 27 source packages in Fedora that depend on systemd-udev by name (most likely for %pre/%post scriptlets). Hence, even if it is renamed, either the old name will have to be provided forever, or someone will have to spend the time to clean this up.

I think the name should be changed, but I don't see it as a priority. (Actually, I'd prefer to follow the same pattern some (many?) other Fedora packages use and rename systemd -> systemd-core and systemd-udev -> systemd. But that would require a lot of effort for a little gain.)

> in
> context of "neither important enough to be in the main package nor big
> enough to deserve a subpackage of its own"

"Important" wasn't the best-fitting word to use. Maybe "universal" would have been better. Anyway, the main systemd package should only contain stuff that's (almost) always needed (even in a container). systemd-udev is used for stuff that does not match that criterion (but most of it is still needed on a real HW or in a VM).

But all this is really diverging from $SUBJECT.

Comment 6 Zbigniew Jędrzejewski-Szmek 2022-10-25 16:28:51 UTC
I'll close this as a duplicate. Realistically, we can try to get this working in F37+.

*** This bug has been marked as a duplicate of bug 2133293 ***


Note You need to log in before you can comment on or make changes to this bug.