ELF files left when remove same package in different arch

[Geass-LL]

I'm using fedora 34, rpm-4.16.1.2-6.fc34.x86_64.

I have installed both binutils.i686 and binutils.x86_64 in my vm. When I tried to remove these packages with rpm -e binutils.i686 binutils.x86_64; I found some ELF files in /usr/bin were left over.

With rpm -e -vvv binutils.i686 binutils.x86_64, I found these files were skipped, not erased.

D: skip       100755  1 (   0,   0)191072 /usr/bin/strip
D: skip       100755  1 (   0,   0) 29000 /usr/bin/strings
D: skip       100755  1 (   0,   0) 33080 /usr/bin/size
D: skip       100755  1 (   0,   0)684560 /usr/bin/readelf
D: skip       100755  1 (   0,   0) 58048 /usr/bin/ranlib
D: skip       100755  1 (   0,   0)424240 /usr/bin/objdump
D: skip       100755  1 (   0,   0)191072 /usr/bin/objcopy
D: skip       100755  1 (   0,   0) 42376 /usr/bin/nm
D: skip       100755  1 (   0,   0)1784664 /usr/bin/ld.bfd
D: skip       000000  0 (   0,   0)     0 /usr/bin/ld
D: skip       100755  1 (   0,   0)104640 /usr/bin/gprof
D: skip       100755  1 (   0,   0) 37408 /usr/bin/elfedit
D: skip       100755  1 (   0,   0)873272 /usr/bin/dwp
D: skip       100755  1 (   0,   0) 28544 /usr/bin/c++filt
D: skip       100755  1 (   0,   0)728624 /usr/bin/as
D: skip       100755  1 (   0,   0) 58040 /usr/bin/ar
D: skip       100755  1 (   0,   0) 29128 /usr/bin/addr2line

The following comments explained how rpm deal with overlapped files when removing packages. So I believe these elf files must be removed after both binutils.i686 and binutils.x86_64 removed.

https://github.com/rpm-software-management/rpm/blob/20572c63b0816bfe30aa8d9fb79975fb909cb1f5/lib/transaction.c#L571-L574

[ffesti]

It's quite possible that this is a bug. Can you still please verify that these files are not owned by another package by running rpm -qf /usr/bin/strip? Thanks!

[pmatilai]

There's a bug alright (a regression I would think), I can easily reproduce (but note binutils-gold, there's a dependency):

[pmatilai🎩︎localhost]$ podman run -i -t fedora:34 [root@31dcd520ed8c /]# dnf -y install binutils.i686 binutils.x86_64 [...] Complete! [root@31dcd520ed8c /]# rpm -e binutils.i686 binutils.x86_64 binutils-gold [root@31dcd520ed8c /]# ls -l /usr/bin/strip -rwxr-xr-x. 1 root root 188392 Sep 16 16:52 /usr/bin/strip [root@31dcd520ed8c /]# rpm -qf /usr/bin/strip file /usr/bin/strip is not owned by any package

Oops. I would've thought there's a test for this but seems not...

The file states are as they should, after reinstalling:

[root@31dcd520ed8c /]# rpm -ql --state binutils|grep /usr/bin/strip normal /usr/bin/strip wrong color /usr/bin/strip

[pmatilai]

I traced this down to rpm 4.14.2 (fedora 30), still happens there. On rpm 4.11.3 (centos 7) the files do get erased, so we have a regression somewhere between 4.11.3 and 4.14.2. Oh joy.

Thanks @Geass-LL for reporting!

[Geass-LL]

It's quite possible that this is a bug. Can you still please verify that these files are not owned by another package by running rpm -qf /usr/bin/strip? Thanks!

Sure, they are not owned by any package.

[root@fedora ~]# ll /usr/bin/addr2line 
-rwxr-xr-x. 1 root root 29128 Mar 12  2021 /usr/bin/addr2line
[root@fedora ~]# rpm -qf /usr/bin/addr2line 
file /usr/bin/addr2line is not owned by any package

[pmatilai]

Another data point is that this only happens when both packages are removed in the same transaction, if removed separately then the wrongcolor state is honored.

[Geass-LL]

May be https://github.com/rpm-software-management/rpm/commit/2d52726bd55f008ea23262c2a3a31ae689cd2af4 leads to this bug. I have tested revert this patch works fine for me. However, I don't know if this will lead to other unexpected bug.

[pmatilai]

Ack, thanks for chasing that down, that's indeed where the behavior changes. Reverting is not the right thing to do here though, as it was buggy to begin with. I suspect this is a case where fixing that bug unearths another one (of not erasing the file at all).

[Geass-LL]

I have prepared a PR which simply adds a check to avoid skipping WRONGCOLOR file. Could you please take a look? Thanks.

https://github.com/rpm-software-management/rpm/pull/1804

[Geass-LL]

@pmatilai I have prepared a new PR. PTAL. https://github.com/rpm-software-management/rpm/pull/1853

[pmatilai]

Reopening as the fix caused a worse regression, ie exactly the thing I was hoping to avoid with the added tests. Fix for this issue reverted for further investigation, erasing files is worse than not erasing.

That went well, not...

[Geass-LL]

ping. Has this issue been fixed?

[JetXujing]

ping. Has this issue been fixed? I see that this issue was removed from the 4.20.0 milestone.

[pmatilai]

It was removed from the milestone because it didn't make it...