RPi4 and support for RTC DS3231
by Barry Scott
I have an RPi4 running Fedora 38 with kernel 6.5.6-200.fc38.aarch64.
So far I figured out that I have to add this line to the config.txt
[pi4]
dtoverlay=i2c-rtc,ds3231
But after a reboot I am not seeing any /dev/rtc* devices.
Also I'm not seeing any rtc drivers load in lsmod output.
Should this work with the Fedora kernel?
If so what do I need to do to make the RTC show up?
Barry
7 months, 4 weeks
U-Boot testing request - 2023.10 series
by Peter Robinson
Hi Folks,
The 2023.10 RC series are now landing in F-39 and rawhide. There's
been the beginnings of a few enhancements.
The first one that is noticeable is a bootmenu during the firmware
init process where it will allow you to select the device/partition
you wish to boot from, with the default selected and the usual time
out. It should make things a little easier for things like
reinstalling off a USB stick for devices that support that sort of
install.
I've done some testing across a bunch of devices, various RPi, the
Pinebook pro and numerous SBCs so I think it should work just fine, at
least be no different than the usual process but I'd like to hear any
feedback.
Regards,
Peter
8 months
Fedora Linux 39 Final blocker status summary #2
by Adam Williamson
Hi folks! We're still trying to get F39 done, so time for another
status update...
Action summary
==============
Accepted blockers
-----------------
1. curl - https://bugzilla.redhat.com/2243182 - ON_QA: QA to test and
karma https://bodhi.fedoraproject.org/updates/FEDORA-2023-0f8d1871d8
2. distribution - https://bugzilla.redhat.com/2243034 - ASSIGNED:
maintainers to try and squeeze out any possible space savings, FESCo to
consider https://pagure.io/fesco/issue/3082
3. ghostscript - https://bugzilla.redhat.com/2241112 - ON_QA: QA to
test and karma
https://bodhi.fedoraproject.org/updates/FEDORA-2023-c2665a9ff3
4. initial-setup - https://bugzilla.redhat.com/2241274 - ON_QA: QA (and
pwhalen, who reported the bug) to test and karma
https://bodhi.fedoraproject.org/updates/FEDORA-2023-133bdc4283
5. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED: desktop
team to investigate and fix, now this is well triaged
6. shim - https://bugzilla.redhat.com/2113005 - NEW: stakeholders to
consider waiving again at go/no-go
7. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED: ARM
team to investigate and fix
8. distribution - https://bugzilla.redhat.com/2242759 - NEW:
stakeholders to consider whether any 'fix' is realistic, implement if
so
Proposed blockers
-----------------
1. anaconda - https://bugzilla.redhat.com/2243206 - POST: blocker
voters to vote, anaconda team to fix if accepted
Bug-by-bug detail
=================
Accepted blockers
-----------------
1. curl - https://bugzilla.redhat.com/2243182 - ON_QA
CVE-2023-38545 curl: a heap based buffer overflow in the SOCKS5 proxy
handshake [fedora-all]
The fix for this is in updates-testing and just needs testing and
karma.
2. distribution - https://bugzilla.redhat.com/2243034 - ASSIGNED
Fedora 39: Server boot aarch64 image exceeds maximum size
This image is oversize because of increases in the size of qualcomm
firmware. (The sizes of aarch64 and x86_64 images differ somewhat
because they include different firmware packages; x86_64 is fine ATM).
We can't drop the new firmware files (says pbrobinson) and I couldn't
see any obvious other place to save 6M when I looked at this. In any
case, the 700M size limit makes no practical sense for aarch64 (700M is
set as the limit because it's the size of a CD; hands up if you have an
aarch64 device with a CD-but-not-DVD drive!), and we are probably
reaching the limits of its usefulness as a protection against "bloat",
since linux-firmware is constantly increasing in size even if we don't
introduce any new "bloat" to the installer environment. So I've
proposed https://pagure.io/fesco/issue/3082 to bump the size limit to
1G for the aarch64 image at least. If FESCo goes for that proposal,
this would be addressed.
3. ghostscript - https://bugzilla.redhat.com/2241112 - ON_QA
CVE-2023-43115 ghostscript: GhostPDL can lead to remote code execution
via crafted PostScript documents [fedora-all]
The fix for this is in updates-testing and just needs testing and
karma.
4. initial-setup - https://bugzilla.redhat.com/2241274 - ON_QA
initial-setup text fails on hardware
The fix for this is in updates-testing and just needs testing and
karma. Especially it'd be great if pwhalen could test and confirm as he
reported the issue.
5. mutter - https://bugzilla.redhat.com/2241632 - ASSIGNED
Netinstall ISO renders a black screen when using kickstart install
(bare metal and VM)
I've managed to narrow this down to a specific mutter pull request
which caused the problem, and found a small change (discovered by
someone from upstream to address a different symptom) that avoids this
bug. Now up to the desktop team to decide what the best real fix is.
6. 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
Sadly we will probably have to waive this one more time, at this point
in the cycle it's not realistic to start backporting kernel changes.
7. uboot-tools - https://bugzilla.redhat.com/2241252 - ASSIGNED
Fedora-Workstation-39_Beta-1.1 boots to a black screen on Raspberry Pi
4
pbrobinson has said he's working on this, unless anyone else expert in
uboot-tools stuff wants to help, not much more to be done.
8. 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 seem to have developed a pretty good understanding of this one now,
but based on that understanding, it may not be realistically possible
to "fix" it - the only interventions proposed so far that might "fix"
it seem rather too radical to introduce as updates to a stable release
(F38), which is where they'd have to go. Unless anyone has a bright
idea, we might just have to accept that this isn't realistically
fixable and waive it to be addressed with documentation.
Proposed blockers
-----------------
1. anaconda - https://bugzilla.redhat.com/2243206 - POST
anaconda should allow installations on drives providing installation
source
This is at -3, +1 in voting currently. Needs more votes. If it happens
to be accepted, anaconda team would have to decide on a fix.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
8 months
