Bug ID 1226517
Summary After snapper rollback/restore marks packages as explicitly installed which were autoinstalled previously
Classification openSUSE
Product openSUSE Tumbleweed
Version Current
Hardware Other
OS Other
Status NEW
Severity Critical
Priority P5 - None
Component Basesystem
Assignee screening-team-bugs@suse.de
Reporter ors0092@gmail.com
QA Contact qa-bugs@suse.de
Target Milestone ---
Found By ---
Blocker ---

Yesterday, I filed a bug report directly on Snapper's upstream GitHub, as I was
advised to do so on the Matrix support chat
(https://github.com/openSUSE/snapper/issues/916). However, the issue was closed
and I was redirected here.

Two days ago, I accidentally noticed something strange. I don't know if this is
how Snapper is supposed to work, but here are my observations and steps to
reproduce:

1. I installed `firewall-applet` manually, and zypper marked it with `i+` as
explicitly installed. It also pulled `firewall-config` automatically as a
dependency (marking it with `i` as auto-installed status) - so far, so good.
2. Then, I did a `sudo zypper rm --clean-deps firewall-applet`, and it
perfectly caught `firewall-config` too, as it was installed automatically as a
dependency.
3. Next, I did a reboot and told Snapper to use the `post` snapshot from the
time when `firewall-applet` was installed. This reverted the removal process to
the point where `firewall-applet` was installed instead, so chronologically we
are at step 1.
4. In the read-only mode, I did a `zypper se -i firewall-`, and to my surprise,
`firewall-config` was also marked with `i+`.
5. I made the `sudo snapper rollback` to see the changes live, and yes,
`firewall-config` was still marked with `i+`.
6. When I did `sudo zypper rm --clean-deps firewall-applet`, it no longer
recognized `firewall-config` to be auto-removed since it was marked as
explicitly installed.
7. This can be also reproduced without rebooting when steps are done from the
GUI YaST2 snapshot tool.
8. Since it was late yesterday, I thought I was too tired and maybe
misunderstood something. So, I double-checked myself and simulated the steps I
made yesterday, just to confirm my theory, and yepp - same results.

No idea why, but snapper removes any affected packages during a snapper
procedure within `/var/lib/zypp/AutoInstalled` but this step is nowhere logged.

Also an additional question for us affected users: how do we trace back which
packages were marked by these rollbacks? As you might guess, there could be
plenty of unnecessary packages using extra drive space, now that are explicitly
marked and thus never get removed via `sudo zypper dup --remove-orphaned` nor
gets listed by `zypper pa --orphaned` or `zypper pa --unneeded` sadly.

4years ago it seems it got already uncovered under boo 1175304, but is also
reported under Leap, this ticket is all about Tumbleweed experiences.


Operating System: openSUSE Tumbleweed 20240617
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
Kernel Version: 6.9.4-1-default (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Core™ i5-6500 CPU @ 3.20GHz
Memory: 15.6 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1050 Ti/PCIe/SSE2
Manufacturer: MSI
Product Name: MS-7972
System Version: 2.0


You are receiving this mail because: