I upgraded with
dnf system-upgrade --releasever=36
dnf system-upgrade reboot
After running the upgrade I see (from running rpm -qa) that the system has a lot of fc36 packages installed. However, it’s still running an fc35 kernel, and gdm won’t start.
systemctl status gdm gives
● gdm.service - GNOME Display Manager
Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2022-05-16 17:19:24 EDT; 1min 22s ago
Main PID: 7216 (gdm)
Tasks: 3 (limit: 9411)
Memory: 2.1M
CPU: 155ms
CGroup: /system.slice/gdm.service
└─7216 /usr/sbin/gdm
May 16 17:19:27 picard gdm[7216]: Gdm: Child process -7343 was already dead.
May 16 17:19:27 picard gdm[7216]: Gdm: GdmDisplay: Session never registered, failing
May 16 17:19:27 picard gdm[7216]: Gdm: Child process -7343 was already dead.
May 16 17:19:28 picard gdm[7216]: Gdm: GdmDisplay: Session never registered, failing
May 16 17:19:28 picard gdm[7216]: Gdm: Child process -7380 was already dead.
May 16 17:19:28 picard gdm[7216]: Gdm: GdmDisplay: Session never registered, failing
May 16 17:19:28 picard gdm[7216]: Gdm: Child process -7380 was already dead.
May 16 17:19:29 picard gdm[7216]: Gdm: GdmDisplay: Session never registered, failing
May 16 17:19:29 picard gdm[7216]: Gdm: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors
May 16 17:19:29 picard gdm[7216]: Gdm: Child process -7417 was already dead.
Not sure how to look at X server logs nowadays. There are Xorg log files in /var/log but the newest is from about 8 years ago.
Also dnf is still using Fedora 35 repos:
~> sudo dnf upgrade --refresh
[sudo] password for jhaiduce:
Copr repo for nixnote2 owned by nunodias 11 kB/s | 3.3 kB 00:00
Copr repo for joplin owned by taw 26 kB/s | 3.6 kB 00:00
Adobe Systems Incorporated 12 kB/s | 2.9 kB 00:00
Docker CE Stable - x86_64 28 kB/s | 3.5 kB 00:00
Dropbox Repository 68 kB/s | 2.9 kB 00:00
Fedora 35 - x86_64 35 kB/s | 14 kB 00:00
Fedora 35 openh264 (From Cisco) - x86_64 6.3 kB/s | 989 B 00:00
Fedora Modular 35 - x86_64 64 kB/s | 13 kB 00:00
Fedora 35 - x86_64 - Updates 55 kB/s | 10 kB 00:00
Fedora Modular 35 - x86_64 - Updates 55 kB/s | 10 kB 00:00
google-earth 24 kB/s | 1.3 kB 00:00
google-earth-pro 32 kB/s | 1.3 kB 00:00
google-musicmanager 14 kB/s | 1.3 kB 00:00
RPM Fusion for Fedora 35 - Free 5.6 kB/s | 2.9 kB 00:00
RPM Fusion for Fedora 35 - Free - Updates 13 kB/s | 2.5 kB 00:00
RPM Fusion for Fedora 35 - Nonfree 16 kB/s | 2.9 kB 00:00
RPM Fusion for Fedora 35 - Nonfree - Updates 6.8 kB/s | 2.7 kB 00:00
skype (stable) 7.0 kB/s | 2.9 kB 00:00
teams 14 kB/s | 3.0 kB 00:00
Dependencies resolved.
===================================================================================================================================================================
Package Architecture Version Repository Size
===================================================================================================================================================================
Upgrading:
container-selinux noarch 2:2.183.0-3.fc35 updates 49 k
pcp x86_64 5.3.7-1.fc35 updates 1.3 M
pcp-conf x86_64 5.3.7-1.fc35 updates 28 k
pcp-libs x86_64 5.3.7-1.fc35 updates 600 k
pcp-selinux x86_64 5.3.7-1.fc35 updates 31 k
pcp-system-tools x86_64 5.3.7-1.fc35 updates 281 k
python3-pcp x86_64 5.3.7-1.fc35 updates 144 k
snap-confine x86_64 2.55.3-2.fc35 updates 2.6 M
snapd x86_64 2.55.3-2.fc35 updates 14 M
snapd-selinux noarch 2.55.3-2.fc35 updates 234 k
Transaction Summary
===================================================================================================================================================================
Upgrade 10 Packages
Total download size: 20 M
Is this ok [y/N]:
Looks like the root cause was disk space exhaustion in /var:
$ df -h /var
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/luks-9a92de1a-7be6-4d37-8bbd-5cca5b2a986c 22G 22G 0 100% /var
But still not sure how to clean up the mess…
I figured out why gdm wouldn’t start. I saw the following in the output from journalctl -ep err:
May 16 17:54:47 picard gdm-launch-environment][3954]: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
May 16 17:54:47 picard pkexec[4286]: gdm: The value for the SHELL variable was not found the /etc/shells file [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAN>
May 16 17:54:49 picard gnome-session-binary[4294]: GLib-GIO-ERROR: Settings schema 'org.gnome.desktop.session' is not installed
aborting...
So apparently org.gnome.desktop.session was missing? So I did a package search with dnf whatprovides:
~> dnf whatprovides \*org.gnome.desktop.session\*
Last metadata expiration check: 38 days, 22:29:01 ago on Thu 07 Apr 2022 07:28:33 PM EDT.
gsettings-desktop-schemas-41.0-1.fc35.i686 : A collection of GSettings schemas
Repo : fedora
Matched from:
Other : *org.gnome.desktop.session*
gsettings-desktop-schemas-41.0-1.fc35.x86_64 : A collection of GSettings schemas
Repo : @System
Matched from:
Other : *org.gnome.desktop.session*
gsettings-desktop-schemas-41.0-1.fc35.x86_64 : A collection of GSettings schemas
Repo : fedora
Matched from:
Other : *org.gnome.desktop.session*
gsettings-desktop-schemas-42.0-1.fc36.x86_64 : A collection of GSettings schemas
Repo : @System
Matched from:
Other : *org.gnome.desktop.session*
Apparently dnf never removed the old version of gsettings-desktop-schemas as part of the upgrade. After uninstalling the old copy of gsettings-desktop-schemas with dnf remove gsettings-desktop-schemas-41.0-1.fc35 and then re-launching gdm with systemctl restart gdm, I now have a gdm login screen.
I tried manually updating the kernel menu but no luck:
~> sudo kernel-install add 5.17.6-300.fc36.x86_64 /lib/modules/5.17.6-300.fc36.x86_64/vmlinuz
[sudo] password for jhaiduce:
dkms: running auto installation service for kernel 5.17.6-300.fc36.x86_64
Error! Could not locate dkms.conf file.
File: /var/lib/dkms/mba6x_bl/20150428.f1482dd/source/dkms.conf does not exist.
Done.
kdump: kernel 5.17.6-300.fc36.x86_64 doesn't exist
If you still have fc35 packages, this usually indicates that the upgrade did not complete (probably because of you running out of space in /var).
I think the first thing here would be to clean out /var because that’s where dnf keeps the rpms to perform the upgrade, and then attempt to bring your system into a consistent state using distro-sync:
sudo dnf --releasever=36 distro-sync
The probably easiest way of cleaning up /var is removing older journal files:
journalctl --vacuum-time=2d
or
journalctl --vacuum-size=200M
Cleaning the dnf cache etc. should also save some space—you can go into /var to see what’s using it and remove things accordingly.
Edit:
removed bits that @augenauf noted in their comment already 
Is there some way to predict how much space I need in /var in advance of the upgrade? I had somewhere between 4 and 6 GB free before upgrading, seems like that should be plenty.
That’s hard to say. This is currently being discussed here on the -devel list where someone else ran into the same issue as you:
The thread noted here seems to indicate that you need at least twice the installed size of the package for each rpm:
So if my download for ~3500 packages was 4.2G, I need 4.2G *2 + some more for the complete transaction (because the 4.2G is compressed rpms, so the “installed” size would be larger).
So if my download for ~3500 packages was 4.2G, I need 4.2G *2 + some more for the complete transaction
Thanks, that rule of thumb sounds useful. Though in my case /var is a separate partition from /usr, so for most packages a majority of the “installed” size goes to /usr (which didn’t fill up). But obviously there’s a lot more going on in /var than simply storing the downloaded rpms. So adding up the installed sizes would probably be an overestimate. But I’ve exhausted /var in the last three upgrades on this machine, so anything to avoid that would help.
I guess the thing to do would be to remove some of the larger packages, do the upgrade, and then re-install them?
I note that your system is partially upgraded, so I’m not sure if a full upgrade is required again. Does the distro-sync command do anything?
I’ve done that before in previous upgrades, but the trigger was that dnf system-upgrade download produced transaction check errors due to insufficient disk space (usually on /usr). But on the last 3 upgrades the transaction check succeeded. So in the future I’ll have to start manually checking free space on /var after running dnf system-upgrade.
Does the
distro-synccommand do anything?
It didn’t, but by the time I tried that I had already cleaned things up by other means (mainly dnf remove --duplicates, and removing duplicates of a few protected packages with rpm -e).
In the future you should follow the published procedure at DNF System Upgrade.
I started with the procedure published there, but because of the partial upgrade dnf distro-sync tried to sync with F35 instead of F36. That’s why I had to manually remove some of the F35 packages. Maybe dnf distro-sync --releasever=36 would have worked, but that usage is not mentioned in the documentation at DNF System Upgrade.