Can I safely remove the 5.14.10-1-MANJARO folder? If so, are there any other places I should check to make sure there are no other rogue files? If not, is there a better way to remove any/all 5.14.10 remnants?
Not sure if my command is very suitable, but I tried to find other 5.14.10 instances, but found only this one path… (editing out all Timeshift snapshots paths I found)
I had an issue when I removed kernel 5.13 via Manjaro Settings GUI and manual intervention was required to remove files from /boot. I found a similar topic that suggested the same action. If uncertain, make a backup of the files first. I suspect that grub makes no reference to these non-listed kernels.
A side note: I use locate -i (alias loc) to find things (see updatedb & systemctl status updatedb), at least to narrow it down, and then use find.
I have confirmed it’s running daily for me as well… first entry in the list
$ systemctl list-timers -all
NEXT LEFT LAST PASSED UNIT ACTIVATES
Wed 2021-12-08 14:26:16 CST 3h 34min left Tue 2021-12-07 14:26:16 CST 20h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Thu 2021-12-09 00:00:00 CST 13h left Wed 2021-12-08 00:00:12 CST 10h ago logrotate.timer logrotate.service
Thu 2021-12-09 00:00:00 CST 13h left Wed 2021-12-08 00:00:12 CST 10h ago man-db.timer man-db.service
Thu 2021-12-09 00:00:00 CST 13h left Wed 2021-12-08 00:00:12 CST 10h ago pkgfile-update.timer pkgfile-update.service
Thu 2021-12-09 00:00:00 CST 13h left Wed 2021-12-08 00:00:12 CST 10h ago shadow.timer shadow.service
Thu 2021-12-09 00:53:59 CST 14h left Wed 2021-12-08 02:48:52 CST 8h ago updatedb.timer updatedb.service
Thu 2021-12-09 14:03:25 CST 1 day 3h left Thu 2021-12-02 10:31:36 CST 6 days ago pamac-mirrorlist.timer pamac-mirrorlist.service
Mon 2021-12-13 00:02:32 CST 4 days left Mon 2021-12-06 00:21:07 CST 2 days ago fstrim.timer fstrim.service
Sat 2022-01-01 15:00:00 CST 3 weeks 3 days left Sat 2021-12-04 15:00:07 CST 3 days ago pamac-cleancache.timer pamac-cleancache.service
n/a n/a n/a n/a firstname.lastname@example.org email@example.com
I’m thinking this issue had one of two possible root causes…
The switch from kernel-alive to kernel module-hook was done at a point where the removal/introduction interrupted the processes in some way… and/or
the dkms issue I experienced during the stable update tossed a wrench in the mix
So hopefully with @freggel.doe 's command, things are now in the appropriate places for kernel-modules-hook to continue it’s cleanup, and keep things lined up for the other processes/timers to find and deal with what they are expecting.