Should Fedora 33 on ARM use BTRFS by default?
I downloaded Fedora-Minimal-armhfp-33-1.2-sda.raw.xz image and installed
it to my Odroid XU4. Checking output from mount -l shows / mounted as
EXT4. I thought Fedora 33 was meant to use BTRFS by default.
I've tried to boot / install Fedora-Server-netinst-aarch64-33-1.2.iso on
my Helios64. Boot starts fine but after few seconds it stops with errors
in dracut shell.
fedora1.txt is complete bootlog
rdsosreport.txt is the generated file from dracut.
Does anybody has a tip to resolve this and get Fedora on Helios64?
In the meeting right after the F33 release, we talked about identifying a
handful of key devices and making sure anyone with a serious interest in
testing or enablement work has what they need. I've talked with Marie, and
while we're not overflowing with cash, Fedora does have unspent budget which
would normally have gone to travel sponsorships and this seems to be a
reasonable thing to use some of it on. IoT is a Fedora Edition, after all,
and worth investing in.
At that meeting, we talked about y'all coming up with a list of specific
hardware we can order for people. Because reimbursements are a mess right
now for unrelated reasons, it's easiest when it's something Marie can
actually go to a web store, click some buttons, and have shipped direct. Can
y'all (IoT WG and ARM SIG) come up with a formal list with prices and URLs?
(Also, if other things like microsd cards need to be included?)
Of course, once we have a list of hardware, I'd also like to send it to
people. I know there's some worry about people volunteering, getting stuff,
and not actually doing anything. We want to make sure the devices are going
to people who will actually be able to make use of them. But I also don't
want that to be a blocker, so, if you're new but serious I am willing to
consider including you too. (Perhaps with the promise that if your best
intentions don't work out, you find someone else to pass the hardware on
Rather than people emailing me at random, which is easy for me to drop, can
the WG and/or SIG come up with a list of people? I'm thinking something like
a dozen people and 1-3 devices each depending on commitment level.
Fedora Project Leader
I'd like to volunteer to help ARM. Also, doesn't have any platform of
preference, where help is needed, I want to help.
El mar., 10 nov. 2020 a las 14:21, Massimiliano Ziccardi (<
> I'd like to volunteer to help test ARM images too. I don't have much
> hardware, but I will be happy to buy some if needed.
> Il giorno mar 10 nov 2020 alle ore 18:12 Jared K. Smith <
> jsmith(a)fedoraproject.org> ha scritto:
>> On Tue, Nov 10, 2020 at 11:30 AM Matthew Miller <mattdm(a)fedoraproject.org>
>>> At that meeting, we talked about y'all coming up with a list of specific
>>> hardware we can order for people.
>> I would love to see the nVidia Jetson Nano (roughly $99 USD) or Jetson
>> Nano 2GB (roughly $54 USD) on that list. I have to of the 4GB version, and
>> thanks to Peter and a few other people doing lots of thankless work, they
>> work quite well out of the box with F33.
>> I'm also happy to volunteer to help test ARM images and the IoT spin on
>> said hardware.
>> IoT mailing list -- iot(a)lists.fedoraproject.org
>> To unsubscribe send an email to iot-leave(a)lists.fedoraproject.org
>> Fedora Code of Conduct:
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
> IoT mailing list -- iot(a)lists.fedoraproject.org
> To unsubscribe send an email to iot-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
GNU/Linux User #589060
Ubuntu User #8749
Fedora Marketing Representative
i have an orange pi r1 that has been in the drawer for a while, b/c it
wasn't supported by any actual distro/upstream kernel when i last tried
to use it. Now it's supported by the fedora-arm-installer (thanks!), and
i installed Fedora-Minimal-armhfp-33-1.2-sda.raw.xz with
fedora-arm-installer and that reported success. I used a new industrial
san disk sd card. i'm powering the board with an usb cable from my
desktop machine and monitoring with minicom via generic usb serial
cable. Unfortunately, everything stops when it gets to "Starting
kernel". Here is the output from minicom:
U-Boot SPL 2020.10 (Oct 06 2020 - 00:00:00 +0000)
DRAM: 256 MiB
Trying to boot from MMC1
U-Boot 2020.10 (Oct 06 2020 - 00:00:00 +0000) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi R1
DRAM: 256 MiB
MMC: mmc@1c0f000: 0, mmc@1c10000: 1
Loading Environment from FAT... Unable to use mmc 0:2... In: serial
Net: phy interface0
Bus usb@1c1a000: USB EHCI 1.00
Bus usb@1c1a400: USB OHCI 1.0
Bus usb@1c1b000: USB EHCI 1.00
scanning bus usb@1c1a000 for devices... 1 USB Device(s) found
scanning bus usb@1c1a400 for devices... 1 USB Device(s) found
scanning bus usb@1c1b000 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:2...
Retrieving file: /extlinux/extlinux.conf
540 bytes read in 3 ms (175.8 KiB/s)
Ignoring unknown command: ui
Ignoring malformed menu command: autoboot
Ignoring malformed menu command: hidden
Ignoring unknown command: totaltimeout
1: Fedora-Minimal-armhfp-33-1.2 (5.8.15-301.fc33.armv7hl)
Retrieving file: /initramfs-5.8.15-301.fc33.armv7hl.img
51820791 bytes read in 2314 ms (21.4 MiB/s)
Retrieving file: /vmlinuz-5.8.15-301.fc33.armv7hl
8610304 bytes read in 385 ms (21.3 MiB/s)
append: ro root=UUID=c60371a2-5cff-4049-b0bb-c22616edca85 rhgb quiet
Retrieving file: /dtb-5.8.15-301.fc33.armv7hl/sun8i-h2-plus-orangepi-r1.dtb
22822 bytes read in 13 ms (1.7 MiB/s)
## Flattened Device Tree blob at 43000000
Booting using the fdt blob at 0x43000000
EHCI failed to shut down host controller.
Loading Ramdisk to 46e94000, end 49fff8f7 ... OK
Loading Device Tree to 46e8b000, end 46e93925 ... OK
Starting kernel ...
A few of you have seen this already, but just wanted to send out a
wider announcement: having been deservedly shamed by pbrobinson, I
spent most of this week working on aarch64 testing in openQA, and am
happy to announce that:
* Quite a few existing issues in tests have been fixed
* Testing coverage has been enhanced a lot to cover the Minimal, Server
and Workstation disk images, with the full set of Base tests run on
* aarch64 testing is now enabled on the production openQA instance!
We've had testing running on the lab (formerly known as staging)
instance for a long time now, and I've been meaning to also enable it
on production for over a year, but it kept getting delayed by this and
that (most recently, the infra move). But now it's done.
The consequences of this - beyond, of course, that you can now see
aarch64 tests in the production openQA web UI - should be that the
aarch64 results show up in the "compose check report" emails, and will
also show up in the validation wiki pages, just like x86_64 results.
openQA should fill in quite a lot of boxes in the Installation, Base
and Cloud pages for future validation events, taking some of the test
load off of manual testers. Next week I intend to enable most of the
Desktop tests on the Workstation disk image too.
I have not enabled updates testing yet, because we just don't have the
capacity, unfortunately. If we can get more testing capacity we could
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
A while ago (around the freeze of FC29) grub2-efi on top of Uboot was proposed as the (potentially) default setup for armhfp too. Unfortunately (IMHO) it did not materialize and I'm searching for the game-breaker.
On buggzilla found a few hints, " we have at least a grub2 <-> kernel bug" (1) among them, they did not make the holdup clear to me.
My investigation so-far:
* It works pretty good with a close to upstream build grub, not with the default gub2 packages. Which makes me believe loading an arm32 kernel as an Portable Executable instead of grub's LoadImage() and StartImage() services may be a game-stopper. NOTE : I understand this is necessary for chain loading efi stubs for secure-boot. IMO this is not the pursued goal here.
* Since kernel patch "efi: libstub/arm: account for firmware reserved memory at the base of RAM" (2) it works on RPI's too (given a "custom" build grub2)
All feedback is appreciated,