|
|
|
|
|
|
|
|
|
|
xen-users
Re: [Xen-users] Xen 4.1.1 DomU Partition table disappearing
On 6 July 2011 23:37, Hans de Bruin <jmdebruin@xxxxxxxxx> wrote:
>> Hello,
>> Don't have a solution here, but I have seen the same problem on
>> one of my DomUs. Maybe if we compare our setups we'd find the cause.
>> 1. Does your DomU run OpenSuSE (11.4)?
>
> 64 bit slackware 1337
>
>> 2. Is your DomU PV or HVM?
>
> My atom is not capable of hvm
>
>> 3. If HVM, are you running PV on HVM drivers?
>> 4. Are you using LVM for your VM images?
>
> yes, the volume group is on top of a linux software mirror
>
>> 5. Are you using LVM in your VM?
>
> no
>
>> 6. Have you tried using a separate distribution?
>
> not yet
>
>> 7. Have you tried creating another DomU to see if it exhibits the
>> same problem?
>
> not yet
>
>> 8. Have you tried a different Dom0 kernel/xen?
>
> not yet
>
>> Basically I remember this problem came up with one of my
>> xen/Dom0/DomU combinations, but didn't have the chance to find out the
>> root cause before moving on to another combination.
>>
>
> I have done some tests using only the setup initrd from my slackware64 dvd.
> I filled another lvm block device with a lot of FF's, and put it in front in
> the vm's disk config. so the troubled partition table is on block device
> /dev/xvdb. After shutdown the FF's on the first disk where all in tact, the
> partition table on de second disk was destroyed. So much for a workaround.
>
> So I went back to the normal configuration and tried to narrow down the
> exact time of destruction. To see the ammount of damage I filled the first
> 1000 512 byte blocks with FF's and recreated the parition table. There are
> two primary partitions on the disk. 1G xvda1 for swap and xvda2 for the rest
> of the 16GB disk. What clears the partition table is:
>
> mount /dev/xvda2 /mnt
>
> some modification of /mnt like creating a directoy, or accessing a directory
> for the first time that day.
>
> And then the killer: sync
>
> So now there is a question number 9. have I tried differed file systems?
>
> not yet
>
> Some of the damage that is done:
>
> root@luna:/home/hans# hexdump -n 8000 /dev/vg4/temp
> 0000000 3bc0 9839 0000 0200 0000 2001 0000 0000
> 0000010 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0000030 0000 0000 134e 9024 8336 8f46 0000 0000
> 0000040 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0001000 ffff ffff ffff ffff ffff ffff ffff ffff
> *
>
> root@luna:/home/hans# hexdump -n 8000 /dev/vg4/temp
> 0000000 3bc0 9839 0000 0200 0000 2501 0000 0000
> 0000010 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0000030 0000 0000 134e 6b28 2b2a f6fc 0000 0000
> 0000040 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0001000 ffff ffff ffff ffff ffff ffff ffff ffff
> *
> 0001f40
>
> So the first 0x01000 bytes get overwritten. That is the size of one memory
> page. It does not look like a ext4 supper block.
>
> --
> Hans
>
I guess I won't be of much help without digging too deeply (just
achieved perfect setup on my machines, don't want to mess it up). :-/
Though personally I'd recommend upgrading your distribution first,
followed by xen and finally the Dom0 kernel, as I have the exact same
problem as you, but one of the above solved it for me.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
|
|