Control: severity -1 minor No, this is not really that important. I consider these symlinks to be a convenience for stupid old boot loaders that are now largely unmaintained.
On Fri, 2015-05-15 at 03:57 +0200, Guilhem Moulin wrote: > Package: src:linux > Version: 4.0.2-1 > Severity: important > > Dear Maintainer, > > I have the following — probably not so common — configuration: > - libreboot BIOS (a deblobed coreboot) with a GRUB2 payload > - root is BTRFS, with rootflags=subvol=@ > > Since I don't want to flash a new payload onto the BIOS chip at each > kernel upgrade, I'm using the following static grub.cfg: > > linux /@/vmlinuz root=UUID=[…] rootflags=subvol=@ resume=UUID=[…] ro > initrd /@/initrd.img GRUB knows how to do this properly, so you're just making things difficult for yourself. > This used to work great until 3.16.0. However my system no longer boots > since the 4.0.0 upgrade, due to the symlink /initrd.img now having an > absolute target: since GRUB doesn't understand BTRFS subvolumes, it > needs to be pointed to /@/boot/initrd.img-4.0.0-1-686-pae somehow. > > Of course the quickfix on my side is to edit the GRUB script to load > ‘initrd /@/boot/initrd.img-4.0.0-1-686-pae’ instead, but it would be > nice to make /initrd.img's target relative again in the post-install > script (/vmlinuz doesn't have this problem by the way). I think the problem you're seeing is that the postinst script creates relative symlinks only if the target file already exists. This is always true for the kernel image, but it is generally not true for the initramfs image. (It would be true on upgrade but in this case we only create the symlink if it is missing or broken.) It looks like this regressed when we moved initramfs generation from explicit invocation to a generic kernel postinst hook. That happened between squeeze and wheezy. Ben. -- Ben Hutchings It is impossible to make anything foolproof because fools are so ingenious.
signature.asc
Description: This is a digitally signed message part
