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
>> 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 to ship microdnf by default for all spins aimed at
potentially low memory machines.
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:
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
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:
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
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.
IRC: adamw | Twitter: adamw_ha
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:
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
for that announcement.
IRC: adamw | Twitter: adamw_ha
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...
Net: eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
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()!
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: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks:
[ 368.471849] dracut-initqueue: 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: [ -e "/dev/disk/by-uuid/6c12ffc9-6ea9-457c-9acf-7a886798e99c" ]
[ 368.473753] dracut-initqueue: fi"
[ 368.545042] dracut-initqueue: Warning: dracut-initqueue: starting timeout scripts
[ 370.304891] dracut-initqueue: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks:
[ 370.353412] dracut-initqueue: 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: [ -e "/dev/disk/by-uuid/6c12ffc9-6ea9-457c-9acf-7a886798e99c" ]
[ 370.355428] dracut-initqueue: fi"
[ 370.426159] dracut-initqueue: Warning: dracut-initqueue: starting timeout scripts
[ 371.795792] dracut-initqueue: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks:
[ 371.845592] dracut-initqueue: 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: [ -e "/dev/disk/by-uuid/6c12ffc9-6ea9-457c-9acf-7a886798e99c" ]
[ 371.847604] dracut-initqueue: fi"
[ 371.922589] dracut-initqueue: 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.
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
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.
PO Box 896
Cowra NSW 2794
I have a Pi4B that is working pretty well with the aarch64 version of Fedora Rawhide, but I have one issue that I haven't been able to find a solution to.
I have an Adafruit RTC connected via I2C (https://www.adafruit.com/product/3386). If I use the kernel device tree, this device is not found.
I then tried switching to the firmware device tree via the instructions in https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi/HATs. That works pretty well - I can now add an overlay for the RTC in /boot/efi/config.txt and the RTC is found during boot. dtoverlay=i2c-rtc,pcf8523,addr=0x68
However, once I've switched to the firmware device tree, I no longer have /dev/vchiq, which means that I can no longer use vcgencmd. Instead, vcgencmd gives me "VCHI initialization failed".
Is there any way to get both the RTC and vcgencmd to work? Which device tree would I choose? Do I have to build a custom kernel or is there some other way to enable the RTC with the kernel device tree?