FS#16702 - [linux] Versioned Kernel installs
Attached to Project:
Arch Linux
Opened by Harley Laue (losinggeneration) - Friday, 16 October 2009, 20:32 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:22 GMT
Opened by Harley Laue (losinggeneration) - Friday, 16 October 2009, 20:32 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:22 GMT
This task depends upon
Closed by Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:22 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/linux/issues/10
Saturday, 25 November 2023, 20:22 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/linux/issues/10
It *does* add maintenance costs - on the dev side: changing the kernel26 dep and renaming the svn dir for each 2.6.X rebuild; and on the user side: manual maintenance in removing the old package when satisfied and changing grub lines.
Additional thought: the kernel26 package can contain dummy symlinks to files in the current kernel package, this way allowing grub and things of the like to remain unchanged for the purpose of tracking the most recent kernel.
kernel-2.6.99 contains /boot/vmlinuz26-2.6.99 and builds /boot/kernel26-2.6.99.img
kernel26 package has (broken) symlinks for /boot/vmlinuz26 -> the above, and /boot/kernel26.img -> the above
Additionally, lts is a different kernel. This mechanism allows for much easier and clearer upgrade paths and testing of new kernels, whereas the lts kernel follows a different path, and releases less often
I like the idea of having some fallback kernel, and this has been suggested, discussed and dismissed a lot. The problem is that pacman doesn't provide a mechanism to do this cleanly, and the solution suggested will result in a number of small issues we will have to work around, making everything quite complex. In short: I don't like it. I am hesitant to do anything like it without proper support for it in pacman.
So a list of things to consider:
* We currently hack the .Y (2.6.X.Y) version out of the kernel; if we do versioned installs do we continue to do this? I don't see how we can. It already seemed a bit odd to me, but I understand the intent (to not have to rebuild external kernel modules). How many of those do we have anymore?
* kernel26 being symlinks makes some sense. How would we pull in the new kernel packages? Bump kernel26 each time to depend on a newer version of the numbered packages?
* It would be trivial, but a cleanup script provided by kernel26 to only keep the last few versions would be nice. We don't see our users as stupid, they can do this as they please. Those with constrained /boot/ partitions will need to be careful, especially since pacman doesn't handle full partitions that well...
* What support from pacman would help here? A concept of a multi-versioned package or something? I can see other cases where this would be helpful (python 2.4, 2.5, etc.) but I'm not sure where we need some extra logic in the package manager. Another meta version parameter?
I think the kernel version hackery should stay, and is a separate, unrelated issue. That is more about the EFFORT to rebuild everything, not the impact on the end user.
pkgname=linux-2.6.30
pkgver=2.6.30.1 -> 2.6.30.99
kernel26 pkgver=2.6.30.X depends=(linux-2.6.30)
Then later:
pkgname=linux-2.6.31
pkgver=2.6.31.1
kernel26 pkgver=2.6.31.X depends=(linux-2.6.31)
This allows -Syu's to work exactly as they do now, with the added benefit/hindrance of NOT removing linux-2.6.30 when we upgrade to 2.6.31. That part will be up to the user
Only problem is we slightly lose with the current makepkg, as it doesn't deal with the way we need to do dynamic things very well (note that the function it will end up calling is an alias as bash doesn't support a declare syntax for dynamic function names):
$ makepkg
==> ERROR: missing package function for split package 'linux-2.6.31'
In this unstable environment, nothing should ever be forever unless the user wishes to deleted the older version. It should always be that the user can go back to the last configuration before the latest upgrade. But wasn't that the purpose of the fallback.img choice on the GRUB menu?
@Mr. K. I don't think fallback.img will help at all if the kernel (for whatever reason) doesn't work. fallback.img is just an auto detected initrd that in most cases /should/ work on your system. So if you screwed up an option in /etc/mkinitcpio.conf you'll still be able to boot. For similar reasons, at least one backup kernel/modules is good to have around after a new kernel upgrade. Thus this feature request :)
On a side note, I'm in the process of trying my proposed method above to see how it actually works.
The major things I changed from the current PKGBUILD was where the kernel version is declared, most of the time using pkgver instead of kernelname and removed most references to kernel26 in kernel26.install (not a full list, but there really wasn't much more then that.)
Here's a sample listing of what it installs:
kernel-2.6.30.1 /usr/src/linux-2.6.30-ARCH/
kernel-2.6.30.1 /lib/modules/2.6.30-ARCH/
kernel-2.6.30.1 /boot/vmlinuz-2.6.30.1
kernel-2.6.30.1 /etc/mkinitcpio.d/kernel-2.6.30.1.preset
Another question I suppose worth asking is kernel26-firmware, will that need to be updated upon each release as well? That is of course assuming a method like this is adopted.
Thanks for the good work.
In fact, I might add that I had always thought that was the purpose of the option during GRUB boot. If that isn't, then what is the point of GRUB? Who needs a menu when there is no choice. Since I found it wasn't the point, I'm lost with trying to figure out what it does. All very weird.
I've always been used to having a simple menu system that allowed me to boot into the partition I wanted to use. It didn't matter what partition, what OS or combination thereof the user wished to utilize. Then along comes the Arch install that reinvents a wheel that won't roll. I still don't understand the thinking behind this whole thing. How much better it would have been if we had simple gone forward from where we've been for fifteen years. One would add another item to their menu, and go from there. And if the package manager had installed a whole new OS kernel, then one should be able to assume that the fall-back system was standing by and ready to be used as a function of the package manager. We should have always been able to boot into a different (the old) version of an OS. All we need was for users to be able to step back to the previous, working setup. In this case, we don't even need a separate partition, since all is simple software replacement. Instead, someone went to a lot of trouble to make something broken by design. (How much more productive it is when we use our abilities to improve rather than reinvent. What wasted man-hours! But, hey, that's just my opinion.)
I've gone over the dialog here again. There is a huge amount of shorthand-speak that doesn't work in the real world, but I attempted to wade thru it. It appears that the issue can be simply stated as the need to make sure that a kernel does not have dependency problems. Is that the gist of it? Two points: 1. the kernel is supposed to be the lowest common denominator, so that shouldn't be an issue, 2. and in my case, all the upgrades I've done since that kernel was available have not caused any problem when I have reverted back to the older kernel. All is working fine now, including things that didn't work before. I have simply learned to avoid 2.6.30.6-1. I do realize that maybe that is just the chance of this combination of upgrades, but there may be no way to tell. It is at least worth trying another simple backup method.
Instead of changing pacman, why not make a simple reversion script? The purpose would be to take the last setup and put it back as it was. Not being sure of the exact inner workings of pacman, IMHO it may be that pacman would need to have an added function of logging the necessary details of the upgrade so that the added (or associated) reversion script would know what to do. This would be simple add-on script-like coding, rather than a complete rework of the program. I would definately not recommend anything that required any sort of reinvent.
In any case, thanks for the response and clarification. I'm glad I'm not alone in wondering about these things.
If not, what are the next steps?
I'm a very new Arch Linux user (approximately one week so far :-)). After a kernel upgrade, I wanted to revert to the old kernel to see if the graphics performance degradation I was seeing was related to the upgrade. Coming from a long history of other distributions, I was somewhat astonished to find the old kernel had been overwritten instead of preserved. More than any other component in the system, a failed kernel upgrade has the potential to prevent booting. A simple reboot into an old kernel is easy and convenient in other distros, and Grub is tailored for exactly this kind of setup. If the various kernels could be treated as separate packages, it would be easy for a user to periodically use pacman to remove obsolete kernels. I don't know how much impact this has on the larger system, although many of the suggestions in the above comments sound reasonable to my Arch-novice ears. Perhaps Subversion tags could be used to mark the location of older kernel PKGBUILDS, allowing development to continue in the kernel26 directory. These "tags" wouldn't necessarily have to live outside of trunk; they could be dropped peer-level to the kernel26 directory, so they are easily accessible to users via abs. I don't really know enough to make too many implementation suggestions, though. But as a user, I'm very much in favor of supporting the simultaneous installation of multiple kernel versions.
Thanks,
Michael Henry
I would suggest that those in the know first explain what is going on in creating the alternative boot setup that we currently have, so that all of us can understand where we stand now. I must admit that I still don't get it.
Thanks.
It sounds like we'd need to start storing kernels, initcpio images, and other relevant info in directories named for the pkgver and pkgrel. This starts to get complex, doesn't it?
I agree, it would be a great feature to be able to upgrade your kernel and trivially boot back into your old one if something went wrong. Can anyone lay out the full steps we'd need to do to make it happen?
Sometimes it might be useful to see the OS kernel as just another program to install. We know that it is possible to have more than one version of a particular program run in the same system. The complexity drops when we consider only one backup rather than multiple versions. It must be assumed that the old one was working and then new one was then added. That's only two. We've got that now, although useless, as another GRUB menu item. (Hopefully, we're not talking multiple boot partitions.)
The only thing we must keep in mind is that the kernel is separate from the other programs which may have been upgraded or installed at the same time. I believe that it is always important to upgrade the kernel separately from the rest of the system, so that the user can reboot and make sure it is working correctly before changing anything else. (I realize that this probably leaves a few things unsaid and assumed, but that's the general idea.)
Perhaps doing a "pacman -Syu" should note that a kernel upgrade exists first and do it separately with a required reboot notification. All other things should halt until this is done.
The alternative is that there is a lack of modularity in Linux, and such must be avoided at all costs. If it might be, as I suspect in this case, we begin to slide down that slippery slope, the whole system begins to be one humugous mess ala micro$oft. We cannot allow such a system to come into being. The issues of diagnosis alone dictate that this cannot be.
Thanks.
/lib/modules might not be a problem, except if the same 2.6.X is in testing, then maybe: /lib/modules/2.6.X-TEST
/kernel26-testing.img
/boot/System.map26-testing
/boot/vmlinuz26-testing
/etc/mkinitcpio.d/kernel26-testing.kver
/etc/mkinitcpio.d/kernel26-testing.preset
Since it is policy of Arch to make the user responsible for the configs, packages etc. it will not be a problem for an Arch user to manually update or remove kernel packages him/herself. Just make sure one kernel package does not overwrite another and leave the maintenance of /boot directory to the user. Arch devs need not worry about whether 1 kernel is installed or 5 or whether the /boot is small for many kernels . Let the user manage those things.
Please version the files in the packages also, like
/boot/vmlinuz26-2.6.35-ARCH
/boot/kernel26-2.6.35-ARCH.img or /boot/initramfs-2.6.35-ARCH.img (similarly for fallback)
/etc/mkinitcpio.d/kernel26-2.6.35-ARCH.kver
/etc/mkinitcpio.d/kernel26-2.6.35-ARCH.preset
I don't think any change is needed for /lib/modules directory
It was also stated before, that the user should not keep track of those things manually, but since arch-linux basically puts all decisions concerning updates to the user, i don't see why this shouldn't apply to the kernel. Maybe it would be possible to let pacman promt the user if he wants to keep old kernels once the user is cleaning the cache. (I mostly clean the cache when the disk is full and when my system is working like a charm)
Actually this problem keeps me from updating my kernel right now, because i need my computer to get some work done, and I don't wont to take the hassle to downgrade the kernel again if something goes wrong. I guess that applies to many users out there.
I keep tinycore linux in my /boot for recovery - it is nice 10M distro which works completely in initrd and can be booted even if whole arch is broken.
Also I have kernel26 in pacman's IgnorePkg and never update kernel while I have no physical access to PC.
"I keep tinycore linux in my /boot for recovery" "Also I have kernel26 in pacman's IgnorePkg and never update kernel while I have no physical access to PC."
The fact that you do this and feel it as a required precaution should pretty strongly reinforce that this is an issue. It's even laughable to consider this (tinycore in /boot) a simpler solution than having a versioned kernel. IMO it's not a fix, it's a work-a-round to the real problem.
Now, if enough users/developers feel this idea isn't following Arch's philosophies close enough, I propose that the kernel26-lts be added to the base group to be installed by default. This still far from ideal, but it'd be a better than nothing. (Don't think of this as conceding defeat. I still strongly believe that versioned kernels are not only a good option, but can even be done in such a way that it follows Arch's philosophies.)
So the kernel26-lts wouldn't be suitable as a stable option for a kernel to recovery boot into upon issues? I hope it didn't look like I was implying for it to be the default kernel to be booted into, rather, a stable kernel that can be relied on to at least always boot. Though, if it's going to cause serious issues, it does nothing for the other case where a versioned kernel would be nice, kernel regressions and driver breakages.
Sergej
I never said anything about it being difficult. It the case of KISS, simple is not defined as easy, it's defined as lacking complexity. Again, I feel that your solution isn't a fix to the issue. It's a way to ignore the issue till it happens, and then work around the issue when it does. It also doesn't do anything for if there's a regression introduced. In that case, all the livecd's and rescue partitions in the world won't be of that much help (because the old kernel is gone.)
May be repacman (http://aur.archlinux.org/packages.php?ID=35687) can back up kernel before upgrade?
1. There is a kernel26 (dummy package) will always depend on the latest kernel version available.
2. Installing a kernel upgrade will rename all the old files (kernel26.img etc) to a versioned copy (kernel-2.638.2 os something) so that everythin is still the same to the old Arch user (except for the additional kernel image, which could be deleted by a simple script or tool if the user wants to).
3. Kernel modules will be placed in a versioned directory, which is not deleted anymore when a new kernel is installed.
4. Every time kernel26 is updated, a new package kernel-2.6.x.x is created that has the exact same contents of the old kernel installation. This is the most tricky part: removing this newly added (and automatically installed package, as it was installed as kernel26) should remove every file associated with it. For an example on how this scheme could work: I remember that using the 2010-05 Arch install cd also renames several packages when you first update with pacman. The same renaming can be used here.
Just my two cents :)
You create many kernel packages, that place them at eg. /boot/kernels/<version> where installing each of them add an entry to grub, and deleting removes it.
The kernel26 package would have
depends=( kernel26-${_basekernel} )
And the install file would (in addition to any steps to add it to grub) do
post_install() {
ln /boot/{kernels/${_basekernel}/kernel26.img,kernel26.img.new}
ln /boot/{kernels/${_basekernel}/vmlinuz26,vmlinuz26.new}
sync
mv -f /boot/vmlinuz26.new /boot/vmlinuz26
mv -f /boot/kernel26.img.new /boot/kernel26.img
sync
}
Items like /lib/modules/<version>/ would be pinned by the version-specific package, forced by the depends.
You only need to update the vmlinuz26 and kernel26.img hardlinks as they are pointed by grub (you could as
well try to update its reference, but as that may be edited by the user, given how cheap hardlinks are,
it seems easier to do this).
conflicts=(!python=3.*)
The ! means, "doesn't conflict". The conflict for the kernel26 could look as follows:
conflicts=(!kernel26 kernel26=<3.0)
The above would mean, we don't conflict with any kernel26 version which is more than 3.0, since the older versions of kernel26 might conflict as they were not designed to work with the newer multiple versions system.
This would not only solve the issue for multiple kernel versions, but it will also simplify multiple other packages such as python. The future "linux-lts" package could simply just require a "linux/lts-version" package. The package repositories will need to support multiple versions of a package also, so python/2 and python/3 could be in the repo.
The only issue with multiple kernel versions is with boot loaders because the kernels would have to be in different locations to not conflict. The kernels would be placed somewhere like "/boot/kernels/linux-*" for each version. From what I understand is that there could be a grub2 script or even a grub2 module which could create the boot menu from different installed kernels inside the "/boot/kernels" folder. This would only support grub2. Grub1 and LILO users would need to manually change there configs to reflect new kernels.
For support with LILO/grub1 there could be a package which trials the latest kernel and provides a symlinks and depends upon the real kernel. A user would have 3 options, use grub2 and the automatic menu's, use the kernel trailing package or edit the config themselves. The trailing package could be something like "linux-symlinks", and the new linux package called "linux" (once 3.0 is released).
The only issue is that dependencies would have to support a new syntax, so you can provide a dependency to a certain set of versions such as python2-bla package would depend on python=2.*, if you have python/3 installed the installer should detect and then install the python/2 package alongside python/3.
The package repositores can continue to store python2/PKGBUILD and python/PKGBUILD but the package name inside the package would be the same "python". The linux kernel could adopt a similar pattern.
If a few people like this then I will file it as a complete new bug/feature report for pacman. I have tried to explain this as clearly as I can, I hope it makes sense.
It also requires support in pacman, so that we can automatically remove old versions. This will all go slowly and take a while, just wanted to let you know that we will start a process that will eventually lead to the resolution of this bug report.
$ cp /boot/vmlinuz26 /boot/vmlinuz26.old
$ cp /boot/kernel26.img /boot/kernel26.img.old
$ mv /lib/modules/`uname -r` /lib/modules/`uname -r`.bak
$ pacman -Sy kernel26
$ mv /lib/modules/`uname -r`.bak /lib/modules/`uname -r`
$ reboot
May be add key to pacman --no-delete-only-replace-and-add-new-files instead of 2 mv commands.
If we want to get fancy, then in addition to the above, we can do something similar to RHEL which updates the grub.conf at every kernel install. Grub would need to have a menuentry auto-added for each installed kernel (and the menuentry auto-removed when a kernel is removed), also like RHEL. The default menuentry would continue pointing to vmlinuz26 (the symlink), only additional grub menuentries would point to specific kernel files. This approach requires zero manual intervention from a user, it will "just work" -- when they reboot, they'll see menus for the latest kernel as well as entries for all the specific versions they kept around. I prefer the KISS approach of not auto-managing grub.conf, but at least creating the kernel packages such that they never conflict with another kernel package except over symlinks.
But adding kernel26 to IgnorePkg and writing 2 scripts (~/bin/upgrade-kernel.sh and ~/bin/remove-old-kernel.sh to clean up) is easy, simple and covers kernel upgrading issue.
Okay, before tons of bikeshedding starts, here it is: Eventually, each kernel package will have a kernel version like 3.1.X-Y-ARCH where X is the upstream patchlevel, Y is the pkgrel and -ARCH indicates that this is the Arch Linux kernel. This will take care of /lib/modules/* not conflicting. Kernel image and initramfs will have this version appended to its filename.
Now, the packages: The 'linux' package will depend on the following packages: linux-version-3.1.X-Y (this is the pkgname, without version) and linux-version-3.1.X2-Y2. The 'linux' package will also manage symlinks like vmlinuz-current and vmlinuz-old. Now, we need a new feature in pacman: we need to be able to obsolete a package so pacman uninstalls it on its own.
Anyway, this approach is not entirely thought out yet, I still see a problem when someone skips a few kernel versions, and with external modules. As I said, we will transition to this slowly rather than in one step.
I recommend that there is a config option in pacman.conf: KERNEL_VERSIONS or something simmilar. This should specify how much versions of kernel should be keept.
For example, let's say it's 3. When first 3 kernel versions install, nothing happens. But when 4th kernel update is installing, pacman should remove the first one. This could be done using a workarouond like this in .install file:
# do a standard depmod, mkinitcpio, create symlinks for new kernel to be run as default
#
# move the pacman lock so another instance of pacman can be run.
# This is save because one pacman is just waiting for the second one to finish, so pacman database is safe.
mv /var/lock/pacman.lock{,.bak}
# get number of kernels installed
num=$( ls -1 /boot | grep vmlinuz-linux- | wc -l )
if (( "$num" <= "$KERNEL_VERSIONS" )); then return 0; fi
# get oldest version and remove old kernel
version=$( ls /boot | grep vmlinuz-linux- | sort -n | tail -n 1 )
version=${version%vmlinuz-linux-}
pacman -R linux-$version
# get the lock file back
mv /var/lock/pacman.lock{.bak,}
pacman -S linux-2.6.32 linux-2.6.33 linux-2.6.34 linux-2.6.35
pacman -S linux
A user who manually installed these packages will not expect them to be removed automatically, but they would be. The other issue is that this may break if linux-lts uses the same system for versioned kernel installs (which it should).
pacman -S linux-lts # This installs linux-2.6.32-1
pacman -S linux # This installs linux-3.0.3-1 (the user already had 3 kernels before this)
The pacman -R will fail due to linux-lts depending on linux-2.6.32.
For these two reasons I think the user should remove a kernel manually and do not do this automatically for a user.
Imho there is no harm in keeping them, we should probably consider a feature like "autoremove" in apt, which removes previously needed, but now unneeded packages, with a hint anyway.
There maybe the problem that a user runs autoremove after installing a new kernel and then removes the current kernel, but I guess this shouldn't be a big issue for arch users.
1: Switch to GRUB2. GRUB 0.97 is undeveloped, patched like nothing else and is dead in the water. GRUB2 has grub-mkconfig and will detect everything in /boot, even Windows partitions on another disk with os-detect.
2: Keep one linux package that generates a different initial ramdisk upon installation/upgrade based on whatever version number you want. This will keep the old initial ramdisks available for use since they're not installed with the kernel, they're generated by mkinitcpio.
3: Call "grub-mkconfig -o /boot/grub/grub.cfg" in the kernel upgrade to re-generate the file. If it overwrites the file and someone has manually customised it, shame on them, because thats not how you modify GRUB2. If a user doesn't have GRUB2, the call will simply fail and the user can update their bootloader. If they're not using GRUB2, then they're probably doing something else, so they'd know what they're doing.
I think that's pretty KISS. I personally don't care about 3, because I know Arch is a bit more manual than others and I have no problem with typing a one-liner.
As a sidenote to Sergej, you say "Also I have kernel26 in pacman's IgnorePkg and never update kernel while I have no physical access to PC". Next time you're buying a PC/Server, get something with iLO, you'll have remote access to the entire system with actual video output, including full system BIOS access :).
@Mitchell: As for your opinion - I don't quite understand what you actually want to do, but you seem to think having a different bootloader will solve some problem. You also seem to think that now everyone uses grub and later everyone will use grub2. You also seem to think that regenerating a configuration file on each update using some voodoo script that we have no control over is a KISS solution. Whatever it is you're suggesting, it won't happen.
I am thinking about simply closing this report. It's going nowhere, everyone just posts new "solutions" that we simply won't implement. I posted a game-plan in an earlier comment, which will eventually be implemented. I consider this very low priority, and thus the required changes will be made slowly. Leaving more and more comments with brilliant "ideas" here (which spam my inbox with bugtracker emails) will not speed it up.
What I'm ultimately saying is to have versioned initial ramdisks, then new initial ramdisks can be generated upon kernel upgrades.
Lastly, no voodoo script by any means. I am only talking about one line to generate a new config for grub. It wouldn't be any more code than what's used to generate the initial ramdisk upon a kernel upgrade now.
I don't assume everyone to have grub as a bootloader at present, no. but those who don't follow defaults and want to do their own thing would be smart enough to deal with updating their bootloader.
Dan and I had a short informal talk recently, and it looks like we can solve this cleanly without having multiple packages of the same name. This requires some changes to the linux package, these changes will probably be done slowly starting with the 3.0 release - most importantly, the different kernel versions must not have file conflicts.
It also requires support in pacman, so that we can automatically remove old versions. This will all go slowly and take a while, just wanted to let you know that we will start a process that will eventually lead to the resolution of this bug report.
Could i ask if this particular work is advanced? Just for have a general idea on when this function will be available?
Thanks.
What I do is I just copy the current kernel with a different name. For example we are currently (at the time of this post) on 3.4.2-2-ARCH.
So I do a `cp /boot/vmlinuz-linuz /boot/kernel-3.4.2-2-ARCH` and `cp /boot/initramfs-linux.img /boot/initramfs-3.4.2-2-ARCH.img` and add the entries into my bootloader. Thus if I ever want to stay on that kernel, I can reboot into the old kernel (or set it as default).
The above method doesn't solve the "Temporarily unable to load my drivers in between kernel upgrades" but it does solve many other issues.
Recently, a kernel upgrade from 3.7.10 to 3.8.3 broke my co-worker's Arch. We had to use a usb drive, unlock LUKS, detect LVM, mount drives, chroot, reinstall 3.7.10.
All would've been simpler, had we the ubuntu-way of choosing older kernels in grub.
Please, think about it.
Thanks.
https://wiki.archlinux.org/index.php/Archboot#PXE_booting_.2F_Rescue_system
Being diligent I run pacman -Syu quite so often.
However I cannot afford to reboot as often.
so here I'm stuck, unable to mount -t cifs //... /..., and why?
uname -a --> 3.12.0-1-ARCH
find /lib/modules/ -name cifs\* --> 3.12.4-1-ARCH
I want at least modules for the currently running kernel to be kept around!
We still need a way to install each kernel version under a different file name and automatically update the boot loader afterwards, but I don't see a solution for this (the freedesktop.org bootloader spec is a start, but 1) you'd lose custom kernel arguments on each update, 2) only gummiboot and a patched grub even support the spec right now).
that's not really great either, arch updates kernel quite often and double kernel update will leave the system without a copy of working (currently running) kernel.
I suppose a working solution would look like this:
keep vmlinuz-3.x.y-m-arch # running kernel
keep vmlinuz-3-z-z-m-arch # newest installed kernel
vmlinuz # copy on FAT, symlink on ext*
same for initramfs
same for /lib/modules/xxx
This is actually not a bad idea. So the package would be linux310, linux312, etc..
let an example
kernel-3.14.0 provides kernel-3base
kernel-3.14.1 provides kernel-2base
kernel-3.14.2 provides kernel-base
then simply upgrade maintain 1 version of diference and keep only 3.
the drawback is that this will force rebuild of alredy buil packages for changin the kernel-type
or you can copy the Manjaro way and adapt it to Arch (bad idea but somone need propose it)
Additionally, @phrakture and I cannot be the only users irritated by such things as USB storage breaking upon upgrading the kernel. This is due to the old module directory being purged immediately and thus requires a reboot before new devices can be hotplugged.
I propose 3 possible solutions to this annoyance:
a.) Versioned/slotted kernels
b.) Build core drivers into the kernel (why for instance are ext4, btrfs, etc. a module?!?)
c.) Create a hook to optionally keep the old modules directory UNTIL reboot.
* modules for newest installed kernel
* modules for other installed kernels (if allowed)
* modules for current running kernel whether installed or not
It's not only about USB, it's also about all on-demand modules, including firewalls, virtualbox, etc.
Typical scenario is:
* boot, work a bit
* pacman -Syu
* start virtualbox, fail
I volunteer to help maintain packages.
As for kernels, we do it as we had before kernel 3.0, where there was a package kernel26(and a kernel24 when arch first started).
linux34, linux310, linux316.
We don't need patch level granularity as in 3.15.7, just minor version granularity.
I propose supporting all of the longterm kernels as found on the kernel.org homepage, as well as keeping a curret kernel.
I can also volunteer CPU and personal time to work on such if needed.
But that's not the issue here and it doesn't help solve the one proposed here when you consider that the current version of the kernel (3.17/16) and at least two of the LTS releases (3.14 and 3.10) get updated at the same time.
[1] http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/
If I were to implement something like that, at least for the initial introduction, I'd leave it as a service to be enabled, instead of implementing it as something that just happens.
As I have my Arch install on ZFS from the AUR, I wouldn't want to be without my data due to some possible issue with modules not building, or being unavailable until a reboot. (I may go months without a reboot.)
I have currently installed a kernel from the ABS. I've simply edited the PKGBUILD to change pkgbase=linux to pkgbase=linux-4.1.6-1, and built the package(s) as usual. The result was being able to install a new kernel and headers without overwriting the old ones. I've also created an empty dummy linux package for compatibility/dependencies.
Now obviously that means that building new modules such as ZFS means pointing the dependency to linux-x.x.x instead of just linux. I've also changed the module names in PKGBUILD to match the kernel it was build for (zfs-git-4.1.6-1). This means I can, if necessary, boot into the older kernel, and still having working modules for it too.
I know this sounds like extra work, but we use Arch because we aren't afraid of that right??
Perhaps instead of having AUR packages look for a specific version of the kernel, why not specify the kernel to build against during makepkg? (I had to fake uname -r to report the new kernel instead of the running kernel.)
makepkg --option <kernel-version>
-- or --
export KERNELVERSON=4.x.x
makepkg
For now, I'll keep experimenting with this to see how to runs in the long term.
There's more to this ticket than kernel in /boot though:
Most importantly, /usr/lib/modules/<version> must be preserved.
Ideally, DKMS should also be built for all preserved versions.
IMO, entire `linux` package content should be available for a) current version, and b) every version installed into /boot
1. Each kernel version has its own version-named package as described above (e.g. linux-1.2.3.4-1.2.3.4-1 where linux-1.2.3.4 is the pkgname and the second 1.2.3.4 is the pkgver),
2. Each one of these version-named packages will "provide" the linux-real=${version} package. That is, although each version-named package looks like a completely different package, it also provides a version of a common named target (i.e. linux-real),
3. A dummy package like linux-virtual-${version} will be created which always depends on the latest linux-real-${version} package and also contains the above mentioned symlinks. This installs the new kernel version as its dependency and leaves older versions installed as unused dependencies,
4. The linux-virtual dummy package also "conflicts" with the "linux-real<=${N older version as you wish}" and so all older kernel versions which provide those older linux-real targets are found by pacman and will be removed after getting a y/N confirmation from the user.
This requires no special maintenance script for removing old kernels nor any special support from the pacman.
Is that thing well tested?
From my first thoughts I would not do that automatically, but I'd love to have a command that could do it.
as nobody seems to be interested in implementing this and there's no real need to have fallback kernels of
the same branch.
I don't think that no one is interested in implementing it, I think that we just didn't come to an agreement on the solution to this issue.
E.g. read my comment above (https://bugs.archlinux.org/task/16702#comment143419). When you have a kernel in /boot and EFI is setup to start it (e.g. using gummiboot or systemd-boot), but the /lib/modules/${KV} directory associated with it is gone, the boot will fail. There will be no option left to boot into the system and one has to boot from another medium (e.g. usb drive) to fix this up by copying the newly installed kernel image into the right place (the place expected by EFI/gummiboot/systemd-boot).
1) boot up kernel X
2) update to kernel X+1
3) plug in usb stick/mount some filesystem/try to load any module not yet loaded
4) cry after you find out old modules (for the running kernel) are gone and you need to reboot
But still, it's just about the running kernel, not about multiple kernels.
This won't change anytime soon. So "Won't implement" and closing this one still makes sense to me.
Do we have any specification on how it is supposed to be implemented?
If not, then what i can do is:
- a systemd init script which copies the current modules into /lib/modules/current + cleanup of the old symlinks to current
- a post uninstall hook for the kernel which will detect and symlink if necessary 4.6.4-1-ARCH/ to current/
Is that solution OK?
Read my comment (https://bugs.archlinux.org/task/16702#comment149162).
Okay, before tons of bikeshedding starts, here it is: Eventually, each kernel package will have a kernel version like 3.1.X-Y-ARCH where X is the upstream patchlevel, Y is the pkgrel and -ARCH indicates that this is the Arch Linux kernel. This will take care of /lib/modules/* not conflicting. Kernel image and initramfs will have this version appended to its filename.
Now, the packages: The 'linux' package will depend on the following packages: linux-version-3.1.X-Y (this is the pkgname, without version) and linux-version-3.1.X2-Y2. The 'linux' package will also manage symlinks like vmlinuz-current and vmlinuz-old. Now, we need a new feature in pacman: we need to be able to obsolete a package so pacman uninstalls it on its own.
Anyway, this approach is not entirely thought out yet, I still see a problem when someone skips a few kernel versions, and with external modules. As I said, we will transition to this slowly rather than in one step.
----------------------------------------------------------------------------------------------------------
So what is the actual holdup on this?
As far as I can see, this can be done today, as long as users are responsible for uninstalling their own kernels (which is not an unreasonable idea).
Do we just need (questionable) support in pacman for obsoleting a package according to user-defined rules?
If so, has anyone opened a ticket against pacman and/or discussed it on the pacman-dev mailing list?
Because an excellent way to make sure it never happens is to forget all about it and then say no one is interested in it because no one is sure what they actually want.
It is as simple as defining a "conflict" rule from the virtual linux package to the older real linux packages.
What if a user skipped some kernel versions?
Define the "conflict" rule to N (e.g. 10) older versions and it will work flawlessly for users who are not N versions behind the Arch release cycle.
... I still don't see what is wrong with requiring users to manage their own orphaned packages, in which case this can be implemented as soon as someone decides they want to do it.
But if automatic purging of old kernels is what is stopping this from being implemented, it would be nice to at least know that that is the reason.
One is the inability to have multiple versions of the kernel at the same time. This is a problem in case you're not sure the new version works, and want an old one to fall back on.
The other is the inability to leave a copy in the filesystem of only the *currently running* kernel and modules. This is a problem for loading new drivers after an upgrade, or for hibernating and resuming system with the same kernel.
In order to solve the first problem, something akin to having a different package for each kernel version is required; and then there is the question of how to manage the old versions, via package conflicts, obsolete package feature for pacman, or just leaving it to the users.
In order to solve the second problem, a script which saves the current kernel and modules at init, perhaps with a bit more (see babali's comment https://bugs.archlinux.org/task/16702#comment149179) is enough.
Now, the question is, which of the two problems are we trying to solve? It is true that a solution for the first one also solves the second one, but is probably more complicated (hence the stalling).
I, for one, think solving the second problem is enough; and as AndyRTR commented here https://bugs.archlinux.org/task/16702#comment149173, for the fallback issue you have -lts kernel versions.
1) have all new kernels installed by default (i.e. have the linux package depend on the latest real kernel package).
2) have a post-install hook which will remove kernel packages, with a configuration file to specify how many releases of the kernel it should keep. It should always leave both the latest and the current running kernel in place.
What do you think?
Copying the kernel to outside of pacman's bookkeeping is ugly and not simple at all, besides which in order to actually use it in any way you'd need to copy it right back. In other words, you are literally trying to trick pacman into thinking a package is uninstalled while leaving the files exactly where they were.
...
As per the original intent of this ticket, the solution is *still* versioned kernel installs.
So-called "simpler" solutions are in fact more complicated, and IMHO against the Arch philosophy.
So, it would be nice to hear from the kernel maintainers if "automatic obsoletion of old kernels, possibly according to user-defined rules" is the only blocker.
Alternatively, bikeshedding is more fun than solutions, so carry on.
I agree that copying files outside of pacman's bookkeeping is not the most elegant of solutions, but it is a possible one. There are precedents for unowned symlinks, such as /etc/localtime, admittedly more in configuration than in binaries. Having a temporary copy of the current modules doesn't sound that bad, perhaps it can even sit outside /usr/lib/modules.
That said, I agree that having multiple kernel versions is definitely also a reasonable solution, and that Arch users should be able to manually manage them. At the very least, it is also possible to have a linux-latest package, so users which don't want to have this feature can go on with the current way of things. So, I second the question whether outside of the obsoletion managament, there are no problems with implementing this.
[1]: https://packages.gentoo.org/packages/app-admin/eclean-kernel
https://github.com/versusvoid/archlinux-kernels-backup
This should be rectified by causing the modules in the linux package not to be removed on upgrade if they correspond to the running version. Instead, the module directory should be marked for deletion. A script running at boot can then remove any old modules marked for deletion where they do not correspond to the running version.
Fix here seems simple using pacman builtin backup. pacman manages backup history depth already and $(pacdiff -o) will flag the offending files for the clean system purists in us all. No less elegant than the way /etc/pacman.d/mirrorlist is handled -- well, excepting that these are binaries. These would be natural pairs having been owned by the same package before orphaning.
In kernel packages:
-backup=("etc/mkinitcpio.d/${pkgbase}.preset")
+backup=("etc/mkinitcpio.d/${pkgbase}.preset" "boot/vmlinuz-${pkgbase}" "boot/initramfs-${pkgbase}.img" "boot/initramfs-${pkgbase}-fallback.img") #fallback merit contestable
Bootloaders then need to know how to find these and register them. Looks like grub already does in 10_linux through flagrant wildcard use. Otherwise, light sed/awk lines in the PKGBUILD can clone out for finding .pacsave suffixes and adding below the primary boot cases.
EDIT: The first word in this report is "Versioned" and I acknowledge I ignored that, but it's not an altogether inelegant idea despite being admittedly limited.
https://bugs.archlinux.org/task/51873
As this issue has been closed with reference to this task (which is ok) and a thoroughly shitty comment (which is not ok), I move here.
If I understand correctly, this issue is in "undecided" state since 2009. Looking at the technicalities, I am not sure why.
The Linux Kernel deployment mechanism is such that several kernel versions may be installed in parallel on a given system.
Why does Arch not make use of that?
Where is the insurmountable problem of having a (configurable) keep last N kernels option, where N can be - say - 3?
What problem is there to at least provide a compatibility symlink for same kernel versions of an older patchlevel?
And finally in reference to the aforementioned shitty comment in task 51873: So if Arch decides to update the Kernel package it really is considered a "bug" on the users side to not immediately reboot? Srsly?
There is no guaranteed compatibility even between kernels of the same minor version, so allowing new modules to be loaded into an old kernel is unsafe and may cause crashes or irrecoverable corruption. This has bitten us in the past.
Yes, after a kernel upgrade you need to reboot if you want to load any modules.
BOTH kernels were 4.8.8
And you are wrong - BTW - with the compatibility between kernels with minor version difference.
see here:
https://lkml.org/lkml/2011/5/29/204
https://en.wikipedia.org/wiki/Linux_kernel#Version_numbering
Quote: "An additional number (now the third number) would be added on when necessary to designate security and bug fixes, as for example with 3.0.18"
You will never have API, IOCTL or otherwise binary incompatible changes with different minor versions. Show some counter-example.
I moved my notebook from Gentoo to Arch to test how things go here. Not having to compile is nice. But do I understand correctly that there are no different versions (ok) and not even "Slots"? of packages?
IIRC the whole Nvidia-OpenCL stuff pulls in a gcc5, while the system has a gcc6?
So no way to have PHP 5.x and PHP 7.x at the same time?
And no, I cannot accept to have to reboot after a 4.8.8-1 to 4.8.8-2 "upgrade" (you may want to look up the meaning of "upgrade")
There are no slots. There can be at most one package with a given name installed. You can have multiple versions of the same software, but you need to give them separate names. As far as the repository and package management is concerned, that makes it separate software.
In the Debian/Ubuntu world, `linux-image...` is a metapackage that always points to the current kernel. This allows for tracking new kernels without immediately removing the old one, and users/admins the freedom to reboot when they choose to, as there are no slots in that packaging system either (and authoring a deb is a lot more work than writing an equivalent PKGBUILD). This could be an acceptable mechanism to implement this without needing to make significant changes to pacman and packaging tools.
With regards to KConfig having the possibility to break ABI for modules, that is true. Kernel ABI compatibility is guaranteed for the userspace ABI only (see: https://www.kernel.org/doc/Documentation/stable_api_nonsense.txt)
pacman is capable of not removing files it installed on install when a package is removed, like any package manager. Simply mark kernel modules as such files and use a hook script executed on boot/shutdown/after pacman execution which cleans up any modules which match neither the installed package version nor the currently running kernel version.
The problem with your solution is that it doesn't actually work. pacman is not, in fact, capable of *not* removing files in a package when it uninstalls the package. Not unless you extend pacman first, by which logic you can do a lot of things. And as has already been noted, extending pacman itself for the specific use case of the linux kernel is ugly.
@heftig,
"Putting a version into the package name causes a large maintenance burden on the side of the repository (the repository management being nearly unmaintained is the reason we're still stuck with SVN)."
What exactly is this maintenance burden? I cannot say I have personal experience, but I would assume the repo management already knows how to handle split packages when the pkgname array changes from one version to the next. Unless you are saying that when part of a split package is removed from the PKGBUILD, it falls out of sight and manual work is required to purge it from the repos? In that case, maybe this is an opportunity to fix something. :p
Saying "this particular solution won't work because the repo management is unmaintained" is, as @Commod0re said, a poor reason to waffle, but moreover, it is essentially saying "we have no intention of dealing with this bugreport in any way, because it involves WORK".
So it is unmaintained -- if you (rhet.) are motivated to solve this bug, you can one-off patch the repo scripts, and then let it languish unmaintained again. Unmaintained just means nobody cares about it, not that it is impossible to work on it.
Is that the blocker then? (Were you wearing your Arch Dev hat when you said that?)
...
Or, does anyone know what the blocker is?
I really want to hear from someone who can say "this is what we need in order to have versioned kernels, if you implement it I will push in support of finally fixing this".
Going over the comments again, it seems there are two serious concerns raised by the people actually in charge around here.
@brain0 mentions earlier ( https://bugs.archlinux.org/task/16702#comment80122 ), that he wants a way for pacman to obsolete and remove old versions automatically. Additionally, the bootloader would need to be reconfigured on every update because not all bootloaders support symlinking a *-latest kernel/initramfs. (I am looking at you, UEFI/ESP on stupid FAT!)
Old versions IMHO are the user's responsibility, but an argument could be made that stuffing the ESP with obsolete kernels is a bad idea. ;)
Grub could ship a pacman hook to update via grub-mkconfig after (versioned) kernel installs -- this might not be a terrible idea anyway, and users are as always free to disable hooks they don't like. So much better than in the install script which can't be disabled!
I don't know about other bootloaders, how easy it is to update automagically.
2) If you really want to install a kernel outside of pacman, there are plenty of ways already. Any solution MUST involve pacman continuing to know that the files exist, or else there is no point of using package managers and we might as well go back to the old days of installing software via `./configure && make && sudo make install`. Or untar'ing the *.pkg.tar.xz into / so it is present on disk but we don't have to worry about pacman knowing about it.
Untar'ing it by hand actually works really well, if you just want to cut it adrift from pacman, why keep around a dummy package which doesn't do anything?
To add insult to injury, pacman would get all worried when about 5000 files drop off the face of pacman, and end up being profoundly irritating.
...
Both those ideas were rejected already, and not only because they have nothing to do with the actual request of this task.
If you have any more horrible and ill-thought-out ideas, please don't mention them. Your comment is the poster child for @brain0's previous comment:
"I am thinking about simply closing this report. It's going nowhere, everyone just posts new "solutions" that we simply won't implement. I posted a game-plan in an earlier comment, which will eventually be implemented. I consider this very low priority, and thus the required changes will be made slowly. Leaving more and more comments with brilliant "ideas" here (which spam my inbox with bugtracker emails) will not speed it up."
Might I add that the aforementioned brilliant "ideas" have already long since driven that particular Arch dev to unsubscribe from this task? Good going, everyone, hope you are happy now you had a chance to talk...
I, personally, just want to know what the status is of the official, blessed "best solution", and how that can be brought to fruition faster if possible.
One month in Arch and already great cinema.
You know - if you "all" want to have a "task" open for over 7 years and dancing around why a solution is not possible, it's actually fine with me.
I'm perfectly fine to keep Arch contained on my notebook only and spare the other dozens of machines that are on a rolling release distro. I also can endure this little hassle, because for me, it is either putting the linux kernel in IgnorePkg=linux or
# /lib/modules
drwxr-xr-x 4 root root 4096 Nov 22 20:04 4.8.10-1-ARCH
lrwxrwxrwx 1 root root 13 Nov 18 09:53 4.8.8-1-ARCH -> 4.8.8-2-ARCH/
lrwxrwxrwx 1 root root 14 Nov 22 22:17 4.8.8-2-ARCH -> 4.8.10-1-ARCH/
Because after it upgraded to 4.8.10 yesterday and NFS stopped working and you really F***ING expect the user to reboot, then you have a distro that is worse than Windows95. But hey - as long as *I* can fix it, no hard feelings.
It should become top priority.
>Untar'ing it by hand actually works really well, if you just want to cut it adrift from pacman, why keep around a dummy package which doesn't do anything?
Old modules can get cleaned up by the cleanup script, not the package manager. There's no particular reason why we should be bothered as to whether it's pacman or another mechanism managing the lifetime of certain files, and many files on the system with managed lifecycles are managed by other processes. The proposed solution provides mechanisms which ensure that all of the files exempted from package manager cleanup are cleaned up by other means. There is no leakage here. No currently available solution, or your suggestion of just installing a kernel manually, offers this.
>To add insult to injury, pacman would get all worried when about 5000 files drop off the face of pacman, and end up being profoundly irritating.
What on earth does 'worry' mean in this context? This is not scientific language.
https://www.reddit.com/r/archlinux/comments/4zrsc3/keep_your_system_fully_functional_after_a_kernel/
It just keeps the running version of kernel modules when upgrading.
Let the kernel package install a flag, e.g. /boot/outdated-initramfs.
Let mkinitcpio remove the flag on successful completion.
Let grub skip the initramfs if the flag is present.
The response by Dave Reisner (falconindy) - Monday, 15 May 2017, 09:54 GMT-8
>You have a fundamental misunderstanding as to how the boot process works.
That may be, I'm used to u-boot. Does grub have no way to do the above?
Please don't spam unrelated bugs, just because that bug (
FS#54052) was closed doesn't mean you can just carry on that bug's conversation here instead.https://github.com/versusvoid/arch-linux-rolling
Grub hook must be more sophisticated though.
IWD is strongly relying on kernel crypto. Therefore if you install a new kernel and don't reboot after it and try to restart the iwd daemon it will not work because of missing kernel crypto modules..
Nope, it's not. See discussion (https://lists.archlinux.org/pipermail/pacman-dev/2016-September/021400.html) about patch I proposed with this "ability".
Kernel package can be versioned and managed somewhat similar to java-runtime, but maintainers just do not bother.
Missing kernel modules is not the only issue. There is also the hibernate-restore issue.
IMHO, implementation of a convenience feature that enables installing a new kernel 'long' before a reboot is not worth much effort and/or code complication.
Add a --unignore flag to pacman's -S mode that will tell pacman to treat all packages in IgnorePkg as if they were explicit targets. Then, `pacman -Suy --unignore` would ask:
:: linux is in IgnorePkg/IgnoreGroup. Install anyway? [Y/n]
:: linux-headers is in IgnorePkg/IgnoreGroup. Install anyway? [Y/n]
:: acpi_call is in IgnorePkg/IgnoreGroup. Install anyway? [Y/n]
That would simplify a just-before-reboot upgrade without having to remember which packages are currently being ignored by pacman.
The problem is that running pacman -Syu might break your system and force you to reboot.
This issue is quite trivial. To be honest I can't explain why it is not fixed already.
I would like to support this and care for it. The current situation is indeed annoying and I don't see any other solution for it in the near future?
Opinions?
Yes falling back to LTS kernel works as well.
Manjaro has similar scripts, which provably resulted in unbootable systems because they were broken and deleted /usr/lib/modules, thereby removing all modules for all kernels, both the booted kernel as well as any newer one that was installed. (Also, I believe they installed the broken script by default.)
This "solution" has been suggested and rejected a number of times in this bug report. It is attempting to solve one half of the problem at completely the wrong level, results in pacman not knowing what files exist on the system, and is racy. I don't believe we should do it.
The status has not really changed since 2011 (per https://bugs.archlinux.org/task/16702#comment80122 and https://bugs.archlinux.org/task/16702#comment82408 ), as far as I'm aware. The kernel can and should be versioned, which allows you to both boot from and load modules from multiple kernels, and currently the only conflicts between packages are the files in /boot, /etc/mkinitcpio.d and /usr/share/libalpm/hooks. All we need is, for kernelname=linux :
1) Rename those files from *${kernelname}* to *${kernelname}-${kernelversion}*, and rename the package to pkgname=${kernelname}-${kernelversion} and create a dummy "${kernelname}" package which depends=("${kernelname}-${kernelversion}").
2) Copy/symlink the bootloader files. A post_install/post_upgrade script in "linux" which checks whether /boot is a fat* filesystem and either symlinks /boot/vmlinuz-${kernelname} to /boot/vmlinuz-${kernelname}-${kernelversion} or copies it, for example, by running `if [ -f "/boot/vmlinuz-${kernelname}-${kernelname}" ]; then ln -sf ... 2>/dev/null || cp ...; fi`. mkinitcpio could have an extra hook which generates a second initramfs, but ideally would learn to copy over the existing one. Since the preset is written in bash, we could just inject the same ln command with naming tweaks, and then exit 0.
3) Someone needs to db-repo-remove old ${kernelname}-${kernelversion} packages from the official repositories, to prune cruft. This could be automated via a small shellscript stored in svn instead of running testingpkg + testing2x, or for bonus points, implement automatic removal of no-longer-existing split pkgnames in dbscripts and I will gratefully merge it as there are already plenty of cases where this is needed by hand (even if it isn't a regular fact of life for any given package).
...
Points #1 & #2 are trivial to implement, but it adds maintenance burden for #3.
Assuming linux-lts is regularly confirmed as bootable on the machine in question, and was not updated at the same time as linux (thus becoming not confirmed as bootable) , yes, it would be more useful.
Accidentally that solution works and integrating it is trivial. I bet your solution won't happen in next few years.
You can see my PKGBUILD here: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=linux-versioned-bin
This PKGBUILD is fetching the already-built linux{,-headers,-docs} packages from a mirror or the Arch archive, and repackaging them with some changes. Those changes are:
* Including the full arch package version number in the names of the packages themselves
* Replacing the contents of /usr/lib/modules/<version>/pkgbase with the kernel name and version (in the same format as the name of the directory for the kernel in /usr/lib/modules). This is what mkinitcpio sees and uses as the name of kernel - so that's what shows up in GRUB for example.
* Using the versioned package names instead of pkgbase in the symlinks /usr/src/<pkgname> and /usr/share/doc/<pkgname> in the headers and docs package
There are three dummy packages: linux-versioned-bin, linux-versioned-headers-bin, and linux-versioned-docs-bin, which depend on the latest versioned packages; and three packages at any one time, linuxX.Y.Z-archN-M-bin, linuxX.Y.Z-archN-M-headers-bin, and linuxX.Y.Z-archN-M-docs-bin for the latest kernel, headers, and docs packages themselves.
Since the package names change when the PKGBUILD is updated, when there is a new version the old ones simply vanish from the AUR. They won't be removed locally from your machine of course - up to you to remove orphan packages at some later time.
The linux-versioned-bin package optionally depends on the AUR package grub-hook: https://aur.archlinux.org/packages/grub-hook/ , which is a pacman hook to run grub-mkconfig after kernel changes. If you use grub (and don't roll your own grub.cfg), you'll need to do this one way or another, and with the hook it is automatic, so highly recommended.
The package also conflicts=(linux), so you'll need to remove the main kernel to test it, and switch to dkms versions of any out-of-tree drivers you need.
If this approach were replicated in the official packages, I think this step mentioned by Eli would be the remaining thing to be done, otherwise if I'm understanding correctly the old packages will remain in the repos:
> for bonus points, implement automatic removal of no-longer-existing split pkgnames in dbscripts
I'll also make a non '-bin' package based on [core]/linux - just avoiding local compilation for now since the kernel takes ages.
Feedback appreciated, I'm not responsible if you make your machine unbootable ;).
I'm confused by this. Just remove the packages and the cpio archives as usual using a default systemd timer (monthly?) that calls pacman. The bin package worked great on real Arch (and only minor tweaks were required locally to adopt) and should also work for community if there is interest in adopting - nothing changes for existing kernel maintainers in core/community. KISS method and I like it. So, for the remaining blocker, what's wrong with adding a simple monthly systemd timer? A user can always create a copy in /etc and make it run more or less frequently. They can do the same with the LTS packages. Add the timer to the grub-hook package (probably rename that as something to do with "kernel-maintenance") and allow for differing retention and initrd naming scenarios (use an array for filenames and include all common names currently in community packages), and enable it by default as part of post-install. For community adoption, your split meta package gains a hard dependency on what is currently named 'grub-hook' and both provides and replaces the equivalent core/community packages. If one of the other Arch consumers adopts it as well, it's a simple change for a cron-monthly job instead of a timer. Also, there is probably no reason to keep all of the fallback images, only the latest. I believe this addresses the remaining concern for users.
AFAICS, although technically addressed in the above, two previous points of contention do actually remain: the removal is not done as a part of regular package maintenance (pacman -Syu), but old packages will be removed, both predictably and consistently; and whomever maintains a like package in community will have to retire the old packages manually. I'm not familiar with how Arch community maintains their repos. Major overkill IMO, but if it is still a point of contention that last part could easily happen with a similar maintenance script that simply runs repo instead of pacman with retention set to 1. Anyway, I'm going to use similar locally. Thanks again.
As far as a prune script, somebody more competent than I can probably use awk for list, but something like the following works:
ret=1
list=`pacman -Qs ^linux[0-9] | grep -vi -e doc -e headers -e "^ " | cut -d " " -f 2 | sort -t. -k 1,1n -k 2,2n -k 3,3n -k 4,4n`
vers=($list)
rems=$(( ${#vers[@]} - ${ret} ))
if [ "${#vers[@]}" -gt "${ret}" ]; then
for pkgver in `echo "${vers[@]}" | tr " " "\n" | head -n "${rems}"`; do
echo "pacman -R linux${pkgver}{,-docs,-headers}-bin"
done
fi
I'd be happy for removal of locally installed kernels to be entirely the user's problem and not automated as part of the packages themselves, I think that would be in line with KISS principles.
The approach I'm taking with the AUR packages linux-versioned-bin [1] and linux-lts-versioned-bin [2] (which it sounds like you're using?) is to have a separate script remove-orphaned-kernels [3] that uninstalls orphaned versioned kernel packages, other than the one currently running. The user could run this script on a timer if they want, or the package could ship a timer, but I like just running it manually every now and again just like I would clear the pacman cache or other occasional system maintenance.
But yes, I think the blocking issue is with removal from the Arch repo database, and I am not familiar enough with how that works to contribute a fix for that.
[1] https://aur.archlinux.org/packages/linux-versioned-bin/
[2] https://aur.archlinux.org/packages/linux-lts-versioned-bin/
[3] https://aur.archlinux.org/packages/remove-orphaned-kernels/
I'm, because of this, no fan to keep old kernels around by default.
The only deficiency that I can see is the maintainer load. What I posted earlier addresses that nicely for me in an automated way, but I'm a one man shop and I don't know how the community maintainers manage their repo. This is three full package removals, three new packages, and three package updates with each new kennel version, not just updating existing packages. This probably does not fit well within the normal maintenance routine. Again, I don't know for certain, but I certainly wouldn't find it unreasonable for new package additions and removal of existing packages to require some form of consensus for accountability. This would definitely qualify as an outlier, and would require a new internal process.
https://github.com/djlucas/LFS-Pacman/tree/master/Main/linux-5.8.5-kernel
https://github.com/djlucas/LFS-Pacman/tree/master/Main/linux-5.8.6-kernel
https://github.com/djlucas/LFS-Pacman/tree/master/Main/linux
Oh yeah, please ignore any meandering comments - LFS's primary goal is user education, so like my posts, they sometimes get long-winded to avoid ambiguity. Also, please don't try to use anything else from that repo on Arch, or at least not as is - it very likely it will break stuff (LFS still uses split /usr, custom CA certificate utilities (though that might actually be worth looking at for the Arch developers given the ease of local modifications I came up with for make-ca/p11-kit and minimum deps), sysvinit not systemd, etc).
But IMHO the following "clean-up mechanismen" not to be considered as "ugly", as it is one working automagically:
The "old" modules have some meaning while the corresponding kernel is still up and running, but not beyond. So why not having the "old" modules in a tmpfs volume mounted at /lib/modules? They will be available as long as there is their kernel running having potential interest in them, but they are guaranteed (!) to be gone upon next boot. The point is that the on-disk state is the very same as with the current solution. A common shutdown, a crash or powerloss - it doesn't matter, there is no additional cleanup required, both old booted kernel and its modules will be gone.
What do I miss?
The TMPFS-solution will only exist after having upgraded your kernel and last till shutdown. That means, it will be created not by an early systemd service all the time, but by pacman after kernel upgrade only. Consider it as a post-install hook of kernel packages. That means btw, that it would be easy to give the user a choice by an EXECUTE_MODULES_PRESEVATION_HOOK FALSE|TRUE option in pacman.conf or whereever. With defaulting to false, nothing would change for most users (reasonable, since most users will reboot immediately after kernel upgrade), but would give those who can't reboot immediately the possibility to alter the behavior.
[~]$ du -hs /usr/lib/modules/`uname -r`
92M /usr/lib/modules/5.8.0-pf5
Also, tmpfs doesn't consume all the reservation. Only what's being really used is… erm… used.
[pkguser@archtest3 ~]$ du -sh /lib/modules/`uname -r`/
442M /lib/modules/5.8.10-arch1-1/
[pkguser@archtest3 ~]$ pacman -Q | grep dkms
[pkguser@archtest3 ~]$
So the solution is effectively something along the lines of:
/usr/share/libalpm/scripts/kernel-pre-upgrade.sh:
TMPDIR=/tmp/modules-`uname -r`
install -vdm750 "${TMPDIR}"
cp -R /usr/lib/modules/`uname -r`/* "${TMPDIR}"
and
/usr/share/libalpm/scripts/kernel-post-upgrade.sh:
TMPDIR=/tmp/modules-`uname -r`
SIZE=$(du -hs /tmp/modules-`uname -r`/ | awk '{print $1}' | tr [:upper:] [:lower:])
# Give a little breathing room.
TSIZE=$(echo ${SIZE} | sed 's/[a-z]//')
TSIZE=$(( ${TSIZE} + 1 ))
SIZE=$(echo -en ${TSIZE}`echo ${SIZE} | grep -o [a-z]`)
mount modules -t tmpfs -o size="${SIZE}" /usr/lib/modules
install -vdm755 /usr/lib/modules/`uname -r`
cp -R "${TMPDIR}"/* /usr/lib/modules/`uname -r`
rm -rf "${TMPDIR}"
I'm not sure how to handle the hooks themselves, but that's ancilary for this part. Is that kind of what you were thinking? It works, the memory used temporarily is almost double the size (as predicted), but frees up as expected. The only caveat I can see is DO NOT do two kernel upgrades without a reboot in between. If you do your updates every night at 3:00 AM and reboot on the weekends, you will create a problem.
To me having a broken system after upgrade is much more MS like...
Look, after an upgrade the kernel image file is gone from disk, but still existent in RAM till reset. Don't you think it has it's logic to treat it's modules in an identical way?
That said I agree that there are very likely much better solutions, I just think my proposal is a good tradeoff for the time being, especially as it can't cause any harm if you don't opt-in to the hook in pacman.conf.
pacman -Suy linux linux-headers linux-firmware
You can run remove-orphaned-kernels after every update if you like, then you'll have at most one extra kernel installed (the currently running one, since it will never remove that). Mid update (after pacman -Syu but prior to running remove-orphaned-kernels), you'll have at most two extra kernels (the currently running one, and the second most recent one, if different), or three if you have both the lts and regular kernels. So if you run remove-orphaned-kernels after every update, your EFI partition needs to have space for three kernels, or four if you have both lts and regular kernels. With a 500MB EFI partition I haven't had an issue with space yet.
Integrating "kernel-modules-hook" may alleviate most of the issues here.
I've put it into a separate feature request, as it is not a versioned kernel install, but only a more streamlined kernel install until rebooted.