Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
On Wed, Aug 10, 2011 at 02:50:46PM -0500, Jonathan Nieder wrote:
> Hi again,
>
> Sorry for the lack of clarity.
>
> Sven Joachim wrote:
> > On 2011-08-10 20:47 +0200, Jonathan Nieder wrote:
>
> >> 3) ln -s lib64.real /lib64.eglibc-tmp
> >> 4) mv -f /lib64.eglibc-tmp /lib64
> >
> > Now you have a broken lib/lib64.eglibc.tmp symlink which is not quite
> > what you want. ;-) It would make more sense to use /lib64.eglibc-tmp/
> > as source, but this seems to fail with ENOTDIR.
>
> Yes, this is what I get for thinking in terms of system calls instead
> of reading the manpage.
>
> mv -fT /lib64.eglibc-tmp /lib64
>
> should work.
No it doesn't work for symlinks.
> >> 5) clean up on next reboot
> >
> > Not sure what you mean with that. Could you elaborate?
>
> Well, I handwaved it, but the problem is that there is no way to
> atomically replace a symlink by a directory, and it would be best if
> this is atomic to avoid disrupting applications running concurrently.
> How to address that? Well, just do the hard part:
>
> rm /lib64
> mv /lib64.real /lib64
>
> when nothing is running concurrently, in early boot.
The problem is that your never reboot chroots.
> Well, that is what I just wrote, but there is a little handwaving
> involved: which initscript, exactly? (The initramfs would be the
> easy place to do that kind of thing, but not everyone uses an
> initramfs.) And how to prevent this from running concurrently with
> another script? I don't have a good answer for that.
>
> One answer would be to make a script for the sysadmin to run to
> take care of it and just leave a /lib64 -> /lib64.real symlink until
> that's done.
>
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: