On 3/3/20 9:38 AM, Paul Kennedy wrote: > I've just tried the latest F32 and Rawhide workstation images, but neither successfully booted for me. Both hung after eth0 came up, then sat for several minutes before logging about dracut timeouts and then a recovery shell (mouse and keyboard never worked). I've seen that someone had success with a Fedora-Workstation-Rawhide-20200110.n.0.aarch64.raw.xz image - has anyone successfully booted from anything newer? The new images do seem to be broken. I just tried the latest one, and as you have seen, the boot process hangs at the Ethernet initialization point.

I also tried Fedora-Minimal-Rawhide-20200214.n.1.aarch64.raw.xz, which is the latest one that I have saved, and it boots, but it won't let me log in on the console. I think that is because plymouth is fighting with agetty. I do have an RPi4 running 64-bit Fedora pretty well, including a KDE desktop. But I started with an earlier image, and it took a lot of fiddling around to get there. I have another RPi4 running Manjaro, and it provides a good 64-bit experience right out of the box. You might want to try that until "Fedora on RPi4" matures.

On 3/3/20 1:12 PM, Peter Robinson wrote: > On Tue, Mar 3, 2020 at 5:56 PM Steven A. Falco <stevenfalco(a)gmail.com&gt; wrote: >> >> On 3/3/20 9:38 AM, Paul Kennedy wrote: >>> I've just tried the latest F32 and Rawhide workstation images, but neither successfully booted for me. Both hung after eth0 came up, then sat for several minutes before logging about dracut timeouts and then a recovery shell (mouse and keyboard never worked). I've seen that someone had success with a Fedora-Workstation-Rawhide-20200110.n.0.aarch64.raw.xz image - has anyone successfully booted from anything newer? >> >> The new images do seem to be broken.  I just tried the latest one, and as you have seen, the boot process hangs at the Ethernet initialization point. > > Kernel or firmware stage? The firmware stage is slow but it does go through. I just tried Fedora-Minimal-Rawhide-20200302.n.1.aarch64.raw.xz and it worked properly.  However, Fedora-Workstation-Rawhide-20200302.n.1.aarch64.raw.xz has a problem, as shown by the attached session.log file.  I let it run for a long period of time, and after 5 or 10 minutes it wound up at a dracut emergency prompt.  Please note that this was a fresh install - the only thing I changed was to enable the console uart in config.txt so I could log the output.

Hi Steve, ----- Original Message ----- > On 3/3/20 1:12 PM, Peter Robinson wrote: > > On Tue, Mar 3, 2020 at 5:56 PM Steven A. Falco <stevenfalco(a)gmail.com&gt; > > wrote: > >> > >> On 3/3/20 9:38 AM, Paul Kennedy wrote: > >>> I've just tried the latest F32 and Rawhide workstation images, but > >>> neither successfully booted for me. Both hung after eth0 came up, then > >>> sat for several minutes before logging about dracut timeouts and then a > >>> recovery shell (mouse and keyboard never worked). I've seen that someone > >>> had success with a > >>> Fedora-Workstation-Rawhide-20200110.n.0.aarch64.raw.xz image - has > >>> anyone successfully booted from anything newer? > >> > >> The new images do seem to be broken. I just tried the latest one, and as > >> you have seen, the boot process hangs at the Ethernet initialization > >> point. > > > > Kernel or firmware stage? The firmware stage is slow but it does go > > through. > > I just tried Fedora-Minimal-Rawhide-20200302.n.1.aarch64.raw.xz and it worked > properly. However, Fedora-Workstation-Rawhide-20200302.n.1.aarch64.raw.xz > has a problem, as shown by the attached session.log file. I let it run for > a long period of time, and after 5 or 10 minutes it wound up at a dracut > emergency prompt. Please note that this was a fresh install - the only > thing I changed was to enable the console uart in config.txt so I could log > the output. We're a few weeks out from Fedora 32 Beta, so Rawhide is getting very little attention right now. Both of these are pre-release as well, so issues are somewhat expected until GA. The last nominated nightly was 20200225.n.0, I tested both Minimal and Workstation images for AArch64 and they should boot as expected. Paul > > >> I also tried Fedora-Minimal-Rawhide-20200214.n.1.aarch64.raw.xz, which is > >> the latest one that I have saved, and it boots, but it won't let me log > >> in on the console. I think that is because plymouth is fighting with > >> agetty. > >> > >> I do have an RPi4 running 64-bit Fedora pretty well, including a KDE > >> desktop. But I started with an earlier image, and it took a lot of > >> fiddling around to get there. > >> > >> I have another RPi4 running Manjaro, and it provides a good 64-bit > >> experience right out of the box. You might want to try that until > >> "Fedora on RPi4" matures. > > > > Other distros are off topic for the list, please keep discussion to > > topic, if you wish to discuss them there's other forums. > > Sorry - I'll use private email in future. > > Steve > > > > _______________________________________________ > arm mailing list -- arm(a)lists.fedoraproject.org > To unsubscribe send an email to arm-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org > _______________________________________________ arm mailing list -- arm(a)lists.fedoraproject.org To unsubscribe send an email to arm-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org

>> I just tried Fedora-Minimal-Rawhide-20200302.n.1.aarch64.raw.xz and it worked >> properly. However, Fedora-Workstation-Rawhide-20200302.n.1.aarch64.raw.xz >> has a problem, as shown by the attached session.log file. I let it run for >> a long period of time, and after 5 or 10 minutes it wound up at a dracut >> emergency prompt. Please note that this was a fresh install - the only >> thing I changed was to enable the console uart in config.txt so I could log >> the output. > > We're a few weeks out from Fedora 32 Beta, so Rawhide is getting very little > attention right now. Both of these are pre-release as well, so issues are > somewhat expected until GA. > > The last nominated nightly was 20200225.n.0, I tested both Minimal and > Workstation images for AArch64 and they should boot as expected. Thanks Paul. I just tried Fedora-Workstation-32-20200225.n.0.aarch64.raw.xz on my RPi4 but it behaves the same as I previously reported. There is a 5 minute pause after the eth0 link becomes ready and I then wind up in the dracut emergency shell.

>>> I just tried Fedora-Minimal-Rawhide-20200302.n.1.aarch64.raw.xz and it worked >>> properly. However, Fedora-Workstation-Rawhide-20200302.n.1.aarch64.raw.xz >>> has a problem, as shown by the attached session.log file. I let it run for >>> a long period of time, and after 5 or 10 minutes it wound up at a dracut >>> emergency prompt. Please note that this was a fresh install - the only >>> thing I changed was to enable the console uart in config.txt so I could log >>> the output. >> >> We're a few weeks out from Fedora 32 Beta, so Rawhide is getting very little >> attention right now. Both of these are pre-release as well, so issues are >> somewhat expected until GA. >> >> The last nominated nightly was 20200225.n.0, I tested both Minimal and >> Workstation images for AArch64 and they should boot as expected. > > Thanks Paul. I just tried Fedora-Workstation-32-20200225.n.0.aarch64.raw.xz on my RPi4 but it behaves the same as I previously reported. There is a 5 minute pause after the eth0 link becomes ready and I then wind up in the dracut emergency shell. That's two different an unrelated problems. Is the pause with ethernet before the grub2 prompt?

>>> Thanks Paul. I just tried Fedora-Workstation-32-20200225.n.0.aarch64.raw.xz on my RPi4 but it behaves the same as I previously reported. There is a 5 minute pause after the eth0 link becomes ready and I then wind up in the dracut emergency shell. >> >> That's two different an unrelated problems. Is the pause with ethernet >> before the grub2 prompt? > > No - the pause is in the kernel. In an earlier email in this chain, I attached a file "session.log". Here is part of that file - note that the eth0 link comes up at around the 28 second mark. Then there is a 5 minute pause where nothing appears to be happening, and then at the 321 second mark, dracut starts printing timeout messages. I don't read attachments, much less compressed globs of information, sorry it takes too much time to search for a needle in a haystack.

> [ 23.467681] raspberrypi-firmware soc:firmware: Request 0x00028001 returned status 0x00000000 > [ 23.969125] bcmgenet fd580000.ethernet: configuring instance for external RGMII (RX delay) > [ 23.986485] bcmgenet fd580000.ethernet eth0: Link is Down > [ 27.394605] systemd-udevd (515) used greatest stack depth: 11696 bytes left > [ 28.172043] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx > [ 28.186922] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > [ 28.241941] NetworkManager (549) used greatest stack depth: 10272 bytes left > [ 234.092146] random: crng init done > [ 234.101385] random: 6 urandom warning(s) missed due to ratelimiting > [ 321.541094] dracut-initqueue[522]: Warning: dracut-initqueue timeout - starting timeout scripts > [ 322.921646] dracut-initqueue[522]: Warning: dracut-initqueue timeout - starting timeout scripts > > The "Warning: dracut-initqueue timeout" messages repeat for a quite a while, then at the 466 second mark we get the following: > > [ 464.979853] dracut-initqueue[522]: Warning: dracut-initqueue timeout - starting timeout scripts > [ 466.181960] dracut-initqueue[522]: Warning: dracut-initqueue timeout - starting timeout scripts > [ 466.183175] dracut-initqueue[522]: Warning: Could not boot. > Starting Setup Virtual Console... > [ OK ] Started Setup Virtual Console. > [ 466.475450] audit: type=1130 audit(1580894910.719:14): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-vconsole-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' > [ 466.475689] audit: type=1131 audit(1580894910.719:15): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-vconsole-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' > Starting Dracut Emergency Shell... > [ 466.661153] audit: type=1131 audit(1580894910.899:16): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=plymouth-start comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' > Warning: /dev/disk/by-uuid/369ee56a-5038-4040-b16e-f127f8a81ba0 does not exist What storage/medium are you booting off? Unless it's a network style of storage it's actually unlikely to be an issue here with the network side of things. More likely storage.

Also what rev of the RPi4 hardware do you have? If it's one of the refresh versions there may be an issue around a firmware <-> kernel interaction. I should have a new rev 2Gb version in the next day or so, there's a proposed patch under review upstream but I think it might need a newer firmware as well. I'll be testing once I have all the pieces available.

>>>>> Thanks Paul. I just tried Fedora-Workstation-32-20200225.n.0.aarch64.raw.xz on my RPi4 but it behaves the same as I previously reported. There is a 5 minute pause after the eth0 link becomes ready and I then wind up in the dracut emergency shell. >>>> >>>> That's two different an unrelated problems. Is the pause with ethernet >>>> before the grub2 prompt? >>> >>> No - the pause is in the kernel. In an earlier email in this chain, I attached a file "session.log". Here is part of that file - note that the eth0 link comes up at around the 28 second mark. Then there is a 5 minute pause where nothing appears to be happening, and then at the 321 second mark, dracut starts printing timeout messages. >> >> I don't read attachments, much less compressed globs of information, >> sorry it takes too much time to search for a needle in a haystack. > Ok - I provided the attachment because people often want the full details rather than a summary. Next time I'll be sure to provide both. > >>> [ 23.467681] raspberrypi-firmware soc:firmware: Request 0x00028001 returned status 0x00000000 >>> [ 23.969125] bcmgenet fd580000.ethernet: configuring instance for external RGMII (RX delay) >>> [ 23.986485] bcmgenet fd580000.ethernet eth0: Link is Down >>> [ 27.394605] systemd-udevd (515) used greatest stack depth: 11696 bytes left >>> [ 28.172043] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx >>> [ 28.186922] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready >>> [ 28.241941] NetworkManager (549) used greatest stack depth: 10272 bytes left >>> [ 234.092146] random: crng init done >>> [ 234.101385] random: 6 urandom warning(s) missed due to ratelimiting >>> [ 321.541094] dracut-initqueue[522]: Warning: dracut-initqueue timeout - starting timeout scripts >>> [ 322.921646] dracut-initqueue[522]: Warning: dracut-initqueue timeout - starting timeout scripts >>> >>> The "Warning: dracut-initqueue timeout" messages repeat for a quite a while, then at the 466 second mark we get the following: >>> >>> [ 464.979853] dracut-initqueue[522]: Warning: dracut-initqueue timeout - starting timeout scripts >>> [ 466.181960] dracut-initqueue[522]: Warning: dracut-initqueue timeout - starting timeout scripts >>> [ 466.183175] dracut-initqueue[522]: Warning: Could not boot. >>> Starting Setup Virtual Console... >>> [ OK ] Started Setup Virtual Console. >>> [ 466.475450] audit: type=1130 audit(1580894910.719:14): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-vconsole-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' >>> [ 466.475689] audit: type=1131 audit(1580894910.719:15): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-vconsole-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' >>> Starting Dracut Emergency Shell... >>> [ 466.661153] audit: type=1131 audit(1580894910.899:16): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=plymouth-start comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' >>> Warning: /dev/disk/by-uuid/369ee56a-5038-4040-b16e-f127f8a81ba0 does not exist >> >> What storage/medium are you booting off? Unless it's a network style >> of storage it's actually unlikely to be an issue here with the network >> side of things. More likely storage. > > I have a 4 GB RPi4 with an SD card. I think you are correct that it looks more like a storage issue. >> Also what rev of the RPi4 hardware do you have? If it's one of the >> refresh versions there may be an issue around a firmware <-> kernel >> interaction. I should have a new rev 2Gb version in the next day or >> so, there's a proposed patch under review upstream but I think it >> might need a newer firmware as well. I'll be testing once I have all >> the pieces available. > > Great. Thanks for checking. Here is the hardware data for my board: > > Hardware : BCM2835 > Revision : c03112 > Serial : 100000004463a5a7 > Model : Raspberry Pi 4 Model B Rev 1.2 > > Based on the revision-codes page [1], this would be the latest revision of the 4 GB RPi4 board. Yes, looks like a rev 1.2 and that could possibly have this problem. Could you file a bug with the following link and let me know what the RHBZ # is? https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=32&a...