/lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

riku2015 · 2015-03-14 21:32:28

Very old (2011) EEE installation broken

[root@eeepc ~]# ls /boot -lah
total 19M
drwxr-xr-x  4 root root 1.0K Jun 24  2013 .
drwxr-xr-x 23 root root 4.0K Apr 27  2013 ..
drwxr-xr-x  2 root root 1.0K Nov  9  2011 grub
-rw-r--r--  1 root root  11M Feb 12  2012 initramfs-linux-fallback.img
-rw-r--r--  1 root root 2.3M Feb 12  2012 initramfs-linux.img
lrwxrwxrwx  1 root root   28 Feb 12  2012 kernel26-fallback.img -> initramfs-linux-fallback.img
lrwxrwxrwx  1 root root   19 Feb 12  2012 kernel26.img -> initramfs-linux.img
drwx------  2 root root  12K Jul 12  2011 lost+found
lrwxrwxrwx  1 root root   13 Feb 12  2012 vmlinuz26 -> vmlinuz-linux
-rw-r--r--  1 root root 2.8M Mar 25  2012 vmlinuzeee
-rw-r--r--  1 root root 2.9M Feb  7  2012 vmlinuz-linux
[root@eeepc ~]# uname -a
Linux eeepc 3.3.0eee #1 PREEMPT Sun Mar 25 15:26:58 ICT 2012 i686 Intel(R) Celeron(R) M processor 900MHz GenuineIntel GNU/Linux
[root@eeepc ~]# pacman
pacman: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)
pacman: /lib/libc.so.6: version `GLIBC_2.16' not found (required by /usr/lib/libarchive.so.13)
pacman: /lib/libc.so.6: version `GLIBC_2.16' not found (required by /usr/lib/libcurl.so.4)
pacman: /lib/libc.so.6: version `GLIBC_2.17' not found (required by /usr/lib/libcurl.so.4)

tried update pacman -S pacman it worked, then came this errors
any suggestions? is this fixable anymore?
cant use pacman so cant do anything

Last edited by riku2015 (2015-03-14 21:34:01)

graysky · 2015-03-14 21:36:05

Backup, format, and reinstall. It will be less work than attempting to salvage a 4-5 year-old build.

ewaller · 2015-03-14 21:39:11

First, as general advise, don't run pacman -S packageName. It will break things. We call that a partial update.
You should use pacman -Syu

That said, there have been a lot of changes to Arch in 4 years. An awful lot. Systemd, Grub2, Files system changes, Netctl, Package signing, and so on. If you want, you can go through the last four years of announcements and perform all of the required manual interventions in the order they were released.

If you have better things to do, I highly recommend a fresh install in this case.

riku2015 · 2015-03-14 21:39:56

alot of work to reinstall whole system but i guess i need to do it.. if there still eee build existing

edit: archlinux is fastest distro on eeepc what i came along..

Last edited by riku2015 (2015-03-14 21:42:13)

riku2015 · 2015-03-14 21:41:14

ewaller wrote:

First, as general advise, don't run pacman -S packageName. It will break things. We call that a partial update.
You should use pacman -Syu
That said, there have been a lot of changes to Arch in 4 years. An awful lot. Systemd, Grub2, Files system changes, Netctl, Package signing, and so on. If you want, you can go through the last four years of announcements and perform all of the required manual interventions in the order they were released.
If you have better things to do, I highly recommend a fresh install in this case.

i tried pacman -Syu first there was alot problems then somewhere they said to upgrade first pacman to get rid of problems, well on my case it broke everything

vostok4 · 2015-03-14 21:48:51

Boot with a USB key, and I'm sure you can fix it up with enough time. ldd is your friend, but it will be a lot of work. I've done it recently to a 3 year install and it was fun. Not trivial, but fun, and a good learning exercise.

ewaller · 2015-03-14 21:50:38

Before you reinstall, what is your partition scheme? If you have separate boot, root, and home partitions, all you really need to do is rebuild the root partition. Find out what you way want to re-install with pacman -Qetq

Pipe that to a file somewhere you can find it during a rebuild (on home, for example) and then do something like

pacman -Syu $(cat theNameOfTheFileWithThePackageNames)
Some things might break because of changes in how things are packaged. Fix the file by hand, lather, rinse, repeat...

Last edited by ewaller (2015-03-14 21:50:53)

Xyne · 2015-03-14 22:53:47

ewaller wrote:

That said, there have been a lot of changes to Arch in 4 years. An awful lot. Systemd, Grub2, Files system changes, Netctl, Package signing, and so on. If you want, you can go through the last four years of announcements and perform all of the required manual interventions in the order they were released.

I don't think that is even possible due to the absence of the intermediate packages. Re-installation is the only way.

It would be interesting to track such updates to provide a timeline that depicts when a full re-installation is necessary, e.g. given the upgrade path "foo-A -> foo-B -> foo-C", with "foo-A -> foo-C" being impossible or very difficult, any system still with foo-A is blocked from upgrade once foo-B is gone. I like the idea of a script that tells the user to just re-install because upgrading is f@#%$).

I've often thought that it would be very handy to have some sort of an upgrade snapshot system that would ensure that any system (fully upgraded at some point after the introduction of the snapshot system) could always be upgraded by stepping through all of the necessary intermediate steps (with pauses and instructions for manual intervention). It would be easy enough to track data base changes by committing the unpacked databases to Git. The same goes for the news items with instructions (which ideally should be part of some Pacman pre-upgrade message system).

Storing necessary intermediate packages would be more challenging. Not only would it require ever-increasing disk space but also implicit versioned dependency tracking given that many package depend on the concurrent version of their dependencies. The required disk space could be limited by limiting support to a fixed interval (e.g. 2 years).

Don't worry, I'm not actually suggesting this as I know that Arch is meant to be updated ASAP. Still, it wouldn't hurt if someone were to implement such a system unofficially.

ewaller · 2015-03-14 23:13:44

Xyne wrote:

I don't think that is even possible due to the absence of the intermediate packages. Re-installation is the only way.

Upon consideration, you are most certainly correct. The hypotheses is defensible -- a move from D to E may make it impossible to move from C to D. It is highly likely that this is the case for an Arch system neglected these last four years.

Last edited by ewaller (2015-03-14 23:14:23)

Scimmia · 2015-03-15 00:43:47

ewaller wrote:

First, as general advise, don't run pacman -S packageName. It will break things. We call that a partial update.
You should use pacman -Syu

I really wish people would stop saying this. pacman -S is not a partial update, pacman -Sy is. pacman -S is perfectly safe.

ewaller · 2015-03-15 01:07:50

Scimmia wrote:

I really wish people would stop saying this. pacman -S is not a partial update, pacman -Sy is. pacman -S is perfectly safe.

I am at one with my duality. As a moderator, I do my damnedest to keep people from hurting themselves by doing a partial upgrade. I full realize that -Sy is a partial upgrade; -S, on the other hand, can result in 404 errors if any time has elapsed between the last database update and full system update and the attempt at the lone package update.

Although -Syu has its own level of evil (unleashed when one does not read the news), it is the lesser of the two. And the path of least resistance.

apg · 2015-03-15 01:16:07

ewaller wrote:

Xyne wrote:
I don't think that is even possible due to the absence of the intermediate packages. Re-installation is the only way.
Upon consideration, you are most certainly correct. The hypotheses is defensible -- a move from D to E may make it impossible to move from C to D. It is highly likely that this is the case for an Arch system neglected these last four years.

I'm not recommending it, particularly in this case since the OP has already broken pacman, but it is entirely possible to update 4-5 year old systems, even without intermediate packages.

Scimmia wrote:

ewaller wrote:
First, as general advise, don't run pacman -S packageName. It will break things. We call that a partial update.
You should use pacman -Syu
I really wish people would stop saying this. pacman -S is not a partial update, pacman -Sy is. pacman -S is perfectly safe.

You are oversimplifying a little. Partial updates happen when you refresh the sync databases and sync a package without doing a full sysupgrade. Doing the sysupgrade at the same time as the db refresh is the commonly recommended solution, but doing the db refresh alone and running the sysupgrade later when syncing a new package is perfectly valid as well. In the latter case pacman -S could be a partial upgrade.

Scimmia · 2015-03-15 01:35:31

apg wrote:

I'm not recommending it, particularly in this case since the OP has already broken pacman, but it is entirely possible to update 4-5 year old systems, even without intermediate packages.

2011 puts it before /lib becoming a symlink, then moved from glibc to filesystem. This makes it very difficult, to the point of not being worth the effort in any way. Not impossible, but rewriting your system byte by byte isn't impossible, either, just extremely impractical.

apg wrote:

Scimmia wrote:
ewaller wrote:
First, as general advise, don't run pacman -S packageName. It will break things. We call that a partial update.
You should use pacman -Syu
I really wish people would stop saying this. pacman -S is not a partial update, pacman -Sy is. pacman -S is perfectly safe.
You are oversimplifying a little. Partial updates happen when you refresh the sync databases and sync a package without doing a full sysupgrade. Doing the sysupgrade at the same time as the db refresh is the commonly recommended solution, but doing the db refresh alone and running the sysupgrade later when syncing a new package is perfectly valid as well. In the latter case pacman -S could be a partial upgrade.

My point is that pacman -S is safe unless you've done something dumb before it, such as pacman -Sy or canceling an update. Advising against -S isn't doing the user any favors, IMO.

apg · 2015-03-15 03:28:32

Scimmia wrote:

apg wrote:
I'm not recommending it, particularly in this case since the OP has already broken pacman, but it is entirely possible to update 4-5 year old systems, even without intermediate packages.
2011 puts it before /lib becoming a symlink, then moved from glibc to filesystem. This makes it very difficult, to the point of not being worth the effort in any way. Not impossible, but rewriting your system byte by byte isn't impossible, either, just extremely impractical.

I don't want to get into this too much further because, as I said, I don't actually recommend this, but you are overselling the difficulty a bit there. The /lib and /bin symlink changes do not present a significant hurdle.

Scimmia wrote:

apg wrote:
Scimmia wrote:
I really wish people would stop saying this. pacman -S is not a partial update, pacman -Sy is. pacman -S is perfectly safe.
You are oversimplifying a little. Partial updates happen when you refresh the sync databases and sync a package without doing a full sysupgrade. Doing the sysupgrade at the same time as the db refresh is the commonly recommended solution, but doing the db refresh alone and running the sysupgrade later when syncing a new package is perfectly valid as well. In the latter case pacman -S could be a partial upgrade.
My point is that pacman -S is safe unless you've done something dumb before it, such as pacman -Sy or canceling an update. Advising against -S isn't doing the user any favors, IMO.

And my point is that pacman -Sy isn't necessarily dumb and pacman -Sy and pacman -S are equally (un)safe. Avoiding partial updates just means running --sysupgrade between --refresh and --sync'ing packages. It doesn't matter one bit whether the --sysupgrade happens at the same time as the --refresh or the --sync. The fact that -Syu is always recomended rather than -Su is pretty arbitrary. Always using -Su makes a bare -Sy perfectly safe in exactly the same way that you are talking about -Syu making a bare -S safe.

Allan · 2015-03-15 03:37:13

apg wrote:

The /lib and /bin symlink changes do not present a significant hurdle.

* To those who know what they are doing...

Why has no-one recommended using the Arch installer as a rescue disk and running "pacman -Syu -r /mnt/"?

Xyne · 2015-03-15 03:51:51

apg wrote:

The fact that -Syu is always recommended rather than -Su is pretty arbitrary. Always using -Su makes a bare -Sy perfectly safe in exactly the same way that you are talking about -Syu making a bare -S safe.

It's not arbitrary. System upgrades and new package installations are different operations. There is no reason to issue an upgrade every time a user tries to install a new package. It's redundant after the first upgrade following a refresh. On the other hand, updating the system immediately after a refresh ensures that all further operations are performed with an internally consistent set of packages.

-Syu ensures consistency for further sync operations
-Sy does not

ewaller · 2015-03-15 04:33:32

Unfortunately, we are now arguing how many angels can dance on the head of a pin. We are in violent agreement that partial updates are bad. We are also dealing with a thread that the rational approach is to throw in the towel and re install. Yes there are subtleties to using pacman; those of us bickering can probably work our ways out of self generated conundrums.

As much as I enjoy a good argument, I am after all, an engineer; lets leave the original poster with some good advise and lets not frighten a new member away by hijacking a thread so moderators, bug wranglers and devs can argue.

riku2015, good job at attracting some of the finest members of the Arch world to your first thread Welcome to Arch.

bigstiffy · 2015-05-06 00:10:57

Ran into this problem recently on an old thinkpad I haven't used in over a year.
Fixed mirrorlist by copying my config from my desktop, tried to update, it declared that pacman should be updated first and it ended up with the same error.
The fix was to restore the libarchive and pacman packages from /var/cache/pacman/pkg/ by extracting the last known working packages to the root directory.
This method should guarantee that you can use pacman again to do the actual upgrade, and make sure pacman gets updated afterwards.
Keep in mind that you will have to follow the article regarding the GnuPG update, you will need you refresh your keyring.

I do not know of any vulnerabilities caused by this method, any user that does can feel free to chime in.

Arch Linux

#1 2015-03-14 21:32:28

/lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

#2 2015-03-14 21:36:05

Re: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

#3 2015-03-14 21:39:11

Re: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

#4 2015-03-14 21:39:56

Re: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

#5 2015-03-14 21:41:14

Re: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

#6 2015-03-14 21:48:51

Re: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

#7 2015-03-14 21:50:38

Re: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

#8 2015-03-14 22:53:47

Re: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

#9 2015-03-14 23:13:44

Re: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

#10 2015-03-15 00:43:47

Re: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

#11 2015-03-15 01:07:50

Re: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

#12 2015-03-15 01:16:07

Re: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

#13 2015-03-15 01:35:31

Re: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

#14 2015-03-15 03:28:32

Re: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

#15 2015-03-15 03:37:13

Re: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

#16 2015-03-15 03:51:51

Re: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

#17 2015-03-15 04:33:32

Re: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

#18 2015-05-06 00:10:57

Re: /lib/libc.so.6: version `GLIBC_2.17' not found (required by pacman)

Board footer