Most books and courses introduce Linux through shell commands, leaving the kernel as a mysterious black box doing magic behind the scenes. In this post, we will run some experiments to demystify it: the Linux kernel is just a binary that you can build and run.
I agree that it’s be useful, and I think you can just install e.g. the LTS kernel next to the regular one.
But even without , the arch way isn’t insane either: when something kernel-related breaks, boot with a live system on USB and fix it.
Case in point: I dimensioned the EFI partition too small, so at some point, me using the zen kernel (which comes with a backup kernel image) messed things up and I couldn’t boot a half-written kernel.
then I
created and booted a live USB stick,
Mounted my / and /boot partitions manually into /mnt/root/ and /mnt/root/boot
Bind-mounted the live system’s /dev and /proc into /mnt/root/{dev,proc}
chrooted into /mnt/root (resulting in an environment using /dev and /proc from the live system and the rest from my system),
Used regular package manager commands to uninstall the zen kernel and install the regular one, and finally
rebooted into the now working system.
It’s not crazy, it doesn’t take long, you just need to know how the system works. Upside is that nothing ever breaks permanently, everything is fixable (except hardware failure)
But even without , the arch way isn’t insane either: when something kernel-related breaks, boot with a live system on USB and fix it.
That is not a replacement for “arrow-key down during boot to select an older kernel”.
I have a server with a RAID card and the kernel at some point introduced a bug with the driver that prevented that server from booting. So I select the older kernel at boot, get the system up and running, mark that kernel as the default until the bug is fixed.
It’s not crazy, it doesn’t take long, you just need to know how the system works.
I know how the system works very well thankyouverymuch. But that’s an insane option when having multiple older kernels is so easy to do and common.
The reason there’s no version in the filename is simply that Arch just doesn’t keep old kernels around.
The
vmlinuz-linuxjust gets replaced whenever you update thelinuxpackage and the old one is deleted immediately.That’s… Insanity. Keeping at least one old kernel is amazingly useful if you run into issues with an update.
I agree that it’s be useful, and I think you can just install e.g. the LTS kernel next to the regular one.
But even without , the arch way isn’t insane either: when something kernel-related breaks, boot with a live system on USB and fix it.
Case in point: I dimensioned the EFI partition too small, so at some point, me using the zen kernel (which comes with a backup kernel image) messed things up and I couldn’t boot a half-written kernel.
then I
/and/bootpartitions manually into/mnt/root/and/mnt/root/boot/devand/procinto/mnt/root/{dev,proc}/mnt/root(resulting in an environment using/devand/procfrom the live system and the rest from my system),It’s not crazy, it doesn’t take long, you just need to know how the system works. Upside is that nothing ever breaks permanently, everything is fixable (except hardware failure)
That is not a replacement for “arrow-key down during boot to select an older kernel”.
I have a server with a RAID card and the kernel at some point introduced a bug with the driver that prevented that server from booting. So I select the older kernel at boot, get the system up and running, mark that kernel as the default until the bug is fixed.
I know how the system works very well thankyouverymuch. But that’s an insane option when having multiple older kernels is so easy to do and common.
As said: installing the LTS kernel also works, I think.
And you wouldn’t use Arch for servers, you want something stable (as in “rarely changing”) there.