Fedora33 on raspberry pi 4: update problem

Ask Fedora
,
1

Hi folks, I’m new to raspberry and since I prefere fedora I installed it on a pi 4 following this guide: Fedora on Raspberry Pi :: Fedora Docs

I used “Fedora-Server-33-1.3.aarch64.raw.xz” from the official download page since those images suggested in the guide above are version 33-1.2 (see here) and didn’t boot, maybe the p4 is not yet supported by this version.

So I installed v33-1.3 using this commandline:
arm-image-installer --image Fedora-Server-33-1.3.aarch64.raw.xz --target=rpi4 --media=/dev/sdg --selinux=ON --norootpass --resizefs

This actualliy did boot and seems to be full-functional.

Problem:
Whenever I update (with “dnf update”) after the next reboot
→ WIFI-Interface completele disappears
→ USB also disappears, so no working Keyboard anymore

What can I do?

1 Like
2

I found the f33 base (33-1,3) works on a pi4. The kernel you get from a dnf update seems to have a video driver that does not work. Also I found the wireless hardware disappeared when I did a dnf update also. SO, stick with the base and avoid a dnf update (for now).

3

Welcome to the forum :slight_smile:

USB is working fine with all kernels alike here, so it might be related to your hardware.

A quick fix would be to simply exclude the kernel from being updated for now. Simply add “exclude=kernel*” to /etc/dnf/dnf.conf.

[main]
gpgcheck=1
installonly_limit=3
...
exclude=kernel*

The vc4 driver introduced in the 5.10 kernel series does not fully support the rpi4 (yet). Video works fine, but the vc4_hdmi sound driver still seems to be broken on the rpi4.
You can simply blacklist the vc4 to get working sound via snd_bcm2835, but you will be set back to the (working) fb driver for video. Hwaccel for video is (not yet) implemented anyway :wink:

You can test it by simply adding module_blacklist=vc4 to the kernel cmdline.
To test this just for the current kernel, add the entry to the appropriate config file found in /boot/loader/entries/.
To make it permanemt for all add the parameter to /etc/default/grub.

GRUB_CMDLINE_LINUX="module_blacklist=vc4 ... rhgb quiet"

followed by

grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Alternative you could add an blacklist enty to /etc/modules-load.d/ and regenerate the initrd.

Regarding the wifi issue I didn’t bother investigating yet, since I don’t use it :grin:

3 Likes
4

Thank you for the info. On my second generation of the sd card I did do a dnf update --exclude=kernel* and that fixed the video driver issue. My system lost video under a 5.10 kernel. I just stayed with a 5.8 kernel. A lot other software was updated (about 710 items). One of those 710 made my wifi disappear. On my third generation of the sd card I just stayed with the 33-1.3 base. I’ve had no problems so far with that. I’d be curious, when you have time, to see what the wifi issue is. Thanks again.

1 Like
5

You could try excluding linux-firmware as well, since it is closely related to the kernel and includes the firmware files for the brcmfmac wifi chip of the rpi4.

1 Like
6

Hi, thank you for the replies. I tried to exclude the kernel from /etc/dnf/dnf.conf by adding the line “exclude=kernel*” and updated, without luck. This alone didn’t do the trick. One may really need to exclude the inux-firmware as well, but I didn’t try this yet.

In another topic here I found a Minimal Install Image v33-1.3 that also works:
https://alt.fedoraproject.org/alt/
Is a bit hard to find, so one may find this link handy. I now flashed this one.
Bluetooth doesn’t seem to work, but I dont need it.

@jdeckerus
Yes, not updateing might be better for now, however it is save to update at least a few packages, like this:
dnf upgrade sudo* openssh* firewall* selinux* openssl* nftables* iptables*

Some sudo versions have a nasty vulnerability, see https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3156

So “dnf list installed sudo” should return at least 1.9.5p2 on Fedora 33.

One tipp for those who had the same needs with the Minimal image:
dnf install bash-completion # if you wanna have a working tab key completion (install, logout, login, works)

Set your locale in case your keyboard layout does not fit:
localectl # Show your settings
dnf search glibc-langpack # find your language pack
dnf install "your language pack" # install your language
dnf install libxkbcommon-x11 # install X11-Layouts, not certain if this is needed
localectl set-x11-keymap "language short" # sets your language

example:
localectl set-x11-keymap de # Sets your keymaps and system language to german

Edit
Remember to set a keyboard layout neutral password in advance.

7

That worked. For a base (33-1.3) system I did a dnf update --exclude=kernel* --exclude=linux-firmware*. It updated 601 packages (on feb 23) I rebooted and everything worked, video, video-sound, usb, wifi. Thank You

1 Like
8

Yes, I can also confim that exluding both kernel* and linux-firmware* is a valid workaround at the moment.

echo exclude = kernel* linux-firmware* >> /etc/dnf/dnf.conf

For the lazy ones, like me.

1 Like
9

Just coming back because I recently updated to kernel 5.10.23-200.fc33.aarch64 using "dnf upgrade kernel"and devices in question like wifi are still there.

The problematic package seems to be linux-firmware* solely.
So excluding it allone alredy makes the difference.

1 Like
10

Your experience is different than mine.

I have been running the base kernel 5.8.15 with the base firmware 20200918-119 on my Pi 4B with F33.

After you posted I tried the kernel you said, 5.10.23 and still got the totally fuzzed multicolored screen.
I then went back to the previous image before the update and tried a firmware update to the latest 20210315-119 and rebooted. Everything seemed to work, video, wireless, USB, so I made another image at that point - kernel 5.8.15 and firmware at 20210315-119.

I since have tried the 5.10.23 kernel again and still get the fuzzed video.
I then installed the latest kernel 5.11.7 and everything (almost) now works. Wireless, USB, video are good. BUT, the one thing I cannot live without is the gnome terminal, since I do a lot of command line stuff. The gnome terminal refuses to accept focus so no keyboard input works. All the gui stuff, and at least some of the other apps accept input from the keyboard so this is getting filed as a bug.

Yes, from raspios I have done the firmware update to the board itself which is supposed to support USB booting with fedora, but I have not yet tried that.

11

That’s interesting. I never had the fuzzed multicoloured screen.

Maybe we use a different image?
I use “Fedora Minimal” from here:
https://alt.fedoraproject.org/alt/

Besides of bash-completion, locales, crond, wget, tar and dnsmasq, it still is very minimal without much overhead.

Since there is no desktop environment installed, I might just don’t experince all those problems.
It just serves as a dhcp and dns provider that also has a blacklist to sort out advertising and other unwanted things.

From last time I installed up to now I didn’t update the firmware.
So I still have:
rpm -qa | grep linux-firmware
linux-firmware-whence-20200918-112.fc33.noarch
linux-firmware-20200918-112.fc33.noarch

I also added
hdmi_force_hotplug=1
to the /boot/efi/config.txt.
Since most of the time I only connect via ssh to the pi and there is (or was?) an issue that prevents the pi from starting if there’s no monitor connected. Using ssh has the advantage that I can conveniently copy and paste. All this additional functionality is provided by the controller host with the full gnome desktop environment.

Searching for a solution for that boot problem that I finally found here I might have come across a thread mentioning a fuzzed out colour screen, but I’m not sure if I remember this correctly.

To figure a bit out what’s going on I now connected a screen to it, rebooted with kernel 5.10.23-200.fc33.aarch64, and didn’t get a fuzzed multicoloured screen.

Also after updating the kernel to 5.11.7-200.fc33.aarch64 I cant see any issues, besides of missing blueteeth, which I don’t use anyway. And this is not new. Using the Fedora Minimal image the bluetooth driver never worked for me and I had no desire to get them working. Maybe they are just missing in the firmware package?
[ 15.048352] Bluetooth: hci0: BCM: firmware Patch file not found, tried:
[ 15.048363] Bluetooth: hci0: BCM: ‘brcm/BCM4345C0.hcd’
[ 15.048371] Bluetooth: hci0: BCM: ‘brcm/BCM.hcd’

What is dmesg --level crit,err saying?

Edit
Can you provide a screenshot of a fuzzed colour screen?
Sometimes this also can be caused by a the connector. But this might change if you slowly and gently move the cable at the micro hdmi connector slot. Be cautious since one can accidentaly do some harm there.

1 Like
12

+1 to this. Although not strictly related, ArchLinuxARM breaks with the most recent linux-firmware updates too so an avoidance to updating it is in order until the upstream claims it to be safe.

Reference Arch Linux ARM • View topic - linux-firmware 20210208.b79d239-1 breaks WiFi

13

Thank you very much for that link. I did not have that available before.

I will have to try later today and see what dmesg tells me, as each time it fuzzes out I have to rewrite the image to the SD card before I can try again. Writing the 64G image takes over half an hour so it is time consuming to make the attempts. The pi does not pause on the grub menu display even though I repeated the same grub setup on my PC that does so. (Pi displays the menu but does not pause) It only boots to the latest numbered kernel installed and won’t take keyboard input during the 1-2 seconds while grub menu is on the screen so it is impossible to boot to the older kernel and remove the offending one.

I am using the Fedora-Workstation-33-1.3.aarch64.raw.xz image downloaded directly from fedora. I have been able to update everything except the kernel* and linux-firmware* packages all along, and with the latest update in the firmware package even that is current now.

There is no reason to suspect a video (or any other cable) connection. My TV is the monitor and everything has consistently worked perfectly from the Pi except when I perform the update to a different kernel. Everything also works with the Ubuntu 20.10 and Raspios distros. Testing has shown that the present issue is only triggered when the kernel is changed on Fedora 33.

I can take a screenshot of the screen the next time it fuzzes.

1 Like
14

You can find the missing BCM4345C0.hcd in the RPI-Distro’s git-repo. Simply (as root) copy it to /usr/lib/firmware/brcm/, check permissions to be 644 and that’s it.

It’s not unusual to have “missing” firmware in fedora. Usually due to licensing issues.

2 Likes
15

I suspect you are still using the fb-driver and updating to the vc4-driver introduced in the 5.10 kernel-series is causing the problems, since both have their own limitations in supported video-modes. So have you tried blacklisting the vc4 driver as mentioned above?

A combination of resolution, frequency and/or overscan might be the cause of the display problems you describe.

16

grub2-reboot might be what you’re looking for :slight_smile:

grub2-reboot -h
Usage: grub2-reboot [OPTION] MENU_ENTRY
Set the default boot menu entry for GRUB, for the next boot only.
  -h, --help              print this message and exit
  -V, --version           print the version information and exit
  --boot-directory=VERZ   expect GRUB images under the directory DIR/grub2
                          instead of the /boot/grub2 directory

MENU_ENTRY is a number, a menu item title or a menu item identifier. Please note that menu items in
submenus or sub-submenus require specifying the submenu components and then the
menu item component. The titles should be separated using the greater-than
character (>) with no extra spaces. Depending on your shell some characters including > may need escaping. More information about this is available
in the GRUB Manual in the section about the 'default' command. 

NOTE: In cases where GRUB cannot write to the environment block, such as when it is stored on an MDRAID or LVM device, the chosen boot menu entry will remain the default even after reboot.
1 Like
17

Thank you for chiming in.
I can verify that the linux-firmware-20210315-119 version works on my Pi 4B. With it everything seems to work, although IDK about bluetooth. As yet I have not tried the bluetooth since I don’t use that right now.

The issues I am having relate to the kernels.
The base 5.8.15 kernel works with no issues of any kind that I have found.
I have tried several different of the 5.10 kernels, including the latest 5.10.23 and this is what I see on screen.

19e51af70ee95dfa434af025a33fa01fc4dfbbf6.jpeg
19e51af70ee95dfa434af025a33fa01fc4dfbbf6.jpeg2016×1512 1.01 MB

USB seems to work but I cannot verify that from the keyboard/mouse because of the screen. When I ssh in I can see the content of a flash drive I have plugged in so I think this only affects the video.
I tried blacklisting the vc4 module with no effect.
I looked at the dmesg output with the 5.10.23 kernel booted and I see a note about the bluetooth firmware, but nothing at all about video. Journalctl also shows noting about video.

I then reinstalled the 5.11.7 kernel and rebooted. A test at the console shows the mouse works as expected. The keyboard works for login, but once logged in the keyboard will not input anything, anywhere, and as I mentioned above, the terminal window does not even appear to take focus. In fact the keyboard would not input anything in any window I tried. I only have the gnome-terminal and firefox by default for keyboard input but it would not work with the 5.11.7 kernel booted.

I find it a little strange that the mouse (logitech MX Ergo trackball) works but the keyboard (logitech K350) does not since they are both using the same USB port via a logitech unifying receiver Also, the flash drive I have attached is accessible (when I connect via ssh) so obviously USB is functional.

18

My hardware is about the same, K360 & MX Ergo trackball, and I rember having trouble some time ago with the hid_logitech_hidpp driver simply dying on login.

rmmod hid_logitech_dj && modprobe hid_logitech_dj

…did the trick for me when needed, but the drivers are behaving quite well recently.

You could try blacklisting hid_logitech_hidpp for a test. The hardware will simply use generic drivers and work along.

Regardig the video issues it is clearly looking like timing issues to me. I’m using Xfce with X without problems, so the problem might be related to Gnome using wayland - which is a little outside of my comfort zone since I quitted using Gnome years ago.

AFAIK the settings are stored in ${HOME}/.config/monitors.xml. Maybe checking and/or testing some VESA-default settings can give a hint.

19

The 5.10 kernel has never worked on the Pi for me.
However, this morning I did another update while the kernel was excluded, and noted that there were a couple new updates to gnome, as well as some to qt5.

I then updated the kernel to 5.11.7, made the changes to the /boot/loader/entries/ conf file for the new kernel adding the module_blacklist=vc4 entry to the kernel command line, and then rebooted.

I am now sending this to you from the Pi, so the recent updates fixed the issue I have been having the last couple days with keyboard input on the 5.11.7 kernel.

I can now state that both the linux-firmware*20210315-119 packages and the kernel 5.11.7 are working fine on the Pi 4B.

# uname -a
Linux raspberry 5.11.7-200.fc33.aarch64 #1 SMP Wed Mar 17 18:43:16 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

Thanks to all for their input and I hope this is able to aid others.
Jeff

EDIT:

I just tested with and without the vc4 module blacklisted.
When that module is not blacklisted and loads, the keyboard input is blocked.
When the vc4 module is blacklisted and does not load the keyboard works normally.

Thus the only problem I have seen so far with F33 kernel 5.11.7 on the Pi seems to be related to that module.

1 Like
20

I just cross-checked on my system and the vc4 is playing quite nicely along with Xfce/X. My guess would be that either the kernel module itself, or the corresponding mesa-code is having trouble with Gnome/wayland. Only the sound via vc4_hdmi still is choppy and unusable, but that might be a case for some ALSA investigation - which I personally don’t intend ATM…

@computersavvy, you might wan’t to consider filing a bug-report.