arm August 2022

arm@lists.fedoraproject.org

14 participants
13 discussions

BeagleBone Black cannot boot with Fedora 34/35
by Zamir SUN 04 Apr '23

04 Apr '23

Hi, Recently I reflashed my BeagleBone Black. However, I find it simply cannot go beyond uboot with Fedora 34 or Fedora 35. Images I tried: Fedora-Minimal-35-20211020.n.0.armhfp.raw.xz Fedora-Minimal-34-1.2.armhfp.raw.xz If I press the button when plug the power cable, it will loop forever like the following U-Boot SPL 2021.10 (Oct 14 2021 - 00:00:00 +0000) Trying to boot from MMC1 U-Boot SPL 2021.10 (Oct 14 2021 - 00:00:00 +0000) Trying to boot from MMC1 U-Boot SPL 2021.10 (Oct 14 2021 - 00:00:00 +0000) Trying to boot from MMC1 CCCCCCCC U-Boot SPL 2021.10 (Oct 14 2021 - 00:00:00 +0000) Trying to boot from MMC1 If I don't press the button it will boot directly to the system in emmc. I've tried different tf cards and concluded it's not the card issue. The latest image that works for me on BBB is Fedora-Minimal-armhfp-33-1.2-sda.raw.xz It's interesting that the image has a different name schema that F34/F35 ones(the sda in filename). I roughly remember I also tried F33 without 'sda' - Fedora-Minimal-33-1.3.armhfp.raw.xz and IIRC this also cannot boot. So is there any different for images with or without -sda ? Can anyone offer some suggestions how I can test or boot F35 on BBB? Thanks in advance! -- Zamir SUN GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E Want to know more about Fedora? Visit https://fedoraproject.org/wiki/ Ready to contribute? See https://whatcanidoforfedora.org/ 想了解更多中文资讯，访问 https://zh.fedoracommunity.org/

2 3

Fedora on Odroid M1
by Andreas Reschke 19 Nov '22

19 Nov '22

Hello, I would like to buy a Odroid M1 (CPU RK3568B2, petitboot as bootloader). Is there any change to install Fedora on it? Even a headless installation would be nice. Greetings Andreas

2 5

Re: Heads-up / for discussion: dnf not working with 1G of RAM or less
by Sandro 30 Aug '22

30 Aug '22

On 29-08-2022 19:32, Chris Murphy wrote: > > > On Mon, Aug 29, 2022, at 11:12 AM, Chris Murphy wrote: >> On Mon, Aug 29, 2022, at 11:10 AM, Adam Williamson wrote: > >>> There *is* a workaround, BTW - I didn't mention this in my >>> original mail, and probably should have. At least according to >>> discussion in the bug, microdnf works OK. So you can use that >>> instead. >> >> Yes, but will you be able to install it? Yes you could go to koji, >> download the correct RPMs, and have rpm do it without dnf but... >> that'd be a pretty saucy work around. > > Can microdnf and dnf co-exist? If so, maybe the non-desktops should > just include microdnf along side dnf? Or is this potentially a trap > where microdnf can also fail for the same reason (i.e. it's not dnf, > it's the size of the repo metadata)? Yes, booth can co-exist. It was proposed at the blocker review meeting[1] to ship microdnf by default for all spins aimed at potentially low memory machines. [1] https://meetbot-raw.fedoraproject.org//fedora-blocker-review/2022-08-29/f37… -- Sandro

1 0

Heads-up / for discussion: dnf not working with 1G of RAM or less
by Adam Williamson 29 Aug '22

29 Aug '22

Hey folks! I apologize for the wide distribution, but this seemed like a bug it'd be appropriate to get a wide range of input on. There's a bug that was proposed as an F37 Beta blocker: https://bugzilla.redhat.com/show_bug.cgi?id=1907030 it's quite an old bug, but up until recently, the summary was apparently accurate - dnf would run out of memory with 512M of RAM, but was OK with 1G. However, as of quite recently, on F36 at least (not sure if anyone's explicitly tested F37), dnf operations are commonly failing on VMs/containers with 1G of RAM due to running out of RAM and getting OOM-killed. There's some discussion in the bug about what might be causing this and potential ways to resolve it, and please do dig into/contribute to that if you can, but the other question here I guess is: how much do we care about this? How bad is it that you can't reliably run dnf operations on top of a minimal Fedora environment with 1G of RAM? This obviously has some overlap with our stated hardware requirements, so here they are for the record: https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/Ha… that specifies 2GB as the minimum memory for "the default installation", by which I think it's referring to a default Workstation install, though this should be clarified. But then there's a "Low memory installations" boxout, which suggests that "users with less than 768MB of system memory may have better results performing a minimal install and adding to it afterward", which kinda is recommending that people do exactly the thing that doesn't work (do a minimal install then use dnf on it), and implying it'll work. After some consideration I don't think it makes sense to take this bug as an F37 blocker, since it already affects F36, and that's what I'll be suggesting at the next blocker review meeting. However, it does seem a perfect candidate for prioritized bug status, and I've nominated it for that. I guess if folks can chime in with thoughts here and/or in the bug report, maybe a consensus will emerge on just how big of an issue this is (and how likely it is to get fixed). There will presumably be a FESCo ticket related to prioritized bug status too. Thanks folks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

5 4

Request for testing: Fedora 37 pre-Beta validation tests
by Adam Williamson 29 Aug '22

29 Aug '22

Hey folks! So we're in freeze for Fedora 37 Beta now, and the first go/no-go meeting should be on September 8. It would be really great if we can get the validation tests run now so we can find any remaining blocker bugs in good time to get them fixed. Right now the blocker list looks short, but there are definitely some tests that have not been run. You can use the testcase_stats view to find tests that need running: https://openqa.fedoraproject.org/testcase_stats/37/ For each validation test set (Base, Desktop etc.) it shows when each test was last performed. So you can easily look for Basic and Beta tests that have not yet been run. We need to run all of these. You can enter results using `relval report-results`, or edit the summary results page at https://fedoraproject.org/wiki/Test_Results:Current_Summary . That's a redirect link which will always point to the validation results page for the currently-nominated compose, which right now is 20220826.n.0. Sumantro will be running a validation 'test week' starting on Wednesday, so you can drop by the Fedora Test Day room on chat.fedoraproject.org to hang out with other testers and get any help you need in testing. See https://lists.fedoraproject.org/archives/list/test-announce@lists.fedorapro… for that announcement. Thanks folks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

1 0

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by pwhalen＠fedoraproject.org 28 Aug '22

28 Aug '22

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2022-08-30 from 15:00:00 to 16:00:00 UTC At fedora-meeting-2(a)irc.libera.chat The meeting will be about: Fedora ARM & AArch64 weekly status meeting. More information available at: [https://fedoraproject.org/wiki/Architectures/ARM](https://fedoraproject.org… Source: https://calendar.fedoraproject.org//meeting/9910/

1 0

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by pwhalen＠fedoraproject.org 21 Aug '22

21 Aug '22

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2022-08-23 from 15:00:00 to 16:00:00 UTC At fedora-meeting-2(a)irc.libera.chat The meeting will be about: Fedora ARM & AArch64 weekly status meeting. More information available at: [https://fedoraproject.org/wiki/Architectures/ARM](https://fedoraproject.org… Source: https://calendar.fedoraproject.org//meeting/9910/

1 0

Failures booting on Pi4
by Steven A. Falco 17 Aug '22

17 Aug '22

Since there has been discussion about supporting Fedora on the Pi4, I decided to try a few rawhide images on a Pi4B with 2 GB of RAM. Most of the experiments below used uSD cards. The results are very strange. To begin, I connected Ethernet, a mouse, keyboard, and an HDMI monitor, along with a serial port on pins 8 and 10 of the 40-pin connector. Fedora-Minimal-Rawhide-20220717.n.0.aarch64.raw.xz fails with the following on the serial port: U-Boot 2022.07-rc6 (Jul 04 2022 - 00:00:00 +0000) DRAM: 2 GiB RPI 4 Model B (0xb03115) Core: 211 devices, 17 uclasses, devicetree: board MMC: mmcnr@7e300000: 1, mmc@7e340000: 0 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... Unexpected XHCI event TRB, skipping... (3db5f620 00000004 01000000 01008401) BUG at drivers/usb/host/xhci-ring.c:530/abort_td()! BUG! resetting ... I tried disconnecting the mouse, keyboard, and Ethernet, but I got the same failure. I then tried just disconnecting the HDMI monitor, while leaving everything else connected. In that case I am able to get further, but then I start getting timeout messages from dracut: [ OK ] Started plymouth-start.ser…e - Show Plymouth Boot Screen. [ OK ] Started systemd-ask-passwo…uests to Plymouth Directory Watch. [ OK ] Reached target cryptsetup.…get - Local Encrypted Volumes. [ OK ] Reached target paths.target - Path Units. [ OK ] Finished systemd-udev-sett…To Complete Device Initialization. Starting multipathd.servic…per Multipath Device Controller... [ OK ] Started multipathd.service…apper Multipath Device Controller. [ OK ] Reached target local-fs-pr…reparation for Local File Systems. [ OK ] Reached target local-fs.target - Local File Systems. Starting systemd-tmpfiles-… Volatile Files and Directories... [ OK ] Finished systemd-tmpfiles-…te Volatile Files and Directories. [ OK ] Reached target sysinit.target - System Initialization. [ OK ] Reached target basic.target - Basic System. [ 368.423014] dracut-initqueue[441]: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks: [ 368.471849] dracut-initqueue[441]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2f6c12ffc9-6ea9-457c-9acf-7a886798e99c.sh: "if ! grep -q After=remote-fs-pre.target /run/systemd/generator/systemd-cryptsetup(a)*.service 2>/dev/null; then [ 368.472914] dracut-initqueue[441]: [ -e "/dev/disk/by-uuid/6c12ffc9-6ea9-457c-9acf-7a886798e99c" ] [ 368.473753] dracut-initqueue[441]: fi" [ 368.545042] dracut-initqueue[441]: Warning: dracut-initqueue: starting timeout scripts [ 370.304891] dracut-initqueue[441]: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks: [ 370.353412] dracut-initqueue[441]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2f6c12ffc9-6ea9-457c-9acf-7a886798e99c.sh: "if ! grep -q After=remote-fs-pre.target /run/systemd/generator/systemd-cryptsetup(a)*.service 2>/dev/null; then [ 370.354565] dracut-initqueue[441]: [ -e "/dev/disk/by-uuid/6c12ffc9-6ea9-457c-9acf-7a886798e99c" ] [ 370.355428] dracut-initqueue[441]: fi" [ 370.426159] dracut-initqueue[441]: Warning: dracut-initqueue: starting timeout scripts [ 371.795792] dracut-initqueue[441]: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks: [ 371.845592] dracut-initqueue[441]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2f6c12ffc9-6ea9-457c-9acf-7a886798e99c.sh: "if ! grep -q After=remote-fs-pre.target /run/systemd/generator/systemd-cryptsetup(a)*.service 2>/dev/null; then [ 371.846757] dracut-initqueue[441]: [ -e "/dev/disk/by-uuid/6c12ffc9-6ea9-457c-9acf-7a886798e99c" ] [ 371.847604] dracut-initqueue[441]: fi" [ 371.922589] dracut-initqueue[441]: Warning: dracut-initqueue: starting timeout scripts Next, I tried Fedora-KDE-Rawhide-20220717.n.0.aarch64.raw.xz and Fedora-Workstation-Rawhide-20220717.n.0.aarch64.raw.xz. Amazingly, they are able to get past the XHCI error even with the HDMI monitor connected. However, they still fail later in the startup process with the same dracut messages that I showed above. I then tried Fedora-Server-Rawhide-20220717.n.0.aarch64.raw.xz. It booted with everything connected. It got to the initial configuration menu, let me set the root password, and booted to a login prompt, which worked perfectly. As a final test, I tried the Fedora-Minimal-Rawhide-20220717.n.0.aarch64.raw.xz and Fedora-KDE-Rawhide-20220717.n.0.aarch64.raw.xz images on a USB flash stick instead of on a uSD card. Both worked perfectly. So, there is something bizarre happening with uSD cards with most of the images I tested. The only image that works for me on a uSD card is the Server image. Note that I tried several different uSD cards - Samsung, SanDisk, and a "no name" card, and got consistent results, so I don't think the uSD cards are at fault. I tried two different USB flash sticks, a SanDisk and a Transcend - both worked perfectly. Steve

5 8

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by pwhalen＠fedoraproject.org 14 Aug '22

14 Aug '22

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2022-08-16 from 15:00:00 to 16:00:00 UTC At fedora-meeting-2(a)irc.libera.chat The meeting will be about: Fedora ARM & AArch64 weekly status meeting. More information available at: [https://fedoraproject.org/wiki/Architectures/ARM](https://fedoraproject.org… Source: https://calendar.fedoraproject.org//meeting/9910/

1 0

RPi (or something similar) cluster and GlusterFS - feedback?
by Philip Rhoades 12 Aug '22

12 Aug '22

People, For many years (after some nasty experiences) I have been in the habit of using a Fedora Work Station (which stays on but gets rebooted fairly frequently) and a separate Fedora server (email-MTA, some Web sites etc) which stays on for very long periods of time and only gets rebooted infrequently. I have other systems that get booted occasionally. My habit has been to backup / rsync important / critical data between the regular WS and the main server as appropriate - this has allowed me on a number of occasions to recover happily when hardware has failed, to get going temporarily again on one or the other machine while I sort out the problem. More recently I have been thinking about building an ARM cluster with Gluster that would hold all the data for both the WS and the main server and any other WSs or servers I might need to run from time to time. I would still make use of an off-site backup anyway but I like the idea of just being able to add another ARM device + SATA drive to the cluster to create more data space. I also thought I would go back to making use of WSs that were basically just X-servers that booted from some sort of USB stick but got the OS image from the cluster - this might be complicated by the fact I now use Sway rather than X - but one problem at a time . . Has anyone here set up a cluster something like this? Have people any suggestions about specific Fedora web pages / docs to look at? I have been tracking CEPH for some time and while it looks interesting, it seems overkill for what I am thinking of doing and more technically difficult to support / debug etc. I am thinking of starting the exercise with 4 RPis each with an 8Tb SATA drive. Thanks, Phil. -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: phil(a)pricom.com.au

5 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

arm August 2022