[BUG] Failed to resolve AST after I rebase from 35 to 36

[zic-github]

Describe the bug I intentionally hit "ostree admin finalize-staged", I get an error as "Failed to resolve AST".

To Reproduce Please describe the steps needed to reproduce the bug:

1. Have been using 35.
2. Run "rpm-ostree rebase fedora:fedora/36/x86_64/silverblue" and it succeeded.
3. If I just reboot it, that staged 36 will go somewhere and 35 will come up. Thus tried manually "ostree admin finalize-staged".
4. Will get below result.

   Copying /etc changes: 126 modified, 8 removed, 5481 added
   Failed to resolve dontaudit statement at /etc/selinux/targeted/tmp/modules/100/abrt/cil:627
   Failed to resolve AST
   semodule:  Failed!
   error: Child process exited with code 1

Expected behavior "ostree admin finalize-staged" suceeds without any errors.

Screenshots If applicable, add screenshots to help explain your problem.

OS version:

rpm-ostree status -b
State: idle
Warning: failed to finalize previous deployment
         error: Child process exited with code 1
         check `journalctl -b -1 -u ostree-finalize-staged.service`
BootedDeployment:
● fedora:fedora/35/x86_64/silverblue
                   Version: 35.20220521.0 (2022-05-21T00:49:30Z)
                BaseCommit: 887a71f52b061c1aff7b898c0e9e363aab519334c828a713d2e416c2fe814d5f
              GPGSignature: Valid signature by 787EA6AE1147EEE56C40B30CDB4639719867C58F
           LayeredPackages: aspell aspell-en at audacity autofs bind cdparanoia chkconfig clang cronie crontabs
                            dhcp-server dia dnf dnssec-trigger dovecot emacs emacs-apel emacs-auto-complete
                            emacs-color-theme emacs-dockerfile-mode emacs-goodies emacs-json-mode emacs-spice-mode
                            emacs-yaml-mode eog evince fail2ban-all flac gimp git-gui gitg gitk gnome-tweak-tool gpm
                            grip gstreamer1-plugins-bad-free-wildmidi gthumb hdparm hostapd-logwatch ibus-mozc info isl
                            kid3 krb5-workstation libatomic_ops libreoffice linuxptp lm_sensors-libs logcheck lollypop
                            ncurses-compat-libs net-tools nginx numlockx pam_ssh_agent_auth peek postfix rhythmbox
                            samba-common-tools samba-dc samba-swat scrub smartmontools spice-gtk squid strace syslog-ng
                            sysstat telnet thunderbird tmpwatch traceroute unbound vinagre virt-manager vlc
                            vlgothic-fonts vlgothic-p-fonts watchdog wireshark wireshark-cli x509watch xset
                    Pinned: yes

Additional context Add any other context about the problem here.

[travier]

You should be able to find the root of the issue in the logs from rpm-ostreed after the reboot, right after the rebase.

[zic-github]

Not sure what you mean.

I thought, during the shutdown, ostree-finalize-staged.service would run. And there, we see the error. And it wipes out the staged 36. Thus, when it goes booted, there is no 36 but the previous 35 comes up.

I forgot to add in the description but if I dare to add,

1. rpm-ostree rebase fedora:fedora/36/x86_64/silverblue, succeeds
2. rpm-ostree status, we see the staged 36 entry
3. ostree admin finalize-staged, we see the error
4. rpm-ostree status, we see the staged 36 entry is gone

I see below error in messages during the shutdown.

May 22 07:03:15 Linux ostree[3396]: error: ostree-finalize-staged.service failed on previous boot: Child process exited with code 1
May 22 07:03:15 Linux systemd[1]: ostree-boot-complete.service: Main process exited, code=exited, status=1/FAILURE
May 22 07:03:15 Linux systemd[1]: ostree-boot-complete.service: Failed with result 'exit-code'.
May 22 07:03:15 Linux systemd[1]: Failed to start OSTree Complete Boot.

I don:t see nothing special for rpm-ostreed during the boot.

[travier]

I would try:

1. rpm-ostree rebase fedora:fedora/36/x86_64/silverblue
2. reboot
3. looks at the logs

[zic-github]

I have 2 physical and 2 virtual machines. Only 1 out of those 4, I see the issue. Other 3 worked fine.

[zic-github]

Finally, I gave up. Looks like for some reason, the selinux targeted policies are broken. I removed everything under /etc/selinux/targeted/active/modules/[124]00/ from both current and staged. And the rebase worked fine. After the rebase deployment booted, I copied over /etc/selinux/targeted/active/modules/[124]00/ from other machine.

Funny thing here is, I saw that AST error only when I tried the rebase. Even in that supposed broken environment, rpm-ostree upgrade worked fine in the same Fedora 35 environment.