set to systemd component but I don't know. What I did: after an dnf upgrade (Jun 17th, 2024), when I logged in to Gnome, it did not find my user environment. It appears that my /home/$LOGNAME was not found. After investigation, I found that it was under /home/home/$LOGNAME. Quick work-around: I created a symlink between /home/home/$LOGNAME and /home/$LOGNAME I have not identified which component has resulted in this behavior's change. $ sudo btrfs subvolume list -ta / ID gen top level path -- --- --------- ---- 256 3513438 5 <FS_TREE>/home 257 3513438 5 <FS_TREE>/root 262 3513353 257 root/var/lib/machines $ grep home /etc/fstab /dev/mapper/luks-SCRAMBLED /home btrfs subvol=home,compress=zstd:1,x-systemd.device-timeout=0 0 0 $ mount |grep /home /dev/mapper/luks-SCRAMBLED on /home type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache,subvolid=5,subvol=/) $ ls -ld /home drwxr-xr-x. 1 root root 22 Jun 17 07:59 /home pju@fedora:/home$ ls -ld /home/home drwxr-xr-x. 1 root root 38 Jan 24 01:00 /home/home Reproducible: Always Steps to Reproduce: 1.reboot system 2.try to log in as standard user under Gnome 3. Actual Results: does not find user environment Expected Results: should find user environment user files should be under /home, not under /home/home
You provide just a few bits of information, and censor even that. How should we be able to figure anything out? IIUC, you are saying that you had /home/foobar directory and it got moved to /home/home/foobar? That is indeed very strange. Please attach the log 'journalctl -b --no-hostname' from the boot when the update was performed.
Created attachment 2037566 [details] journalctl related to the dnf update sequence
Created attachment 2037567 [details] dnf update sequence - seems to be the cause of the issue described here
log uploaded as requested. I did look into it a bit closer. It seems that the "mounted" filesystems are not what I expect as I see "/" content under "/home/root" $ ls / afs bin boot dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var $ ls /home/root afs bin boot dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var fstab has not changed: $ ls -l /etc/fstab -rw-rw-r--. 1 root root 871 Jul 16 2022 /etc/fstab It contains: $ grep btrfs /etc/fstab /dev/mapper/luks-55d5c94e-8346-4c75-9d7d-ab67425969ee / btrfs subvol=root,compress=zstd:1,x-systemd.device-timeout=0 0 0 /dev/mapper/luks-55d5c94e-8346-4c75-9d7d-ab67425969ee /home btrfs subvol=home,compress=zstd:1,x-systemd.device-timeout=0 0 0 However,mounted subvolume is id=5 instead of 256 $ sudo mount|grep btrfs /dev/mapper/luks-55d5c94e-8346-4c75-9d7d-ab67425969ee on / type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache,subvolid=257,subvol=/root) /dev/mapper/luks-55d5c94e-8346-4c75-9d7d-ab67425969ee on /home type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache,subvolid=5,subvol=/) $ sudo btrfs subvolume list -ta / ID gen top level path -- --- --------- ---- 256 3514007 5 <FS_TREE>/home 257 3514007 5 <FS_TREE>/root 262 3513353 257 root/var/lib/machines
Comment on attachment 2037566 [details] journalctl related to the dnf update sequence journalctl -b-2 --no-hostname --since today
> /dev/mapper/luks-55d5c94e-8346-4c75-9d7d-ab67425969ee on /home type btrfs > (rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache,subvolid=5,subvol=/) ^^^^^^^^ So this is the bug. Jun 17 07:50:20 systemd-getty-generator[406736]: Failed to parse $SYSTEMD_GETTY_AUTO environment variable, ignoring: Permission denied Jun 17 07:50:20 audit[406735]: AVC avc: denied { create } for pid=406735 comm="systemd-fstab-g" name=".#50-device-timeout.conf5afe7ef69a7d85eb" scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=0 Jun 17 07:50:20 audit[406735]: AVC avc: denied { create } for pid=406735 comm="systemd-fstab-g" name=".#50-device-timeout.conf91eb5d3316810d38" scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=0 Jun 17 07:50:20 (sd-exec-[406723]: /usr/lib/systemd/system-generators/systemd-fstab-generator failed with exit status 1. Jun 17 07:50:23 setroubleshoot[406768]: SELinux is preventing systemd-fstab-g from create access on the file .#50-device-timeout.conf5afe7ef69a7d85eb. For complete SELinux messages run: sealert -l 681b9089-c13e-4c38-b0f9-6ca20db1872f Jun 17 07:50:23 setroubleshoot[406768]: SELinux is preventing systemd-fstab-g from create access on the file .#50-device-timeout.conf5afe7ef69a7d85eb. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-fstab-g should be allowed create access on the .#50-device-timeout.conf5afe7ef69a7d85eb file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'systemd-fstab-g' --raw | audit2allow -M my-systemdfstabg # semodule -X 300 -i my-systemdfstabg.pp Jun 17 07:50:23 setroubleshoot[406768]: SELinux is preventing systemd-fstab-g from create access on the file .#50-device-timeout.conf91eb5d3316810d38. For complete SELinux messages run: sealert -l 681b9089-c13e-4c38-b0f9-6ca20db1872f Jun 17 07:50:23 setroubleshoot[406768]: SELinux is preventing systemd-fstab-g from create access on the file .#50-device-timeout.conf91eb5d3316810d38. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-fstab-g should be allowed create access on the .#50-device-timeout.conf91eb5d3316810d38 file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'systemd-fstab-g' --raw | audit2allow -M my-systemdfstabg # semodule -X 300 -i my-systemdfstabg.pp Looking at the code, we first try to write out the timeout drop-in, and abort if that fails. So we don't get to writing out the rest of the config, in particular options, so subvol=/home is not present in the generated device unit. I see a bunch of commits for fstab-generator in the selinux policy, but not for this particular error. Those files are created under /run/systemd/generator*, so I don't think this can be a case of bad labelling on the filesystem causing problems and tcontext looks correct too. Instead, for some reason the policy must be disallowing this. I'll reassign this for comments. systemd 255.7-1.fc40 selinux-policy-targeted-40.22-1.fc40.noarch
Thanks Zbigniew. To your point, as a confirmation of your diagnosis: $ ls -l /run/systemd/generator/home.mount -rw-r--r--. 1 root root 345 Jun 17 07:54 /run/systemd/generator/home.mount (corresponds to a boot after the faulty upgrade) $ grep -A4 Mount /run/systemd/generator/home.mount [Mount] What=/dev/mapper/luks-55d5c94e-8346-4c75-9d7d-ab67425969ee Where=/home Type=btrfs whereas on a not upgraded system, I have: $ grep -A4 Mount /run/systemd/generator/home.mount [Mount] What=/dev/disk/by-uuid/b99104db-0685-435d-ba89-cdf6caa6be86 Where=/home Type=btrfs Options=subvol=home this confirms what you wrote: "we don't get to writing out the rest of the config"
https://github.com/systemd/systemd/pull/33416 modifies the code in systemd to avoid writing half of the file. But it won't fix the issue fully, since the denial would still prevent writing out of the full thing.
Meanwhile I set selinux to permissive :-( $ sudo sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: permissive Mode from config file: permissive Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 $ journalctl -b|grep denied Jun 20 18:41:57 fedora kernel: audit: type=1400 audit(1718901716.803:3): avc: denied { read write open } for pid=991 comm="systemd-fstab-g" path="/run/systemd/generator/dev-mapper-luks\x2d55d5c94e\x2d8346\x2d4c75\x2d9d7d\x2dab67425969ee.device.d/.#50-device-timeout.confb7ce7d46661063b7" dev="tmpfs" ino=865 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1 Jun 20 18:41:57 fedora kernel: audit: type=1400 audit(1718901716.803:4): avc: denied { getattr } for pid=991 comm="systemd-fstab-g" path="/run/systemd/generator/dev-mapper-luks\x2d55d5c94e\x2d8346\x2d4c75\x2d9d7d\x2dab67425969ee.device.d/.#50-device-timeout.confb7ce7d46661063b7" dev="tmpfs" ino=865 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1 Jun 20 18:41:57 fedora kernel: audit: type=1400 audit(1718901716.803:5): avc: denied { setattr } for pid=991 comm="systemd-fstab-g" name=".#50-device-timeout.confb7ce7d46661063b7" dev="tmpfs" ino=865 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1 Jun 20 18:41:57 fedora kernel: audit: type=1400 audit(1718901716.803:6): avc: denied { remove_name } for pid=991 comm="systemd-fstab-g" name=".#50-device-timeout.confb7ce7d46661063b7" dev="tmpfs" ino=865 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=dir permissive=1 Jun 20 18:41:57 fedora kernel: audit: type=1400 audit(1718901716.803:7): avc: denied { rename } for pid=991 comm="systemd-fstab-g" name=".#50-device-timeout.confb7ce7d46661063b7" dev="tmpfs" ino=865 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1 Jun 20 18:41:57 fedora kernel: audit: type=1400 audit(1718901716.805:8): avc: denied { unlink } for pid=991 comm="systemd-fstab-g" name="50-device-timeout.conf" dev="tmpfs" ino=865 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1
Got two user reports on IRC and Matrix about this. Both have selinux-policy-40.23-1.fc40.noarch, and default Btrfs layouts. Both report this tidbit >$ systemctl cat home.mount >/run/systemd/generator/home.mount ># Automatically generated by systemd-fstab-generator > >[Unit] >Documentation=man:fstab(5) man:systemd-fstab-generator(8) >SourcePath=/etc/fstab >Before=local-fs.target >After=blockdev@dev-mapper-luks\x2d2bcc804b\x2d5677\x2d49fb\x2dac53\x2ddeadbeefd139.target > >[Mount] >What=/dev/mapper/luks-2bcc804b-5677-49fb-ac53-deadbeefd139 >Where=/home >Type=btrfs Notice the missing mount options. In the working case there's a fourth line: >Options=noatime,subvol=home So what ends up happening is we get the top-level of the file system mounted at the `/home` mount point instead of the `home` subvolume.
Also, both users in comment 10 report the problem being solved by enforcing=0, and they both have nearly the same AVCs found in comment 9. IrishFBall32: Jun 26 17:46:18 fedora kernel: audit: type=1400 audit(1719438378.077:3): avc: denied { read write } for pid=1119 comm="systemd-fstab-g" path="/run/systemd/generator/dev-mapper-luks\x2d2bcc804b\x2d5677\x2d49fb\x2dac53\x2ddeadbeefd139.device.d/.#50-device-timeout.conf122f9a10144b1733" dev="tmpfs" ino=1029 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1 Jun 26 17:46:18 fedora kernel: audit: type=1400 audit(1719438378.077:4): avc: denied { setattr } for pid=1119 comm="systemd-fstab-g" name=".#50-device-timeout.conf122f9a10144b1733" dev="tmpfs" ino=1029 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1 Jun 26 17:46:18 fedora kernel: audit: type=1400 audit(1719438378.077:5): avc: denied { remove_name } for pid=1119 comm="systemd-fstab-g" name=".#50-device-timeout.conf122f9a10144b1733" dev="tmpfs" ino=1029 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=dir permissive=1 Jun 26 17:46:18 fedora kernel: audit: type=1400 audit(1719438378.077:6): avc: denied { rename } for pid=1119 comm="systemd-fstab-g" name=".#50-device-timeout.conf122f9a10144b1733" dev="tmpfs" ino=1029 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1 Jun 26 17:46:18 fedora kernel: audit: type=1400 audit(1719438378.160:7): avc: denied { read write } for pid=1119 comm="systemd-fstab-g" path="/run/systemd/generator/dev-mapper-luks\x2d2bcc804b\x2d5677\x2d49fb\x2dac53\x2ddeadbeefd139.device.d/.#50-device-timeout.conf555eee47e031c6d7" dev="tmpfs" ino=1037 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1 Jun 26 17:46:18 fedora kernel: audit: type=1400 audit(1719438378.161:8): avc: denied { setattr } for pid=1119 comm="systemd-fstab-g" name=".#50-device-timeout.conf555eee47e031c6d7" dev="tmpfs" ino=1037 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1 Jun 26 17:46:18 fedora kernel: audit: type=1400 audit(1719438378.161:9): avc: denied { rename } for pid=1119 comm="systemd-fstab-g" name=".#50-device-timeout.conf555eee47e031c6d7" dev="tmpfs" ino=1037 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1 Jun 26 17:46:18 fedora kernel: audit: type=1400 audit(1719438378.161:10): avc: denied { unlink } for pid=1119 comm="systemd-fstab-g" name="50-device-timeout.conf" dev="tmpfs" ino=1029 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1 edofriedman: Jun 27 00:27:19 edo-laptop kernel: audit: type=1400 audit(1719437239.012:3): avc: denied { read write } for pid=992 comm="systemd-fstab-g" path="/run/systemd/generator/dev-mapper-luks\x2da2c03a64\x2dd3c5\x2d4250\x2db31f\x2daa63346cd59a.device.d/.#50-device-timeout.conf0e56dd1adbb997e3" dev="tmpfs" ino=900 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1 Jun 27 00:27:19 edo-laptop kernel: audit: type=1400 audit(1719437239.012:4): avc: denied { setattr } for pid=992 comm="systemd-fstab-g" name=".#50-device-timeout.conf0e56dd1adbb997e3" dev="tmpfs" ino=900 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1 Jun 27 00:27:19 edo-laptop kernel: audit: type=1400 audit(1719437239.012:5): avc: denied { remove_name } for pid=992 comm="systemd-fstab-g" name=".#50-device-timeout.conf0e56dd1adbb997e3" dev="tmpfs" ino=900 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=dir permissive=1 Jun 27 00:27:19 edo-laptop kernel: audit: type=1400 audit(1719437239.012:6): avc: denied { rename } for pid=992 comm="systemd-fstab-g" name=".#50-device-timeout.conf0e56dd1adbb997e3" dev="tmpfs" ino=900 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1 Jun 27 00:27:19 edo-laptop kernel: audit: type=1400 audit(1719437239.014:7): avc: denied { unlink } for pid=992 comm="systemd-fstab-g" name="50-device-timeout.conf" dev="tmpfs" ino=900 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1 Jun 27 00:27:20 edo-laptop audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { status } for auid=n/a uid=0 gid=0 path="/usr/lib/systemd/system/power-profiles-daemon.service" cmdline="" function="mac_selinux_filter" scontext=system_u:system_r:tlp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:power_unit_file_t:s0 tclass=service permissive=1 exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
I don't have an explanation why everyone is not running into this problem though. I've relabeled, still don't hit it. Had one of the above users relabel, they still hit it.
(In reply to Chris Murphy from comment #12) > I don't have an explanation why everyone is not running into this problem > though. I've relabeled, still don't hit it. Had one of the above users > relabel, they still hit it. I appear to be the first one to report this issue (although with a title not accurately reflecting the root cause). I am also surprised that this situation seems not to affect everyone. I have not further investigated since I changed SELinux to permissive mode, which fixes the issue in an unsatisfactory way. FWIW I have never experienced such issue in upgrading Fedora on this laptop: version updates went flawlessly since Jun 2021 (i.e. I don't use a recently installed OS).
@pjumelle does it seem deterministic? Or could it be a race condition? I wonder what percent of boots you see the AVC messages.
Created attachment 2038520 [details] showing that it occurs at each boot since my 17.06 system update as requested by Chris, output of: for i in $(seq -5 0); do journalctl -b$i| grep "denied.*systemd-fstab-g" done
(In reply to Chris Murphy from comment #14) > @pjumelle does it seem deterministic? Or could it be a race > condition? I wonder what percent of boots you see the AVC messages. It happens at every boot, see attachment.
Could you boot with parameter `systemd.log_level=debug` and then attach the resulting journal file from `journalctl -b -o short-monotonic --no-hostname > journal.log`? I'm trying to understand what this file ".#50-device-timeout.confdee694f92e4b64e5" is all about, and if there's really a device timeout happening and why. That doesn't directly fix the bug, but it would explain why not everyone is experiencing it. And might give a clue to SELINUX folks how to go about fixing it.
".#50-device-timeout.confdee694f92e4b64e5" is a temporary file that is created when writing the file 50-device-timeout.conf. The file is written and then atomatically renamed to the target name. The avcs above indicate that it's being written by systemd-fstab-generator.
Chris, as commented by Zbigniew, this file is created by systemd-fstab-generator: pju@fedora:/run/systemd/generator/dev-mapper-luks\x2d55d5c94e\x2d8346\x2d4c75\x2d9d7d\x2dab67425969ee.device.d$ cat 50-device-timeout.conf # Automatically generated by systemd-fstab-generator # from supplied options "subvol=home,compress=zstd:1,x-systemd.device-timeout=0" [Unit] JobRunningTimeoutSec=0
I'm not experiencing the bug, or any AVC messages, and don't have that file. But I do have: >$ cat /run/systemd/generator/dev-mapper-luks\\x2d10d575f0\\x2df041\\x2d48a2\\x2db1ed\\x2db1236e03d5e3.device.d/40-device-timeout.conf ># Automatically generated by systemd-cryptsetup-generator > >[Unit] >JobTimeoutSec=infinity This doesn't help me understand why some folks are hitting this and others aren't. I just got another user report of this problem after upgrading from 39 to 40.
As I mentioned earlier my installation went through various upgrades since Fedora 33 (Workstation). Are all the reports you get related to upgraded systems?
The comment in my fstab says it was generated by the installer in July 2021 which seems to be a few months after Fedora 34's release so it could have something to do with some older upgrade.
Hi, Similar issue: Upgraded from 38 to 40 the other week (I upgraded to 39 first, then after checking the post-upgrade activities were done continued on to F40). I have a LUKS partition with BTRFS subvolumes mounted at the root (/) and /home $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 119.2G 0 disk ├─sda1 8:1 0 200M 0 part /boot/efi ├─sda2 8:2 0 1G 0 part /boot └─sda3 8:3 0 118G 0 part └─luks-1826c92e-a4f4-48cf-ab9b-e5f6fb4233eb 253:0 0 118G 0 crypt /home / zram0 252:0 0 8G 0 disk \[SWAP\] /etc/fstab: /dev/mapper/luks-1826c92e-a4f4-48cf-ab9b-e5f6fb4233eb / btrfs subvol=root,compress=zstd:1,x-systemd.device-timeout=0 0 0 /dev/mapper/luks-1826c92e-a4f4-48cf-ab9b-e5f6fb4233eb /home btrfs subvol=home,compress=zstd:1,x-systemd.device-timeout=0 0 0 UUID=4dad5759-da08-4d99-8741-07f2509209cc /boot ext4 defaults 1 2 UUID=851B-DA3C /boot/efi vfat umask=0077,shortname=winnt 0 2 When I logged in after upgrade as my normal user I discovered that /home now contained "root" and "home", i.e it was mounting the root of the btrfs volume instead of the subvolume despite fstab saying subvol=home. This would happen on most but not all reboots. (I tried selinux relabelling but this did not fix the issue.) When I checked the generated home.mount systemd unit file it was missing the options. If I then unmounted and mounted /home it corrected the situation until the next reboot (and occasionally, immediately after remounting and rebooting it also worked for the second boot, but not always) It seems like systemd isn't generating the home.mount correctly from fstab at boot but does once the system is up. I compared the generated home.mount unit file before and after the remount and could see that the options from fstab were missing. I have worked around the issue by running `systemctl edit home.mount` and adding those missing options which has resolved the issue for me for now: [Mount] Options=subvol=home,compress=zstd:1 I can confirm that this laptop has also been through multiple upgrades of fedora. The btrfs setup would have been configured during rekick of the laptop in June 2021 with whatever Fedora was latest at the time. I initially posted a form of this report in https://chat.fedoraproject.org/#/room/#fedora:fedoraproject.org and cmurf pointed out this bug report and suggested I added my workaround to it as above.
I applied Mark's work-around as follows: 1. systemctl edit home.mount (and insert the "correct" version of home.mount) 2. reboot and check 3. change back to SELINUX=enforcing in /etc/sysconfig/selinux 4. reboot (I have not played with a relabel or restorecon, I don't think this is necessary). Difference can be seen in: $ sudo systemctl cat home.mount # /run/systemd/generator/home.mount # Automatically generated by systemd-fstab-generator [Unit] Documentation=man:fstab(5) man:systemd-fstab-generator(8) SourcePath=/etc/fstab Before=local-fs.target After=blockdev@dev-mapper-luks\x2d55d5c94e\x2d8346\x2d4c75\x2d9d7d\x2dab67425969ee.target [Mount] What=/dev/mapper/luks-55d5c94e-8346-4c75-9d7d-ab67425969ee Where=/home Type=btrfs # /etc/systemd/system/home.mount.d/override.conf [Unit] Documentation=man:fstab(5) man:systemd-fstab-generator(8) SourcePath=/etc/fstab Before=local-fs.target After=blockdev@dev-mapper-luks\x2d55d5c94e\x2d8346\x2d4c75\x2d9d7d\x2dab67425969ee.target [Mount] What=/dev/mapper/luks-55d5c94e-8346-4c75-9d7d-ab67425969ee Where=/home Type=btrfs Options=subvol=home,compress=zstd:1
(In reply to Philippe Jumelle from comment #21) >Are all the reports you get related to upgraded systems? I'm only aware of upgrades being affected. But the sample size is small.
After the last system update, I noticed that the automatically generated file was now correct i.e. had the right mount options. $ systemctl cat home.mount|grep -E "#|Options" # /run/systemd/generator/home.mount # Automatically generated by systemd-fstab-generator Options=subvol=home,compress=zstd:1 # /etc/systemd/system/home.mount.d/override.conf Options=subvol=home,compress=zstd:1 I then removed the override.conf file. The selinux updated packages are listed below: $ sudo dnf history info 654|grep selinux Upgrade nbdkit-selinux-1.38.3-1.fc40.noarch @updates Upgraded nbdkit-selinux-1.38.2-1.fc40.noarch @@System Upgrade selinux-policy-40.26-1.fc40.noarch @updates Upgraded selinux-policy-40.24-1.fc40.noarch @@System Upgrade selinux-policy-devel-40.26-1.fc40.noarch @updates Upgraded selinux-policy-devel-40.24-1.fc40.noarch @@System Upgrade selinux-policy-targeted-40.26-1.fc40.noarch @updates Upgraded selinux-policy-targeted-40.24-1.fc40.noarch @@System Thanks to whoever has fixed this issue.
Correct, there were substantial related changes in selinux-policy-40.25 and further will follow. Fix for the tlp issue is on the way, thanks everybody for patience and reporting back.
FEDORA-2024-995d585c91 (selinux-policy-40.27-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-995d585c91
FEDORA-2024-995d585c91 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-995d585c91` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-995d585c91 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-995d585c91 (selinux-policy-40.27-1.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.