Bug#785343: linux-image-4.0.0-1-686-pae: /@/initrd.img not found, due to the symlink /initrd.img having an absolute target
On Fri, 2015-05-15 at 05:24 +0200, Guilhem Moulin wrote: On Fri, 15 May 2015 at 03:57:35 +0100, Ben Hutchings wrote: GRUB knows how to do this properly, so you're just making things difficult for yourself. Since there is always a risk of bricking the board when flashing the BIOS chip, I don't want to add a hook add flash it whenever I upgrade the kernel. [...] Why would you need to flash the whole chip? Isn't the configuration in its own flash partition? 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
Bug#785343: linux-image-4.0.0-1-686-pae: /@/initrd.img not found, due to the symlink /initrd.img having an absolute target
On Fri, 15 May 2015 at 13:47:59 +0100, Ben Hutchings wrote: On Fri, 2015-05-15 at 05:24 +0200, Guilhem Moulin wrote: On Fri, 15 May 2015 at 03:57:35 +0100, Ben Hutchings wrote: GRUB knows how to do this properly, so you're just making things difficult for yourself. Since there is always a risk of bricking the board when flashing the BIOS chip, I don't want to add a hook add flash it whenever I upgrade the kernel. [...] Why would you need to flash the whole chip? Isn't the configuration in its own flash partition? Not that I know of. At the moment the format doesn't allow “support multiple CBFSes per firmware image” [0]. My current way of upgrading the grub.cf is to replace the grub.cfg in the ROM, then flash the whole chip [1]: cbfstool libreboot.rom remove -n grub.cfg cbfstool libreboot.rom add -t raw -n grub.cfg -f grub.cfg flashrom -p internal -w libreboot.rom And using flashrom on the go makes me sweaty ;-) As the coreboot wiki says: “Disadvantages: more risky if you have no way to recover ”. -- Guilhem. [0] http://www.coreboot.org/CBFS#FMAP [1] http://www.coreboot.org/GRUB2#combining_with_coreboot signature.asc Description: Digital signature
Bug#785343: linux-image-4.0.0-1-686-pae: /@/initrd.img not found, due to the symlink /initrd.img having an absolute target
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 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). Cheers, -- Guilhem. -- Package-specific info: ** Version: Linux version 4.0.0-1-686-pae (debian-ker...@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-16) ) #1 SMP Debian 4.0.2-1 (2015-05-11) ** Command line: BOOT_IMAGE=/@/vmlinuz root=UUID=a17c2310-b308-4dd0-8cef-a7f8ca750081 rootflags=subvol=@ resume=UUID=102accd9-30dd-4081-8a7f-a1310ad9a1ee ro ** Not tainted -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.0.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- debconf information excluded signature.asc Description: Digital signature
Bug#785343: linux-image-4.0.0-1-686-pae: /@/initrd.img not found, due to the symlink /initrd.img having an absolute target
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
Bug#785343: linux-image-4.0.0-1-686-pae: /@/initrd.img not found, due to the symlink /initrd.img having an absolute target
On Fri, 15 May 2015 at 03:57:35 +0100, Ben Hutchings wrote: GRUB knows how to do this properly, so you're just making things difficult for yourself. Since there is always a risk of bricking the board when flashing the BIOS chip, I don't want to add a hook add flash it whenever I upgrade the kernel. And in case you meant I could make GRUB reads its config file on disk, this unfortunately doesn't apply here since it's fully encrypted (including /boot; decryption takes place in GRUB). -- Guilhem. signature.asc Description: Digital signature
