[Nottingham] Gentoo experts: emerge file collisions!?

[Martin]

OK, so a few moons later and... The reckless step is being attempted... 
Backups have been made!

A few bits inlined:

Martin wrote:
> Richard Ward wrote:
>> Martin wrote:
>>
>>> So... What is the procedure to complete the update without breaking the 
>>> system the update is running on?
>>>
>>> (Or is this just a case of over-caution in portage?)
>>>
>>> Cheers,
>>> Martin
>>>
>> Ok, I think the following should work, but *please* either backup your 
>> root partition or make a copy and try it in a chroot on the copy first, 
>> obviously a system with a broken glibc is going to be a huge PITA.
> 
> I thought that might be the case... Backups done.
> 
> 
>> It may make it easier to first build a binary package for glibc, that 
>> way you won't have to recompile every time you try something, and you'll 
>> have a convenient backup of all the files that glibc wants:
>>
>> emerge glibc --buildpkgonly
> 
> That ran smoothly finishing with:
> 
>  >>> Completed installing glibc-2.9_p20081201-r2 into 
> /var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/image/
> 
> ecompressdir: bzip2 -9 /usr/share/man
> ecompressdir: bzip2 -9 /usr/share/info
> making executable: usr/lib/libc.so
> making executable: usr/lib/libpthread.so
>  >>> Done.
> 
> 
>> Then do `ls $PKGDIR' to check the file is there. next time you want to 
>> try and install this glibc version you can use:
> 
> Well... $PKGDIR isn't set and there's nothing in "/var/tmp/portage". 
> Nothing in "/var/tmp/binpkgs" either :-(
> 
> Or should I be looking in some other default location?
> 
> OK... So I've now set in /etc/make.conf:
> 
> PKGDIR="/var/tmp/binpkgs"
> 
> and I'm rerunning the "emerge glibc --buildpkgonly". See if I get the 
> binaries this time.

That ran fine.


>> emerge -K glibc

That gives a:

  * Package 'sys-libs/glibc-2.9_p20081201-r2' NOT merged due to file
  * collisions. If necessary, refer to your elog messages for the whole
  * content of the above message.


>> The best thing to do is probably to just temporarily disable collision 
>> detection:
>>
>> COLLISION_IGNORE="/" emerge glibc
>>
>> With any luck thats all it will take, check stuff is working, re-emerge 
>> stuff to use the new glibc, and move on.

I actually used:

COLLISION_IGNORE="/" ; emerge glibc

and it soon dived into a whole big load of compiling. Wouldn't it take 
advantage of the existing compiled binary packages or is a "-K" needed 
still?


Hopefully, the following bits won't be needed!

>> If, however, vital files turn up missing/broken, you can just `emerge -k 
>> glibc' again afterwards, or if that doesn't work due to missing files 
>> just mount your system in a live distro or similar, untar the package 
>> that emerge built, and dump the files in their correct locations.
>>
>> Once thats done it may be an idea to re-emerge your whole system, 
>> starting with gcc.
>>
>> I you get problems of vital utilities breaking the process half way 
>> through because they won't work with the new libc or without the missing 
>> files, you can start the process again but first re-emerge them with 
>> USE="STATIC" so that they will no longer need the shared libraries (eg 
>> tar, wget).
>>
>> Keep us posted on how it goes, and do make a backup first!

I think this is one to sleep on to see if is still working come the morning!


>> P.S.
>> I've never used one, but there are such things as overlay filesystems, 
>> where you mount a file system read-only, then mount another one 'on top' 
>> of it, so it appears from your point ov view you are modifying the 
>> original system, but when you get rid of the overlay the original is 
>> unmodified. It strikes me this would be perfect for doing what you are 
>> trying to do, and would save all the time it takes to to a backup.
> 
> LVM or filesystem snapshots (or overlays) are indeed rather nice and 
> definitely the way to go!

Indeed so. I'm playing with LVM and snapshots to take pristine backups 
that can also then be verified byte-for-byte. Not tried a writeable 
snapshot yet for experimenting. Roll on btrfs soon with it's 
filesystem-based versioning!


> Still not sure if unionfs is good or just good for confusion...

Used it once and it certainly causes confusion!!


>> P.P.S
>> Make a backup first! :)
> 
> Very wise :-)

Cheers,
Martin


-- 
----------------
Martin Lomas
martin at ml1.co.uk
----------------