postinst.d/99-default script doesn't seem to work - Fedora kernel become the default one after update

[Alien3294]

After last two Fedora kernel updates yesterday and today, I noticed each time it became a default kernel to boot. I have the /etc/kernel/postinst.d/99-default script in place with correct set of permissions.

When I execute grubby --set-default=/boot/$(ls /boot | grep vmlinuz.*cachy | sort -V | tail -1) manually, Cachy kernel becomes the default one again.

[Laertes87]

I noticed the same thing since upgrading to Fedora 44. With Fedora 43 it worked.

The script seems to be executed, at least its output was correct in the terminal after the chain of post install scripts for the kernel. And executing the script manually (not just the grubby command) also works.

So it seems as if the order of post install scripts was altered in Fedora 44 that overrides what this script does after it has been executed.

[mikaeldui]

@Alien3294 @Laertes87 I'm investigating. I was hoping that the 99- prefix would make it run very last, but it seems it didn't help.

[Hekel1989]

Hi, I hit the exact same issue on Fedora 44. I've had a bit of back and forth with my local Qwen3.6 27B, and it got to the conclusion that the postinst.d/99-default script alone isn't enough. it suggested the fix below, which I've implemented, and so far so good, works great :)

Obviously very open to corrections if there are better ways to achieve this.

---

Why the script fails

When dnf update installs a new Fedora kernel, the kernel RPM's %post scriptlet calls kernel-install add which triggers all /etc/kernel/postinst.d/* scripts. Your 99-default runs and sets the CachyOS kernel as default — but then Fedora's own %post scriptlet runs its own grubby --set-default after the postinst.d scripts finish, overwriting your setting. So Fedora "wins" the race every time.

The postinst.d script is useful as a best-effort layer, but it can't guarantee CachyOS stays default on its own.

---

The fix — add a systemd timer as enforcement

What works reliably is adding a systemd oneshot service + timer that forces the default at boot and daily. This way, even if Fedora overwrites grubby during dnf update, the default gets corrected before you log in.

1. Create a helper script:

sudo tee /usr/local/bin/cachyos-set-default.sh > /dev/null << 'EOF'
#!/bin/bash
set -e
CACHY_KERNEL=$(ls /boot | grep vmlinuz.*cachy | sort -V | tail -1)
if [ -n "$CACHY_KERNEL" ]; then
    grubby --set-default="/boot/$CACHY_KERNEL"
fi
EOF
sudo chmod 755 /usr/local/bin/cachyos-set-default.sh

2. Create the systemd service:

sudo tee /etc/systemd/system/cachyos-default-kernel.service > /dev/null << 'EOF'
[Unit]
Description=Set CachyOS kernel as default boot entry
DefaultDependencies=no
After=local-fs.target
Before=default.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/cachyos-set-default.sh
RemainAfterExit=no

[Install]
WantedBy=multi-user.target
EOF

3. Create the timer (fires 5s after boot + daily):

sudo tee /etc/systemd/system/cachyos-default-kernel.timer > /dev/null << 'EOF'
[Unit]
Description=Run CachyOS default kernel enforcement on boot and daily

[Timer]
OnBootSec=5s
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target
EOF

4. Enable and start:

sudo systemctl daemon-reload
sudo systemctl enable --now cachyos-default-kernel.timer

---

Why this works

The timer fires early in the boot process (before your desktop loads), so by the time you log in, the default is already set to CachyOS. The daily run is backup insurance. You don't need to exclude the Fedora kernel from updates — it still gets security patches, it just never "wins" the default slot.

I've tested this live on Fedora 44: manually set Fedora kernel as default via grubby, triggered the service, and it correctly flipped back to CachyOS. The postinst.d/99-default script is still worth keeping as a first line of defense, but the timer is the real enforcer.

[Alien3294]

I'm gonna test it when next kernel update hits.

[Laertes87]

Doesn't that mean you would need to reload the service after running the update? Otherwise if you reboot directly after the update, you would still not have the CachyOS kernel as default since the service would only load after kernel selection.

[Hekel1989]

Doesn't that mean you would need to reload the service after running the update? Otherwise if you reboot directly after the update, you would still not have the CachyOS kernel as default since the service would only load after kernel selection.

I just tried and it worked for me.

But, I do agree with your logic here. The timer is set to run daily , so if you were to wait before rebooting, it'd definitely work. But, the scenario you just described, yeah, thinking about it logically, it should go the way you said.
Tomorrow I'll build a brand new VM, set this up before I run a kernel update, and see if it's consistent.

I'll report back here once that's done.

[Alien3294]

Doesn't that mean you would need to reload the service after running the update? Otherwise if you reboot directly after the update, you would still not have the CachyOS kernel as default since the service would only load after kernel selection.

I just tried and it worked for me.

But, I do agree with your logic here. The timer is set to run daily , so if you were to wait before rebooting, it'd definitely work. But, the scenario you just described, yeah, thinking about it logically, it should go the way you said. Tomorrow I'll build a brand new VM, set this up before I run a kernel update, and see if it's consistent.

I'll report back here once that's done.

@Hekel1989 any update on that?

[Hekel1989]

Doesn't that mean you would need to reload the service after running the update? Otherwise if you reboot directly after the update, you would still not have the CachyOS kernel as default since the service would only load after kernel selection.

I just tried and it worked for me.

But, I do agree with your logic here. The timer is set to run daily , so if you were to wait before rebooting, it'd definitely work. But, the scenario you just described, yeah, thinking about it logically, it should go the way you said. Tomorrow I'll build a brand new VM, set this up before I run a kernel update, and see if it's consistent.

I'll report back here once that's done.

@Hekel1989 any update on that?

Hi, sorry I've been terribly busy and forgot to update the issue. I have tested on a brand new VM and you were right, it doesn't fully work.

I haven't had a chance to test other solutions, but I will update this issue once I do

[mikaeldui]

Hello everyone!

I think I've come up with a solution by using the DNF5 actions plugin.

First remove the old kernel postinst script with sudo rm /etc/kernel/postinst.d/99-default, and then run the following to install the actions plugin and create a post_transaction action:

sudo dnf install libdnf5-plugin-actions

sudo mkdir -p /etc/dnf/libdnf5-plugins/actions.d

sudo tee /etc/dnf/libdnf5-plugins/actions.d/cachy-default.actions << 'EOF'
# After installing any kernel* package, set the latest CachyOS kernel as the default boot entry
post_transaction:kernel*:in::/usr/bin/sh -c /usr/bin/grubby\ --set-default=/boot/$(ls\ /boot\ |\ grep\ vmlinuz.*cachy\ |\ sort\ -V\ |\ tail\ -1)
EOF

Please let me know if it works for you too!

[broken-usb]

I've added the new script, just gotta wait until a new Fedora Kernel update gets release to see if it works

[Laertes87]

Same here, waiting for a new Fedora kernel update.

[Seramis]

Have to try it out.

Theoretically one could run dnf reinstall to install current fedora kernel again and it should be sufficient to confirm it is working?