slackpkg, lilo+elilo+initrd

Darth Vader · 06-06-2018, 07:12 AM

Just of records, to note that RHEL's YUM, DNF or even the freaking Yast2 of SuSE does NOT play at all with bootloaders while updating packages.

Basically, who do this thing is the very Package Manager (aka RPM) because in pre-install and post-install scripts from packages are coded commands for.

Also to note that they does NOT *upgrade* kernel packages, usually they have an install/remove only policy for these particular packages. And this thing I will love to see adopted also in Slackware.

bormant · 06-06-2018, 09:45 AM

Quote:

Originally Posted by allend

If you install a stock Slackware kernel package, the /boot/vmlinuz symlink is created to point to the kernel in that package.

... and may be this is the another reason to ignore /boot/vmlinuz symlink: if you have both kernel-generic and kernel-huge packages installed then 'slackpkg upgrade-all' at post-install step will always see the /boot/vmlinuz as symlink to the huge kernel (or huge-smp for 32 bit). Yes, because 'kernel-huge' sorted after 'kernel-generic' and doinst.sh from kernel-huge package overwrites symlink to huge kernel later than kernel-generic's do.

allend · 06-06-2018, 10:26 AM

Quote:

Just of records, to note that RHEL's YUM, DNF or even the freaking Yast2 of SuSE does NOT play at all with bootloaders while updating packages.

Basically, who do this thing is the very Package Manager (aka RPM) because in pre-install and post-install scripts from packages are coded commands for.

Also to note that they does NOT *upgrade* kernel packages, usually they have an install/remove only policy for these particular packages. And this thing I will love to see adopted also in Slackware.

And your point is?

Quote:

... and may be this is the another reason to ignore /boot/vmlinuz symlink: if you have both kernel-generic and kernel-huge packages installed then 'slackpkg upgrade-all' at post-install step will always see the /boot/vmlinuz as symlink to the huge kernel (or huge-smp for 32 bit). Yes, because 'kernel-huge' sorted after 'kernel-generic' and doinst.sh from kernel-huge package overwrites symlink to huge kernel later than kernel-generic's do.

And the script will fall through to prompting to running lilo without building an initrd.

bormant · 06-06-2018, 12:29 PM

Quote:

Originally Posted by allend

And the script will fall through to prompting to running lilo without building an initrd.

Yes, this part of post-install will be disabled in this scenario and initrd will not be upgraded... But when slackpkg is done user will change /boot/vmlinuz symlink to generic kernel and has no chance to use slackpkg initrd autoupdate feature.
This is the reason to not to use vmlinuz symlink as an indicator to recreate initrd.

allend · 06-06-2018, 01:02 PM

Quote:

But when slackpkg is done user will change /boot/vmlinuz symlink to generic kernel and has no chance to use slackpkg initrd autoupdate feature.

The focus of this thread is how to allow slackpkg to make a sensible suggestion to the system adminstrator to update the initrd if the generic kernel has been updated. If slackpkg is done, and the symlink has been changed, then the resulting environment is out of scope.

bormant · 06-06-2018, 02:54 PM

Quote:

Originally Posted by allend

The focus of this thread is how to allow slackpkg to make a sensible suggestion to the system adminstrator to update the initrd if the generic kernel has been updated.

... and if slackpkg will use /boot/vmlinuz to make the suggestion it cannot make sensible suggestion in the simplest case when kernel-generic and kernel-huge are both installed (as in recommended full install).
In this case (1) kernel-generic is installed but (2) initrd will not be updated. Surprise.

zerouno · 06-06-2018, 03:06 PM

Note: the focus is not initrd+generic but kernel+initrd.
I use a kernel huge but I need an initrd since some driver is not included in the huge.

The script should not check for kernel type but should search the initrd.