Updating kernels

upnort · 08-23-2017, 02:55 PM

In another thread some good advice was provided:

Quote:

Just one thing: I usually advise people to keep a copy of the previous kernel which was successfully running; just in case, you know. I'm saying this as you mentioned "copy the new kernel over the previous one". So, as a precaution it is always good to know you have a copy of a stable working kernel.

How much work would be required to update slackpkg (and slapt-get) to support running two or more kernels? Invoking installpkg rather than upgradepkg? Yes, the default in slackpkg is to blacklist and not update new kernels at all.

At work I have to use Debian and CentOS. By default, within these distros the previous kernels are not deleted. The GRUB boot loader is updated to show previous kernels with the most recent kernel as the default.

This approach provides users an escape path. Manually installing new kernels and then manually editing boot loader config files seems a bit -- clunky. Yes, I have been doing that manually in my Slackware systems for many years. As a precaution, for many days after updating the kernel in Slackware I retain the boot menu options for the previous kernel.

Is there interest in updating kernels in this way in Slackware?

hazel · 08-23-2017, 03:53 PM

I think the problem is that Slackware uses lilo. Now some of us are very fond of lilo. I greatly prefer it to grub because it's so brilliantly simple in concept and execution. But it has one huge disadvantage: you have to update it by hand. If you've added a new kernel, you have to put in a stanza for it. I don't think there's any way of automating that.

One reason grub has become so popular is that it provides an automated update facility. You run update-grub and grub's os-finder script picks up your new kernel and puts it in the menu. For a lot of modern users, especially those who came over from Windows, this is what they want. They don't want to have to get their hands dirty editing bootloader config files. And the inevitable complexity and bloat is a price they are willing to pay. The Debian and Red Hat families both use grub, but I don't think that Slackware ever will.

55020 · 08-23-2017, 04:06 PM

You don't need to diddle lilo.conf all the time if you use the stable name 'vmlinuz' thoughtfully provided as a symlink by volkerdi, nor does your fallback entry in lilo.conf need to be rotated -- just rename the original 14.2 kernel to e.g. vmlinuz-original.

Hollow laughter about grub's automatic updates. Those damn dead old kernels accumulate and need to be cleared out manually. No, thanks.

magicm · 08-23-2017, 04:10 PM

I'm not exactly sure what you're proposing (a script?, possibly an extension to slackpkg, or whatever).

But, if I'm running a stable version of slackware (I am; 14.2 x86_64), and a new kernel becomes available in the stable Changelog, would I like to have a "push button, get cookie" method of:
1) keeping my current running kernel as working choice in my bootloader (which for me is LILO, as I do not run UEFI), and
2) while installing the new kernel listed in the Changelog as the default working choice in my bootloader,

The answer is, yes, I'd like that.

Of course, that opens up other questions, like determining what I use as my default bootloader, huge vs. generic+initrd (and how to set that up).

But, as an idea .... I like it.

Didier Spaier · 08-23-2017, 04:35 PM

Some remarks:

This option of installing another version instead of upgrading exists in slapt-get. Quoting "man slapt-get":

Quote:

--no-upgrade
Install the package rather than attempting to detect if a previous version is installed and upgrading it. This is useful for installing kernel packages. This option is only valid for --install targets.

You will still need to rebuild an initrd if you use a generic kernel, whether you install or upgrade.

If it's an upgrade provided as security fix for -stable, it should be safe to upgrade, instead of installing alongside the previous one. Then, the recommended way stated by Pat in the ChangeLog is:

Quote:

Be sure to upgrade your initrd after upgrading the kernel packages.
If you use lilo to boot your machine, be sure lilo.conf points to the correct
kernel and initrd and run lilo as root to update the bootloader.
If you use elilo to boot your machine, you should run eliloconfig to copy the
kernel and initrd to the EFI System Partition.

In the same case the Slackware Security Mailing List provides detailed instructions that are worth reading carefully:

Code:

Installation instructions:
+------------------------+

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.75-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.75 | 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.75-smp version when running
mkinitrd_command_generator.  Note that this is only for 32-bit -- 64-bit
systems should always use 4.4.75 as the version.

If you are using lilo or elilo to boot the machine, you'll need to ensure
that the machine is properly prepared before rebooting.

If using LILO:
By default, lilo.conf contains an image= line that references a symlink
that always points to the correct kernel.  No editing should be required
unless your machine uses a custom lilo.conf.  If that is the case, be sure
that the image= line references the correct kernel file.  Either way,
you'll need to run "lilo" as root to reinstall the boot loader.

If using elilo:
Ensure that the /boot/vmlinuz symlink is pointing to the kernel you wish
to use, and then run eliloconfig to update the EFI System Partition.


+-----+

In slapt-get, even if the kernels are blacklisted in slapt-getrc you can still upgrade them. just write:

Code:

slapt-get --update
slapt-get --upgrade -s # The blacklisted packages should be listed as such.
slapt-get -install kernel kernel-modules kernel-firmware ...

If you use upgradepkg (and slapt-get -i, IIRC), the symlinks will be written by the tools.
Else, writing symlinks if you want and making sure lilo.conf is edited accordingly is your duty. And of course, don't forget to double-check lilo.conf, then type:
Code:
```
lilo -t -v # then if the output is OK
lilo
```

bormant · 08-23-2017, 11:21 PM

You can copy kernel-huge-* and kernel-modules-* say to kernel-huge-rescue-* and kernel-modules-rescue-* in
/var/log/packages/ and /var/log/scripts/
and add new image section to lilo.conf with full kernel filename, run lilo.

Now when you upgrade that kernel packages, the files from original kernel-huge and kernel-modules will be holded by our new kernel-*-rescue-* package records in the package database.

PS. For 32-bit Slackware pay attention to -smp suffixes.

PPS. This trick uses Slackware package naming scheme where package name ends before 3rd-from-right minus. There are no duplicate names as kernel-huge and kernel-huge-rescue are different names so slackpkg works as usual.

enorbet · 08-23-2017, 11:47 PM

Lilo - If running /sbin/lilo is successful on a new kernel there is no problem other than whether that new kernel is fully capable of a successful boot, but any previously successful kernel not removed before /sbin/lilo is run is still a successful boot option. OTOH if running /sbin/lilo is unsuccessful, this doesn't mean the bootloader is "borked' only that it remains at the last successful run which includes a working kernel and only the new stanza is unsuccessful until fixed.

Grub2 - I despise the way in which OSprober works and always disable it on any install that forces me to use grub. Actually, I despise allowing anything so fundamental as the kernel to be handled by anything automatic.

Updating kernels and their respective bootlopaders is most definitely the sort of job I want done right which means I must do it myself and not leave for anyone else no matter how good their intentions might be. That is only one reason I have been a Slackware devotee for decades and likely, that will continue for life.

So, to answer your final question, I, for one, have zero interest in Slackware ever becoming automated at this level and I trust that if it ever were to become an option, that the hands on approach will always be default. If I were interested in automation I'd probably use something like Arch but then rolling releases of any kind, let alone one coupled with systemd, hold no appeal for me.

elcore · 08-24-2017, 12:08 AM

Quote:

Originally Posted by enorbet

Grub2 - I despise the way in which OSprober works and always disable it on any install that forces me to use grub. Actually, I despise allowing anything so fundamental as the kernel to be handled by anything automatic.

I agree, it's good that is supports automating tedious tasks, but having a choice of single monolithic configuration file is much appreciated.
My opinion is that bootloaders, kernels and rc scripts are critical parts of the system and should not be handled by automated tools by default.
There's certain security complications around some of these tools, it's common to see for example bouncer automaton gone rogue but compromised subsystem automaton can do way more damage than a simple bouncer.
So I'd prefer to edit config files by hand, at least on machines I'm responsible for.

1337_powerslacker · 08-24-2017, 08:54 PM

Quote:

Originally Posted by enorbet

Grub2 - I despise the way in which OSprober works and always disable it on any install that forces me to use grub. Actually, I despise allowing anything so fundamental as the kernel to be handled by anything automatic.

Updating kernels and their respective bootlopaders is most definitely the sort of job I want done right which means I must do it myself and not leave for anyone else no matter how good their intentions might be. That is only one reason I have been a Slackware devotee for decades and likely, that will continue for life.

Personally, I find grub too complex for the job it's intended to do. I'm of the school of thought that a tool meant to do a particular task ought to be as simple to use as possible. From what I've been able to gather, grub is best manipulated by automatic tools, because the syntax is too daunting for even geeks to hand-tune, let alone ordinary users. As long as LILO works (and I have no need of anything UEFI offers at this point, nor do I anticipate needing its services in the foreseeable future), I intend to keep on using it. As the old saying goes, "If it ain't broke..."

I agree that kernel updating is best done by hand, and is actually one of the big beefs I have with other distros that update automatically; that is, I have to a) wait for new kernels to be made available, b) said kernel is probably stock from kernel.org; and c) I may want to use -rc kernels if necessary. Slackware is simple enough to allow me to a) download new kernels as they become available; b) patch it for additional functionality; and c) if -rc kernels provide needed functionality, then I have the option to download it.

Just my

elcore · 08-25-2017, 01:31 AM

Quote:

Originally Posted by 1337_powerslacker

From what I've been able to gather, grub is best manipulated by automatic tools

I'd disagree, because grub2 is modular it only loads what is specified in the file, so the syntax can be very complex but also very simple.
It all depends on how it's packaged, and what commands run from doinst.sh. In practice, it can certainly be as simple as LILO if configured that way.
I wrote the static grub.conf manually which points to kernel symlinks, for me it's just a file that is written once and never touched again.
It doesn't need too be updated at all, I used menu.lst from grub-legacy the same way, only time I had to touch that file was installation time.
Building a kernel on this setup will end with "can't find LILO" but I already got a simple script which points symlinks to new kernel.
As I already mentioned it's a critical part of the system, I'll repackage it myself if the packager decides to mkconfig from doinst.sh.

luvr · 08-25-2017, 03:55 AM

Quote:

Originally Posted by 1337_powerslacker

Personally, I find grub too complex for the job it's intended to do.

That's my opinion, too.

Quote:

From what I've been able to gather, grub is best manipulated by automatic tools, because the syntax is too daunting for even geeks to hand-tune, let alone ordinary users.

The syntax only seems too complex, because that's what the automated tools make it look like. Manually writing a configuration file is not that hard, because you can ignore all the complexity that an automatically generated configuration file includes. (A bit like autotools will generate awfully complicated make files, while manually written make files will be a whole lot simpler.)

hazel · 08-25-2017, 05:33 AM

Quote:

Originally Posted by luvr

That's my opinion, too.

The syntax only seems too complex, because that's what the automated tools make it look like. Manually writing a configuration file is not that hard, because you can ignore all the complexity that an automatically generated configuration file includes. (A bit like autotools will generate awfully complicated make files, while manually written make files will be a whole lot simpler.)

That's what you do in LFS. They give you models for a handwritten grub.cfg file and the installed package doesn't include any scripts. The problem is that if you are dual-booting LFS with something like Debian, the Debian updates will mess up your grub configuration. That's why I use lilo but let Debian think I am still using grub. It stops me getting errors during Debian updates.

luvr · 08-25-2017, 06:23 AM

Quote:

Originally Posted by hazel

That's why I use lilo but let Debian think I am still using grub. It stops me getting errors during Debian updates.

Do you mean that you install LILO in your Master Boot Record (assuming your PC is running in Legacy BIOS mode), and install GRUB to the Boot Block of your Debian system partition? That's how I do it, except that my Master Boot Loader is still a GRUB Legacy version that I compiled myself a long time ago. It's showing its age by now, so I'm seriously considering migrating my Master Boot Loader to something better, and LILO seems like a great candidate to me.

I've also been wondering about some sort of Proof-of-Concept experiment, which would consist of using a Linux kernel with an Initial RAM disk (somewhat like how the Slackware installer works) as a boot loader (even though that would be serious overkill, for sure; that's why it would be just an experiment). I just wonder how I would then get the boot-loading kernel and the initrd loaded and started, and how I would have to boot an entry (be it through chainloading or through direct kernel and initrd loading) selected by the user.

hazel · 08-25-2017, 07:52 AM

Quote:

Originally Posted by luvr

Do you mean that you install LILO in your Master Boot Record (assuming your PC is running in Legacy BIOS mode), and install GRUB to the Boot Block of your Debian system partition?

No. I let Debian install GRUB to the MBR, then overwrote it with LILO from another distro. Since Debian still has all the grub configuration files, the apt system thinks I am using grub. Each time the initrd gets updated it updates the grub.cfg file, but that doesn't affect me any more. One of the few advantages of grub from my point of view is that updating it doesn't involve the mbr, so you can have what you like in there.

Quote:

I just wonder how I would then get the boot-loading kernel and the initrd loaded and started, and how I would have to boot an entry (be it through chainloading or through direct kernel and initrd loading) selected by the user.

If you had a uefi chip, you could boot a kernel directly from it, provided it had efistubs configured in. But using a Linux kernel as a bootloader would just be copying grub, because that's what grub basically is.

sundialsvcs · 08-25-2017, 08:08 AM

The kernel is simply another package, and it can be both installed and removed. Some distros, such as Ubuntu, program new-kernel packages to flag old kernels as "no longer used" so that their automated package-cleanup process will remove them. When a kernel package is removed, the boot-menu is updated as well. The most-recent kernel is the default but several earlier kernels are available as a fall-back.