… 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.
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)
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.
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):
)
so figured a reⁿinstall was in order. Opted out of all security modules in the installer, re-ran everything I ran yesterday.
I think I’ll cash in my chips for now though and revisit that topic later…