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 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
