Bug 1810134
| Summary: | Raspberry Pi 4 rev 1.2 gets stuck in dracut shell on boot. | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Steven A. Falco <stevenfalco> | ||||||||
| Component: | kernel | Assignee: | Peter Robinson <pbrobinson> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 32 | CC: | airlied, bskeggs, hdegoede, ichavero, itamar, jarodwilson, jeremy, jglisse, john.j5live, jonathan, josef, kernel-maint, linville, masami256, mchehab, mjg59, pbrobinson, steved | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2020-03-16 20:35:54 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Steven A. Falco
2020-03-04 15:29:48 UTC
Created attachment 1667570 [details]
journal log from workstation boot
Here is the result of journalctl, showing the system ending up in the dracut emergency shell.
Created attachment 1667572 [details]
console serial port log for workstation
Here is the serial port log for Fedora-Workstation-32-20200225.n.0.aarch64.raw.xz showing the dracut emergency console.
Created attachment 1667573 [details]
console serial port log for minimal
Here in contrast is a log from Fedora-Minimal-32-20200225.n.0.aarch64.raw.xz, which works perfectly.
There is something different between the Minimal and Workstation builds, in that Minimal works fine, but Workstation fails to boot.
I try to bring up an aarch64 image on a different Soc but also get stuck in the emergency shell. For me udev does not load any kernel modules and 'udevadm trigger' even segfaults. Out of curiosity, is udev loading the kernel modules properly for you? I.e. what is the output of 'lsmod' in your emergency shell. (In reply to billiboy from comment #4) > I try to bring up an aarch64 image on a different Soc but also get stuck in > the emergency shell. This is explicitly a RPi4 rev 1.2 bug. It's a problem that doesn't affect other SoCs, if you're seeing an issue it's a different bug. FEDORA-2020-da32b0c604 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-da32b0c604 bcm283x-firmware-20200306-1.163d84c.fc32 has been pushed to the Fedora 32 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-da32b0c604 I tried merging bcm283x-firmware-20200306-1.163d84c.fc32.aarch64.rpm into several images: Fedora-Workstation-32-20200225.n.0.aarch64.raw.xz Fedora-Workstation-32-20200307.n.0.aarch64.raw.xz Fedora-Workstation-32-20200308.n.0.aarch64.raw.xz In all cases, the dracut shell bug is still present. (In reply to Steven A. Falco from comment #8) > I tried merging bcm283x-firmware-20200306-1.163d84c.fc32.aarch64.rpm into > several images: > > Fedora-Workstation-32-20200225.n.0.aarch64.raw.xz > Fedora-Workstation-32-20200307.n.0.aarch64.raw.xz > Fedora-Workstation-32-20200308.n.0.aarch64.raw.xz > > In all cases, the dracut shell bug is still present. Did you also add the latest rawhide kernel into that? This bug may also be coming into play (it might also be the issue with other SoCs mentioned previously). https://www.spinics.net/lists/linux-mmc/msg57733.html I did not try the rawhide kernel. I'm not sure how I would do that, since we are still running from the initial ram disk when the error occurs. I could try unpacking the initial ram disk, substituting a different kernel, and repacking the initial ram disk. Is that the right way to run the experiment you are suggesting? Or is there a way that I can generate a compose locally with the rawhide kernel? Running a compose is something I'd be interested in learning how to do, anyway. I'll try Fedora-Workstation-Rawhide-20200307.n.1.aarch64.raw.xz once it finishes downloading, with and without the bcm283x-firmware-20200306-1.163d84c.fc32.aarch64.rpm package to see if that shows anything interesting. Also, we should not lose sight of the fact that the Minimal image does not get stuck in dracut, but the Workstation image does. I don't know if that is due to a timing difference, or something else. I tried Fedora-Workstation-Rawhide-20200307.n.1.aarch64.raw.xz both without bcm283x-firmware-20200306-1.163d84c.fc32.aarch64.rpm and with it. Both experiments landed in "emergency mode". This build is using kernel 5.6.0-0.rc4.git1.1.fc33.aarch64. I see that there is a newer kernel, kernel-5.6.0-0.rc5.git0.1.fc33, that was just built. I'll see if there is a way that I can hack that into the Workstation images.
> Also, we should not lose sight of the fact that the Minimal image does not
> get stuck in dracut, but the Workstation image does. I don't know if that
> is due to a timing difference, or something else.
We should not lose sight that accelerated graphics doesn't work yet on the RPi4 and the support for it is still experimental.
bcm283x-firmware-20200306-1.163d84c.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, please make note of it in this bug report. |