On 2021-04-16, Bastian Germann wrote: > On Wed, 10 Feb 2021 09:37:01 +0100 Ivo De Decker <iv...@debian.org> wrote: >> > With a locally built version of 2020.10+dfsg-2, I can no longer >> > reproduce this issue at all. >> > >> > Could you try with the new version? >> >> Testing/unstable now has version 2021.01+dfsg-2. Benedikt, could you try this >> version to see if the issue is still there? > > On a Lamobo R1, I can verify 2021.01 versions not to boot with a default > environment. However, > 2020.10+dfsg-2 boots. Even though the original issue has the same outcome, I > guess it is caused by > something else. I figured out my problem is caused by > https://github.com/u-boot/u-boot/commit/f3866909e35074ea6f50226d40487a180de1132f. > The > boot_efi_bootmgr will run and read a bad dtb, which makes a boot.scr boot > fail. > > The issue is fixed in 2021.04 (experimental) which has the same default > environment as 2021.01.
I can confirm this on the Lamobo R1, when rootfs is on scsi0 and it first attempts to boot from microSD (failing to find boot_efi on mmc0). If I force it to boot from scsi0 first by interrupting the boot to get to a u-boot shell, and typing "setenv boot_targets scsi0", it worked fine with 2021.01 (e.g. it didn't hit the bootefi codepath) as well. Booting the debian-installer image from https://d-i.debian.org/daily-images/armhf/20210416-00:15/netboot/SD-card-images/ worked for me (which currently uses 2021.01). That said, I'm not sure if this is the same issue as in the original report, as the symptom stuck at "Starting kernel ..." can be caused by a wide variety of issues... live well, vagrant
signature.asc
Description: PGP signature
