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=
```
---
Links:
[0]: https://wiki.debian.org/RaspberryPiImages
