Re: Raspi 4 debian image update-initramfs
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 :-| )
Reply to: