PSA: Rawhide Server (and other xfs) installs broken
by Adam Williamson
Hey folks! Just a heads up that Rawhide Server installs are broken in
today's Rawhide compose (and any custom install using xfs). This is
because a new version of xfsprogs went into Rawhide and grub2 cannot
detect filesystems made with it:
https://bugzilla.redhat.com/show_bug.cgi?id=2247926
I've identified the patches needed in grub2, but I can't patch it
myself as I'm not on the list of people who can build packages that
need to be Secure Boot signed, and anyway, working on the grub2 package
is a bit of a nightmare for non-maintainers due to the whole "hundreds
of patches that are pulled from an alternative upstream git repo"
thing.
I've requested xfsprogs be untagged for now:
https://pagure.io/releng/issue/11763
so if that gets done, things should work again after the next compose.
Unfortunately openQA didn't catch this because we don't test xfs
installs on updates :( Maybe I'll have to add a test somehow.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
5 months, 3 weeks
Cuirrent state of F39 Fedora Server Edition for ARM SBCs / RaspberryPi
by Peter Boy
As with the latest release candidate (rc 1.5) from today we have still an issue with the ARM SBC / RPi image.
* The RPi image needs a nomodeset fix on the arm-imange-installer comandline, otherwise it boots with a black screen
* Afterwards you can’t manage the storage because LVM is broken.
* All my Rockchip based devices (RockPro64, Rock Pi 4, Roc-3399-pc) can’t boot at all, because the broken LVM prevents the U-Boot files to get copied onto the SD card. The same will be true for all other devices besides RPi, too, that need U-Boot files to be able to boot
See details in the bug reports:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2246871
https://bugzilla.redhat.com/show_bug.cgi?id=2244305
There are ways around that
* You can fix that by manually deleting the content of /etc/lvm/devices, which is currently not documented anywhere and probably not a location, an admin should mess with. An RPi would then work as far as I know. For all other devices this doesn’t work without additional steps.
* You get the other devices booting which have a workable *and* compatible SPI U-Boot installed and can substitute the U-Boot files otherwise be copied to the SD card by arm-image-installer. And then use the before mentioned fix.
* Fedora provides for some devices a SPI module which should work (I didn’t test that). But it is a real challenge to install those the Fedora way (https://nullr0ute.com/2021/05/fedora-on-the-pinebook-pro/), and a real adventure if you have a non-US keyboard.
* Some devices are supported by non-Fedora software, e.g. tow-boot (https://tow-boot.org <https://tow-boot.org/>). You can install the SPI very comfortable and the current version can also boot the Fedora image without Fedora U-Boot files.
In the latter 3 cases you would additionally have to fix the LVM image.
The question is, how to proceed with that situation.
a) I suggested to make the bug a release blocker.
b) Others objected, because there is a workaround available.
In case of b)
Do we really want to publish a broken image along with the other media as a regular release?
Alternatively, we might
- Publish it separately well below our regular media as kind of "technical sneak preview“
- Skip F39 for ARM SBC and continue to distribute the F38 image
- rely to third party software, e.g. tow-boot for devices it supports
- Other ideas?
We should discuss this today at the meeting.
--
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
5 months, 3 weeks
