OK thanks lucas and Gunnar. Sorry for any inconvenience that I does not found this bugreport. Have a nice weekend.
Am 31.07.20 um 18:09 schrieb Gunnar Wolf: > [ Adding a Cc: to #964915 ] Lucas Nussbaum dijo [Fri, Jul 31, 2020 at > 02:15:29PM +0200]: >> Hi, Can you confirm that it's not >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964915 > Yes, that's precisely the culprit. Even more - Both basti and me > didn't find it any further because (I guess) we both booted with the > HDMI console. When using a serial console, I found the all too > familiar: Begin: Running /scripts/local-block ... done. Begin: Running > /scripts/local-block ... done. Begin: Running /scripts/local-block ... > done. And of course, after a couple iterations, I got dumped to the > very useful busybox: Begin: Running /scripts/local-block ... done. > Begin: Running /scripts/local-block ... done. done. Gave up waiting > for root file system device. Common problems: - Boot args (cat > /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - > Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/mmcblk0p2 > does not exist. Dropping to a shell! BusyBox v1.30.1 (Debian > 1:1.30.1-4) built-in shell (ash) Enter 'help' for a list of built-in > commands. (initramfs) So, Basti: 1. Try editing cmdline.txt in your > first partition, replacing «/dev/mmcblk0p2» by «LABEL=RASPIROOT» as > the bug report suggests 2. If you don't use a serial console, consider > removing the «console=ttyS1,115200» part, so that the main information > is sent to the HDMI output. Or even better, swap the order, so that > the serial console functionality is preserved, but the main console is > HDMI. So, we should definitively address item 1, as it is a serious > bug (and I'm bumping up severity - It will affect all Raspberry > models, not just the 4). As for 2... well, we can document it and > maybe add some black magic to the initrd generation to allow the user > to specify what the default console should be. But as the preferences > are completely depending on the user and there is no "righter" > value... And, following Lucas' report -- I think his last point > actually makes a lot of sense: 1) setting ROOTPART=`findmnt -n > --output=source /boot/firmware/`, 2) or using the label and doing > ROOTPART=`findmnt -n --output=source /boot/firmware/`; > ROOTLABEL="`lsblk -no label $ROOTPART`", and when overwriting > cmdline.txt using "root=LABEL=$ROOTLABEL", 3) or my personal favorite > - not touching cmdline.txt at all. I don't really see the point of > modifying it during postinst of a kernel package, unless the > pre_cmdline stuff needs to modify console boot settings for some > reason. So that's surely an issue to look into ASAP! (and yes, the bug > is not getting any younger :-| )
