Re: Bug#1070666: util-linux: last(1) is broken on i386 since 2.40-8
Control: reassign 1070666 glibc Control: affects 1070666 util-linux On Mon, May 06, 2024 at 11:51:50PM +0300, Eugene Berdnikov wrote: > Upgrade of util-linux from 2.39.3-6 to 2.40-8 on i386 systems breaks > last(1), while the same upgrade on amd64 systems does not break it. > Examples on my hosts running in 32-bit mode: > > -- > root@citrine # /usr/bin/last -3 > last: unrecognized ut_type: 22985 > last: preallocation size exceeded [..] This is probably - I haven't checked - the struct layout problem mentioned by Florian Weimer, supposedly fixed in glibc 2.40. Might be nice to get that for trixie. Thanks, Chris
Processed: Re: Bug#1070666: util-linux: last(1) is broken on i386 since 2.40-8
Processing control commands: > reassign 1070666 glibc Bug #1070666 [util-linux] util-linux: last(1) is broken on i386 since 2.40-8 Bug reassigned from package 'util-linux' to 'glibc'. No longer marked as found in versions util-linux/2.40-8. Ignoring request to alter fixed versions of bug #1070666 to the same values previously set > affects 1070666 util-linux Bug #1070666 [glibc] util-linux: last(1) is broken on i386 since 2.40-8 Added indication that 1070666 affects util-linux -- 1070666: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070666 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1071084: locales: update-locale hides error information when invoking 'locale charmap'
Package: locales
Version: 2.38-10
Severity: normal
Tags: newcomer, patch
The perl script update-local internally invokes 'locale charmap' to perform
additional checks.
However if this call fails for some reason, update-locale always only prints
"Error: invalid locale settings: LANG=" which can be very misleading when
the root-cause is actually different.
I.e. sample output of "sudo /usr/sbin/update-locale LANG=de_AT.UTF-8" on Debian
Trixie:
*** update-locale: Error: invalid locale settings: LANG=de_AT.UTF-8
After applying the following patch:
==
--- /usr/update-locale 2024-05-13 23:42:46.584127893 +0200
+++ /usr/sbin/update-locale 2024-05-13 23:40:25.160121142 +0200
@@ -88,7 +88,7 @@
{
# Check that this locale does exist
my $charset = `LANG= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE=
LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE=
LC_MEASUREMENT= LC_IDENTIFICATION= LC_ALL= $env locale charmap 2>&1`;
- die "*** $progname: Error: invalid locale settings: $env\n"
+ die "*** $progname: Error: invalid locale settings:
$env\n\n--$charset--\n"
if ($charset =~ m/Cannot set/);
# If LANGUAGE is set, its first value must be compatible with
LC_MESSAGES
if (defined $arg{LANGUAGE})
==
The output contains the actual information why the call to "locale chaarmap"
failed, thus making it possible to investigate why the call actually failed:
===
*** update-locale: Error: invalid locale settings: LANG=de_AT.UTF-8
--locale: Cannot set LC_CTYPE to default locale: No such file or
directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968
--
===
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages locales depends on:
ii debconf [debconf-2.0] 1.5.86
ii libc-bin 2.38-10
ii libc-l10n 2.38-10
locales recommends no packages.
locales suggests no packages.
-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "de_AT.UTF-8",
LC_MONETARY = "de_AT.UTF-8",
LC_CTYPE = "C.UTF-8",
LC_ADDRESS = "de_AT.UTF-8",
LC_TELEPHONE = "de_AT.UTF-8",
LC_NAME = "de_AT.UTF-8",
LC_MEASUREMENT = "de_AT.UTF-8",
LC_IDENTIFICATION = "de_AT.UTF-8",
LC_NUMERIC = "de_AT.UTF-8",
LC_PAPER = "de_AT.UTF-8",
LANG = "de_AT.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locales/locales_to_be_generated:
locales/default_environment_locale: None
[bts-link] source package src:glibc
# # bts-link upstream status pull for source package src:glibc # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # https://bts-link-team.pages.debian.net/bts-link/ # user debian-bts-l...@lists.debian.org # remote status report for #1070668 (http://bugs.debian.org/1070668) # Bug title: glibc: packages FTBFS caused by vector math library header on arm64 # * http://sourceware.org/bugzilla/show_bug.cgi?id=30909 # * remote status changed: (?) -> UNCONFIRMED usertags 1070668 + status-UNCONFIRMED thanks
Bug#1070490: libc6: Unpacking libc6:amd64 2.28-10+deb10u3 over 2.28-10+deb10u2 breaks system
There was one more problem. On machines having this symlink lrwxrwxrwx 1 root root 9 Apr 27 2021 /lib64 -> usr/lib64 Installing package libc6 2.28-10+deb10u3 removed /lib64/ld-linux-x86-64.so.2 before end of the installation (during some package installation scripts). So the installation won't end correctly. Ending with the same broken system as mentioned earlier. This could be fixed with nasty hack (no warranty guaranteed) perl -e 'mkdir "lib64.new"; symlink "/lib/x86_64-linux-gnu/ld-2.28.so", "lib64.new/ld-linux-x86-64.so.2"; symlink "/lib/x86_64-linux-gnu/libgcc_s.so.1", "lib64.new/libgcc_s.so.1"; unlink "/lib64"; rename "lib64.new", "/lib64"' (You can't use bash or it will gets broken after unlink /lib64) Hope this won't break anything else. Regards, Jan On Thu, 9 May 2024 10:30:36 +0200 Jan Krčmář wrote: > Thanks for your investigation. There is a buster running as a base system. > I didn't notice that the libcrypt1 does not come from buster earlier. > > This situation is probably caused by newer openafs-client/bullseye package, > which depends on libcrypt1/bullseye, which definitely breaks libc6/buster. > There were several bugs in the openafs some time ago, so the decision was > made to switch to the bullseye version, ending with weird distribution state. > > Removing the libcrypt1 package resolves the the problem. > > Cheers, > Jan > > On Mon, 6 May 2024 20:00:10 +0300 > Adrian Bunk wrote: > > > On Mon, May 06, 2024 at 05:37:37PM +0100, Adam D. Barratt wrote: > > > On Mon, 2024-05-06 at 13:02 +0200, Jan Krčmář wrote: > > > > Package: libc6 > > > > Version: 2.28-10+deb10u3 > > > > > > > > Upgrading the system (Debian 10/Buster) causes corrupted system, > > > > ending with kernel panic and unbootable system. > > > > > > > [...] > > > > The following packages will be upgraded: > > > > apt apt-transport-https apt-utils base-files ca-certificates > > > > > > The fact that APT is being upgraded here seems strange - APT hasn't > > > changed in buster for 3 years. What's your base system? > > > > There's also > > > > Unpacking base-files (10.3+deb10u13) over (10.3+deb10u5) ... > > > > That's outdated since September 2020. > > > > > > Unpacking libc6:amd64 (2.28-10+deb10u3) over (2.28-10+deb10u2) ... > > > > Replaced by files in installed package libcrypt1:amd64 (1:4.4.18-4) > > > > ... > > > > > > This, on the other hand, looks like you've done something odd to your > > > system. libcrypt1 doesn't exist until bullseye, so at some point you > > > have partially upgraded your base system. In conjunction with your pre- > > > upgrade system apparently having an APT version that's /older/ than the > > > one in buster, this feels odd. > > > > There is related nastiness with partial upgrades from buster to > > bullseye, see the last two items at [1]. > > > > I am not sure whether it is the root cause here, but it's at least > > plausible that not being able to have the Breaks in libcrypt1 causes > > problems for such partially upgraded systems. > > > > > Regards, > > > > > > Adam > > > > cu > > Adrian > > > > [1] > > https://tracker.debian.org/news/1239066/accepted-libxcrypt-14418-3-source-into-unstable/ > > smime.p7s Description: S/MIME cryptographic signature
