Bug#979970: libselinux1: dependency to newer libc6 ignored by/missing for aptitude
reassign 979970 src:glibc,src:libselinux,src:apt,src:openssh thanks On 2021-01-25 11:59, Laurent Bigonville wrote: > reassign 979970 src:glibc 2.30-1 > affects 979970 + libselinux1 > thanks > > On Tue, 12 Jan 2021 13:31:19 +0100 Charlemagne Lasse > wrote: > > > Right now, an update from buster to bullseye on amd64 completely > > bricks the system because libselinux1 is requiring a libc6 which is > > not yet installed on the system: > > > > Preparing to unpack .../0-libselinux1_3.1-2+b2_amd64.deb ... > > De-configuring libselinux1:i386 (2.8-1+b1) ... > > Unpacking libselinux1:amd64 (3.1-2+b2) over (2.8-1+b1) ... > > tar: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.30' not > > found (required by /lib/x86_64-linux-gnu/libselinux.so.1) > > dpkg-deb: error: tar subprocess returned error exit status 1 > > > > It is then not possible anymore to recover the system because dpkg > > (mv, ...) is no longer working. > > > > There is most likely some kind dependency missing to let aptitude > > known that it must first update libc6 before it can update > > libselinux1. At least on this system, the installed version of libc6 > > for amd64 and i386 was still 2.28-10 when this happened > > After some discussion on IRC it looks like the problem is apparently coming > from the breaks added to the libc6 package. The break hasn't been added randomly, but in response to upstream release notes and bug #965932. In short the openssh seccomp filters in buster are too narrow, and do not allow the new 64-bit syscalls needed for 64-bit time_t compatibility to be used. So we definitely can't drop this break. For me this is not a libc6 bug. Or if it is, it is as much the fault of libc6 (for using new syscalls) than libselinux1 (for starting using symbol versioning). I am therefore reassigning the bug. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Processed: Re: libselinux1: dependency to newer libc6 ignored by/missing for aptitude
Processing commands for cont...@bugs.debian.org: > reassign 979970 src:glibc,src:libselinux,src:apt,src:openssh Bug #979970 [src:glibc] libselinux1: dependency to newer libc6 ignored by/missing for aptitude Bug reassigned from package 'src:glibc' to 'src:glibc,src:libselinux,src:apt,src:openssh'. No longer marked as found in versions glibc/2.30-1. Ignoring request to alter fixed versions of bug #979970 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 979970: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979970 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#979970: libselinux1: dependency to newer libc6 ignored by/missing for aptitude
On Tue, Jan 26, 2021 at 12:52:52PM +0100, Aurelien Jarno wrote: > reassign 979970 src:glibc,src:libselinux,src:apt,src:openssh > thanks > > On 2021-01-25 11:59, Laurent Bigonville wrote: > > reassign 979970 src:glibc 2.30-1 > > affects 979970 + libselinux1 > > thanks > > > > On Tue, 12 Jan 2021 13:31:19 +0100 Charlemagne Lasse > > wrote: > > > > > Right now, an update from buster to bullseye on amd64 completely > > > bricks the system because libselinux1 is requiring a libc6 which is > > > not yet installed on the system: > > > > > > Preparing to unpack .../0-libselinux1_3.1-2+b2_amd64.deb ... > > > De-configuring libselinux1:i386 (2.8-1+b1) ... > > > Unpacking libselinux1:amd64 (3.1-2+b2) over (2.8-1+b1) ... > > > tar: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.30' not > > > found (required by /lib/x86_64-linux-gnu/libselinux.so.1) > > > dpkg-deb: error: tar subprocess returned error exit status 1 > > > > > > It is then not possible anymore to recover the system because dpkg > > > (mv, ...) is no longer working. > > > > > > There is most likely some kind dependency missing to let aptitude > > > known that it must first update libc6 before it can update > > > libselinux1. At least on this system, the installed version of libc6 > > > for amd64 and i386 was still 2.28-10 when this happened > > > > After some discussion on IRC it looks like the problem is apparently coming > > from the breaks added to the libc6 package. > > The break hasn't been added randomly, but in response to upstream > release notes and bug #965932. In short the openssh seccomp filters in > buster are too narrow, and do not allow the new 64-bit syscalls needed > for 64-bit time_t compatibility to be used. > > So we definitely can't drop this break. For me this is not a libc6 bug. > Or if it is, it is as much the fault of libc6 (for using new syscalls) > than libselinux1 (for starting using symbol versioning). This is not a question of finding the right solution, but more of the least worst one. Currently, the breaks potentially avoids non-working openssh-server during a partial upgrade at the expense of breaking the system in a full upgrade. We can't have that. The reason this happens is the cycle: New libselinux1 needs new libc6, new libc6 needs newer libselinux1. The right solution would be to deconfigure libselinux1, then unpack libc6, then unpack new libselinux1, but it seems that this is not what's happening, and we can't easily change apt to fix it. An alternative solution, for openssh-server would be to avoid using the new syscalls for 64-bit time_t compatibility I assume (forcing it to link with older symbol versions?), but there are other cycles between libselinux1 and libc6 from what I heard. So well, like hack up libc6 to avoid exposing the new symbol versions and recompile everything against it? If you have alternative suggestions to avoid removing the Breaks, please let me know, but as it stands, I believe that this is the option that causes the least amount of breakage. We've reached the point where we have too many dependencies and conflicts too low in the stack, and it becomes too much for apt to handle. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#979970: libselinux1: dependency to newer libc6 ignored by/missing for aptitude
On Tue, Jan 26, 2021 at 01:44:47PM +0100, Julian Andres Klode wrote: > On Tue, Jan 26, 2021 at 12:52:52PM +0100, Aurelien Jarno wrote: > > The break hasn't been added randomly, but in response to upstream > > release notes and bug #965932. In short the openssh seccomp filters in > > buster are too narrow, and do not allow the new 64-bit syscalls needed > > for 64-bit time_t compatibility to be used. Would it help to get those seccomp filter fixes into buster, and then we could tell people that they have to upgrade to the latest point release first? Awkward but not unprecedented I think. > An alternative solution, for openssh-server would be to avoid using the > new syscalls for 64-bit time_t compatibility I assume (forcing it to > link with older symbol versions?), Changing openssh-server in bullseye can't possibly help here, because if you've upgraded openssh-server then that will include the updated seccomp filters anyway. Changing openssh-server in buster might help, but if so it would be much simpler to take the approach above (backporting the seccomp filter fixes) rather than doing symbol versioning hacks. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#981068: [arm64] ldconfig segfaults inside a qemu-aarch64-static chroot
control: reassign -1 qemu-user-static control: found -1 qemu-user-static/1:3.1+dfsg-8 control: close -1 1:5.0-1 control: affects -1 libc6 On 2021-01-25 23:13, Domenico Andreoli wrote: > Package: libc-bin > Version: 2.31-7 > > The issue is reproducible inside a arm64 chroot, on a amd64 host, > via qemu-aarch64-static. No problems on a native arm64. > > Package upgrade fails with segmentation fault on post-installation, > it's ldconfig: > > # dpkg -i libc-bin_2.31-7_arm64.deb > Unknown host QEMU_IFLA type: 50 > Unknown host QEMU_IFLA type: 51 > Unknown host QEMU_IFLA type: 50 > Unknown host QEMU_IFLA type: 51 > Unknown host QEMU_IFLA type: 50 > Unknown host QEMU_IFLA type: 51 > Unknown host QEMU_IFLA type: 50 > Unknown host QEMU_IFLA type: 51 > (Reading database ... 50524 files and directories currently installed.) > Preparing to unpack libc-bin_2.31-7_arm64.deb ... > Unpacking libc-bin (2.31-7) over (2.31-6) ... > Setting up libc-bin (2.31-7) ... > qemu: uncaught target signal 11 (Segmentation fault) - core dumped > Segmentation fault > qemu: uncaught target signal 11 (Segmentation fault) - core dumped > Segmentation fault > dpkg: error processing package libc-bin (--install): > installed libc-bin package post-installation script subprocess returned > error exit status 139 > Processing triggers for man-db (2.9.3-2) ... > Errors were encountered while processing: > libc-bin > # > > # ldconfig -v > Unknown host QEMU_IFLA type: 50 > Unknown host QEMU_IFLA type: 51 > Unknown host QEMU_IFLA type: 50 > Unknown host QEMU_IFLA type: 51 > Unknown host QEMU_IFLA type: 50 > Unknown host QEMU_IFLA type: 51 > Unknown host QEMU_IFLA type: 50 > Unknown host QEMU_IFLA type: 51 > qemu: uncaught target signal 11 (Segmentation fault) - core dumped > qemu: uncaught target signal 11 (Segmentation fault) - core dumped > zsh: segmentation fault ldconfig -v > # > > The issue is introduced with --enable-static-pie on -7, downgrading to > -6 or rebuilding -9 without --enable-static-pie makes the problem go away. PIE support on arm64 requires at least qemu version 5.0. Please upgrade your qemu version. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Processed: Re: Bug#981068: [arm64] ldconfig segfaults inside a qemu-aarch64-static chroot
Processing control commands:
> reassign -1 qemu-user-static
Bug #981068 [libc-bin] [arm64] ldconfig segfaults inside a qemu-aarch64-static
chroot
Bug reassigned from package 'libc-bin' to 'qemu-user-static'.
No longer marked as found in versions glibc/2.31-7.
Ignoring request to alter fixed versions of bug #981068 to the same values
previously set
> found -1 qemu-user-static/1:3.1+dfsg-8
Bug #981068 [qemu-user-static] [arm64] ldconfig segfaults inside a
qemu-aarch64-static chroot
The source qemu-user-static and version 1:3.1+dfsg-8 do not appear to match any
binary packages
Marked as found in versions qemu-user-static/1:3.1+dfsg-8.
> close -1 1:5.0-1
Bug #981068 [qemu-user-static] [arm64] ldconfig segfaults inside a
qemu-aarch64-static chroot
Marked as fixed in versions qemu/1:5.0-1.
Bug #981068 [qemu-user-static] [arm64] ldconfig segfaults inside a
qemu-aarch64-static chroot
Marked Bug as done
> affects -1 libc6
Bug #981068 {Done: Aurelien Jarno } [qemu-user-static]
[arm64] ldconfig segfaults inside a qemu-aarch64-static chroot
Added indication that 981068 affects libc6
--
981068: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981068
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
