Was just doing an update, and saw glibc-2.22-4. Updating that gave the following error:- [2015-10-12 07:43] [ALPM-SCRIPTLET] bash: loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))' failed. This totally hosed my system, so I had to download the ISO and downgrade. However I can't seem to find glibc-2.22-4 anymore, not even on www.archlinux.org. Did I have a compromised mirror, or was it simply a mistake in pushing? For reference, I provide my top-most mirror (generated from reflector months ago) in case that's useful:- Server = http://archlinux.polymorf.fr/$repo/os/$arch
No 2.22-4 available here. Mirrors: Server = http://archlinux.limun.org/$repo/os/$arch Server = http://mirror.de.leaseweb.net/archlinux/$repo/os/$arch Server = http://ftp.tuxdroid.org/archlinux/$repo/os/$arch Server =http://archlinux.surlyjake.com/archlinux/$repo/os/$arch [rocketmouse@archlinux ~]$ pacman -Si glibc | grep Ver Version : 2.22-3 [rocketmouse@archlinux ~]$ pacman -Q glibc glibc 2.22-3 [rocketmouse@archlinux ~]$ downgrade glibc | grep 22 1) glibc-2.22-3-x86_64.pkg.tar.xz (local) 2) glibc-2.22-3-x86_64.pkg.tar.xz (remote) 3) glibc-2.22-1-x86_64.pkg.tar.xz (remote) ^C [rocketmouse@archlinux ~]$ grep pkgrel /var/abs/core/glibc/PKGBUILD pkgrel=3 Regards, Ralf
On Mon, Oct 12, 2015 at 3:00 AM, Oon-Ee Ng
Was just doing an update, and saw glibc-2.22-4. Updating that gave the following error:- [2015-10-12 07:43] [ALPM-SCRIPTLET] bash: loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))' failed.
This totally hosed my system, so I had to download the ISO and downgrade.
However I can't seem to find glibc-2.22-4 anymore, not even on www.archlinux.org. Did I have a compromised mirror, or was it simply a mistake in pushing? For reference, I provide my top-most mirror (generated from reflector months ago) in case that's useful:-
It was in [testing], briefly, but got pulled after an hour. https://projects.archlinux.org/svntogit/packages.git/log/?h=packages/glibc
On Mon, Oct 12, 2015 at 09:00:38AM +0800, Oon-Ee Ng wrote:
Was just doing an update, and saw glibc-2.22-4. Updating that gave the following error:- [2015-10-12 07:43] [ALPM-SCRIPTLET] bash: loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))' failed.
This totally hosed my system, so I had to download the ISO and downgrade.
However I can't seem to find glibc-2.22-4 anymore, not even on www.archlinux.org. Did I have a compromised mirror, or was it simply a mistake in pushing? For reference, I provide my top-most mirror (generated from reflector months ago) in case that's useful:-
I had the same problem. I had a fun time fixing that by scp'ing a staically linked busybox over using another system, decompressing the old package with that, using machinectl shell to gain root access, and then running pacman with LD_LIBRARY_PATH to where I decompressed the package to restore it. But then, I didn't even have to reboot! Note to self (and others): keep a statically linked suid root copy of busybox handy.
Sun, 11 Oct 2015 19:17:53 -0700
"Ian D. Scott"
I had a fun time fixing that by scp'ing a staically linked busybox over using another system, decompressing the old package with that, using machinectl shell to gain root access, and then running pacman with LD_LIBRARY_PATH to where I decompressed the package to restore it. But then, I didn't even have to reboot!
Note to self (and others): keep a statically linked suid root copy of busybox handy.
Nice one! +1 I got unlucky as well but as it's just my old, not-so-important notebook and I had the archiso USB key within arm's reach, I simply pulled the plug. Perfect opportunity to plug this old DynDNS host of mine: http://allan.broke-it.net SCNR ;-) --byte
On Mon, Oct 12, 2015 at 11:02 AM, Jens Adam
Sun, 11 Oct 2015 19:17:53 -0700 "Ian D. Scott"
: I had a fun time fixing that by scp'ing a staically linked busybox over using another system, decompressing the old package with that, using machinectl shell to gain root access, and then running pacman with LD_LIBRARY_PATH to where I decompressed the package to restore it. But then, I didn't even have to reboot!
Note to self (and others): keep a statically linked suid root copy of busybox handy.
Nice one! +1
I got unlucky as well but as it's just my old, not-so-important notebook and I had the archiso USB key within arm's reach, I simply pulled the plug.
Perfect opportunity to plug this old DynDNS host of mine:
SCNR ;-)
--byte
I KNEW it =) This sort of thing only seems to happen after I happen to reformat the last archISO USB drive to copy a slightly larger file from one place the another....
On Sun, 11 Oct 2015 19:17:53 -0700 "Ian D. Scott"
Note to self (and others): keep a statically linked suid root copy of busybox handy.
Busybox in the repo is statically linked, but you should really have a usb stick or PXE boot with a somewhat recent ISO because in many situations even busybox won't help you. Nice to keep it around anyway.
On 12-10-2015 09:49, Florian Pritz wrote:
On Sun, 11 Oct 2015 19:17:53 -0700 "Ian D. Scott"
wrote: Note to self (and others): keep a statically linked suid root copy of busybox handy.
Busybox in the repo is statically linked, but you should really have a usb stick or PXE boot with a somewhat recent ISO because in many situations even busybox won't help you. Nice to keep it around anyway.
I assume the "best" course of action in these cases is to use pacman with --root and give it the path to the hosed / right? -- Mauro Santos
On Oct 12, 2015 11:01 PM, "Mauro Santos"
On 12-10-2015 09:49, Florian Pritz wrote:
On Sun, 11 Oct 2015 19:17:53 -0700 "Ian D. Scott"
wrote: Note to self (and others): keep a statically linked suid root copy of busybox handy.
Busybox in the repo is statically linked, but you should really have a usb stick or PXE boot with a somewhat recent ISO because in many situations even busybox won't help you. Nice to keep it around anyway.
I assume the "best" course of action in these cases is to use pacman with --root and give it the path to the hosed / right?
I wouldn't say it's the best in all scenarios, but it's a sure way of fixing the problem if you didn't happen to have a statically linked suid busybox ready.
-- Mauro Santos
participants (8)
-
Andrew Chen
-
Florian Pritz
-
Ian D. Scott
-
Jan Alexander Steffens
-
Jens Adam
-
Mauro Santos
-
Oon-Ee Ng
-
Ralf Mardorf