Hi,
After updates (I'll attach them below) today, when I rebooted, my desktop comes up with a black only background. That isn't terrible, but I have been using wallpapoz, and now it does nothing. I can bring it up, and tell it to restart, but nothing happens.
The worse thing is that tab completion no longer works. That's such a keystroke saver for things I do often, it is like having my fingers cut off.
There weren't a lot of updates (comparatively speaking), and I don't see anything that would have caused this. Maybe glib2 for the wallpapoz? But what for the tab completion. I'll keep investigating, this is just a heads up for anyone else who is running F37.
2022-08-28T06:27:53-0700 SUBDEBUG Upgrade: glib2-2.73.3-2.fc37.x86_64 2022-08-28T06:27:56-0700 SUBDEBUG Upgrade: openblas-0.3.21-3.fc37.x86_64 2022-08-28T06:27:56-0700 SUBDEBUG Upgrade: libsss_idmap-2.7.4-1.fc37.x86_64 2022-08-28T06:27:57-0700 SUBDEBUG Upgrade: libsss_certmap-2.7.4-1.fc37.x86_64 2022-08-28T06:27:57-0700 SUBDEBUG Upgrade: plasma-workspace-common-5.25.4-2.fc37.x86_64 2022-08-28T06:27:57-0700 SUBDEBUG Upgrade: libkworkspace5-5.25.4-2.fc37.x86_64 2022-08-28T06:27:58-0700 SUBDEBUG Upgrade: plasma-workspace-libs-5.25.4-2.fc37.x86_64 2022-08-28T06:28:01-0700 SUBDEBUG Installed: zbar-libs-0.23.90-5.fc37.x86_64 2022-08-28T06:28:01-0700 SUBDEBUG Upgrade: python3-sssdconfig-2.7.4-1.fc37.noarch 2022-08-28T06:28:01-0700 SUBDEBUG Upgrade: libipa_hbac-2.7.4-1.fc37.x86_64 2022-08-28T06:28:01-0700 SUBDEBUG Upgrade: abseil-cpp-20220623.0-1.fc37.x86_64 2022-08-28T06:28:06-0700 SUBDEBUG Upgrade: mozc-2.28.4730.102-3.fc37.x86_64 2022-08-28T06:28:07-0700 SUBDEBUG Upgrade: zbar-devel-0.23.90-5.fc37.x86_64 2022-08-28T06:28:07-0700 SUBDEBUG Upgrade: zbar-gtk-0.23.90-5.fc37.x86_64 2022-08-28T06:28:07-0700 SUBDEBUG Upgrade: plasma-workspace-geolocation-5.25.4-2.fc37.x86_64 2022-08-28T06:28:07-0700 SUBDEBUG Upgrade: plasma-workspace-geolocation-libs-5.25.4-2.fc37.x86_64 2022-08-28T06:28:08-0700 SUBDEBUG Upgrade: plasma-lookandfeel-fedora-5.25.4-2.fc37.noarch 2022-08-28T06:28:08-0700 SUBDEBUG Upgrade: plasma-workspace-wayland-5.25.4-2.fc37.x86_64 2022-08-28T06:28:08-0700 SUBDEBUG Upgrade: plasma-workspace-5.25.4-2.fc37.x86_64 2022-08-28T06:28:48-0700 SUBDEBUG Upgrade: plasma-workspace-x11-5.25.4-2.fc37.x86_64 2022-08-28T06:28:48-0700 SUBDEBUG Upgrade: openblas-openmp-0.3.21-3.fc37.x86_64 2022-08-28T06:28:49-0700 SUBDEBUG Upgrade: openblas-openmp64-0.3.21-3.fc37.x86_64 2022-08-28T06:28:50-0700 SUBDEBUG Upgrade: openblas-openmp64_-0.3.21-3.fc37.x86_64 2022-08-28T06:28:51-0700 SUBDEBUG Upgrade: openblas-serial-0.3.21-3.fc37.x86_64 2022-08-28T06:28:53-0700 SUBDEBUG Upgrade: openblas-serial64-0.3.21-3.fc37.x86_64 2022-08-28T06:28:54-0700 SUBDEBUG Upgrade: openblas-serial64_-0.3.21-3.fc37.x86_64 2022-08-28T06:28:55-0700 SUBDEBUG Upgrade: openblas-threads-0.3.21-3.fc37.x86_64 2022-08-28T06:28:56-0700 SUBDEBUG Upgrade: openblas-threads64-0.3.21-3.fc37.x86_64 2022-08-28T06:28:57-0700 SUBDEBUG Upgrade: openblas-threads64_-0.3.21-3.fc37.x86_64 2022-08-28T06:28:58-0700 SUBDEBUG Upgrade: NetworkManager-libnm-1:1.40.0-1.fc37.x86_64 2022-08-28T06:28:59-0700 SUBDEBUG Upgrade: NetworkManager-1:1.40.0-1.fc37.x86_64 2022-08-28T06:29:01-0700 SUBDEBUG Upgrade: NetworkManager-wwan-1:1.40.0-1.fc37.x86_64 2022-08-28T06:29:01-0700 SUBDEBUG Upgrade: glib2-devel-2.73.3-2.fc37.x86_64 2022-08-28T06:29:03-0700 SUBDEBUG Upgrade: amule-nogui-2.3.3-8.fc37.x86_64 2022-08-28T06:29:04-0700 SUBDEBUG Upgrade: sssd-nfs-idmap-2.7.4-1.fc37.x86_64 2022-08-28T06:29:04-0700 SUBDEBUG Upgrade: rss2email-3.14-1.fc37.noarch 2022-08-28T06:29:04-0700 SUBDEBUG Upgrade: python3-pungi-4.3.6-1.fc37.noarch 2022-08-28T06:29:05-0700 SUBDEBUG Upgrade: libtar-1.2.20-25.fc37.x86_64 2022-08-28T06:29:06-0700 SUBDEBUG Upgrade: libsss_sudo-2.7.4-1.fc37.x86_64 2022-08-28T06:29:06-0700 SUBDEBUG Upgrade: libsss_nss_idmap-2.7.4-1.fc37.x86_64 2022-08-28T06:29:06-0700 SUBDEBUG Upgrade: sssd-client-2.7.4-1.fc37.x86_64 2022-08-28T06:29:06-0700 SUBDEBUG Upgrade: libsss_autofs-2.7.4-1.fc37.x86_64 2022-08-28T06:29:06-0700 SUBDEBUG Upgrade: sssd-common-2.7.4-1.fc37.x86_64 2022-08-28T06:29:08-0700 SUBDEBUG Upgrade: sssd-krb5-common-2.7.4-1.fc37.x86_64 2022-08-28T06:29:08-0700 SUBDEBUG Upgrade: sssd-dbus-2.7.4-1.fc37.x86_64 2022-08-28T06:29:09-0700 SUBDEBUG Upgrade: sssd-common-pac-2.7.4-1.fc37.x86_64 2022-08-28T06:29:09-0700 SUBDEBUG Upgrade: sssd-ad-2.7.4-1.fc37.x86_64 2022-08-28T06:29:09-0700 SUBDEBUG Upgrade: sssd-ipa-2.7.4-1.fc37.x86_64 2022-08-28T06:29:09-0700 SUBDEBUG Upgrade: sssd-krb5-2.7.4-1.fc37.x86_64 2022-08-28T06:29:09-0700 SUBDEBUG Upgrade: sssd-ldap-2.7.4-1.fc37.x86_64 2022-08-28T06:29:09-0700 SUBDEBUG Upgrade: python3-sss-2.7.4-1.fc37.x86_64 2022-08-28T06:29:10-0700 SUBDEBUG Upgrade: sssd-proxy-2.7.4-1.fc37.x86_64 2022-08-28T06:29:10-0700 SUBDEBUG Upgrade: knot-libs-3.2.0-1.fc37.x86_64 2022-08-28T06:29:10-0700 SUBDEBUG Installed: kseexpr-4.0.4.0-1.fc37.x86_64 2022-08-28T06:29:10-0700 SUBDEBUG Upgrade: krita-libs-5.1.0-1.fc37.x86_64 2022-08-28T06:29:11-0700 SUBDEBUG Upgrade: krita-5.1.0-1.fc37.x86_64 2022-08-28T06:29:21-0700 SUBDEBUG Upgrade: knot-resolver-5.5.2-1.fc37.x86_64 2022-08-28T06:29:23-0700 SUBDEBUG Upgrade: sssd-2.7.4-1.fc37.x86_64 2022-08-28T06:29:23-0700 SUBDEBUG Upgrade: sssd-tools-2.7.4-1.fc37.x86_64 2022-08-28T06:29:23-0700 INFO --- logging initialized --- 2022-08-28T06:29:23-0700 SUBDEBUG Upgrade: libsss_simpleifp-2.7.4-1.fc37.x86_64 2022-08-28T06:29:23-0700 SUBDEBUG Upgrade: sssd-idp-2.7.4-1.fc37.x86_64 2022-08-28T06:29:23-0700 SUBDEBUG Upgrade: sssd-kcm-2.7.4-1.fc37.x86_64 2022-08-28T06:29:24-0700 SUBDEBUG Upgrade: libtar-devel-1.2.20-25.fc37.x86_64 2022-08-28T06:29:24-0700 SUBDEBUG Upgrade: pungi-4.3.6-1.fc37.noarch 2022-08-28T06:29:25-0700 SUBDEBUG Upgrade: rss2email-zsh-completion-3.14-1.fc37.noarch 2022-08-28T06:29:25-0700 SUBDEBUG Upgrade: amule-2.3.3-8.fc37.x86_64 2022-08-28T06:29:26-0700 SUBDEBUG Upgrade: zbar-gtk-devel-0.23.90-5.fc37.x86_64 2022-08-28T06:29:27-0700 SUBDEBUG Upgrade: NetworkManager-bluetooth-1:1.40.0-1.fc37.x86_64 2022-08-28T06:29:27-0700 SUBDEBUG Upgrade: NetworkManager-adsl-1:1.40.0-1.fc37.x86_64 2022-08-28T06:29:27-0700 SUBDEBUG Upgrade: NetworkManager-initscripts-ifcfg-rh-1:1.40.0-1.fc37.x86_64 2022-08-28T06:29:27-0700 SUBDEBUG Upgrade: NetworkManager-initscripts-updown-1:1.40.0-1.fc37.noarch 2022-08-28T06:29:27-0700 SUBDEBUG Upgrade: NetworkManager-ovs-1:1.40.0-1.fc37.x86_64 2022-08-28T06:29:27-0700 SUBDEBUG Upgrade: NetworkManager-ppp-1:1.40.0-1.fc37.x86_64 2022-08-28T06:29:27-0700 SUBDEBUG Upgrade: NetworkManager-team-1:1.40.0-1.fc37.x86_64 2022-08-28T06:29:27-0700 SUBDEBUG Upgrade: NetworkManager-wifi-1:1.40.0-1.fc37.x86_64 2022-08-28T06:29:27-0700 SUBDEBUG Upgrade: openblas-devel-0.3.21-3.fc37.x86_64 2022-08-28T06:29:28-0700 SUBDEBUG Upgrade: sddm-breeze-5.25.4-2.fc37.noarch 2022-08-28T06:29:28-0700 SUBDEBUG Upgrade: ibus-mozc-2.28.4730.102-3.fc37.x86_64 2022-08-28T06:29:28-0700 SUBDEBUG Upgrade: python3-libipa_hbac-2.7.4-1.fc37.x86_64 2022-08-28T06:29:28-0700 SUBDEBUG Upgrade: zbar-0.23.90-5.fc37.x86_64 2022-08-28T06:29:41-0700 SUBDEBUG Upgrade: apvlv-0.4.0-1.fc37.x86_64 2022-08-28T06:29:43-0700 SUBDEBUG Upgrade: glib2-doc-2.73.3-2.fc37.noarch 2022-08-28T06:29:52-0700 SUBDEBUG Upgrade: gpicview-0.2.5-16.fc37.x86_64 2022-08-28T06:29:53-0700 SUBDEBUG Upgrade: tig-2.5.7-1.fc37.x86_64 2022-08-28T06:29:53-0700 SUBDEBUG Upgrade: tcpreplay-4.4.2-1.fc37.x86_64 2022-08-28T06:29:54-0700 SUBDEBUG Upgrade: python3-sss-murmur-2.7.4-1.fc37.x86_64 2022-08-28T06:29:54-0700 SUBDEBUG Upgrade: python3-scikit-learn-1.1.2-1.fc37.x86_64 2022-08-28T06:30:04-0700 SUBDEBUG Upgrade: python3-ecdsa-0.18.0-1.fc37.noarch 2022-08-28T06:30:05-0700 SUBDEBUG Upgrade: perl-Sub-HandlesVia-0.036-1.fc37.noarch 2022-08-28T06:30:05-0700 SUBDEBUG Upgrade: osinfo-db-20220727-2.fc37.noarch 2022-08-28T06:30:08-0700 SUBDEBUG Upgrade: neovim-0.7.2-3.fc37.x86_64 2022-08-28T06:30:13-0700 SUBDEBUG Upgrade: ilbc-3.0.4-3.fc37.x86_64 2022-08-28T06:30:13-0700 SUBDEBUG Upgrade: grpc-data-1.48.0-2.fc37.noarch 2022-08-28T06:30:13-0700 SUBDEBUG Upgrade: NetworkManager-config-connectivity-fedora-1:1.40.0-1.fc37.noarch
On Sun, 28 Aug 2022 11:04:03 -0700 stan via test test@lists.fedoraproject.org wrote:
After updates (I'll attach them below) today, when I rebooted, my desktop comes up with a black only background. That isn't terrible, but I have been using wallpapoz, and now it does nothing. I can bring it up, and tell it to restart, but nothing happens.
The worse thing is that tab completion no longer works. That's such a keystroke saver for things I do often, it is like having my fingers cut off.
Update: One of the problems is probably due to the fact that the system no longer mounts any partition in fstab except the root partition of the fedora I am running. My wallpapoz gets its wallpaper photographs from a directory on a data partition. It also fails on the swap partition.
Aug 28 17:16:27 fedora systemd[1]: Failed to mount mnt-to_archive.mount - /mnt/to_archive. Aug 28 17:16:27 fedora systemd[1]: mnt-to_archive.mount: Failed with result 'exit-code'. Aug 28 17:16:27 fedora systemd[1]: mnt-to_archive.mount: Mount process exited, code=exited, status=32/n/a
Aug 28 17:16:16 fedora systemd[1]: Failed to activate swap uuid\x3da4377658\x2d7454\x2d45ed\x2daaf2\x2d355f80cc9e9a.swap - /uuid=a4377658-7454-45ed-aaf2-355f80cc9e9a. Aug 28 17:16:16 fedora systemd[1]: uuid\x3da4377658\x2d7454\x2d45ed\x2daaf2\x2d355f80cc9e9a.swap: Failed with result 'exit-code'. Aug 28 17:16:16 fedora systemd[1]: uuid\x3da4377658\x2d7454\x2d45ed\x2daaf2\x2d355f80cc9e9a.swap: Swap process exited, code=exited, status=255/EXCEPTION
And a little later, Aug 28 17:16:16 fedora swapon[510]: swapon: cannot open /uuid=a4377658-7454-45ed-aaf2-355f80cc9e9a: No such file or directory
blkid can find all the missing partitions, and they have the right uuid, the same as in /etc/fstab.
On Sun, 28 Aug 2022 18:11:13 -0700 stan via test test@lists.fedoraproject.org wrote:
Update: One of the problems is probably due to the fact that the system no longer mounts any partition in fstab except the root partition of the fedora I am running. My wallpapoz gets its wallpaper photographs from a directory on a data partition. It also fails on the swap partition.
Aug 28 17:16:27 fedora systemd[1]: Failed to mount mnt-to_archive.mount - /mnt/to_archive. Aug 28 17:16:27 fedora systemd[1]: mnt-to_archive.mount: Failed with result 'exit-code'. Aug 28 17:16:27 fedora systemd[1]: mnt-to_archive.mount: Mount process exited, code=exited, status=32/n/a
Aug 28 17:16:16 fedora systemd[1]: Failed to activate swap uuid\x3da4377658\x2d7454\x2d45ed\x2daaf2\x2d355f80cc9e9a.swap - /uuid=a4377658-7454-45ed-aaf2-355f80cc9e9a. Aug 28 17:16:16 fedora systemd[1]: uuid\x3da4377658\x2d7454\x2d45ed\x2daaf2\x2d355f80cc9e9a.swap: Failed with result 'exit-code'. Aug 28 17:16:16 fedora systemd[1]: uuid\x3da4377658\x2d7454\x2d45ed\x2daaf2\x2d355f80cc9e9a.swap: Swap process exited, code=exited, status=255/EXCEPTION
And a little later, Aug 28 17:16:16 fedora swapon[510]: swapon: cannot open /uuid=a4377658-7454-45ed-aaf2-355f80cc9e9a: No such file or directory
blkid can find all the missing partitions, and they have the right uuid, the same as in /etc/fstab.
Booted an older Fedora, and it had no problems mounting all the drives and swap. So, not the drives.
Booted F37 with older kernels that worked just fine before these updates, now have the mount problem. So, the update changed something in the boot process. It wasn't mount that changed, because that wasn't updated (the util-linux-core package hasn't changed since Aug 5). I look at that list of packages, and I don't see anything in there that should affect boot. systemd is the same, and that is what handles the mounting of swap and drives. The same systemd worked fine before a reboot after the updates, and still boots the system, just doesn't mount anything but the root partition.
On Sun, 2022-08-28 at 18:34 -0700, stan via test wrote:
On Sun, 28 Aug 2022 18:11:13 -0700 stan via test test@lists.fedoraproject.org wrote:
Update: One of the problems is probably due to the fact that the system no longer mounts any partition in fstab except the root partition of the fedora I am running. My wallpapoz gets its wallpaper photographs from a directory on a data partition. It also fails on the swap partition.
Aug 28 17:16:27 fedora systemd[1]: Failed to mount mnt-to_archive.mount - /mnt/to_archive. Aug 28 17:16:27 fedora systemd[1]: mnt-to_archive.mount: Failed with result 'exit-code'. Aug 28 17:16:27 fedora systemd[1]: mnt-to_archive.mount: Mount process exited, code=exited, status=32/n/a
Aug 28 17:16:16 fedora systemd[1]: Failed to activate swap uuid\x3da4377658\x2d7454\x2d45ed\x2daaf2\x2d355f80cc9e9a.swap - /uuid=a4377658-7454-45ed-aaf2-355f80cc9e9a. Aug 28 17:16:16 fedora systemd[1]: uuid\x3da4377658\x2d7454\x2d45ed\x2daaf2\x2d355f80cc9e9a.swap: Failed with result 'exit-code'. Aug 28 17:16:16 fedora systemd[1]: uuid\x3da4377658\x2d7454\x2d45ed\x2daaf2\x2d355f80cc9e9a.swap: Swap process exited, code=exited, status=255/EXCEPTION
And a little later, Aug 28 17:16:16 fedora swapon[510]: swapon: cannot open /uuid=a4377658-7454-45ed-aaf2-355f80cc9e9a: No such file or directory
blkid can find all the missing partitions, and they have the right uuid, the same as in /etc/fstab.
Booted an older Fedora, and it had no problems mounting all the drives and swap. So, not the drives.
Booted F37 with older kernels that worked just fine before these updates, now have the mount problem. So, the update changed something in the boot process. It wasn't mount that changed, because that wasn't updated (the util-linux-core package hasn't changed since Aug 5). I look at that list of packages, and I don't see anything in there that should affect boot. systemd is the same, and that is what handles the mounting of swap and drives. The same systemd worked fine before a reboot after the updates, and still boots the system, just doesn't mount anything but the root partition.
systemd doesn't exactly *do* the mounting, it just...farms it out.
Those errors look almost like it's literally trying to mount the device `/uuid=a4377658-7454-45ed-aaf2-355f80cc9e9a` , which obviously isn't going to work...
Can you show your /etc/fstab or the systemd mount units (whichever you're using) for these mounts? Can you mount the devices manually with e.g. mount /dev/real/path/to/target /mnt/to_archive or whatever?
On Sun, 28 Aug 2022 22:44:46 -0700 Adam Williamson adamwill@fedoraproject.org wrote:
systemd doesn't exactly *do* the mounting, it just...farms it out.
Those errors look almost like it's literally trying to mount the device `/uuid=a4377658-7454-45ed-aaf2-355f80cc9e9a` , which obviously isn't going to work...
uuid=f9cf797e-5e90-4fa0-921a-33fac09c1960 /mnt/to_archive ext4 defaults,nofail 0 0
Can you show your /etc/fstab or the systemd mount units (whichever you're using) for these mounts? Can you mount the devices manually with e.g. mount /dev/real/path/to/target /mnt/to_archive or whatever?
mount /dev/sda6 mtn/to_archive works.
But, I haven't changed the layout of the fstab, and it worked prior to this. Could this failure have to do with the failure in the dracut services (documented in another mail) during startup?
On Mon, 29 Aug 2022 06:36:38 -0700 stan via test test@lists.fedoraproject.org wrote:
On Sun, 28 Aug 2022 22:44:46 -0700 Adam Williamson adamwill@fedoraproject.org wrote:
systemd doesn't exactly *do* the mounting, it just...farms it out.
Those errors look almost like it's literally trying to mount the device `/uuid=a4377658-7454-45ed-aaf2-355f80cc9e9a` , which obviously isn't going to work...
uuid=f9cf797e-5e90-4fa0-921a-33fac09c1960 /mnt/to_archive ext4 defaults,nofail 0 0
Can you show your /etc/fstab or the systemd mount units (whichever you're using) for these mounts? Can you mount the devices manually with e.g. mount /dev/real/path/to/target /mnt/to_archive or whatever?
mount /dev/sda6 mtn/to_archive works.
But, I haven't changed the layout of the fstab, and it worked prior to this. Could this failure have to do with the failure in the dracut services (documented in another mail) during startup?
You put me on the right path. After the direct device mount worked, I tried mounting using the UUID, and it failed when I used the line from the fstab. It turns out that UUID is case sensitive. I'm not sure if that is a new thing, or if I changed them all to lower case in the fstab somehow. But, after I changed them all to upper case in the fstab, everything started working again.
Thanks!
On Mon, 29 Aug 2022 07:23:56 -0700 stan via test test@lists.fedoraproject.org wrote:
You put me on the right path. After the direct device mount worked, I tried mounting using the UUID, and it failed when I used the line from the fstab. It turns out that UUID is case sensitive. I'm not sure if that is a new thing, or if I changed them all to lower case in the fstab somehow. But, after I changed them all to upper case in the fstab, everything started working again.
Thinking about this, I had to have caused the problem. I was adding a new drive to the fstab for backups, and I think I used the command in vim that converts a name to lower or upper case during that. I don't use it often, and I must have somehow made it act upon the whole file instead of just the selected text. How did I not notice that all the upper case changed to lower case? Operator error. :-)
There isn't enough information available to understand the problem. Please provide the complete /etc/fstab, blkid, and journalctl -b for a failing boot while booting with parameters:
systemd.log_level=debug rd.debug udev.log-priority=debug
That will sufficiently slow down the boot that if the problem is related to a race condition, the problem may not happen. If that's the case you'll have to do separate boots with one of the above parameters at a time to see which debug method exposes the cause.
-- Chris Murphy
On Sun, 28 Aug 2022 18:34:56 -0700 stan via test test@lists.fedoraproject.org wrote:
Booted an older Fedora, and it had no problems mounting all the drives and swap. So, not the drives.
Booted F37 with older kernels that worked just fine before these updates, now have the mount problem. So, the update changed something in the boot process. It wasn't mount that changed, because that wasn't updated (the util-linux-core package hasn't changed since Aug 5). I look at that list of packages, and I don't see anything in there that should affect boot. systemd is the same, and that is what handles the mounting of swap and drives. The same systemd worked fine before a reboot after the updates, and still boots the system, just doesn't mount anything but the root partition.
It looks like dracut is failing the pre-trigger, pre-mount, and mount activities during boot. I checked, and none of the dracut files have been modified.
~ 06:05 AM root 6 # systemctl status dracut-pre-udev.service ○ dracut-pre-udev.service - dracut pre-udev hook Loaded: loaded (/usr/lib/systemd/system/dracut-pre-udev.service; static) Active: inactive (dead) since Mon 2022-08-29 05:36:36 MST; 28min ago Duration: 1.971s Docs: man:dracut-pre-udev.service(8) man:dracut.bootup(7) Main PID: 303 (code=exited, status=0/SUCCESS) CPU: 17ms
Aug 29 05:36:36 fedora systemd[1]: dracut-pre-udev.service: Deactivated successfully. Aug 29 05:36:36 fedora systemd[1]: Stopped dracut-pre-udev.service - dracut pre-udev hook. ~ 06:05 AM root 6 # systemctl status dracut-pre-trigger.service ○ dracut-pre-trigger.service - dracut pre-trigger hook Loaded: loaded (/usr/lib/systemd/system/dracut-pre-trigger.service; static) Active: inactive (dead) Condition: start condition failed at Mon 2022-08-29 05:36:35 MST; 28min ago Docs: man:dracut-pre-trigger.service(8) man:dracut.bootup(7)
Aug 29 05:36:35 fedora systemd[1]: dracut-pre-trigger.service - dracut pre-trigger hook was skipped because all trigger condition checks failed. ~ 06:05 AM root 6 # systemctl status dracut-pre-mount.service ○ dracut-pre-mount.service - dracut pre-mount hook Loaded: loaded (/usr/lib/systemd/system/dracut-pre-mount.service; static) Active: inactive (dead) Condition: start condition failed at Mon 2022-08-29 05:36:35 MST; 28min ago Docs: man:dracut-pre-mount.service(8) man:dracut.bootup(7)
Aug 29 05:36:35 fedora systemd[1]: dracut-pre-mount.service - dracut pre-mount hook was skipped because all trigger condition checks failed. ~ 06:05 AM root 6 # systemctl status dracut-mount.service ○ dracut-mount.service - dracut mount hook Loaded: loaded (/usr/lib/systemd/system/dracut-mount.service; static) Active: inactive (dead) Condition: start condition failed at Mon 2022-08-29 05:36:36 MST; 29min ago Docs: man:dracut-mount.service(8) man:dracut.bootup(7)
Aug 29 05:36:36 fedora systemd[1]: dracut-mount.service - dracut mount hook was skipped because all trigger condition checks failed.
I checked in /etc for configuration files that were changed before this happened, and got the following list. I truncated the gconf list, it doesn't seem it would be relevant to the problem.
# find /etc -mtime 2 -print /etc/sysconfig/network-scripts/readme-ifcfg-rh.txt /etc/rwtab.d /etc/rwtab.d/sssd /etc/logrotate.d /etc/logrotate.d/sssd /etc/pam.d/sssd-shadowutils /etc/pam.d/kde /etc/krb5.conf.d/enable_sssd_conf_dir /etc/krb5.conf.d/sssd_enable_idp /etc/krb5.conf.d/kcm_default_ccache /etc/rhsm/ca /etc/xdg/startkderc /etc/xdg/autostart/org.kde.plasmashell.desktop /etc/xdg/qtchooser /etc/samba /etc/dbus-1/system.d/org.freedesktop.sssd.infopipe.conf /etc/cifs-utils /etc/highlight /etc/X11/xinit/xinitrc.d /etc/NetworkManager /etc/NetworkManager/dispatcher.d /etc/NetworkManager/dispatcher.d/pre-down.d /etc/NetworkManager/dispatcher.d/no-wait.d /etc/NetworkManager/dispatcher.d/pre-up.d /etc/NetworkManager/dnsmasq-shared.d /etc/NetworkManager/conf.d /etc/NetworkManager/dnsmasq.d /etc/NetworkManager/NetworkManager.conf /etc/NetworkManager/system-connections /etc/sssd /etc/sssd/conf.d /etc/sssd/pki /etc/gconf/schemas /etc/gconf/gconf.xml.defaults /etc/gconf/gconf.xml.defaults/%gconf-tree-id.xml /etc/gconf/gconf.xml.defaults/%gconf-tree-ca@valencia.xml /etc/gconf/gconf.xml.defaults/%gconf-tree-da.xml /etc/gconf/gconf.xml.defaults/%gconf-tree-kn.xml /etc/gconf/gconf.xml.defaults/%gconf-tree-ko.xml /etc/gconf/gconf.xml.defaults/%gconf-tree-en_GB.xml ...
I don't see a smoking gun in any of this. Why would the dracut checks start failing if there wasn't some kind of configuration change? Or are they just a red herring, and the actual problem is somewhere else?