Re: glibc 2.7-3 MIGRATED to testing causes system to stop starting new programs
Hello glibc maintainers, I managed to reboot the VPS in repair mode. I see a lot of messages like in /var/log/syslog (example from dovecot, but others programs give errors too): Dec 8 21:18:28 foobar dovecot: child 21837 (login) returned error 127 Dec 8 21:19:28 foobar dovecot: imap-login: imap-login: error while loading shared libraries: /lib/libc.so.6: file too short I manually installed glibc 2.7-4 (libc6_2.7-4_i386.deb) and will reboot after the backup is finished. Is there anything else I can check to find out what happened? On Sun, Dec 09, 2007 at 01:08:17AM +0100, Aurelien Jarno wrote: I guess you are using a RedHat kernel version 2.6.9-5.ELsmp. This kernel is unsupported due to broken RedHat specific patches. Please ask your VPS provider for an upgrade to a non RedHat kernel or a more recent RedHat kernel. Is there a way to find out the kernel name/type of the VPS host system. My 'uname -a' gives: Linux foobar 2.6.9-023stab043.1-smp #1 SMP Mon Mar 5 16:38:22 MSK 2007 i686 GNU/Linux Regards, Pieter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc 2.7-3 MIGRATED to testing causes system to stop starting new programs
On Sun, Dec 09, 2007 at 01:03:01PM +0100, Pierre Habouzit wrote: I manually installed glibc 2.7-4 (libc6_2.7-4_i386.deb) and will reboot after the backup is finished. No that won't work you have to go back to a 2.6 one. I'm restoring a backup. When everything is fixed I'll update my Debian 4.0 testing distribution when my VPS host kernel is compatible with glibc 2.7-4 or later. Is there anything else I can check to find out what happened? The kernel you run on has a custom redhat patch that conflicts with the new O_CLOEXEC feature. Either they change the kernel, or you keep a pre 2.6. I assume you mean pre 2.7 (being 2.6). According to https://lwn.net/Articles/236843/ the O_CLOEXEC flag appeared in kernel 2.6.23. I called my VPS provider (Strato), and according to the tech guy they use Debian as host OS. I logged a service request to be sure. My 'uname -a' lists: Linux foobar 2.6.9-023stab043.1-smp #1 SMP Mon Mar 5 16:38:22 MSK 2007 i686 GNU/Linux Can anybody help me find the kernel patch I should ask to be installed (I doubt they do that in short time with a big hosting company like Strato). Can anybody tell me how I can make sure my system doesn't get crashed the next time I do 'apt-get upgrade'? Or should the new patch in glibc-4 prevent problems automatically? Regards, Pieter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
More on additional glibc test to prevent Debian on Redhat+TUX VPS users to get in troubles when upgrading to glibc 2.7-3.
Can anybody help me find the kernel patch I should ask to be installed (I doubt they do that in short time with a big hosting company like Strato). actually it's a patch to remove (it's called the TUX patch afaict). I found a broader description of it at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454638 I now understand that the problem is caused by the non-standard RHEL kernel my VPS-provider (Strato) uses. Debian maintainers blame the (non-standard) Redhat+TUX kernel. Redhat blames the use of a non-standard TUX patch. The VPS software people who used this kernel (probably Virtuozzo) should fix this permanently by not using the TUX patch, or creating another fix. I agree with Comment #5 from John Salmon at the Redhat glibc tracker at http://sourceware.org/bugzilla/show_bug.cgi?id=5227#c5 in which he states: I see no reason to ignore a straightforward test, modeled after the other tests in dirent/, that passes when glibc is working correctly and that fails on some systems which happen to be unsupported? The test code for finding failing on a non-standard kernel host system, can be found in the Redhat bug tracker. I hope Debian maintainers can re-open Bug#454638 and create a test that prevents these problems, so that others don't have to run into these nasty issues like I did. Please promote the additional test to the testing distribution. My problems began after [2007-12-05] when glibc 2.7-3 was MIGRATED to testing. I'll hold libc6 upgrades in my Debian testing distribution next time I'll upgrade my VPS. I first need to wait until my restore is done. I didn't expect a restore of a big VPS hosting company to take up to 24 hours. Regards, Pieter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
glibc 2.7-3 MIGRATED to testing causes system to stop starting new programs
Hello GNU libc maitainers,
I don't now if this is a new bug, or an addition to bug
#454266 or #454557, so I'm mailing the maintainers.
Today I ran into severe problems after doing a 'apt-get update apt-get
upgrade'. My previous full update and upgrade was on 2007-12-05 20:25.
See http://gewis.nl/~pieterb/tmp/dpkg.log for the tail of my dpkg.log.
There were problems with upgrading libc to 2.7-3 and after that I could not
start a lot of programs anymore. I tried installing libc 2.7-4 manualy with
dpkg, but I couldn't get it done.
I'll try to recover /var/lib/{apt,dpkg} and /lib from backup tommorow, but I
think it would be good to either:
- upgrade glibc to 2.7-4, or
- downgrade glibc 2.6 in testing?
to prevent other people like me from serious messing up their system.
I tried running 'dpkg -l libc6-i686' as suggested in Bug#454557 but it
didn't work.
If there is anything I can do to help fight these problems please tell me.
Regards,
Pieter
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc 2.7-3 MIGRATED to testing causes system to stop starting new programs
On Sat, Dec 08, 2007 at 06:04:54PM -0500, Clint Adams wrote: On Sat, Dec 08, 2007 at 11:33:47PM +0100, PieterB wrote: There were problems with upgrading libc to 2.7-3 and after that I could not start a lot of programs anymore. I tried installing libc 2.7-4 manualy with dpkg, but I couldn't get it done. What does could not start a lot of programs anymore mean? I will elaborate a bit more. The systems seems not able to read/access directory on the disk. For example: # dpkg -l libc6-i686 dpkg-query: cannot scan updates directory `/var/lib/dpkg/updates/': Unknown error 530 foobar:/var/log# apt-get update E: Unable to read /etc/apt/apt.conf.d/ - opendir (530 Unknown error 530) # dpkg -i libc6_2.7-4_i386.deb dpkg: cannot scan updates directory `/var/lib/dpkg/updates/': Unknown error 530 I can still access the directories with 'cd', but accessing the file index (with shell 'ls' or programs), does not seem to work. I'm quite sure there is nothing wrong with the disk (it's a RAID-1 SAN on a VPS). The webserver fortuately just works fine for static pages. I'll try to reboot tommorow. I can't access the machine with ssh. I get: ssh_exchange_identification: Connection closed by remote host One of the upgrades on http://gewis.nl/~pieterb/tmp/dpkg.log caused serious problems. Is it possible to promote glibc 2.7-4 to testing to prevent stuff like this happening. PTS currently says Too young, only 1 of 10 days old Regards, Pieter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
