[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |