heads up: /lib removal
 

Hey all,

Allan pushed glib 2.16-2 into [testing] which removes /lib as a
directory, replacing it with a symlink. A bit of advice...

- In the simplest case, the upgrade can be done as simply as:

pacman -Syu --ignore glibc && pacman -S glibc

- Since nothing is ever simple, if the above still fails on installation
of glibc (with a somewhat cryptic "/lib exists" error), you'll need to
figure out what's still in /lib that doesn't belong to glibc.
Generally this will end up being modules/. pacman -Qo /lib/* will
pinpoint what needs fixing/removing. Deal with anything that isn't
owned explicitly by glibc and complete the installation.

It shouldn't need to be said, but I'll mention it anyways:

Do. Not. Use. (the) --force. Obi-wan approves of this.

d

heads up: /lib removal
 

On Sat, Jul 07, 2012 at 13:25:29 -0400, Dave Reisner wrote:
> Hey all,
>
> Allan pushed glib 2.16-2 into [testing] which removes /lib as a
> directory, replacing it with a symlink. A bit of advice...
>
> - In the simplest case, the upgrade can be done as simply as:
>
> pacman -Syu --ignore glibc && pacman -S glibc
>
> - Since nothing is ever simple, if the above still fails on installation
> of glibc (with a somewhat cryptic "/lib exists" error), you'll need to
> figure out what's still in /lib that doesn't belong to glibc.
> Generally this will end up being modules/. pacman -Qo /lib/* will
> pinpoint what needs fixing/removing. Deal with anything that isn't
> owned explicitly by glibc and complete the installation.
>
> It shouldn't need to be said, but I'll mention it anyways:
>
> Do. Not. Use. (the) --force. Obi-wan approves of this.



Also, install busybox so you have statically linked tools to
fix your system if it breaks (specifically "rmdir" and "ln").


Geert


--
geert.hendrickx.be :: geert@hendrickx.be :: PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!

heads up: /lib removal
 

Allan pushed glib 2.16-2 into [testing] which removes /lib as a
directory, replacing it with a symlink. A bit of advice...

- In the simplest case, the upgrade can be done as simply as:

pacman -Syu --ignore glibc && pacman -S glibc

- Since nothing is ever simple, if the above still fails on installation
of glibc (with a somewhat cryptic "/lib exists" error),


I have an older Arch-testing system in a virtual machine, which I don't
think I can upgrade very easily, since it requires a newer glibc (has
2.13-5 now) to upgrade a lot of the packages that have files in /lib


Also it asks me about a pacman update that also can't be done because of
a glibc dependency.


I wonder if it be possible to upgrade Arch installed from the
2011.08.19 release?




--
дамјан

heads up: /lib removal
 

Say no to updating pacman first and read the news. If you choose to
reinstall use the net iso or core-remote it will install only up to date
packages, do not use the core iso's cache.
On Jul 7, 2012 9:27 PM, "Damjan" <gdamjan@gmail.com> wrote:

> Allan pushed glib 2.16-2 into [testing] which removes /lib as a
>> directory, replacing it with a symlink. A bit of advice...
>>
>> - In the simplest case, the upgrade can be done as simply as:
>>
>> pacman -Syu --ignore glibc && pacman -S glibc
>>
>> - Since nothing is ever simple, if the above still fails on installation
>> of glibc (with a somewhat cryptic "/lib exists" error),
>>
>
> I have an older Arch-testing system in a virtual machine, which I don't
> think I can upgrade very easily, since it requires a newer glibc (has
> 2.13-5 now) to upgrade a lot of the packages that have files in /lib
>
> Also it asks me about a pacman update that also can't be done because of a
> glibc dependency.
>
> I wonder if it be possible to upgrade Arch installed from the 2011.08.19
> release?
>
>
>
> --
> дамјан
>
>
>

heads up: /lib removal
 

Say no to updating pacman first and read the news. If you choose to
reinstall use the net iso or core-remote it will install only up to date
packages, do not use the core iso's cache.


I did try saying no to pacman, but that didn't help.
Then I installed core/glibc 2.16 first, it did work fine, then I could
upgrade

pacman and almost everything. There were only 2-3 packages that I had to
remove by hand (heimdal is one I remember) and reinstall later.


--
дамјан

heads up: /lib removal
 

On 08/07/12 03:25, Dave Reisner wrote:
> Hey all,
>
> Allan pushed glib 2.16-2 into [testing] which removes /lib as a
> directory, replacing it with a symlink. A bit of advice...
>
> - In the simplest case, the upgrade can be done as simply as:
>
> pacman -Syu --ignore glibc && pacman -S glibc
>
> - Since nothing is ever simple, if the above still fails on installation
> of glibc (with a somewhat cryptic "/lib exists" error), you'll need to
> figure out what's still in /lib that doesn't belong to glibc.
> Generally this will end up being modules/. pacman -Qo /lib/* will
> pinpoint what needs fixing/removing. Deal with anything that isn't
> owned explicitly by glibc and complete the installation.
>
> It shouldn't need to be said, but I'll mention it anyways:
>
> Do. Not. Use. (the) --force. Obi-wan approves of this.
>


So... this upgrade has been more fun than expected. At the moment
there appears to a "limitation" in pacman so I would recommend updating
like:

Step 0) open a root shell - this can be used to recover if anything goes
wrong

Step 1) run:
pacman -Qo /lib/*
Deal with (either via updating from the repo or rebuilding) anything not
owned by glibc

Step 2) run:
find /var/lib/pacman/local -name files | xargs grep "^lib/$"
This should only return glibc. If not, rebuild those packages not to
own the /lib directory

Step 3) pacman -Syu


If something goes wrong (you will see a message like "call to execv
failed"), use your root shell to do:
/usr/lib/ld-2.16.so /bin/rm -r /lib
/usr/lib/ld-2.16.so /bin/ln -s usr/lib /lib



Note that all this should have been unnecessary and the instructions
given by falconindy should have been enough. But there appears to be a
genuine pacman bug in conflict checking where it ignores other packages
owning a directory when it checks if it can be removed. Hopefully this
can be fixed soon... There may be something else going on with here
too, but we are unsure as of yet.

Note that pacman will detect when there are files in /lib that do not
belong to glibc before upgrade, just not if some other package owns /lib
only (with no files). So all the cases I tested (folder and files in
/lib, both owned and unowned by packages) do not result in the error.

Allan

heads up: /lib removal
 

> So... this upgrade has been more fun than expected. At the moment
> there appears to a "limitation" in pacman so I would recommend updating
> like:
>
> Step 0) open a root shell - this can be used to recover if anything goes
> wrong
>
> Step 1) run:
> pacman -Qo /lib/*
> Deal with (either via updating from the repo or rebuilding) anything not
> owned by glibc
>
> Step 2) run:
> find /var/lib/pacman/local -name files | xargs grep "^lib/$"
> This should only return glibc. If not, rebuild those packages not to
> own the /lib directory
>
> Step 3) pacman -Syu
>
>
> If something goes wrong (you will see a message like "call to execv
> failed"), use your root shell to do:
> /usr/lib/ld-2.16.so /bin/rm -r /lib
> /usr/lib/ld-2.16.so /bin/ln -s usr/lib /lib
>
>
>
> Note that all this should have been unnecessary and the instructions
> given by falconindy should have been enough. But there appears to be a
> genuine pacman bug in conflict checking where it ignores other packages
> owning a directory when it checks if it can be removed. Hopefully this
> can be fixed soon... There may be something else going on with here
> too, but we are unsure as of yet.
>
> Note that pacman will detect when there are files in /lib that do not
> belong to glibc before upgrade, just not if some other package owns /lib
> only (with no files). So all the cases I tested (folder and files in
> /lib, both owned and unowned by packages) do not result in the error.
>
> Allan
>
>

From the pacman -Qo /lib/* command I discovered a module directory
with some left over kernels modules. I checked /usr/lib/modules and
had the modules for my current kernels so I did the stupid thing and
sudo rm -Rvf /lib/modules. Don't jump yet, because Allan's procedure
worked perfectly after that.

Actually for such a massive upgrade I think things went well.

Myra

--
Life's fun when your sick and psychotic!

heads up: /lib removal
 

On za, 2012-07-07 at 13:25 -0400, Dave Reisner wrote:
> Hey all,
>
> Allan pushed glib 2.16-2 into [testing] which removes /lib as a
> directory, replacing it with a symlink. A bit of advice...
>
> - In the simplest case, the upgrade can be done as simply as:
>
> pacman -Syu --ignore glibc && pacman -S glibc
>
> - Since nothing is ever simple, if the above still fails on installation
> of glibc (with a somewhat cryptic "/lib exists" error), you'll need to
> figure out what's still in /lib that doesn't belong to glibc.
> Generally this will end up being modules/. pacman -Qo /lib/* will
> pinpoint what needs fixing/removing. Deal with anything that isn't
> owned explicitly by glibc and complete the installation.
>
> It shouldn't need to be said, but I'll mention it anyways:
>
> Do. Not. Use. (the) --force. Obi-wan approves of this.

I didn't need --force to fuck up my system. When I upgraded like above,
I got file conflicts because of some depmod files in /lib/modules,
combined with an old ancient udev-compat package. I removed udev-compat
and the files, but there were still some empty directories in /lib.
When running pacman -S glibc, pacman didn't detect any file conflicts,
installed the new glibc, told me that it could not extract /lib and then
left my system in a state that couldn't execute a single command
anymore.

heads up: /lib removal
 

On 08/07/12 23:36, Jan de Groot wrote:
> On za, 2012-07-07 at 13:25 -0400, Dave Reisner wrote:
>> Hey all,
>>
>> Allan pushed glib 2.16-2 into [testing] which removes /lib as a
>> directory, replacing it with a symlink. A bit of advice...
>>
>> - In the simplest case, the upgrade can be done as simply as:
>>
>> pacman -Syu --ignore glibc && pacman -S glibc
>>
>> - Since nothing is ever simple, if the above still fails on installation
>> of glibc (with a somewhat cryptic "/lib exists" error), you'll need to
>> figure out what's still in /lib that doesn't belong to glibc.
>> Generally this will end up being modules/. pacman -Qo /lib/* will
>> pinpoint what needs fixing/removing. Deal with anything that isn't
>> owned explicitly by glibc and complete the installation.
>>
>> It shouldn't need to be said, but I'll mention it anyways:
>>
>> Do. Not. Use. (the) --force. Obi-wan approves of this.
>
> I didn't need --force to fuck up my system. When I upgraded like above,
> I got file conflicts because of some depmod files in /lib/modules,
> combined with an old ancient udev-compat package. I removed udev-compat
> and the files, but there were still some empty directories in /lib.
> When running pacman -S glibc, pacman didn't detect any file conflicts,
> installed the new glibc, told me that it could not extract /lib and then
> left my system in a state that couldn't execute a single command
> anymore.
>

Thanks, that was a case I had missed in patching pacman to detect these
conflicts early.

These two patches should catch all issues noted so far during the
conflict checking stage and prevent these rouge extractions:
http://mailman.archlinux.org/pipermail/pacman-dev/2012-July/015678.html
http://mailman.archlinux.org/pipermail/pacman-dev/2012-July/015679.html

Allan

heads up: /lib removal
 

On 07/07/2012 07:28 PM, Geert Hendrickx wrote:

On Sat, Jul 07, 2012 at 13:25:29 -0400, Dave Reisner wrote:

Hey all,

Allan pushed glib 2.16-2 into [testing] which removes /lib as a
directory, replacing it with a symlink. A bit of advice...

- In the simplest case, the upgrade can be done as simply as:

pacman -Syu --ignore glibc && pacman -S glibc

- Since nothing is ever simple, if the above still fails on installation
of glibc (with a somewhat cryptic "/lib exists" error), you'll need to
figure out what's still in /lib that doesn't belong to glibc.
Generally this will end up being modules/. pacman -Qo /lib/* will
pinpoint what needs fixing/removing. Deal with anything that isn't
owned explicitly by glibc and complete the installation.

It shouldn't need to be said, but I'll mention it anyways:

Do. Not. Use. (the) --force. Obi-wan approves of this.



Also, install busybox so you have statically linked tools to
fix your system if it breaks (specifically "rmdir" and "ln").


Geert


Just wanted to give a warm thank for all hints, as my upgrade to glibc
2.16-2 went very smooth by following strictly the descibes steps.

Great help from the community as always.

Regards.