Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cannot be loaded by kernel version 4.14.13-1: Unknown symbol __x86_indirect_thunk_r15 (err 0)
Package: linux-headers-4.14.0-3-amd64 Version: 4.14.17-1 When I build VirtualBox kernel modules using linux-headers-4.14.0-3-amd64 version 4.14.17-1, the resulting modules can't be loaded using linux-image-4.14.0-3-amd64 version 4.14.13-1. When I build the same modules using headers version 4.14.13-1, they load successfully. Here are some error messages: systemd[1]: Starting LSB: VirtualBox Linux kernel module... kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r15 (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_rax (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_rdx (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r14 (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_rbx (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r13 (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r10 (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_rcx (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_rsi (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r9 (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r12 (err 0) kernel: vboxdrv: Unknown symbol __x86_indirect_thunk_r8 (err 0) virtualbox[6834]: Loading VirtualBox kernel modules...modprobe vboxdrv failed. Please use 'dmesg' to find out why ... failed! virtualbox[6834]: failed!
Bug#828705: Linux kernel update creates redundant symlinks
On 27.06.2016 15:45, Ben Hutchings wrote: Control: tag -1 wontfix On Mon, 2016-06-27 at 15:20 +0300, Evgeny Kapun wrote: On 27.06.2016 15:03, Ben Hutchings wrote: Doesn't lilo fail if a file specified in its configuration is missing? Ben. LILO has an "optional" option which makes it skip an entry if either the kernel or the initrd file is missing (or is a broken link). That's a good point. I checked whether liloconfig would put the 'optional' keyword in /etc/lilo.conf, but the config file it generated didn't mention the symlinks at all. So I don't think it makes sense to assume that people use the 'optional' keyword. There are other boot loaders that I think will use the symlinks during package updates: elilo, palo and zipl. They all have similar configuration syntax to lilo, but it appears that elilo and palo do not support the 'optional' keyword. Although the 'old' symlinks will sometimes be redundant, I don't think this issue outweighs the inconvenience of a failed boot loader update. Ben. On the other hand, the current behavior (when both pairs of symlinks are always kept) was introduced not so long ago, so most existing setups should work with the old behavior. And I can't find anyone reporting the old behavior as a bug, so I think that the old behavior isn't actually any more problematic than the current one. Maybe add a config option to choose between the old and the current behavior? Also, if keeping all these symlinks is so important, then maintainer scripts should always prevent the only remaining installed kernel version from being removed, since there is no way to have valid symlinks after that. Now, such removal would proceed without any confirmation (unless that version happens to be the same as the one that is currently running), and all symlinks will be removed.
Bug#828705: Linux kernel update creates redundant symlinks
On 27.06.2016 15:03, Ben Hutchings wrote: Doesn't lilo fail if a file specified in its configuration is missing? Ben. LILO has an "optional" option which makes it skip an entry if either the kernel or the initrd file is missing (or is a broken link).
Bug#828705: Linux kernel update creates redundant symlinks
On 27.06.2016 11:51, Ben Hutchings wrote:
Control: reassign -1 linux-base 4.3
Control: tag -1 moreinfo
On Mon, 2016-06-27 at 03:59 +0300, Evgeny Kapun wrote:
Package: linux-image-4.6.0-1-amd64
Version: 4.6.2-2
When updating the package linux-image-4.6.0-1-amd64 from version
4.6.2-1 to version 4.6.2-2, post-install script printed this:
I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.6.0-1-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-4.6.0-1-amd64
After that, both /{vmlinuz,initrd.img} and /{vmlinuz,initrd.img}.old
point to the same kernel version, 4.6.0-1-amd64. Aren't these .old
symlinks supposed to point to the previous version?
If only one version is installed, both pairs of links will be pointed
to it. Previously, one or both pairs could be left broken.
Is there another version installed?
Ben.
No, there is only one version installed. Previously, there was only one pair of
links in this case (the .old links were removed). I think that the old behavior
is better because with the current behavior, bootloaders which use these
symlinks (such as LILO) will create two menu entries for the same kernel
version, which is confusing. When there is only one pair, such bootloaders will
only create one entry.
Bug#828705: Linux kernel update creates redundant symlinks
Package: linux-image-4.6.0-1-amd64
Version: 4.6.2-2
When updating the package linux-image-4.6.0-1-amd64 from version 4.6.2-1 to
version 4.6.2-2, post-install script printed this:
I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.6.0-1-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-4.6.0-1-amd64
After that, both /{vmlinuz,initrd.img} and /{vmlinuz,initrd.img}.old point to
the same kernel version, 4.6.0-1-amd64. Aren't these .old symlinks supposed to
point to the previous version?
Bug#812120: update-initramfs fails if busybox is not installed
Package: initramfs-tools-core Version: 0.121 If I try to run update-initramfs while busybox is not installed, I get an error message: E: busybox is required but not installed E: /usr/share/initramfs-tools/hooks/busybox failed with return 1. This happens irrespective of the BUSYBOX setting in /etc/initramfs-tools/initramfs.conf.
Bug#812120: update-initramfs fails if busybox is not installed
On 20.01.2016 22:41, Ben Hutchings wrote: On Wed, 2016-01-20 at 22:21 +0300, Evgeny Kapun wrote: Package: initramfs-tools-core Version: 0.121 If I try to run update-initramfs while busybox is not installed, I get an error message: E: busybox is required but not installed E: /usr/share/initramfs-tools/hooks/busybox failed with return 1. This happens irrespective of the BUSYBOX setting in /etc/initramfs-tools/initramfs.conf. You have another package installed (maybe cryptsetup) that requires busybox to work in the initramfs. Try this: grep -r BUSYBOX /usr/share/initramfs-tools/conf-hooks.d Ben. Yes, I have cryptsetup installed, but this problem appeared only after upgrading initramfs-tools to version 0.121.
