Slackpkg batch mode hangs when kernel is upgraded

[piterpunk]

When kernel is upgraded, Slackpkg shows a warning on screen and waits the user press enter to acknowledge it. If it's running as a cronjob or called by an orchestration tool in batch mode, wait the enter key press hangs forever.

[saxa]

I would suggest to code an upgrade-all-with-kernel option which would upgrade directly and run the /sbin/lilo. I that case the upgrade-all option should exclude the kernel-* packages.

[piterpunk]

I would suggest to code an upgrade-all-with-kernel option which would upgrade directly and run the /sbin/lilo. I that case the upgrade-all option should exclude the kernel-* packages.

I am a bit adamant about adds new commands to Slackpkg. I just want to not hang the machine waiting a user interaction in a non-interactive mode.

The old behaviour of Slackpkg was close to your suggestion, it ran /sbin/lilo after kernel upgrade, but nowadays there are many Slackware systems using elilo or grub as its boot loaders, in these cases, blindly run lilo doesn´t solve anything and can even mess with the installed boot loader.

That's why a stock Slackpkg only warns the user that the kernel was upgraded and leave the action to be done to the user.

If you wants to restore the old behaviour when a new kernel is found you can extend lookkernel function. For a example of how to do this, take a look the z-post-functions.sh script.

[zuno]

Use to upgrade a kernel in batch mode is never a good idea since it requires a reboot.

However you can also look the zlookkernel from slackpkg+ https://github.com/zuno/slackpkgplus/blob/master/src/zlookkernel.sh It manage some lilo/elilo configuration including the initrd rebuild. It also allow to choose interactive/not interactive mode. It should works without slackpkg+ (not tested)

However I never used it in crib since a small failure maybe catastrophic (not booting system).

[piterpunk]

Use to upgrade a kernel in batch mode is never a good idea since it requires a reboot.

The goal is to allow an unattended execution to run unattended, currently you can't do that with stock Slackpkg

To handle the upgraded kernel you can have more commands in the script, cron, playbook, state, whatever you use to call Slackpkg in batch mode But this will be futile if the Slackpkg execution hangs waiting forever.

However you can also look the zlookkernel from slackpkg+ https://github.com/zuno/slackpkgplus/blob/master/src/zlookkernel.sh It manage some lilo/elilo configuration including the initrd rebuild. It also allow to choose interactive/not interactive mode. It should works without slackpkg+ (not tested)

The script that I link in previous answer does the same for my configurations, of course in a much more crude way as it presumes a lot of previous configuration (as a mkinitrd.conf, use of package provided symlinks, etc...). At least I can say it is only a didactic example to cover its many quirks.

Actually, I use it as-is in most my Slackware machines because I don't want to manually manage a dozen systems.

[saxa]

The old behaviour of Slackpkg was close to your suggestion, it ran /sbin/lilo after kernel upgrade, but nowadays there are many Slackware systems using elilo or grub as its boot loaders, in these cases, blindly run lilo doesn´t solve anything and can even mess with the installed boot loader.

What about autodetecting the bootloader used ?

[piterpunk]

What about autodetecting the bootloader used ?

I think this can be a plan for future releases. Or at least have a configuration to tell Slackpkg which boot manager is in use.

Currently you can use an addon like the zlookkernel.sh or z-post-functions.sh (both linked in previous answers) to automatically creates the initrd and update the boot loader.

[saxa]

I am all for that second option of haveing a configuration to make sure the boot loader used is the one as configured.

[rworkman]

9d5166d13bce28fee36327c1e00a66fcacb77025 merged to close this; thanks!