| Summary: | >=sys-apps/debianutils-2.29 breaks installkernel for non-"modern" systems | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jeroen Roovers (RETIRED) <jer> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ansla80, bugs+gentoo, const, gentoo, gentoo |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485278 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 273060 | ||
| Attachments: |
debian-utils-2.29-installkernel.patch
debian-utils-2.29-installkernel.patch debian-utils-2.29-installkernel.patch debianutils-2.30-installkernel.patch |
||
Created attachment 160097 [details, diff]
debian-utils-2.29-installkernel.patch
The reasoning behind Debian's installkernel patch appears to be that the symlinks are only interesting for systems that use lilo as bootloader. The "modern" predicate appears to indicate a preference for grub, which Debian only uses for amd64 and i386. All the other arches that Debian and indeed Gentoo supports are left out in the cold. At the end of installkernel, the call to mkboot has been commented. Again, this is good for grub users but ignores other bootloader installers' modes of operation. Created attachment 160100 [details, diff]
debian-utils-2.29-installkernel.patch
Introduce the same test -L logic where it concerns running mkboot.
Created attachment 160102 [details, diff]
debian-utils-2.29-installkernel.patch
Ew, I fell into the same trap.
this really should be sent to bugs.debian.org seeing as how they maintain it I hit the same bug. Is it possible, that this patch is not applied to 2.30? Since I don't have symlink support since 2.30. Jer please send it? The last patch is by the way faulty, because it tries to revert the earlier version of patches, which are of course not applicable to the original source. Created attachment 184863 [details, diff]
debianutils-2.30-installkernel.patch
I adopted Jeroen's patches, so that the symlink logic with vmlinuz and vmlinuz.old as it was before: added move if versions mismatch.
I just not into mkboot, so I will leave that to someone more skilled.
I have my /boot on a very small USB flash media. I enjoyed the symlinking behavior because it resulted in fewer pages written to my flash and wasted less space. Now I have two identical copies of each of vmlinuz and vmlinuz.old: -rw-r--r-- 1 root root 1977728 2009-04-23 21:17 vmlinuz -rw-r--r-- 1 root root 1998880 2009-03-03 22:43 vmlinuz-2.6.27-gentoo-r8 -rw-r--r-- 1 root root 1977728 2009-04-23 21:17 vmlinuz-2.6.28-gentoo-r5 -rw-r--r-- 1 root root 1998880 2009-03-03 22:43 vmlinuz.old They are not even hard links of the same inode. They are separate copies, wasting space. Do we have a Debian bug report number for this patch yet? (In reply to comment #11) > Do we have a Debian bug report number for this patch yet? I have sent a second e-mail reply through the bug referenced in this bug report's URL field. I had done so previously but it appears to have gone to /dev/null, since I never got any feedback. Version 3.0.1 is in the tree. It no longer provides mkboot and it might fix the symlinking issue. Else we wait until 3.0.2 is uploaded. Version 3.0.2 is in the tree now. Is there anything against the way 3.1.3 handles this? symlinking works fine. I'm happy with 3.1 and 3.2. |
The patch of [URL] was apparently applied without any checks on the non-modern system it is purport to still support. On a system where any of /boot/{vmlinu[xz],config,System.map} is a symlink, installkernel now unreasonably requires it to be a symlink to the kernel version to be installed as well, or it will not do any symlinking. Worse still, if that is not the case (either condition fails), it replaces the symlink with a copy of the file and the old symlinking behaviour is lost forever[1], because on the next run of installkernel, it fails on the first requirement. [1] That is, until the symlinks are restored and the soon to be attached patch is installed...