| Summary: | qemuriscv64 boot hang on master | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Trevor Gamblin <tgamblin> | ||||
| Component: | core | Assignee: | Trevor Gamblin <tgamblin> | ||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Undecided | CC: | meta.mr.watcher, meta.watcher, randy.macleod | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 0.0.0 | ||||||
| Hardware: | RISCV | ||||||
| OS: | other | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | Don't know | |||||
| Attachments: |
|
||||||
I've traced it to this commit: https://git.openembedded.org/openembedded-core/commit/?id=ab07d62ee0f3bd721e5733ae645842db1fd3882d If I revert that, images boot OK with runqemu. Now to find out why. This may be Fedora-43 specific since that's where Trevor saw the problem. For me, qemuriscv64 for core-image-minimal booted fine for me on Jan 5, 2026, and I just tried c-i-full-cmdline and it booted fine too: root@qemuriscv64:~# uname -r 6.18.1-yocto-standard This is with oe-core HEAD at: 0ed4776533 Revert "glibc: Enable NFS local file locking for glibc tests" and building on an ubuntu-22.024 host system and starting from nothing in sstate-cache. I do have meta-oe/meta-* in my layers and I added ripgrep to the image. Trevor said that he is going to try another machine/distro. Confirmed that this seems to be unique to my Fedora machine (although the only other one I've tested is an Ubuntu 22.04 workstation). Going to completely clean my sstate-cache and rebuild, to see if it's another case of corrupted sstate. Looks to be a corrupted sstate issue with F43 - if I delete my entire sstate-cache and rebuild, I can boot. Seems to be a duplicate of 16087. I can boot after completely deleting my sstate-cache: Poky (Yocto Project Reference Distro) 5.2.99+snapshot-0ed4776533145c901611d7f4f942490e33481335 qemuriscv64 /dev/ttyS0 qemuriscv64 login: QEMU: Terminated runqemu - INFO - Cleaning up runqemu - INFO - Host uptime: 104519.10 runqemu - INFO - Removing /home/tgamblin/workspace/yocto/openembedded-core/build/tmp/deploy/images/qemuriscv64/core-image-minimal-qemuriscv64.rootfs-20260106181831.ext4 tgamblin@megalith ~/workspace/yocto/openembedded-core/build (master)$ cat /etc/os-release NAME="Fedora Linux" VERSION="43 (Server Edition)" RELEASE_TYPE=stable ID=fedora VERSION_ID=43 VERSION_CODENAME="" PRETTY_NAME="Fedora Linux 43 (Server Edition)" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:43" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f43/" SUPPORT_URL="https://ask.fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=43 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=43 SUPPORT_END=2026-12-02 VARIANT="Server Edition" VARIANT_ID=server tgamblin@megalith ~/workspace/yocto/openembedded-core/build (master) |
Created attachment 5167 [details] qemuboot conf file Building an image on master for qemuriscv64 and trying to boot it with QEMU seems to result in an immediate hang. Tested by setting MACHINE = "qemuriscv64" and running "bitbake core-image-full-cmdline". At least on my end, it seems to happen whether we use the default kernel (6.18) or set PREFERRED_PROVIDER_linux-yocto = "6.16%" in local.conf. I've attached a copy of the generated qemuboot.conf file for reference.