SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I should add that the 440.31 driver is installed with the --dkms option on 4.19.83 first. Then, dkms compiles a module for 5.4-rc7 on the first reboot after installation. It created the module on first boot for 5.4-rc6 also. I can boot all three kernels now with a nvidia.ko module in each. I haven't tried to run the nvidia installer on either 5.4x kernels.
RedHat has a tech article describing two mitigation techniques:
- disable TSX feature of the CPU with the kernel boot parameter "tsx="
- clear CPU buffers upon context switch with the kernel boot parameter "tsx_async_abort="
It needs both new (patched) kernel and latest Intel microcode: https://access.redhat.com/solutions/...nchronousabort
It came to my attention that users (just the same as i did) struggle to run a parallel kernel by the means of slackpkg and go to lengths to achieve this.
It troubled me some and i vent ahead with the 5.4.0-rc7 and tried to find a Slackware-y way of doing this:
To whome it might concern:
Code:
# slackpkg search kernel # to find the exact names
# slackpkg download kernel-huge-5.4.0_rc7-x86_64-1 kernel-modules-5.4.0_rc7-x86_64-1 kernel-generic-5.4.0_rc7-x86_64-1 #only download so renaming is not needed
# installpkg /var/cache/packages/testing/packages/kernel-*.txz # it is spewed on the screen where they are downloaded
Hope this helps and further streamlines the testing and feedback in the future
I guess that inconvenient side effect is to be expected?
There are only two ways to circumvent this, and both are manual I'm afraid:
1. Do the test run with the kernel and if it works - pick one to stick with
2. Alternatively, restrain from further package upgrading for the (short?) while you test-drive two kernels
It appears to me that Slackware does not really support (nor was intended for) running two installed kernel versions in parallel - think of kernel headers and the confusion for builds depending on having them present and assuming there are only one headers?
Could it be that running two parallel kernels is ought to be but a passing affair?
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,096
Original Poster
Rep:
If by "parallel" you mean having two more than one kernel installed, yes, easy to do, if, IMHO, you do it the "old fashion way".
Run installpkg on each set of the five kernel packages, which are generic, huge, headers, modules, and source. Of course you can elect to not install the huge or generic kernel.
Then edit your /etc/lilo.conf appropriately. Then run, lilo
Done.
Example, skipping the "global section" for brevity,
......
Quote:
vga=769
# ramdisk = 0 # paranoia setting
# End LILO global section
# Linux bootable partition config begins
image = /boot/vmlinuz-generic-5.4.0-rc7
initrd = /boot/initrd-5.4.0-rc7.gz
root = /dev/sda3
label = kernel-5.4.0
read-only # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
# Linux Kernel 4.19.84 bootable config begins
image = /boot/vmlinuz-huge-4.19.84
# initrd = /boot/initrd-4.19.84.gz
root = /dev/sda3
label = kernel-4.19.84
read-only
# Linux Kernel 4.19.84 bootable config ends
# Windows bootable partition config begins
other = /dev/sda1
label = win7pro
table = /dev/sda
# Windows bootable partition config ends
Of course, it would be a good idea to rename each initrd just after it is created so the proper one is used with its corresponding image.
Last edited by cwizardone; 11-13-2019 at 11:57 AM.
It appears to me that Slackware does not really support (nor was intended for) running two installed kernel versions in parallel
No: slackpkg upgrade expects only a single version of each package to be installed, so it is slackpkg and not slackware as total distro that really doesn't support two (or more) kernels in parallel.
I always have (at least) two kernel versions installed and often three:
- a "backup" kernel, as a safe and known to be working fallback choice
- the current active kernel, probably newer then the backup
- a "new upgrade" to be tested, NOT the default one at boot
Every time a newer kernel is announced I install it as the "new" choice in the boot menu,
try it, possible build NVidia, Vbox, etc modules FOR it.
Only when I'm comfortable with this new update I let it replace the "current" one (which will become the "old" one) by changing some symbolic links in /boot (no EFI here).
So after that I'm back again to two kernels.
I.e. in 14.2 the links are:
old: 4.4.190
cur: 4.4.199
new: 4.4.201
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
