I know people are hating AI, but Opus again helped me. My system is fixed and updated. It diagnosed the root cause and told me how to fix it and I can attest that it worked. Below you can find a writeup on what was done.

When working with AI I check the commands I don't understand, consult the tldr pages and man pages or ask it to further explain what it wants to do and why. I also have Snapper and Restic backup so I wasn't too worried about screwing things up.

However, if system updates can fail like this and I'm not at fault (I wasn't), then I think Tumbleweed or rolling distros in general are not for me. I cannot keep asking AI for help, SELinux, labeling something in the filesystem -- I don't even know what that means. It was rough today and it gave me a scare. I am not ready to troubleshoot such advanced concepts as a Linux newbie, so I think I'll bail and switch to something else.

---

Fixing zypper dup failure on openSUSE Tumbleweed with SELinux

A debugging session covering an accountsservice RPM install failure during
zypper dup, caused by a stale compiled SELinux policy in the kernel.

---

The problem

zypper dup failed on a single package:

error: lsetfilecon: (11 /usr/share/accountsservice, system_u:object_r:accountsd_share_t:s0) Invalid argument  
error: Plugin selinux: hook fsm_file_prepare failed  
error: unpacking of archive failed on file /usr/share/accountsservice: cpio: (error 0x2)  
error: accountsservice-23.13.9-11.3.x86_64: install failed  
error: accountsservice-23.13.9-11.2.x86_64: erase skipped  
(  4/360) Installing: accountsservice-23.13.9-11.3.x86_64 ..................................................................................................[error]  
Installation of accountsservice-23.13.9-11.3.x86_64 failed:  
Error: Subprocess failed. Error: RPM failed: Command exited with status 1.  
Abort, retry, ignore? [a/r/i] (a): a  
Warning: %posttrans and %transfiletrigger scripts are not executed when aborting!  
Problem occurred during or after installation or removal of packages:  
Installation has been aborted as directed.  

---

Diagnosis

The key line is:

lsetfilecon: (11 /usr/share/accountsservice, system_u:object_r:accountsd_share_t:s0) Invalid argument  

RPM's SELinux plugin is trying to apply the label accountsd_share_t to
/usr/share/accountsservice, and the kernel returns EINVAL. This typically
means one of:

1. The filesystem doesn't support the xattrs SELinux needs, or
2. The SELinux policy loaded in the kernel doesn't know the type being applied.

The %posttrans warning at the end is a consequence — it means other packages
queued in the transaction had their post-transaction scripts skipped, so the
system is in a partially-upgraded state.

Gathering facts

rpm -q selinux-policy  
# → selinux-policy-20260410-1.1.noarch  

zypper info selinux-policy  
# → Status: up-to-date, Version: 20260410-1.1  

sudo getenforce  
# → Enforcing  

sudo semanage module -l | grep accountsd  
# → accountsd                 100       pp  

sudo seinfo -t accountsd_share_t  
# → Types: 0          ← smoking gun  

df -T /usr/share/accountsservice  
# → /dev/mapper/cr_root btrfs ...  

getfattr -d -m - /usr/share/accountsservice  
# → security.selinux="system_u:object_r:usr_t:s0"  

sudo ausearch -ts recent -m AVC  
# → AVCs related to snapper_sdbootutil_plugin_t, all permissive=1  
# → unrelated to this failure  

What the results mean

• selinux-policy on disk is current (20260410-1.1).
• The accountsd module is installed at priority 100.
• But seinfo -t accountsd_share_t returns Types: 0 — the loaded kernel
  policy does not know this type.
• Filesystem is Btrfs with xattrs working; the existing label usr_t is set
  fine, so it's not a filesystem support issue.
• The AVCs in the audit log are unrelated noise from the aborted dup — all
  permissive=1, from sdbootutil housekeeping.

Root cause

The selinux-policy RPM on disk defines accountsd_share_t, but the kernel
is running an older compiled policy that predates that type. When RPM's
SELinux plugin tried to apply accountsd_share_t, the kernel said "I don't
know what that is" → EINVAL.

This usually happens when selinux-policy was updated on disk in an earlier
transaction, but the policy store wasn't recompiled and reloaded — likely
because a %posttrans script that would have called semodule -B was
skipped during a prior interrupted transaction.

---

Fix

1. Rebuild and reload the policy store

sudo semodule -B  

This forces the modular policy (including accountsd) to be recompiled from
the on-disk modules and loaded into the kernel. It can take 30–90 seconds.

2. Verify the type is now known

sudo seinfo -t accountsd_share_t  
# → Types: 1  

3. Retry the dup

sudo zypper dup  

The accountsservice install should now succeed. Because the first attempt
aborted with %posttrans scripts skipped, zypper dup may have extra
cleanup/reinstall work to do — that's expected.

4. Regenerate TPM2 PCR predictions

During the dup, sdbootutil emitted warnings like:

NVIndex policy created  
WARNING: Volume key cannot be extracted. Dropping PCR 15  
WARNING: File measure-pcr-prediction should be updated  
WARNING: Call sdbootutil update-predictions --measure-pcr  
find: '/var/lib/pcrlock.d/': No such file or directory  

Breakdown:

• Volume key cannot be extracted. Dropping PCR 15 — expected and
  harmless. sdbootutil binds without PCR 15 when the volume key isn't
  available; unlock still works via other PCRs.
• find: '/var/lib/pcrlock.d/': No such file or directory — ties back to
  one of the AVCs we saw: the snapper sdbootutil plugin removed pcrlock.d
  during cleanup. permissive=1 means SELinux didn't block it; this is a
  plugin ordering issue, not an SELinux problem.
• WARNING: Call sdbootutil update-predictions --measure-pcr — the PCR
  prediction file needs regenerating before the next boot, or TPM2 may fail
  to release LUKS keys and you'll fall back to the passphrase prompt.

Run the suggested command once dup completes cleanly:

sudo sdbootutil update-predictions --measure-pcr  

5. Schedule a filesystem relabel and reboot

The on-disk label on /usr/share/accountsservice was still the generic
usr_t, so after a policy jump it's worth reconciling all labels:

sudo fixfiles onboot  
sudo reboot  

fixfiles onboot schedules a full relabel at next boot — takes a few minutes
during boot but is the cleanest way to get labels in sync with the updated
policy.

---

Full sequence

sudo semodule -B                                    # rebuild policy  
sudo seinfo -t accountsd_share_t                    # verify: Types: 1  
sudo zypper dup                                     # finish the dup  
sudo sdbootutil update-predictions --measure-pcr    # regen TPM predictions  
sudo fixfiles onboot                                # schedule relabel  
sudo reboot  

---

Safety notes

• Before rebooting, confirm the LUKS passphrase is accessible (in a password
  manager). TPM2 auto-unlock is a convenience layer on top of the passphrase
  — if predictions are wrong, the system falls back to the passphrase rather
  than locking you out.
• openSUSE's Btrfs + snapper setup means a pre-dup snapshot exists. Confirm
  with sudo snapper list. If anything goes sideways, an older snapshot can
  be booted from systemd-boot.
• If the TPM2 unlock fails at first boot after dup, enter the passphrase and
  re-run sudo sdbootutil update-predictions --measure-pcr once booted —
  predictions sometimes need recalculating against the actual booted
  measurements.

---

Key takeaways

• lsetfilecon ... Invalid argument during an RPM install = the kernel
  policy doesn't know a type the package is trying to apply. Fix with
  semodule -B to recompile and reload.
• seinfo -t <type> returning Types: 0 for a type you expect to exist is
  the definitive signal that the loaded policy is stale relative to what's on
  disk.
• When a zypper dup aborts mid-transaction, %posttrans scripts are
  skipped — which can leave SELinux policy out of sync and cause cascading
  failures on the next dup. Finishing the transaction cleanly and relabeling
  afterwards is the safe recovery path.
• The sdbootutil PCR warnings are separate from the SELinux issue but worth
  addressing in the same session, since the next reboot will exercise both.