On Wed, 10 Feb 2021 09:37:01 +0100 Ivo De Decker <iv...@debian.org> wrote:
On Mon, Jan 04, 2021 at 08:27:51PM -0800, Vagrant Cascadian wrote:
> >> I'll test on a few of my systems to see if I can reproduce the issue.
> >
> > I can confirm similar behavior on a pinebook, although the kernel does
> > boot and actually load, and eventually displays on the LCD display (if I
> > "setenv console" from u-boot commandline). It even responds
> > appropriately to ctrl-alt-delete, so it is not a completely hung
> > kernel...
>
> 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.
