BeagleBone Black cannot boot with Fedora 34/35
by Zamir SUN
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/
5 months, 3 weeks
Fedora on Odroid M1
by Andreas Reschke
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
10 months, 1 week
Re: Heads-up / for discussion: dnf not working with 1G of RAM or less
by Sandro
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/f...
-- Sandro
1 year
Heads-up / for discussion: dnf not working with 1G of RAM or less
by Adam Williamson
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/...
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
1 year, 1 month
Request for testing: Fedora 37 pre-Beta validation tests
by Adam Williamson
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.fedorap...
for that announcement.
Thanks folks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
1 year, 1 month
Failures booting on Pi4
by Steven A. Falco
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
1 year, 1 month
RPi (or something similar) cluster and GlusterFS - feedback?
by Philip Rhoades
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
1 year, 1 month
