Fedora Upgrade: F40 -> F41
Prior to upgrade while still on Fedora 40, some trepidation regarding kernel updates and a seeming XFS bug:
# working
6.9.7-200.fc40.x86_64
# broken
6.10.6-200.fc40.x86_64
XFS (dm-2): Metadata corruption detected at xfs_dinode_verify.part.0+0x1a3/0xa90 [xfs], inode 0x81 dinode
XFS (dm-2): Unmount and run xfs_repair
XFS (dm-2): First 128 bytes of corrupted metadata buffer:
# working
6.13.7-100.fc40.x86_64Kernel in the clear, go for broke:
dnf system-upgrade download --releasever=41
dnf system-upgrade reboot>>> Running post-transaction scriptlet: kernel-core-0:6.13.8-200.fc41.x86_64 >>> Finished post-transaction scriptlet: kernel-core-0:6.13.8-200.fc41.x86_64 >>> Scriptlet output: >>> WARNING: PV /dev/sda2 in VG fedora is using an old PV header, modify the VG to update. >>> WARNING: PV /dev/sda2 in VG fedora is using an old PV header, modify the VG to update. >>> >>> Running trigger-install scriptlet: systemd-0:256.12-1.fc41.x86_64 >>> Finished trigger-install scriptlet: systemd-0:256.12-1.fc41.x86_64 >>> Scriptlet output: >>> Failed to connect to user scope bus via machine transport: No medium found >>> Failed to connect to user scope bus via machine transport: No medium found >>> >>> Running trigger-post-uninstall scriptlet: systemd-0:256.12-1.fc41.x86_64 >>> Finished trigger-post-uninstall scriptlet: systemd-0:256.12-1.fc41.x86_64 >>> Scriptlet output: >>> Failed to connect to user scope bus via machine transport: No medium found >>> >>> Running trigger-post-uninstall scriptlet: systemd-0:256.12-1.fc41.x86_64 >>> Finished trigger-post-uninstall scriptlet: systemd-0:256.12-1.fc41.x86_64 >>> Scriptlet output: >>> Failed to connect to user scope bus via machine transport: No medium found >>> Complete!
See https://access.redhat.com/solutions/5906681.Sigh. Not my first run-in with metadata changes in lvm hitting old or ancient volumes.
pvck --dump headers /dev/sda2 | grep pv_header_extension.version
pv_header_extension.version 1
vgck --updatemetadata fedora
pvck --dump headers /dev/sda2 | grep pv_header_extension.version
pv_header_extension.version 2On a last note, with the change from NetworkManager-1.46.6-1.fc40.x86_64 to NetworkManager-1.50.3-1.fc41.x86_64, static IP assignments no longer work the old-fashioned way out of /etc/sysconfig/network-scripts/ifcfig-xxx. See https://fedoramagazine.org/converting-networkmanager-from-ifcfg-to-keyfiles/ (also https://blogs.gnome.org/thaller/2021/02/02/initscripts-ifcfg-rh-format-in-networkmanager-and-its-future/ and https://www.reddit.com/r/Fedora/comments/11z0wwy/anyone_knows_where_fedora_keeps_the_net_interfaces/).
They mean business:
# yum install network-scripts
No match for argument: network-scriptsResorting to other old ways:
ifconfig eno1 inet 192.168.1.13 netmask 255.255.255.0
route add default gw 192.168.1.1Time to figure out why my eno1 was not migrated to the standard keyfile location:
# ls -la /etc/NetworkManager/system-connections/ total 16 drwxr-xr-x. 2 root root 78 Feb 26 19:00 . drwxr-xr-x. 7 root root 4096 Apr 9 16:22 .. -rw------- 1 root root 186 Dec 10 2023 eno2.nmconnection -rw------- 1 root root 186 Dec 10 2023 eno3.nmconnection -rw------- 1 root root 186 Dec 10 2023 eno4.nmconnection# nmcli con show NAME UUID TYPE DEVICE Wired connection 1 95932bca-5a29-3696-b511-f34ed772531d ethernet eno1 lo 06e9fdf7-05a6-4aba-af44-c38df283c8ee loopback lo eno2 3254bab1-b7ba-4ecd-9d34-b2cf4dbd35db ethernet -- eno3 89f57eeb-92fd-4dc9-83d3-98cf21bcc09a ethernet -- eno4 354c45a2-ca61-404a-ba62-b2c52b75f5de ethernet -- Wired connection 2 1e8fb4aa-bb7e-343f-a419-f94c05914ad7 ethernet -- Wired connection 3 d033c2dd-b9e8-3ccb-9707-4dd0100deaee ethernet -- Wired connection 4 727b83f1-b664-3ee3-b60a-6fc91e57a37d ethernet --# nmcli -f TYPE,FILENAME,NAME conn TYPE FILENAME NAME ethernet /run/NetworkManager/system-connections/Wired connection 1.nmconnection Wired connection 1 loopback /run/NetworkManager/system-connections/lo.nmconnection lo ethernet /etc/NetworkManager/system-connections/eno2.nmconnection eno2 ethernet /etc/NetworkManager/system-connections/eno3.nmconnection eno3 ethernet /etc/NetworkManager/system-connections/eno4.nmconnection eno4 ethernet /run/NetworkManager/system-connections/Wired connection 2.nmconnection Wired connection 2 ethernet /run/NetworkManager/system-connections/Wired connection 3.nmconnection Wired connection 3 ethernet /run/NetworkManager/system-connections/Wired connection 4.nmconnection Wired connection 4Referring to another source with more details, https://opensource.com/article/22/8/migrate-networkmanager-keyfiles-configuration), attempts at migration within the tooling do not initially work:
# nmcli connection migrate eno1 Error: unknown connection 'eno1'. Error: cannot migrate unknown connection(s): 'eno1'.
# nmcli connection migrate 95932bca-5a29-3696-b511-f34ed772531d
Connection 'Wired connection 1' (95932bca-5a29-3696-b511-f34ed772531d) successfully migrated.
# ls /etc/NetworkManager/system-connections/ eno2.nmconnection eno3.nmconnection eno4.nmconnectionA quick look at config:
# NetworkManager --print-config # NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf (lib: 22-wifi-mac-addr.conf) [main] # plugins= # rc-manager=auto # migrate-ifcfg-rh=false # auth-polkit=true # dhcp=internal # iwd-config-path= configure-and-quit=no [logging] # backend=journal # audit=false [device] # wifi.backend=wpa_supplicant [connection.22-wifi-mac-addr] match-device=type:wifi wifi.cloned-mac-address=stable-ssid # no-auto-default file "/var/lib/NetworkManager/no-auto-default.state"
Changing migrate-ifcfg-rh to true, and a restart, and I now have a defined connection:
# cat eno1.nmconnection [connection] id=eno1 uuid=88bc8a5d-09a8-4a7f-829b-2e5bc8c3bc23 type=ethernet interface-name=eno1 [ethernet] [ipv4] address1=192.168.1.13/24,192.168.1.1 method=auto [ipv6] addr-gen-mode=default method=auto [proxy]Finally.
Leave a comment