Updating from Tumbleweed 20260331 to 20260415, zypper dup fails at accountsservice :(

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  
(557/916) 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!  

What should I do?

  • MrScruff@lemmy.zip
    link
    fedilink
    arrow-up
    1
    ·
    3 days ago

    The failed zypper dup could have been from a day or week ago. It only recompiles the policy binary in the post transaction hooks.

    If you want to track it down take a look in /var/log

    There will be zypper logs and in zypp/history you can see all your transactions.

    • steel_for_humans@piefed.socialOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 days ago

      OK, that’s interesting :) I’m learning something new. What would I be looking for in the Zypper history log? Any keywords you’d look for?

      • MrScruff@lemmy.zip
        link
        fedilink
        arrow-up
        1
        ·
        2 days ago

        I would start by grepping /var/log/zypper.log for aborted or posttrans, seeing where the previous installation failed to run the post transaction hook. Then check the timestamp and see if it makes more sense what happened.

        I don’t use opensuse, or zypper, (arch btw) so I’m sorry I can’t give more detailed help.

        The good news is I’ve seen multiple broken Ubuntu/Debian/etc systems from aborted upgrades too. So I don’t think your situation is unique to your distro. It’s more about learning what you system is actually doing when you update and how catch when something has gone wrong.