Ed W wrote:
> On 17/10/2010 13:47, Adrian Reyer wrote:
>> Hi Gordan,
>>
>> On Sun, Oct 17, 2010 at 12:29:07PM +0100, Gordan Bobic wrote:
>>> RHEL6 as the host/guest). If one set was 32-bit and the other
>>> 64-bit, the sizes would be different.
>> I take it, checksums are the same as well?
>> What about a broken linker? Can you exec /lib/ld-linux-x86-64.so.2
>> (Debian filename, might be named slightly different at your place)?
>> That had been the issue with a similar effect without unification on a
>> 32bit system I ran 2 years back. Nothing seemed to be exectutable
>> anymore as a result.
>>
>
> Yeah, funnily I just (yesterday) managed to recreate something very
> similar in a chroot where I completely messed up a libc update... I
> didn't debug it too much, but it was quite peculiar in that every
> executable suddenly stopped claiming to be an executable. They even
> looked wierd from another 32bit chroot mounting the dead chroot...
>
> I didn't study it too much, but definitely things go a bit peculiar if
> you mess up libc... Curious
I'm seeing this messing up libc. I am checking all the files from the
host. The guests aren't even running when I'm hashifying. The steps are
quite literally:
1) Have a working vserver chroot
2) Backup up the files that will be trashed, /bin, /sbin, /lib ...
3) vserver <guest_name> hashify
4) Reboot. For some reason the hashified files will at this point be
stuck in caches and cannot be flushed out.
# echo 3 > /proc/sys/vm/drop_caches
doesn't reduce caches to below about 350MB for me after hashifying, even
though before hashifying it reduced the cache memory usage down to 10-15MB.
5) Once the machine comes back up, try "file" and "md5" on the files in
the hashified guest and compare them to the files you backed up before
hashifying. The hashified files in the guest seem to have random content
in them, that appears to have come from them getting mapped to wrong
blocks on the disk.
Gordan
Received on Wed Oct 20 14:44:28 2010