[Pkg-raspi-maintainers] Bug#996915: raspi-firmware: hook breaks label-based booting

[lymkwi]

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