Hi,

usually Liquorix is upgraded to new kernel versions (or should I say vice versa :-) ) quite quickly, which is great.

However, a problem for users can be the fact that all packages of the previous kernel version are removed from the (Ubuntu) repos quickly as well. Once uninstalled intentionally or by mistake, they can't be reinstalled. Patching and building the kernel from source is time consuming and will only appeal to a handful of users.

Unfortunately, there is some software around that usually won't run or build with the latest kernel, like VirtualBox. This issue hit me during the transition from 5.9 to 5.10, and by a stupid mistake I uninstalled 5.10 a couple of days ago and now I can't run VirtualBox anymore because it won't work with 5.11.

Therefore my suggestion is to always keep one package of the previous kernel version, preferably the latest, in the repos. I guess this would be appreciated by many users.


Cheers,
r.
Back to top

Try to change your own practices, I've never allowed kernels to be uninstalled, I install them manually, when I want them, and always leave at least one old one installed in case something is wrong with the new one. In some 15 years this practice has never failed, I install them manually, and remove them manually, and keep as many previous ones installed as I want. The system has no say in this at all, it's all up to me. I only install new kernels when I feel like doing it, it never happens automatically.

This hasn't changed for ages, and it works, the main culprit here is often using the kernel metapackages, which means you a re already trusting that everything will work perfectly with new kernels, and when the time comes for the system to get rid of old stuff, it does it automatically, more or less, at least that's how I understand metapackage installed kernels.

This is particularly relevant with using a frozen pool distro and a rolliing release latest current kernel, a combination which is almost always going to cause failures at some point if you use any dkms modules or rely on software that is kernel version dependent.

Using a current kernel in a frozen pool distro requires that users understand what that means, and understand how to maintain their systems, that's not really the job of liquorix in my opinion. Besides, the last good one might have been 2 or 3 kernels back, and you might only discover the issue at a later point.

You can always roll back to the distro kernel of course, then change the behavior to stop relying on automated updates of the kernel, which in my experience will almost always cause a failure at some point, particularly with dkms and laptops.
Back to top

Thanks for your reply. Usually I install and uninstall kernels to my liking without letting metapackages interfere too much, but in this case it was solely my mistake that I removed 5.10.

Please don't get me wrong - I'm not expecting the liquorix team to help maintain my system. But due to the high frequency of kernel updates, I still think that keeping one previous version at hand would be very helpful, be it for debugging purposes. It could be frozen with the last release before transitioning to the next kernel version, so there would be no extra effort aside from reserving ~100MB of server space.


Cheers,
r.
Back to top

he keeps a lot of kernels available, not sure for every distro, this is debian:



I don't know about the others, looks like the ubuntu ppa just has the one.

The AUR packagers only keep one, I don't know about if damentz runs his own arch pacman repo.

If it's the case that aur and ppa don't have old versions, that's all the more reason to manage your system more carefully.
Back to top

Thanks - I got your message, already with your previous post ;-)

Still, in Ubuntu it really seems to be just the one:



Meanwhile, I've built my own 5.10.17-lqx1-liquorix from source, but as said - this thread wasn't supposed to be only about me.


--
Back to top

Liquorix has always been a roll forward kernel. It's been up to volunteer work to archive Liquorix kernels and keep them somewhere else (smxi did this for some time). Not surprisingly, it costs money archive old kernels and make them easily available for anyone interested in them. Writing the code to do that and make the kernels easily available is really only a thing I'd do with a paid job, not on my free time. I'll never use the fruits of this work since it's more sustainable to just rebuild the kernel at an older git commit than fish through a website for an old binary that may not work anymore.

Regarding VirtualBox, I think something major happened inside the organization and they've having a really hard time keeping up with current kernels. It's unprecedented, perhaps due to a brain drain caused by the pandemic? We'll only really find out from an insider that decides to blow the whistle.

The answer you don't want to hear is you need to be able to adapt when running on rolling software updates. Things will break and it's up to you what your strategy to minimize risk is. For example, with how bad VirtualBox has been handling modern kernels, it's about the right time to take a serious look at alternatives. You have VMware Workstation (where VMware has been doing a MUCH better job than Oracle on kernel compatibility), and QEMU + friends, like libvirtd and the different interfaces. If I was in your situation I'd immediately figure out how to replicate my work environment somewhere else and plan to get off VirtualBox permanently.

If what I wrote above is too difficult and time costly, you NEED to switch to a frozen distribution and stick with their stock kernel. There's a reason people use Ubuntu and stay in the walled garden, you can treat your system like an appliance and it'll work stably until the next major update where a significant amount of time is required to update.

I hope I'm not preaching to the choir here, but it takes a certain attitude to run a system with rolling updates, and you're just dealing with the ordinary pain associated with it.
Back to top

smxi still does the kernel archiving, but that's only for Debian users, and will never be for any other distro because, well, that's, as damentz says, time that I don't want to spend, and I'd have to get paid to do it since it does me no good at all. It's a super low priority item for me now however, though I do tend to keep up with his latest last major versions a s a general rule, never with just latest sub versions of current major version.

It's very easy to volunteer others to do the thing you want done, but the people that are more impressive are the ones that do the things they want done, and do it for a long time, like the great guy who wanted stable frozen pool liquorix kernels, so he packaged those for years, until he stopped, since, well, we don't get paid for this stuff, and life moves on. But he was a great example of someone who wanted something done, and did it, and kept doing it for a long time.
Back to top