Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.dist > #1199978
| From | lymkwi <lymkwi@vulpinecitrus.info> |
|---|---|
| Newsgroups | linux.debian.bugs.dist |
| Subject | Bug#996915: raspi-firmware: hook breaks label-based booting |
| Date | 2024-06-06 01:00 +0200 |
| Message-ID | <IM7LP-U2t-1@gated-at.bofh.it> (permalink) |
| References | <Dange-7Nk-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi, This issue is still ongoing on systems that rely on `rapi-firmware`. It appeared around a year ago on one particular Raspberry Pi 4 board I own for which the microSD card containing the rootfs partition competes with a USB device when enumerated, leading to inconsistent symbolic device names, and while I solved the resulting boot-time hang several months ago, a new kernel update brought it back. While I personally see no inherent problem with the `z50-raspi-firmware` post-install hook modifying kernel arguments (the way `grub-mkconfig` would on a system with the grub bootloader, for example), and especially because you can override the `$ROOTPART` portion of Linux arguments, the hook should absolutely *not* use paths to the block device's path. Even RaspberryPi images for Debian [0] use labels, as mentioned by Cyril two and a half years ago. What's even more baffling is that the post-install hook involved correctly derives the `$ROOTPART` variable for ZFS and btrfs-type root filesystems. `findmnt` is perfectly capable of returning the UUID of an ext4 partition (which i assume a lot of root partitions are, and ext4 partitions will always have a UUID), why not add a new choice in the case determined from `$(root_info fstype)`? It'd simply go like: ``` case $fstype in ext4) uuid="$(root_info uuid)" && ROOTPART="UUID=$uuid" || echo "raspi-firmware: warning: unable to determine ext4 UUID for root partition." >&2 ;; ``` And such. More generally, the best solution I have to propose is for the hook to not query `source` first in most cases. Instead, it should try to find the UUID of the root partition, then fall back on `source` if one cannot be found. ZFS and Btrfs can still be handled as special cases too. Something like: ``` uuid="$(root_info uuid)" && ROOTPART="UUID=$uuid" || ROOTPART=/dev/mmcblk0p2 if [ -z "$ROOTPART" ] ; then # Fall back on `source` but warn that it could lead to inconsistent reboot. ROOTPART=$(root_info source) || echo "raspi-firmware: warning: unable to determine root fs mount point." >&2; echo "raspi-firmware: warning: fell back on root device path as kernel argument. Inconsistent device order may lead to non-booting device." >&2; fi ``` While scouring the issues open for `raspi-firmware` I also checked possible linked issues: #1055084 (either caused by this or at least unsolvable because of it). Until this issue is solved at the source, my personal workaround will be something like this written in `/etc/default/raspi-firmware` : ``` ROOTPART=UUID=<redacted> ``` --- Links: [0]: https://wiki.debian.org/RaspberryPiImages
Back to linux.debian.bugs.dist | Previous | Next | Find similar | Unroll thread
Bug#996915: raspi-firmware: hook breaks label-based booting lymkwi <lymkwi@vulpinecitrus.info> - 2024-06-06 01:00 +0200
csiph-web