On 2021-05-16, Vagrant Cascadian wrote: > Control: severity 988217 serious > > On 2021-05-07, Vagrant Cascadian wrote: >> On 2021-04-16, Bastian Germann wrote: >>> 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. >> >> Different enough to warrant it's own bug, cloning... >> >> >>> 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. >> >> This would definitely be good to fix in bullseye, but this is quite late >> in the release cycle.
Heinrich, I was wondering if you had thoughts to share on the above linked patch? How safe is it to apply to 2021.01 (e.g. the version that will ship in bullseye), and have there been further developments upstream relevent to this issue that might be good to be aware of? > After recently upgrading several more systems that turned out to be > affected by this, I'm bumping the severity of this bug... > > >> Will need to test failure and success cases with and without EFI as well >> as boot.scr and extlinux.conf to make sure this doesn't cause >> regressions in other boot paths... > > This still needs some work! > > >> An ugly workaround in the meantime would be to add a no-op boot.scr on >> the media (e.g. mmc0) and then fall back to the other boot methods. > > I'm not sure this workaround is viable in a variety of situations... live well, vagrant
signature.asc
Description: PGP signature
