Heya,
Just re-installed my desktop using the latest snapshot (20250311).
Un-tar’d my dotfiles, set my hostname, added my second disk to /etc/fstab,
UUID=<SOMETHING> /home/peniblec/media xfs user,exec 0 0
… and then restarted to a black screen. Logged in on tty1, panicked a bit seeing my $HOME absent, glanced at the journal,
Mar 12 23:21:36 amdahl30 kernel: audit: type=1305 audit(1741818096.965:181): op=set audit_pid=0 old=1124 auid=4294967295 ses=4294967295 subj=unconfined res=1
Mar 12 23:21:37 amdahl30 kernel: audit: type=1305 audit(1741818097.020:182): op=set audit_enabled=0 old=1 auid=4294967295 ses=4294967295 subj=unconfined res=1
Mar 12 23:21:37 amdahl30 auditctl[4085]: enabled 0
Mar 12 23:21:37 amdahl30 auditctl[4085]: failure 1
Mar 12 23:21:37 amdahl30 auditctl[4085]: pid 0
Mar 12 23:21:37 amdahl30 auditctl[4085]: rate_limit 0
Mar 12 23:21:37 amdahl30 auditctl[4085]: backlog_limit 64
Mar 12 23:21:37 amdahl30 auditctl[4085]: lost 0
Mar 12 23:21:37 amdahl30 auditctl[4085]: backlog 1
Mar 12 23:21:37 amdahl30 auditctl[4085]: backlog_wait_time 60000
Mar 12 23:21:37 amdahl30 auditctl[4085]: backlog_wait_time_actual 0
Mar 12 23:21:37 amdahl30 auditctl[4085]: No rules
… figured I’d try SELINUX=disabled in /etc/selinux/config, restarted, and now:
- a regular restart remains stuck at the splash screen, before the login manager; I can’t seem to open a TTY and I can’t find a trace of these boots in the logs;
- a restart using GRUB’s “rescue mode” successfully starts the graphical session.
I guess I’m left with these questions:
- is there a fine manual I should have read about SELinux vs arbitrary fstab additions, or am I conflating correlation with causation?
- should I bother trying to fix my mess (so that I can boot (a) without rescue mode (b) with SELinux enabled), or just re-re-install?
Happy to share more logs if that can help; going to hit the hay for now - hadn’t seen that sucker punch coming, or I would have waited for a more opportune time before re-installing. Thanks for your time.
Morning 
- a restart using “rescue mode” in GRUB’s advanced options successfully starts the graphical session.
(I should add: “… with ~/media properly mounted”, to dispel doubt about the fstab entry being well-formed)
- is there a fine manual I should have read about SELinux vs arbitrary fstab additions, or am I conflating correlation with causation?
Working theory, since previous installation was from November, so Tumbleweed switched to SELinux: that second disk lacks some metadata that SELinux wants. Not sure what the remediation is yet - sprinkling the right (fs)context mount option in fstab, running a command to label the disk, adding a /.autorelabel file… much reading to do.
SELINUX=disabled in /etc/selinux/config
(FWIW, permissive yields the same results as enforcing: home is not mounted)
This usually hints at the video (driver) issues.
Working theory, since previous installation was from November, so Tumbleweed switched to SELinux: that second disk lacks some metadata that SELinux wants. Not sure what the remediation is yet - sprinkling the right (fs)context mount option in fstab, running a command to label the disk, adding a /.autorelabel file… much reading to do.
OK, two elements that invalidate this theory, or at least complicate the picture:
-
restoring SELinux (SELINUX=enforcing), commenting out the fstab entry, then rebooting, yields the same (initial) problem: no login manager, can switch to tty1, no home mounted; infuriatingly, logs are somewhat hard to preserve (all traces of journalctl disappear after a reboot; must write them to e.g. /etc since nothing else seems to be mounted correctly, and network is not started, so no way to exfiltrate); they do show some ominous messages:
systemd-fstab-generator[714]: Failed to open /etc/fstab: Permission denied
kernel: audit: type=1400 audit(1741850845.945:3): avc: denied { read } for pid=714 comm="systemd-fstab-g" name="fstab" dev="sda2" ino=216168 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=unconfined_u:object_r:cache_home_t:s0 tclass=file permissive=0
(sd-exec-[709]: /usr/lib/systemd/system-generators/systemd-fstab-generator failed with exit status 1.
systemd-gpt-auto-generator[716]: Failed to parse fstab: Permission denied
kernel: audit: type=1400 audit(1741850845.960:4): avc: denied { read } for pid=716 comm="systemd-gpt-aut" name="fstab" dev="sda2" ino=216168 scontext=system_u:system_r:systemd_gpt_generator_t:s0 tcontext=unconfined_u:object_r:cache_home_t:s0 tclass=file permissive=0
kernel: audit: type=1400 audit(1741850845.960:5): avc: denied { read } for pid=716 comm="systemd-gpt-aut" name="fstab" dev="sda2" ino=216168 scontext=system_u:system_r:systemd_gpt_generator_t:s0 tcontext=unconfined_u:object_r:cache_home_t:s0 tclass=file permissive=0
(sd-exec-[709]: /usr/lib/systemd/system-generators/systemd-gpt-auto-generator failed with exit status 1.
-
keeping SELinux disabled and the fstab entry commented out, then rebooting, still requires me to go through rescue mode; otherwise I still get stuck before the login manager with not even a TTY.
That’ll be all for this morning on my side.
I don’t want to dismiss this outright, but given the journalctl evidence that SELinux prevents systemd from reading fstab, I think I’ll keep looking on the SELinux side before looking into video drivers - which worked fine the first handful of boots after re-installation, so not sure how the video drivers would have become messed up? I didn’t have the time to do much damage after the install.
(The worst I can think of, which I omitted in my OP, was zypper source-install --build-deps-only emacs which does install a host of weird packages, some of which could conceivably mess with video drivers? 
)
FWIW, after waiting long enough at the splash screen I get when I (a) disabling SELinux (b) doing a non-rescue boot, I finally got a more informative screen. Again, SELinux seems to be involved - even though it is disabled.
So refined working theory: I botched /etc/fstab metadata by editing it (perhaps because I used Emacs’s /sudoedit:: method?). Not sure how to fix this - sudo restorecon /etc/fstab did not help. Might try to re-re-install - as i said, didn’t get the opportunity to do much on this frehs re-installation anyway.
So refined working theory: I botched /etc/fstab metadata by editing it (perhaps because I used Emacs’s /sudoedit:: method?). Not sure how to fix this - sudo restorecon /etc/fstab did not help. Might try to re-re-install - as i said, didn’t get the opportunity to do much on this frehs re-installation anyway.
Clobbered /var/log/zypp/history with a misplaced tee 
so figured a reⁿinstall was in order. Opted out of all security modules in the installer, re-ran everything I ran yesterday.
Lightly de-noised history FTR (possibly out-of-order: some commands run in the TTY, others in the GUI):
tar xvf /run/media/peniblec/[…disk label…]/bkp.amdahl30.2025-03-13.tgz
sudo zypper source-install --build-deps-only emacs
rm -rf .emacs .emacs.d/
emacs &
sudo localectl set-x11-keymap fr pc105 latin9 ctrl:nocaps
sudo zypper install htop ripgrep mpv
sudo hostnamectl hostname amdahl30
setfacl -m u:sddm:x ~/
setfacl -m u:sddm:r ~/.face.icon
sudo firewall-cmd --add-service=mdns
sudo firewall-cmd --add-service=mdns --permanent
mkdir media
mount media
rmdir Music/
ln -sv media/music Music
(Not pictured:
- letting the Plasma tray widget mount the
/run/media disk where the backup tarball lives;
- adding the
~/media mountpoint back to /etc/fstab as shown in the OP using Emacs’s /sudoedit:: method
- a handful of successful reboots)
So the status quo is not very satisfying intellectually - no SELinux at all 
I think I’ll cash in my chips for now though and revisit that topic later…
