Ok, leaving a trace here as well, regarding the u-boot upload in the focal Unapproved queue, other than direct messages: currently in the .changes file there are 3 bugs attached, 2 of which do not have SRU templates, so we'd need that + since this is a backport, I feel a bit sad that there's no backport tracking bug (since it's quite a big u-boot bump). So I'd recommend either modifying one of the bugs into a 'backport latest u-boot to focal' with a proper test case of all supported platforms, or creating a new one, attaching it to the changelog and then re-uploading. Do we still use u-boot for focal raspi images? I guess we do? If yest, we'd need to have testing of the pi images as well in the testcase of this SRU tracking bug.
Also, quickly browsing through the debdiff of the new version I see this line in debian/control: +Breaks: flash-kernel (<< 3.104) ...but focal doesn't have flash-kernel 3.104. So this would need the new flash-kernel backported? Or at least some changes done + changing the breaks. I guess I'll reject the upload for now. We can always re-upload or fetch it from the rejected queue. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-riscv in Ubuntu. https://bugs.launchpad.net/bugs/1923162 Title: riscv64 images fail to boot in qemu Status in linux-riscv package in Ubuntu: Invalid Status in u-boot package in Ubuntu: Fix Released Status in u-boot-menu package in Ubuntu: Fix Released Status in linux-riscv source package in Focal: Invalid Status in u-boot source package in Focal: New Status in u-boot-menu source package in Focal: Fix Committed Status in linux-riscv source package in Hirsute: Invalid Status in u-boot source package in Hirsute: Fix Committed Status in u-boot-menu source package in Hirsute: Fix Released Bug description: [Impact] * u-boot may crash when attempting to boot extlinux.conf which specifies fdtdir; the given u-boot config doesn't specify a dtb filename to load; autodetection tries to make one up using $soc & $board variables; and if one or both of them are not set (as it is the case for qemu) it would crash. Fix this crash by doing validation / checking when quering for $soc & $board variables in autodetectionn. [Test Plan] * Use qemu & uboot produced by the build that fixes this bug report properly and attempt to boot hirsute's riscv64+unmatched image. * It should boot correctly without a crash / qemu backtrace. [Where problems could occur] * This patch is bein upstreamed. If one is using external uboot (i.e. provided by some other vendor) it may still crash when trying to boot Ubuntu's riscv64 rootfs or cloud image. [Other Info] * Patch is being reviewed upstream https://lists.denx.de/pipermail/u-boot/2021-May/449176.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1923162/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
