forked from sig_altarch/RockyRpi
85 lines
3.0 KiB
Plaintext
85 lines
3.0 KiB
Plaintext
List of technical issues encountered in building the Rocky 9 Raspberry Pi image, and how they were overcome:
|
|
|
|
|
|
###
|
|
1)
|
|
SELinux file label issues during image create:
|
|
|
|
When SELinux is enforcing in the image, it attempts to label files as the kickstart is running.
|
|
Unfortunately, if building an EL9 image on an EL8 kernel + host system, there will be incompatibilities with the labels on the SELinux implementations, which causes the errors.
|
|
|
|
SOLUTION: Build the image on an EL9 or equivalent Fedora host, or disable SELinux in the kickstart (it can be turned on later in the image, but there is a relabel process to go through)
|
|
|
|
|
|
|
|
|
|
###
|
|
2)
|
|
RPMDB + libdnf issues:
|
|
|
|
When trying to install new packages, you get repeated warnings from DNF saying "warning: Found bdb Packages database while attempting sqlite backend: using bdb backend."
|
|
It also prevents the import of RPM GPG keys, which effectively means no package installs.
|
|
|
|
Similar to this:
|
|
https://bugzilla.redhat.com/show_bug.cgi?id=1836108
|
|
|
|
|
|
SOLUTION: Build the image on an EL9 host, OR run "rpmdb --rebuilddb" at the end of %post in kickstart, or on the Raspberry Pi itself.
|
|
|
|
|
|
|
|
|
|
###
|
|
3)
|
|
RPi Broadcom Wifi Issue
|
|
|
|
Since Fedora 34(?), the linux-firmware package has all of its artifacts xz-compressed in order to save space.
|
|
This breaks the Raspberry Pi wifi driver, as the firmware file locations are hard-coded, and will not use the .xz files.
|
|
|
|
|
|
SOLUTION:
|
|
As a workaround, a script is included in the rocky-rpi-release package which copies the firmware .xz files, extracts them, and puts them back in the proper directory (alongside the original .xz files).
|
|
The script (fix-wifi-rpi.sh) is run during the kickstart to fix wireless, and can be run by root at any time.
|
|
The files in question live in /lib/firmware/brcm/.
|
|
|
|
A better, non-workaround solution will require more research - likely a rpi-kernel patch.
|
|
|
|
|
|
|
|
|
|
|
|
###
|
|
4)
|
|
DNF/Appliance Creator Unmount issues:
|
|
|
|
When finishing image creation, the host machine's DNF can "hang" on to open files, causing the various unmounts at the end of the process to fail, and thus the whole image process.
|
|
|
|
The errors vary in their locations, but look like this:
|
|
|
|
umount: /var/tmp/imgcreate-e84ozsji/install_root/sys/fs/selinux/load: not mounted.
|
|
Traceback (most recent call last):
|
|
File "/usr/bin/livecd-creator", line 265, in
|
|
sys.exit(main())
|
|
|
|
|
|
Livecd-Tools Bug Report and discussion: https://github.com/livecd-tools/livecd-tools/issues/232
|
|
Related RH Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2087734
|
|
LibDNF patch: https://github.com/rpm-software-management/dnf/commit/5ce5ed1ea08ad6e198c1c1642c4d9ea2db6eab86
|
|
|
|
|
|
SOLUTION:
|
|
|
|
A simple patch needs to be applied to the HOST system's libdnf base.py (ex: /usr/lib/python3.9/site-packages/dnf/base.py )
|
|
The patch is here: https://github.com/rpm-software-management/dnf/commit/5ce5ed1ea08ad6e198c1c1642c4d9ea2db6eab86
|
|
|
|
Basically: "import gc" (at the top)
|
|
|
|
and at the bottom of the reset() method:
|
|
|
|
if sack and goal:
|
|
gc.collect()
|
|
|
|
|
|
This fixes the hanging file handle/unmount issue
|
|
|