[Pkg-raspi-maintainers] Bug#964915: Raspi 4 debian image update-initramfs

[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 :-| )