Versioned Kernel installs
| Task Info (Flyspray) | |
|---|---|
| Opened By | Harley Laue (losinggeneration) |
| Task ID | 16702 |
| Type | Feature Request |
| Project | Arch Linux |
| Category | Packages: Core |
| Version | None |
| OS | All |
| Opened | 2009-10-16 20:32:32 UTC |
| Status | Assigned |
| Assignee | Tobias Powalowski (tpowa) |
| Assignee | Jan Alexander Steffens (heftig) |
| Assignee | David Runge (dvzrv) |
| Assignee | Levente Polyak (anthraxx) |
Details
The problem: The current method of upgrading kernels will remove the current kernel, modules, and initrd on upgrades. This is a problem because: imagine if the new kernel has a serious regression in it on your hardware, or worse yet, it doesn’t boot at all. Now all of a sudden, the user is stuck with no clear, straight forward path to fix the issue.
In a nutshell: kernel26 will become a dummy package with a dependency on kernel-${version} and symbolic links will be updated post-upgrade to the newly installed kernel/initrd.
Detailed reasoning for this solution: Every kernel PKGBUILD will have a version number in the pkgname. For instance: instead of it being just kernel26, it’ll now be kernel-2.6.30. kernel26 will now be basically a dummy package that only depends on kernel-2.6.30. When the maintainers go to update the kernel, they'll update the kernel package, and kernel26 package with the new appropriate kernel version number (this will be what? Maybe once a month or so.)
Now, vmlinuz26, kernel26.img will need to obviously be changed. One option would be to automatically upgrade grub/lilo/etc with an appropriate rule. I don't think most people who use Arch would like this option terribly much. So another option would be to have symbolic links in /boot for vmlinuz26->vmlinuz-2.6.30 changed to vmlinuz26->vmlinuz-2.6.31 upon upgrade. This way, the old kernel is still easily accessible on upgrades, and upgrades will still be seamless (and more or less, act like they do now.)
Possible problem: One problem with this approach would be users will be responsible for periodically removing old kernels. For this, I don't know of a simple solution.
I don't think this one small issue should stop the idea from being shot down entirely.
Ref: http://losinggeneration.homelinux.org/2009/10/16/why-arch-linuxs-kernel-upgrades-suck