arm October 2023

arm@lists.fedoraproject.org

11 participants
16 discussions

Fedora on Rock 5B
by Andreas Reschke 11 Jun '24

11 Jun '24

Hi there, I've tried to install Fedora on my Rock 5 without success. Booting with https://github.com/edk2-porting/edk2-rk3588/releases/download/v0.7.1/rock-5… on SD-Card and source from https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everythin…. Board boots up fine but later starting in loop with 350.456154] dracut-initqueue[1065]: Warning: ############# Anaconda installer errors end ############### [ 352.156835] dracut-initqueue[1065]: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks: [ 352.161387] dracut-initqueue[1065]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2froot.sh: "[ -e "/dev/root" ]" [ 352.164564] dracut-initqueue[1065]: Warning: /lib/dracut/hooks/initqueue/finished/wait_for_disks.sh: "[ "$main_loop" -ge "10" ]" [ 352.167716] dracut-initqueue[1065]: Warning: /lib/dracut/hooks/initqueue/finished/wait_for_settle.sh: "[ -f /tmp/settle.done ]" [ 352.171999] dracut-initqueue[1065]: Warning: dracut-initqueue: starting timeout scripts [ 352.172610] dracut-initqueue[1065]: Warning: ############# Anaconda installer errors begin ############# [ 352.172852] dracut-initqueue[1065]: Warning: # # [ 352.173097] dracut-initqueue[1065]: Warning: It seems that the boot has failed. Possible causes include [ 352.173296] dracut-initqueue[1065]: Warning: missing inst.stage2 or inst.repo boot parameters on the [ 352.173537] dracut-initqueue[1065]: Warning: kernel cmdline. Please verify that you have specified [ 352.173731] dracut-initqueue[1065]: Warning: inst.stage2 or inst.repo. [ 352.173918] dracut-initqueue[1065]: Warning: Please also note that the 'inst.' prefix is now mandatory. [ 352.174156] dracut-initqueue[1065]: Warning: # # [ 352.174354] dracut-initqueue[1065]: Warning: #### Installer errors encountered during boot: #### [ 352.174543] dracut-initqueue[1065]: Warning: # # [ 352.174775] dracut-initqueue[1065]: Warning: Reason unknown [ 352.174970] dracut-initqueue[1065]: Warning: # # Full log file: see rock.txt Has anybody more succcess ? Greetings Andreas

3 10

No devices with F39 on Raspberry Pi
by Peter Boy 30 Oct '23

30 Oct '23

Just checked the F39 rc1.2 on an raspi4 with Server Edition. The fix for the display issue (https://bugzilla.redhat.com/show_bug.cgi?id=2241252) does work for Server, too. But there is a next issue: If I try to adjust the LVM volume to the size of the SD card, I can enlarge the partition mmcblk0p3 using cfdisk as usual without issues. But with pvresize I get > $ sudo pvresize /dev/mmcblk0p3 > [sudo] password for pb: > Cannot use /dev/mmcblk0p3: device is not in devices file > 0 physical volume(s) resized or updated / 0 physical volume(s) not resized A lsblk > # lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS > mmcblk0 179:0 0 59.5G 0 disk > ├─mmcblk0p1 179:1 0 600M 0 part /boot/efi > ├─mmcblk0p2 179:2 0 1G 0 part /boot > └─mmcblk0p3 179:3 0 57.9G 0 part > └─fedora-root 253:0 0 5.4G 0 lvm / > zram0 252:0 0 3.7G 0 disk [SWAP] looks fine and as expected. And with cockpit -> storage the category „devices“ is empty (instead of listing a LVM volume fedora as to expect). It seems, there is something badly wrong with the image. Hence the error message with arm-installer after writing the image onto disk: > = Writing image complete! > mount: /tmp/root: unknown filesystem type 'LVM2_member'. > dmesg(1) may have more information after failed mount system call. as mentioned in an earlier mail and as discussed at the go/no-go meeting (https://meetbot.fedoraproject.org/fedora-meeting/2023-10-26/f39-final-go_no… ) The bottom line is that Server Edition is still unusable on Raspi4 and any other SBC, unfortunately. What to do and how to proceed (the next go/no-go meeting is in 4 days expecting rc 1.4 tomorrow or shortly after) ? -- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy(a)fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast

3 5

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by coremodule＠fedoraproject.org 30 Oct '23

30 Oct '23

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2023-10-31 from 16:00:00 to 17: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/10455/

1 0

Do we have a chance to get a fix vor the Server variant?
by Peter Boy 28 Oct '23

28 Oct '23

Just a question: Now, that the f39 release is delayed by a week, do we have a chance of a fix for the server variant? For one thing, the problem of the failed mount of the image would have to be fixed on the server variant. As far as I understand the arm installation script, either something is wrong with the disk image or it has been changed and that needs to be addressed in the script now. And furthermore it would be very helpful if the workaround for the black screen could also be done transitionally with the script. -- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy(a)fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast

2 2

Fwd: [Call for Action] Help Testing F39 ARM
by Peter Robinson 26 Oct '23

26 Oct '23

For arm testers too ---------- Forwarded message --------- From: Geoffrey Marr <gmarr(a)redhat.com> Date: Thu, Oct 26, 2023 at 5:05 AM Subject: [Call for Action] Help Testing F39 ARM To: Fedora discussions about the Internet of Things <iot(a)lists.fedoraproject.org> Hi IoT Testers, Tomorrow will be the Fedora 39 Go/No-Go (26 October 2023). Currently, there are several Raspberry Pi-related blockers that will be up for consideration at the meeting. There is a plan to attempt to get sufficient testing on an RC that was spun up several hours ago, and then vote to ship this as F39 with a notice that RPi is not supported at launch and that users should not upgrade from F38 until the issue is fixed. Because of the widespread use of RPi hardware in IoT and ARM testing however, and these bugs affecting the ability of users to test with the RPi, the F39 ARM version specifically is lacking in test results. I am reaching out to the IoT list in the hope that some of you might have ARM hardware *other than* RPi that could be used to help fill in the test matrix [0]. This could be the Jetson Nano, Odroid XU4, or any other ARM board that can boot F39 ARM and help with testing. You can find a list of other supported hardware here: [1]. This approach is a bit unorthodox, but the commonalities between Fedora IoT and Fedora ARM are such that some of the IoT users might have ARM hardware laying around that could be used for testing. Your test results will help us ship F39 without slipping again! Thanks everyone! Geoff Marr IRC: coremodule [0] https://fedoraproject.org/wiki/Test_Results:Fedora_39_RC_1.2_Summary [1] https://fedoraproject.org/wiki/Architectures/ARM#Supported_Hardware_and_Dev… _______________________________________________ IoT mailing list -- iot(a)lists.fedoraproject.org To unsubscribe send an email to iot-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/iot@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

4 4

F39 candidate composes coming - here's the plan
by Adam Williamson 26 Oct '23

26 Oct '23

Hey folks! Just to keep everyone in the loop regarding F39 plans. As you may have noticed, we've slipped once or twice already (depending on whether you count the "early target date") and are in danger of slipping again. The go/no-go meeting is scheduled for tomorrow (2023- 10-26). The outstanding blockers are all Raspberry Pi-related, aside from the shim one we've been waiving for several releases and intend to waive again. Matthew Miller, Kevin Fenzi and I came up with this plan: we're going to run a compose right now without fixes for the two outstanding Pi blockers (2241252 and 2244305). If QA can get sufficient testing on this done by the go/no-go meeting, we can discuss the possibility of shipping it and noting that there are known issues with Raspberry Pi that are taking time to resolve, and Pi users should not install or upgrade to F39 until they're resolved (or something like that). If at any point a fix for 2241252 shows up, we'll run another compose with the fix included. If that gets sufficient testing by the time of the meeting, we can also consider that as a candidate to ship. If ARM team decide to attempt a fix for 2244305 we'd also pull that in, but if not, we think it's reasonable to consider revoting or waiving that bug, as it seems not to happen very commonly or consistently and the proposed "fix" apparently comes with tradeoffs of some kind. So, QA folks, please stand ready to test one or two candidate composes soon. If we wind up with two, we will consider most test results to apply to both, as the only difference should be uboot-tools; we would want to run ARM hardware tests, at least, on both composes if possible. The usual announcement mails will be sent for the completed composes. Thanks folks! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

1 1

Re: Fedora Linux 39 Final blocker status summary #3
by Adam Williamson 26 Oct '23

26 Oct '23

On Wed, 2023-10-25 at 22:02 +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Oct 20, 2023 at 04:55:57PM -0700, Adam Williamson wrote: > > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW: anyone at > > all to come up with a genius fix, otherwise we'll likely have to > > document this > > Happy to oblige ;--] Genius located! Thanks, Zbigniew :) -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

2 2

Fedora Linux 39 Final blocker status summary #3
by Adam Williamson 26 Oct '23

26 Oct '23

Hi folks! We're still trying to get F39 done, so time for another status update... Action summary ============== Accepted blockers ----------------- 1. kexec-tools - https://bugzilla.redhat.com/2243068 - VERIFIED: releng to push the fix stable 2. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED: desktop team (and adamwill) to keep trying to come up with a fix 3. shim - https://bugzilla.redhat.com/2113005 - NEW: assume this will be waived 4. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED: ARM team (pbrobinson) to fix it 5. uboot-tools - https://bugzilla.redhat.com/2244305 - ASSIGNED: ARM team to evaluate and fix if possible, ARM/QA to test on more systems if possible 6. distribution - https://bugzilla.redhat.com/2242759 - NEW: anyone at all to come up with a genius fix, otherwise we'll likely have to document this Bug-by-bug detail ================= Accepted blockers ----------------- 1. kexec-tools - https://bugzilla.redhat.com/2243068 - VERIFIED kdump is enabled by default on desktops This is basically fixed, just waiting to be pushed stable. 2. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED Netinstall ISO renders a black screen when using kickstart install (bare metal and VM) Well, we kinda had a fix for this, but it turns out to break something even worse (now anaconda isn't visible on the Workstation live image). So we're still stuck trying to find a perfect fix, unfortunately. Desktop team plus me to keep cranking away on it. 3. shim - https://bugzilla.redhat.com/2113005 - NEW Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards Let's just assume this is gonna be waived. 4. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED Fedora-Workstation-39_Beta-1.1 boots to a black screen on Raspberry Pi 4 Peter says "So we've basically got to the bottom of the problem and worked out the issue, I now just need to come up with a fix.", so that's what we're waiting on. 5. uboot-tools - https://bugzilla.redhat.com/2244305 - ASSIGNED Fedora Server 39 does not boot on Raspberry Pi 4 (RPi4) from microSD card slot This one's also waiting on ARM team (i.e. Peter), but seems somewhat less clear-cut of a blocker, so we're kinda waiting for his take on that, plus testing from other Raspberry Pi owners would be useful. 6. distribution - https://bugzilla.redhat.com/2242759 - NEW dnf system-upgrade fails on some RPi4 due to system boot date that pre- dates gpg key We're still kinda kicking around ideas for "fixing" this, but I think if push comes to shove, we'll wind up revoting or waiving it as not practically fixable. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

3 2

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by coremodule＠fedoraproject.org 24 Oct '23

24 Oct '23

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2023-10-24 from 16:00:00 to 17: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/10455/

3 2

Re: Fedora Linux 39 Final blocker status summary #3
by Adam Williamson 21 Oct '23

21 Oct '23

On Sat, 2023-10-21 at 11:34 +0200, Tomasz Torcz wrote: > On Fri, Oct 20, 2023 at 08:40:43PM -0500, Chris Adams wrote: > > Once upon a time, Adam Williamson <adamwill(a)fedoraproject.org> said: > > > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW > > > dnf system-upgrade fails on some RPi4 due to system boot date that pre- > > > dates gpg key > > > > > > We're still kinda kicking around ideas for "fixing" this, but I think > > > if push comes to shove, we'll wind up revoting or waiving it as not > > > practically fixable. > > > > Not adding to the ticket (because "me too" is not useful there), but... > > I think Fedora should include SOME type of "fake hwclock"-type thing for > > systems with no RTC (make a systemd service depend on /dev/rtc not > > existing?), as other RPi-targeted distros do. This isn't RPi-specific, > > a number of the small boards have no RTC. I do typically add an RTC to > > my Pis, but not always (for various reasons). > > We already have systemd-timesyncd. On startup, it syncs the time to > the mtime of: > - /var/lib/systemd/timesync/clock file; or > - /usr/lib/clock-epoch file; or > - a time derived from the source tree at build time > > timesyncd is mentioned in the bug, but I didn't read everything. There are several ways we could certainly address the bug going forward. Say, starting with a Fedora 40 Change. But it seems less clear how we could safely fix it for upgrades from F37 or F38 to F39, without pushing a level of change that is inappropriate for a stable release. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

arm October 2023