Update to Fedora 39-40 failed / Kernel won't update

Ask Fedora
,
1

Hi there,

I’ve updated a Fedora Workstation to v39 (and v40 yesterday). During the upgrade process I did not see any errors. Booting also gave me no problems, but when I tried to login my system froze for about 1 minute, and then send me back to the login screen. When I reboot my system and select a different kernel version (5.2.17-300.fc30.x86_64) I could succesfully login, but I can’t login using the latest installed kernel (5.3.11-300.fc31.x86_64).

Now this is the first time I noticed that my system hasn’t updated my kernel in a loooong time. I assumed that when I updated/upgraded my system it would automatically update my kernel as well, but aparently something is broken.

Anyone got some ideas on how I can:

  1. Repair dnf so it automatically updates the kernel properly?
  2. Fix my login problems?

Here’s some preliminary data on the system:

$ uname -a
Linux xxxxx.yyy.local 5.2.17-200.fc30.x86_64 #1 SMP Mon Sep 23 13:42:32 UTC 2019 x86_64 GNU/Linux

$ cat /etc/os-release 
NAME="Fedora Linux"
VERSION="40 (Workstation Edition)"
ID=fedora
VERSION_ID=40
VERSION_CODENAME=""
PLATFORM_ID="platform:f40"
PRETTY_NAME="Fedora Linux 40 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:40"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f40/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=40
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=40
SUPPORT_END=2025-05-13
VARIANT="Workstation Edition"
VARIANT_ID=workstation
2

How much free space do your root and boot partitions have? If you have been upgrading since Fedora 30 your partitions may be too small.

There are ways to “lock” or “protect” specific packages and also ways to limit the number of kernel versions that are installed. Is it possible you used the version-lock plugin or added a file in /etc/dnf/protected.d?

It is helpful if you provide the output from inxi -Fzxx and df -lH so we have a full picture of your hardware platform.

You might want to try booting the Live USB to check that your system can run Fedora 40.

3

I have to ask, is this an honest mistake ? You mentioned Fedora 39 > Fedora 40 but the kernels you are listing are from Fedora 30 and Fedora 31 respectively :thinking:

4

Hi George, thanks for your reply. Here’s my system info:

$ inxi -Fzxx
System:
  Kernel: 5.2.17-200.fc30.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 9.2.1
  Desktop: GNOME v: 46.1 tk: GTK v: 3.24.41 wm: gnome-shell dm: GDM
    Distro: Fedora Linux 40 (Workstation Edition)
Machine:
  Type: Desktop System: Shuttle product: SH67H v: V1.0
    serial: <superuser required>
  Mobo: Shuttle model: FH67H v: 1.0 serial: <superuser required>
    part-nu: 1.0 BIOS: American Megatrends v: 2.06 date: 09/11/2014
CPU:
  Info: quad core model: Intel Core i5-3570K bits: 64 type: MCP
    arch: Ivy Bridge rev: 9 cache: L1: 256 KiB L2: 1024 KiB L3: 6 MiB
  Speed (MHz): avg: 3408 high: 3621 min/max: 1600/3800 cores: 1: 3526
    2: 3621 3: 3444 4: 3042 bogomips: 27136
  Flags: avx ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: AMD Caicos PRO [Radeon HD 7450] vendor: Micro-Star MSI
    driver: radeon v: kernel arch: TeraScale-2 pcie: speed: 2.5 GT/s lanes: 16
    ports: active: HDMI-A-1 empty: DVI-D-1,VGA-1 bus-ID: 01:00.0
    chip-ID: 1002:677b temp: 39.0 C
  Display: x11 server: X.Org v: 1.20.14 with: Xwayland v: 23.2.6
    compositor: gnome-shell driver: X: loaded: radeon
    unloaded: fbdev,modesetting,vesa dri: r600 gpu: radeon display-ID: :0
    screens: 1
  Screen-1: 0 s-res: 3440x1440 s-dpi: 96
  Monitor-1: HDMI-A-1 mapped: HDMI-0 model: Dell U3415W res: 3440x1440
    dpi: 109 diag: 865mm (34.1")
  API: OpenGL v: 4.5 vendor: mesa v: 24.0.6 glx-v: 1.4 es-v: 3.1
    direct-render: yes renderer: AMD CAICOS (DRM 2.50.0 /
    5.2.17-200.fc30.x86_64 LLVM 18.1.1) device-ID: 1002:677b
  API: EGL Message: EGL data requires eglinfo. Check --recommends.
Audio:
  Device-1: Intel 6 Series/C200 Series Family High Definition Audio
    vendor: Holco Enterprise Co /Shuttle driver: snd_hda_intel v: kernel
    bus-ID: 00:1b.0 chip-ID: 8086:1c20
  Device-2: AMD Caicos HDMI Audio [Radeon HD 6450 / 7450/8450/8490 OEM R5
    230/235/235X OEM] vendor: Micro-Star MSI driver: snd_hda_intel v: kernel
    pcie: speed: 2.5 GT/s lanes: 16 bus-ID: 01:00.1 chip-ID: 1002:aa98
  API: ALSA v: k5.2.17-200.fc30.x86_64 status: kernel-api
  Server-1: PipeWire v: 1.0.5 status: active (process) with:
    1: pipewire-pulse status: active 2: wireplumber status: active
    3: pipewire-alsa type: plugin 4: pw-jack type: plugin
Network:
  Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
    vendor: Holco Enterprise Co /Shuttle driver: r8169 v: kernel pcie:
    speed: 2.5 GT/s lanes: 1 port: d000 bus-ID: 05:00.0 chip-ID: 10ec:8168
  IF: enp5s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
  IF-ID-1: virbr0 state: down mac: <filter>
RAID:
  Hardware-1: Intel SATA Controller [RAID mode] driver: ahci v: 3.0
    bus-ID: 00:1f.2 chip-ID: 8086:2822
  Device-1: md126 type: mdraid level: mirror status: active size: 3.64 TiB
  Info: report: 2/2 UU blocks: 3907015680 chunk-size: N/A
  Components: Online: 0: sdb 1: sda
  Device-2: md127 type: mdraid level: N/A status: inactive size: N/A
  Info: report: N/A blocks: 5808 chunk-size: N/A
  Components: Online: N/A Spare: 0: sda 1: sdb
Drives:
  Local Storage: total: raw: 7.29 TiB usable: -3891538608 used: 2.42 TiB
  ID-1: /dev/sda vendor: HGST (Hitachi) model: HDS724040ALE640
    size: 3.64 TiB speed: 6.0 Gb/s serial: <filter>
  ID-2: /dev/sdb vendor: HGST (Hitachi) model: HDS724040ALE640
    size: 3.64 TiB speed: 6.0 Gb/s serial: <filter>
Partition:
  ID-1: / size: 300 GiB used: 110.89 GiB (37.0%) fs: btrfs dev: /dev/dm-2
    mapped: fedora-root
  ID-2: /boot size: 975.9 MiB used: 255.9 MiB (26.2%) fs: ext4
    dev: /dev/md126p5
  ID-3: /home size: 1.23 TiB used: 1.2 TiB (98.2%) fs: btrfs dev: /dev/dm-3
    mapped: fedora-home
Swap:
  ID-1: swap-1 type: zram size: 8 GiB used: 0 KiB (0.0%) priority: 100
    dev: /dev/zram0
  ID-2: swap-2 type: partition size: 24 GiB used: 0 KiB (0.0%) priority: -2
    dev: /dev/dm-1 mapped: fedora-swap
Sensors:
  System Temperatures: cpu: 40.0 C mobo: N/A gpu: radeon temp: 40.0 C
  Fan Speeds (rpm): N/A
Info:
  Memory: total: 32 GiB available: 31.38 GiB used: 5.97 GiB (19.0%)
  Processes: 355 Power: uptime: 2d 5m Init: systemd v: 255
    target: graphical (5) default: graphical
  Packages: pm: flatpak pkgs: 12 Compilers: clang: 18.1.1 gcc: 14.0.1
    Shell: Bash v: 5.2.26 running-in: gnome-terminal inxi: 3.3.34

And I believe the partitions are large enough:

$ df -lH
Bestandssysteem         Grootte Gebruikt Besch Geb% Aangekoppeld op
devtmpfs                    17G        0   17G   0% /dev
tmpfs                       17G        0   17G   0% /dev/shm
tmpfs                       17G     2,4M   17G   1% /run
tmpfs                      4,2M        0  4,2M   0% /sys/fs/cgroup
/dev/mapper/fedora-root    323G     120G  201G  38% /
tmpfs                       17G     5,8M   17G   1% /tmp
/dev/md126p2               108G      20G   89G  18% /mnt/windows
/dev/md126p5               1,1G     269M  685M  29% /boot
/dev/mapper/fedora-home    1,4T     1,4T   22G  99% /home
tmpfs                      3,4G     4,0M  3,4G   1% /run/user/1000
/dev/sdc1                  2,3G     2,3G     0 100% /run/media/eelcapone/Fedora-WS-Live-40-1-14

Booting from USB to Fedora Live 40 also works fine.

5

I have to ask, is this an honest mistake ? You mentioned Fedora 39 > Fedora 40 but the kernels you are listing are from Fedora 30 and Fedora 31 respectively :thinking:

Hi hammerhead corvette, yes, the kernels are from Fedora 30 and 31. I’ve never noticed that the kernels were never updated, so apparently something went wrong years ago…

6

If you just recently updated, could you try to do a dnf distro-sync --best --allowerasing

7

I’ll give that a try. But I have updated for the last years every 1-2 weeks or so…

8

The reason to try this is so we can see if the kernel will update with a distro-sync command from dnf. Please try it and report back with feedback. If not we would need to try other things to see what is blocking the kernel from updating.

9

Please post the output of lsblk -f
That output from df -lh seems to indicate this machine is booting in legacy mode and may not have the required BIOS boot partition for doing so with the newer fedora versions. Lsblk would provide that info.

If that is the case then it would probably be best to do a new clean reinstall so the partitions are properly configured for the newer kernels (and maybe even switch over to UEFI booting)

10

This is not good:

  • when a filesystem is nearly full, rotating disks need to use a lot of head movement to put data in empty spaces. This increases the chances that an
    older disk will fail

  • linux filesystems can optimize disk layout to improve performance. When a disk is nearly full (90% is a common threshold), those optmizations no longer work, so disk access slows

Shuttle BIOS Download version 2.06 says: “Caution 1: This BIOS only for Motherboard V2.0” but you appear to have V1.0.