Control: owner -1 ! Control: tags -1 + moreinfo Hi,
On Wed, Jul 17, 2024 at 01:55:12PM +0200, Santiago Vila wrote: > Thanks a lot for the report. I'm hereby forwarding it to > Helmut Grohne, who did the latest usrmerge changes. Accepted. Thanks for notifying me again. I admit I wasn't expecting multiple problems to reported here. Do you think I should subscribe to base-files' bug reports to provide faster responses? > I see "Foreign Architectures: i386", maybe that could > be a factor for this problem to be more likely to happen. I'm not yet convinced as the failing effect happens on /lib64. > Also, I wonder if running unstable and not upgrading in a long time, > given the t64 transition which has not finished yet, could be slightly > more dangerous than upgrading to the testing of the day first (in a similar > way that we do not support upgrades which skip releases, like buster to > bookworm, or bullseye to trixie). The time wasn't that long. 2.37 is later than bookworm. I think such an upgrade should be supported and I had specifically tested my patches for this case. Even now, such an upgrade just works (and other people would have complained as well): mmdebstrap bookworm /dev/null http://deb.debian.org/debian --variant=apt --chrooted-customize-hook='sed -i -e s/bookworm/unstable/ /etc/apt/sources.list && apt-get update && apt-get -y dist-upgrade' On Wed, 17 Jul 2024 07:46:14 +0200, Oswald Buddenhagen wrote: > while upgrading the system after a rather long time, this happened: > > # apt dist-upgrade > ... > Unpacking base-files (13.3) over (13) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-fU8xAF/12-base-files_13.3_amd64.deb (--unpack): > trying to overwrite '/lib64', which is also in package libc6:amd64 2.37-12 > Errors were encountered while processing: > /tmp/apt-dpkg-install-fU8xAF/12-base-files_13.3_amd64.deb > E: Sub-process /usr/bin/dpkg returned an error code (1) This is surprising. In version 13, /lib64 is missing from base-files (and only installed by libc6). In version 13.3, it is a symbolic link pointing to usr/lib64. libc6:amd64 2.37-12 should contain /lib64 as a directory, so this is a symlink vs directory conflict in principle. Since your system has gone past bookworm, the actual /lib64 should be a symbolic link. Can you check what /lib64 actually was on your system? If it still was a directory, we consider this an unsupported skip-upgrade and need to figure out why the usrmerge conversion did not happen. In this case, base-files.preinst should have errored out, so that condition seems fairly unlikely. If it is something else, dpkg should unlink and replace it without an error. In neither case, we should see this error. I am wondering now whether a post-bookworm dpkg increased its conflict checks. I attempted reproducing that by upgrading dpkg first, but unstable dpkg depends on an updated libc6, which breaks old base-files, so we again end up with base-files being upgraded first and that happens to work (if you come from bookworm). More precise knowledge of the actual dpkg version (before upgrading) is required to further this avenue. > notably, it didn't try to unpack libc6 first. when i tried that > manually, i got this: > > # dpkg -i base-files_13.3_amd64.deb libc6_2.39-4_* > (Reading database ... 362942 files and directories currently installed.) > Preparing to unpack base-files_13.3_amd64.deb ... > Unpacking base-files (13.3) over (13) ... > dpkg: error processing archive base-files_13.3_amd64.deb (--install): > trying to overwrite '/lib64', which is also in package libc6:amd64 2.37-12 > dpkg: regarding libc6_2.39-4_amd64.deb containing libc6:amd64: > libc6:amd64 breaks base-files (<< 13.3~) > base-files (version 13) is present and installed. > > dpkg: error processing archive libc6_2.39-4_amd64.deb (--install): > installing libc6:amd64 would break base-files, and > deconfiguration is not permitted (--auto-deconfigure might help) > dpkg: regarding libc6_2.39-4_i386.deb containing libc6:i386: > libc6:i386 breaks base-files (<< 13.3~) > base-files (version 13) is present and installed. The unpack order is ok in principle. That's also how it works in my tests (except that I don't see the failure). > with the suggested switch, a few more packages, and a temporarily > inoperable system (due to missing /lib64), i got out of it, but > this obviously isn't the way to go. This suggests that you cannot tell us what /lib64 was before your failed upgrade and we may be unable to recover the case. Do you have backups from the time before you upgraded? Ideally, you provide your package database and the direct contents of your / folder (non-recursive) for diagnosis. In the absence of backups, /var/log/apt/history.log likly is helpful still. If you prefer doing this confidentially, you may send them via gpg encrypted mail to me directly and I guess Chris (zeha@d.o) would also volunteer to be a trusted party implementing a reproducer. Maybe you can also shed some light on whether the underlying filesystem behaves sanely. What filesystem are you using for the rootfs? If there is any overlayfs, fuse or wsl2 involved, that would be interesting. Feel free removing the moreinfo tag via "Control: tags -1 - moreinfo" on a reply supplying answers or we'll do that for you. Thanks in advance Helmut
