Future kernel upgrades
by tadgy from LinuxQuestions.org on (#6QQEZ)
Hey Pat,
A few of us in the ##slackware channel were discussing the removal of the -huge kernel earlier, and I made a suggestion that struck a chord with a few users, so wanted to repeat it here.
Now that we only have the one kernel, and seem to be moving towards grub as the bootloader (though that isn't strictly necessary for my suggestion) I thought it might be an idea to have a
Code:/etc/kernel-upgrade.d/directory where users could add scripts to do any post kernel upgrade tasks that they would usually manually complete.
For example, creating/updating an initrd, copying the kernel+initrd in /boot/efi and updating a bootloader.
The scripts in this directory could be called from the kernel-generic doinst.sh (only for scripts that are +x) during upgrades to save the user manual intervention that they might forget after kernel upgrades.
I don't suggest populating this directory with any default scripts, but simply providing it for the admin to use if they choose.
It may take a lot of the unintended fails out of the upgrade process - it's a script once and forget thing.
What do you think? :)
A few of us in the ##slackware channel were discussing the removal of the -huge kernel earlier, and I made a suggestion that struck a chord with a few users, so wanted to repeat it here.
Now that we only have the one kernel, and seem to be moving towards grub as the bootloader (though that isn't strictly necessary for my suggestion) I thought it might be an idea to have a
Code:/etc/kernel-upgrade.d/directory where users could add scripts to do any post kernel upgrade tasks that they would usually manually complete.
For example, creating/updating an initrd, copying the kernel+initrd in /boot/efi and updating a bootloader.
The scripts in this directory could be called from the kernel-generic doinst.sh (only for scripts that are +x) during upgrades to save the user manual intervention that they might forget after kernel upgrades.
I don't suggest populating this directory with any default scripts, but simply providing it for the admin to use if they choose.
It may take a lot of the unintended fails out of the upgrade process - it's a script once and forget thing.
What do you think? :)