[SOLVED] Confused about 2019-07-22 14.2 kernel update

Skaendo · 07-22-2019, 12:10 AM

NVM: I guess that my mirror just hadn't caught up.

FlinchX · 07-22-2019, 01:26 AM

I will ask here since it's related. I suppose the changelog entry should read "4.4.186", not "4.4.182", since that's what I see in patches/packages ?

Skaendo · 07-22-2019, 02:06 AM

Quote:

Originally Posted by FlinchX

I will ask here since it's related. I suppose the changelog entry should read "4.4.186", not "4.4.182", since that's what I see in patches/packages ?

That is what I was seeing when I checked OSUOSL and it seems that it is only a typo in the changelog as far as I can tell.

Edit: Just to be safe, I have not upgraded yet.

ehartman · 07-22-2019, 03:13 AM

Quote:

Originally Posted by FlinchX

I suppose the changelog entry should read "4.4.186", not "4.4.182"

Yes, 4.4.182 was the previous kernel update for 14.2, so probably a case of bad cut-n-paste.

magicm · 07-22-2019, 09:00 AM

Yes - this is what slackpkg update presented to me for update just now

Mon Jul 22 08:55:35 CDT 2019
----------------------------------
Upgraded: patches :: kernel-firmware-20190717_bf13a71-noarch-1.txz
Upgraded: patches :: kernel-generic-4.4.186-x86_64-1.txz
Upgraded: patches :: kernel-headers-4.4.186-x86-1.txz
Upgraded: patches :: kernel-huge-4.4.186-x86_64-1.txz
Upgraded: patches :: kernel-modules-4.4.186-x86_64-1.txz
Upgraded: patches :: kernel-source-4.4.186-noarch-1.txz

==================================

nycace36 · 07-29-2019, 06:06 PM

Would UNSolve this if I could.

Quote:

Originally Posted by FlinchX

I will ask here since it's related. I suppose the changelog entry should read "4.4.186", not "4.4.182", since that's what I see in patches/packages ?

At least one other major and one minor confusion I see around the 2019-07-22 14.2 update.

Major misleadingment
According to the actual announcement of the update at http://www.slackware.com/security/vi...ecurity.704001, all the 64bit kernel updates are provided from

Code:

ftp://ftp.slackware.com/pub/slackware/slackware66-14.2/patches/packages/linux-4.4.186/

See any problem with that? If not, then look a bit more carefully and observe that the second half of the ftp path is ../slackware66-14.2/patches/packages/linux-4.4.186/

Minor misleadingment
The same kernel update announcement from http://www.slackware.com/security/vi...ecurity.704001 has the following Installation instructions up until the lilo/elilo steps:

Quote:

+------------------------+
Upgrade the packages as root:
# upgradepkg kernel-*.txz

If you are using an initrd, you'll need to rebuild it.
For a 32-bit SMP machine, use this command (substitute the appropriate
kernel version if you are not running Slackware 14.2):
# /usr/share/mkinitrd/mkinitrd_command_generator.sh -k 4.4.186-smp | bash
For a 64-bit machine, or a 32-bit uniprocessor machine, use this command
(substitute the appropriate kernel version if you are not running
Slackware 14.2):
# /usr/share/mkinitrd/mkinitrd_command_generator.sh -k 4.4.186 | bash

Please note that "uniprocessor" has to do with the kernel you are running,
not with the CPU. Most systems should run the SMP kernel (if they can)
regardless of the number of cores the CPU has. If you aren't sure which
kernel you are running, run "uname -a". If you see SMP there, you are
running the SMP kernel and should use the 4.4.186-smp version when running
mkinitrd_command_generator. Note that this is only for 32-bit -- 64-bit
systems should always use 4.4.186 as the version.

Right, but kjhambrick writes at https://www.linuxquestions.org/quest...6/#post5558460:

Quote:

Looking back at your file listing of /boot/ your pkg manager tool did an upgradepkg instead of an installpkg on the kernel.

Note that there are no old 4.4.12 files in /boot/ at all ...

UPGRADING the Kernel will always lead to trouble if you use Generic + an initrd file unless you mkinitrd ; edit lilo.conf ; run lilo every time there is a new Kernel.

UPGRADING the Kernel MAY lead to trouble if there happen to be regressions in the Kernel where it won't work on your Hardware for some reason.

OTOH if you always INSTALL your Kernels ( never UPGRADE ), you'll always have one-or-more fall-back Kernels to boot if things go south.

Still seems to be a source of confusion

Richard Cranium · 07-29-2019, 09:40 PM

Well, you could use slackroll instead of slackpkg; the former has a set of commands (kernel-upgrade and kernel-clean) which help dealing with kernel upgrades.

(Hmm. Since I mentioned slackroll, I thought that I'd try it again. It noticed (unlike slackpkg) that I still had apmd installed and did not have either nc or bluez-firmware installed. I'm not surprised about apmd but am surprised about bluez-firmware and nc.)