Re: Fedora 32 on RPI4
by Thomas H.P. Andersen
On Fri, Apr 3, 2020 at 6:13 PM Stefan Wahren <stefan.wahren(a)i2se.com> wrote:
> Hi Fred,
>
> Am 03.04.20 um 13:10 schrieb Fred van Zwieten:
> > I haven't retried it yet, but I do have some extra info on my previous
> > (and failed) attempt:
> >
> > I used arm-image-installer as the tool. As it does not yet have a rpi4
> > target, I used the rpi3 value. It does boot, but, like I said, it
> > hangs in a later stage. I will provide screenshots when I am able to
> > test again.
> >
> > This is the (relevant) output from /proc/cpuinfo:
> > Hardware : BCM2835
> > Revision : c03111
> > Serial : 1000000094b1358a
> > Model : Raspberry Pi 4 Model B Rev 1.1
>
> this should work with Linux 5.6. So i don't have an idea what's the
> problem here.
>
I have the exact same model/revision (confirmed with /proc/cpuinfo when
booting raspbian) and mine boots without problems.
These are the steps I did to get it to boot to gnome-shell:
Wrote Fedora-Minimal-32-20200328.n.0.aarch64.raw.xz (latest compose from
koji at the time) with arm-image-installer to the sd.
Resized partion.
Booted and set up users etc.
Once booted I ran:
# dnf update
# dnf install fedora-release-workstation-32 --allowerasing
# dnf group install workstation-product
# dnf install bash-completion
and then after a reboot:
# systemctl start graphical.target
This got me a gnome-shell (on llvmipe obviously, but it is usable)
> Rev 1.2 needs recent changes to sdhci-iproc and the devicetree.
>
> Best regards
> Stefan
>
> >
> > - Fred
> >
> > On Fri, Apr 3, 2020 at 12:25 PM Andreas Reschke <arm_ml(a)rirasoft.de
> > <mailto:arm_ml@rirasoft.de>> wrote:
> >
> > Hello Dirk,
> >
> > I've tried it with balenaEtcher: It works !!
> >
> > Thank you for that tip !!
> >
> > Andreas
> >
> > PS: I dind't know why it not works with xzcat and dd but now I have a
> > working method.
> >
> > Am 03.04.20 um 10:23 schrieb Dirk Streubel:
> > >> Hello together,
> > >>
> > >> Hello Dirk
> > >>
> > >> how did you you install
> > Fedora-Minimal-32_Beta-1.2.aarch64.raw.xz on SD-Card?
> > >>
> > >> Just xzcat Fedora-Minimal-32_Beta-1.2.aarch64.raw.xz | dd
> > of=/dev/sdc status=progress bs=4M
> > >>
> > >> didn't work for me. All I get is a dracut shell
> > >>
> > >>
> > >> Thanks
> > >>
> > >> Andreas
> > > Hello Andreas,
> > >
> > > yes, i installed the two Version yesterday on a 64 GB SD Card.
> > >
> > > Image has been unpacked with all necessary tools.
> > >
> > > For installation on the SD Card i use balenaEtcher. That Program
> > works fine here.
> > >
> > > Dirk
> > >
> > >
> > >
> > >
> > >
> > >> _______________________________________________
> > >> arm mailing list -- arm(a)lists.fedoraproject.org
> > <mailto:arm@lists.fedoraproject.org>
> > >> To unsubscribe send an email to
> > arm-leave(a)lists.fedoraproject.org
> > <mailto:arm-leave@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
> > <mailto:arm@lists.fedoraproject.org>
> > > To unsubscribe send an email to
> > arm-leave(a)lists.fedoraproject.org
> > <mailto:arm-leave@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
> > <mailto:arm@lists.fedoraproject.org>
> > To unsubscribe send an email to arm-leave(a)lists.fedoraproject.org
> > <mailto:arm-leave@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
> _______________________________________________
> 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
>
4 years, 1 month
Re: Fedora 32 on RPI4
by Stefan Wahren
Hi Fred,
Am 03.04.20 um 13:10 schrieb Fred van Zwieten:
> I haven't retried it yet, but I do have some extra info on my previous
> (and failed) attempt:
>
> I used arm-image-installer as the tool. As it does not yet have a rpi4
> target, I used the rpi3 value. It does boot, but, like I said, it
> hangs in a later stage. I will provide screenshots when I am able to
> test again.
>
> This is the (relevant) output from /proc/cpuinfo:
> Hardware : BCM2835
> Revision : c03111
> Serial : 1000000094b1358a
> Model : Raspberry Pi 4 Model B Rev 1.1
this should work with Linux 5.6. So i don't have an idea what's the
problem here.
Rev 1.2 needs recent changes to sdhci-iproc and the devicetree.
Best regards
Stefan
>
> - Fred
>
> On Fri, Apr 3, 2020 at 12:25 PM Andreas Reschke <arm_ml(a)rirasoft.de
> <mailto:arm_ml@rirasoft.de>> wrote:
>
> Hello Dirk,
>
> I've tried it with balenaEtcher: It works !!
>
> Thank you for that tip !!
>
> Andreas
>
> PS: I dind't know why it not works with xzcat and dd but now I have a
> working method.
>
> Am 03.04.20 um 10:23 schrieb Dirk Streubel:
> >> Hello together,
> >>
> >> Hello Dirk
> >>
> >> how did you you install
> Fedora-Minimal-32_Beta-1.2.aarch64.raw.xz on SD-Card?
> >>
> >> Just xzcat Fedora-Minimal-32_Beta-1.2.aarch64.raw.xz | dd
> of=/dev/sdc status=progress bs=4M
> >>
> >> didn't work for me. All I get is a dracut shell
> >>
> >>
> >> Thanks
> >>
> >> Andreas
> > Hello Andreas,
> >
> > yes, i installed the two Version yesterday on a 64 GB SD Card.
> >
> > Image has been unpacked with all necessary tools.
> >
> > For installation on the SD Card i use balenaEtcher. That Program
> works fine here.
> >
> > Dirk
> >
> >
> >
> >
> >
> >> _______________________________________________
> >> arm mailing list -- arm(a)lists.fedoraproject.org
> <mailto:arm@lists.fedoraproject.org>
> >> To unsubscribe send an email to
> arm-leave(a)lists.fedoraproject.org
> <mailto:arm-leave@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
> <mailto:arm@lists.fedoraproject.org>
> > To unsubscribe send an email to
> arm-leave(a)lists.fedoraproject.org
> <mailto:arm-leave@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
> <mailto:arm@lists.fedoraproject.org>
> To unsubscribe send an email to arm-leave(a)lists.fedoraproject.org
> <mailto:arm-leave@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
4 years, 1 month
Re: Fedora 32 on RPI4
by Fred van Zwieten
Hi Peter,
Yeah, I currently run Buster on it. As soon as I can get to an RH based
aarch distro, I jump.
Fedora 32 aarch is the one, I hope...
- Fred
On Fri, Apr 3, 2020 at 1:17 PM Peter Robinson <pbrobinson(a)gmail.com> wrote:
> > I haven't retried it yet, but I do have some extra info on my previous
> (and failed) attempt:
> >
> > I used arm-image-installer as the tool. As it does not yet have a rpi4
> target, I used the rpi3 value. It does boot, but, like I said, it hangs in
> a later stage. I will provide screenshots when I am able to test again.
> >
> > This is the (relevant) output from /proc/cpuinfo:
>
> Are you running a custom or non Fedora kernel because the upstream
> kernel Fedora uses doesn't propagate most of the information such as a
> the Rev/Model number of the RPi.
>
> > Hardware : BCM2835
> > Revision : c03111
> > Serial : 1000000094b1358a
> > Model : Raspberry Pi 4 Model B Rev 1.1
> >
> > - Fred
> >
> > On Fri, Apr 3, 2020 at 12:25 PM Andreas Reschke <arm_ml(a)rirasoft.de>
> wrote:
> >>
> >> Hello Dirk,
> >>
> >> I've tried it with balenaEtcher: It works !!
> >>
> >> Thank you for that tip !!
> >>
> >> Andreas
> >>
> >> PS: I dind't know why it not works with xzcat and dd but now I have a
> >> working method.
> >>
> >> Am 03.04.20 um 10:23 schrieb Dirk Streubel:
> >> >> Hello together,
> >> >>
> >> >> Hello Dirk
> >> >>
> >> >> how did you you install Fedora-Minimal-32_Beta-1.2.aarch64.raw.xz on
> SD-Card?
> >> >>
> >> >> Just xzcat Fedora-Minimal-32_Beta-1.2.aarch64.raw.xz | dd
> of=/dev/sdc status=progress bs=4M
> >> >>
> >> >> didn't work for me. All I get is a dracut shell
> >> >>
> >> >>
> >> >> Thanks
> >> >>
> >> >> Andreas
> >> > Hello Andreas,
> >> >
> >> > yes, i installed the two Version yesterday on a 64 GB SD Card.
> >> >
> >> > Image has been unpacked with all necessary tools.
> >> >
> >> > For installation on the SD Card i use balenaEtcher. That Program
> works fine here.
> >> >
> >> > Dirk
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >> _______________________________________________
> >> >> 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
> >> _______________________________________________
> >> 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
>
>
4 years, 1 month
Re: Fedora 32 on RPI4
by Michael Young
On Fri, 3 Apr 2020, Fred van Zwieten wrote:
> I haven't retried it yet, but I do have some extra info on my previous (and
> failed) attempt:
>
> I used arm-image-installer as the tool. As it does not yet have a rpi4
> target, I used the rpi3 value. It does boot, but, like I said, it hangs in a
> later stage. I will provide screenshots when I am able to test again.
>
> This is the (relevant) output from /proc/cpuinfo:
> Hardware : BCM2835
> Revision : c03111
> Serial : 1000000094b1358a
> Model : Raspberry Pi 4 Model B Rev 1.1
I am also having problems with my Pi 4 with the latest Fedora 32 kernels
and it is also
Revision : c03111
Michael Young
4 years, 1 month
Re: Fedora 32 on RPI4
by Peter Robinson
> I haven't retried it yet, but I do have some extra info on my previous (and failed) attempt:
>
> I used arm-image-installer as the tool. As it does not yet have a rpi4 target, I used the rpi3 value. It does boot, but, like I said, it hangs in a later stage. I will provide screenshots when I am able to test again.
>
> This is the (relevant) output from /proc/cpuinfo:
Are you running a custom or non Fedora kernel because the upstream
kernel Fedora uses doesn't propagate most of the information such as a
the Rev/Model number of the RPi.
> Hardware : BCM2835
> Revision : c03111
> Serial : 1000000094b1358a
> Model : Raspberry Pi 4 Model B Rev 1.1
>
> - Fred
>
> On Fri, Apr 3, 2020 at 12:25 PM Andreas Reschke <arm_ml(a)rirasoft.de> wrote:
>>
>> Hello Dirk,
>>
>> I've tried it with balenaEtcher: It works !!
>>
>> Thank you for that tip !!
>>
>> Andreas
>>
>> PS: I dind't know why it not works with xzcat and dd but now I have a
>> working method.
>>
>> Am 03.04.20 um 10:23 schrieb Dirk Streubel:
>> >> Hello together,
>> >>
>> >> Hello Dirk
>> >>
>> >> how did you you install Fedora-Minimal-32_Beta-1.2.aarch64.raw.xz on SD-Card?
>> >>
>> >> Just xzcat Fedora-Minimal-32_Beta-1.2.aarch64.raw.xz | dd of=/dev/sdc status=progress bs=4M
>> >>
>> >> didn't work for me. All I get is a dracut shell
>> >>
>> >>
>> >> Thanks
>> >>
>> >> Andreas
>> > Hello Andreas,
>> >
>> > yes, i installed the two Version yesterday on a 64 GB SD Card.
>> >
>> > Image has been unpacked with all necessary tools.
>> >
>> > For installation on the SD Card i use balenaEtcher. That Program works fine here.
>> >
>> > Dirk
>> >
>> >
>> >
>> >
>> >
>> >> _______________________________________________
>> >> 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
>> _______________________________________________
>> 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
4 years, 1 month
Re: Fedora 32 on RPI4
by Fred van Zwieten
I haven't retried it yet, but I do have some extra info on my previous (and
failed) attempt:
I used arm-image-installer as the tool. As it does not yet have a rpi4
target, I used the rpi3 value. It does boot, but, like I said, it hangs in
a later stage. I will provide screenshots when I am able to test again.
This is the (relevant) output from /proc/cpuinfo:
Hardware : BCM2835
Revision : c03111
Serial : 1000000094b1358a
Model : Raspberry Pi 4 Model B Rev 1.1
- Fred
On Fri, Apr 3, 2020 at 12:25 PM Andreas Reschke <arm_ml(a)rirasoft.de> wrote:
> Hello Dirk,
>
> I've tried it with balenaEtcher: It works !!
>
> Thank you for that tip !!
>
> Andreas
>
> PS: I dind't know why it not works with xzcat and dd but now I have a
> working method.
>
> Am 03.04.20 um 10:23 schrieb Dirk Streubel:
> >> Hello together,
> >>
> >> Hello Dirk
> >>
> >> how did you you install Fedora-Minimal-32_Beta-1.2.aarch64.raw.xz on
> SD-Card?
> >>
> >> Just xzcat Fedora-Minimal-32_Beta-1.2.aarch64.raw.xz | dd of=/dev/sdc
> status=progress bs=4M
> >>
> >> didn't work for me. All I get is a dracut shell
> >>
> >>
> >> Thanks
> >>
> >> Andreas
> > Hello Andreas,
> >
> > yes, i installed the two Version yesterday on a 64 GB SD Card.
> >
> > Image has been unpacked with all necessary tools.
> >
> > For installation on the SD Card i use balenaEtcher. That Program works
> fine here.
> >
> > Dirk
> >
> >
> >
> >
> >
> >> _______________________________________________
> >> 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
> _______________________________________________
> 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
>
4 years, 1 month
Re: What is the latest arm64 image that people have successfully run on the RPi4?
by Steven A. Falco
On 3/4/20 10:17 AM, Peter Robinson wrote:
>>>>>> 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&compo...
>
The bug number is 1810134 [1]. I have to run to an appointment right now, but I'll add the logs to the bug report when I return.
Steve
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1810134
4 years, 2 months
Re: What is the latest arm64 image that people have successfully run on the RPi4?
by Steven A. Falco
On 3/4/20 8:34 AM, Peter Robinson wrote:
>>>> 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.
Steve
[1] https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-c...
4 years, 2 months
Re: Adding an RTC module
by Peter Robinson
On Tue, Jan 28, 2020 at 3:32 PM Steven A. Falco <stevenfalco(a)gmail.com> wrote:
>
> On 1/28/20 9:39 AM, Peter Robinson wrote:
> > On Tue, Jan 28, 2020 at 1:59 PM Steven A. Falco <stevenfalco(a)gmail.com> wrote:
> >>
> >> I'd like to add an RTC module to a Raspberry Pi. I see that uboot has some support for device tree overlays, but if I'm reading the code correctly, it doesn't seem to be enabled for the Pi.
> >>
> >> Is it possible to use device tree overlays at this point, or am I better off building a custom kernel?
> >
> > Yes, mostly, but there's still a whole bunch of corner cases, for
> > Raspberry Pi we use the Firmware provided DT and not the kernel DT.
> > It's only really clean on aarch64 and completely doesn't work on RPi4
> > (yet another reason there's been no announcement around RPi4 support).
>
> I see. U-boot says it is using 0:2 /dtb/broadcom/bcm2711-rpi-4-b.dtb, and I've confirmed that: If I hand-edit that dtb file to add the RTC (pcf8523@68) to the I2C bus (i2c@7e804000) it works - the RTC is reported as being managed by the kernel. So it looks like the RPi4 is using the kernel device tree rather than the firmware one.
Correct, that is the default and on the RPi4 it crashes on boot using
the firmware DT.
> I have not been entirely successful rebuilding the kernel yet (using mock on the RPi4 itself). The dtc portion of the build fails because of the gcc10 change from -fcommon to -fno-common. I need to tweak the kernel spec file to work around that, but my first attempt was a little too heavy-handed. Seems that a lot of stuff needs -fno-common, but dtc needs -fcommon.
Well patches are welcome, I need to engage with upstream and I only
have so many hours in a week. As I've stated previously the RPi4 is
currently no supported and we are getting there but I do it in my own
personal time.
4 years, 3 months
Re: [RPI3B+ & Ethernet On Board Card]
by Peter Robinson
On Sat, Jan 11, 2020 at 8:27 AM RENARD Pierre-Francois
<pfrenard(a)gmail.com> wrote:
>
> Hello guys,
>
> just to let you know, Eric Dumazet from netdev mailing list found 2 bugs
> one related to a memory leak (just been added to mainstream)
> one related to gso max size (from yesterday night)
>
> with both patches I am not able to reproduce the issue !!
Do you have a link to the upstream patches on the list by chance?
> Fox
>
> On 1/7/20 9:28 AM, Stefan Wahren wrote:
> > Hello Pierre-Francois,
> >
> > On 06.01.20 23:49, RENARD Pierre-Francois wrote:
> >> Hello Stefan,
> >>
> >> I am sorry I did not report the issue to linux-netdev mailing list.
> > sorry for being not clear. But could you please still submit this bug
> > report to linux-netdev?
> >
> > Fedora don't have the resources to fix this bug and the Raspberry Pi
> > guys won't fix any issues in the Fedora kernel. We need to fix this in
> > the mainline kernel or least inform the lan78xx maintainer about the
> > issue. I'm not able to reproduce this issue on my RPi 3B+.
> >
> > In order to report your issue to the relevant maintainers please submit
> > a bug report to the following addresses:
> >
> > Nicolas Saenz Julienne <nsaenzjulienne(a)suse.de>
> > Woojung Huh <woojung.huh(a)microchip.com>
> > Microchip Linux Driver Support <UNGLinuxDriver(a)microchip.com>
> > netdev(a)vger.kernel.org
> > linux-usb(a)vger.kernel.org
> >
> > It's important to mention lan78xx in subject line.
> >
> > Thanks
> > Stefan
> > ||
> >
> >> I can simply explain why :
> >> - it did submit to github repo which seams to be in charge of the
> >> dev + provides a workaround
> >> - after a few hours of reading 1.5 years of comments for this
> >> issue to find the commands for the workaround, it did miss the end of
> >> your email.
> >> - it was not obvious for me that linux-netdev is a mailing list,
> >> and by the way I don't know how to send this issue to the mailing list
> >> (google did not help me on that ..)
> >>
> >> Thanks
> >> Fox
> >>
> >>
> >> On 1/6/20 3:46 PM, Stefan Wahren wrote:
> >>> Hi,
> >>>
> >>> On 06.01.20 15:30, RENARD Pierre-Francois wrote:
> >>>> OK,
> >>>> upgrade done, running now kernel 5.4.7-200.fc31, same issue with scp.
> >>> this sounds like a known issue [1]. There is at least a workaround [2].
> >>>
> >>> [1] - https://github.com/raspberrypi/linux/issues/2482
> >>> [2] -
> >>> https://github.com/raspberrypi/linux/commit/5f0e4c1cc51a2aee86b2a554b65cb...
> >>>
> >>>
> >>>> Should I open an issue on readhat bugzilla or kernel bugzilla ?
> >>> It would be the best to report this to linux-netdev and the lan78xx
> >>> maintainer.
> >>>
> >>> Thanks
> >>> Stefan
> >>>
> >>>> Thanks
> >>>> Fox
> >>>>
> >>>>
> >>>> On 1/6/20 12:48 PM, Peter Robinson wrote:
> >>>>>> kernel is 5.3.11-300.fc31 (the one I am using these days, for F30 I
> >>>>>> don't remember but I guess the issue was there whatever the kernel)
> >>>>>>
> >>>>>> My devices are all 3B+, but I can do tests with 3B also.
> >>>>>>
> >>>>>> There is no router between client and server.
> >>>>>>
> >>>>>> No packet is lost
> >>>>>> outut from ping
> >>>>>>
> >>>>>> 200 packets transmitted, 200 received, 0% packet loss, time 206903ms
> >>>>>> rtt min/avg/max/mdev = 0.357/0.453/0.659/0.036 ms
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I am trying this small test
> >>>>>>
> >>>>>> in a shell :
> >>>>>> cd /net/NFSSERVER/directories_path/
> >>>>>> while true; do sleep 1; ls -al ; done
> >>>>>>
> >>>>>> in another shell
> >>>>>> cd /net/NFSSERVER/directories_path/
> >>>>>> dd if=/dev/zero of=./data.dd bs=4k count=1000000
> >>>>>> status=progress
> >>>>>>
> >>>>>> in the first shell each second, I have a ls command running
> >>>>>> when I launch the second command, I have no more updates ( ls is
> >>>>>> hanged)
> >>>>>> whatever the configuration ....
> >>>>>> and dd is running with an output such as
> >>>>>>
> >>>>>> Output from RPI3B 1227259904 bytes (1.2 GB, 1.1 GiB)
> >>>>>> copied, 99 s, 12.4 MB/s
> >>>>>> Output from RPI3B+ & usb ethernet 2765832192 bytes (2.8 GB,
> >>>>>> 2.6
> >>>>>> GiB) copied, 106.039 s, 26.1 MB/s
> >>>>>> Output from RPI3B+ & native ethernet 378548224 bytes (379 MB, 361
> >>>>>> MiB) copied, 8 s, 47.1 MB/s
> >>>>>> on the last one the update is also hanged on dd, here is an
> >>>>>> update
> >>>>>> 744927232 bytes (745 MB, 710 MiB) copied,
> >>>>>> 247 s,
> >>>>>> 3.0 MB/s
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> with PI3B I was able to ctrl-c the dd command, and ls restarts to
> >>>>>> loop
> >>>>>>
> >>>>>> with PI3B+ & usb ethenet card I was able to ctrl-c the dd command,
> >>>>>> and
> >>>>>> ls restarts to loop
> >>>>>>
> >>>>>> with RPI3B+ & natif ethernet I cannot ctrl-c the dd command I
> >>>>>> needed to
> >>>>>> kill -9 the dd process and I got these messages from journal (and ls
> >>>>>> restarts to loop)
> >>>>>>
> >>>>>> Jan 06 12:02:43 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:43 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:43 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:43 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:45 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:45 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:46 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:46 pi12.intranet.net kernel: nfs: server syno01 OK
> >>>>>> Jan 06 12:02:46 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:46 pi12.intranet.net kernel: nfs: server syno01 OK
> >>>>>> Jan 06 12:02:46 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:46 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:47 pi12.intranet.net kernel: nfs: server syno01 OK
> >>>>>> Jan 06 12:02:47 pi12.intranet.net kernel: nfs: server syno01 OK
> >>>>>> Jan 06 12:02:47 pi12.intranet.net kernel: nfs: server syno01 OK
> >>>>>> Jan 06 12:02:47 pi12.intranet.net kernel: nfs: server syno01 OK
> >>>>>> Jan 06 12:02:47 pi12.intranet.net kernel: nfs: server syno01 OK
> >>>>>> Jan 06 12:02:47 pi12.intranet.net kernel: nfs: server syno01 OK
> >>>>>> Jan 06 12:02:47 pi12.intranet.net kernel: nfs: server syno01 OK
> >>>>>> Jan 06 12:02:47 pi12.intranet.net kernel: nfs: server syno01 OK
> >>>>>> Jan 06 12:02:48 pi12.intranet.net kernel: rpc_check_timeout: 397
> >>>>>> callbacks suppressed
> >>>>>> Jan 06 12:02:48 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:48 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:48 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:48 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:48 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:48 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:48 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:48 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:48 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>> Jan 06 12:02:48 pi12.intranet.net kernel: nfs: server syno01 not
> >>>>>> responding, still trying
> >>>>>>
> >>>>>>
> >>>>>> I am also doing the test
> >>>>>>
> >>>>>> generating a 4GB file locally and scp this file to the NFS server
> >>>>>>
> >>>>>> RPI3B : 100% 4000MB 8.2MB/s 08:06
> >>>>>> RPI3B+ & usb ethernet : 100% 4000MB 8.8MB/s 07:32
> >>>>>> RPI3B+ & native ethernet : scp freezes after a few very slow MB
> >>>>>> transfered : "5% 216MB 4.7MB/s"
> >>>>>> and finally I got
> >>>>>> client_loop: send disconnect: Broken pipe
> >>>>>> lost connection
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I don't think this is a NFS issue but more generaly an issue with the
> >>>>>> driver of the native ethernet card ??
> >>>>> Quite possibly a combination of driver issues with your particular
> >>>>> setup.
> >>>>>
> >>>>> We don't do any direct development on the drivers, we simply ship
> >>>>> upstream kernel and drivers as we don't have the resources to that
> >>>>> with the RPi or any other arm device.
> >>>>>
> >>>>> That said there was some fixes in the 5.4 series on the ethernet
> >>>>> driver shipped on the 3B+ and the current stable kernel is 5.4.7
> >>>>>
> >>>>> Peter
> >>>>>
> >>>>>> On 12/31/19 5:40 PM, Peter Robinson wrote:
> >>>>>>>> I am running Fedora 31, aarch64 release on many Raspberry PI 3B+.
> >>>>>>> You don't state which kernel you're running.
> >>>>>>>
> >>>>>>>> I have exactly the same behaviour with all the RPIs.
> >>>>>>> Are they all 3B+ devices?
> >>>>>>>
> >>>>>>>> When trying to access a NFS server ( perfectly working with my
> >>>>>>>> laptops
> >>>>>>>> running fedora X86) with a ls command when a huge transfer is on
> >>>>>>>> going,
> >>>>>>>> I have a lot of "NFS server not responding" in journal and ls is
> >>>>>>>> hanged.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I tried to replace the onboard ethernet card with a USB 1GB
> >>>>>>>> ethernet and
> >>>>>>>> I don't have this issue at all.
> >>>>>>>>
> >>>>>>>> I also tried to change port on the switch with the same result (
> >>>>>>>> not
> >>>>>>>> working with on board card, working with USB one)
> >>>>>>>>
> >>>>>>>> I also had such network issue with Fedora 30.
> >>>>>>> Which kernel are you running with F-30? Are you stating you see the
> >>>>>>> same issue as on F-31.
> >>>>>>>
> >>>>>>>> Are you aware of such a behavior, if not I will open an issue.
> >>>>>>> Not had one reported, and there are others using NFS on their
> >>>>>>> Raspberry Pis. We would need a LOT more information than what you've
> >>>>>>> supplied, the problem with NFS issues is that they are often very
> >>>>>>> dependent on the local setup, client/server/switch/network config
> >>>>>>> etc
> >>>>>>> so are often hard to replicate, especially without a lot of extra
> >>>>>>> details.
> >>>> _______________________________________________
> >>>> 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
> >>>>
> >>
>
4 years, 4 months
