On Thu, 30 May 2013, Jean-Yves Migeon wrote:
Do you get the same output between "disklabel /dev/xbd1" and "disklabel -Ar
/dev/xbd1"?
I would also try dd'ing the LV and pass it through vnconfig(8) (never did it,
YMMV).
I've seen weird behavior from domU when it falls on specific forbidden
o
Le 30/05/13 16:16, Emile `iMil' Heitor a écrit :
I suggest checking this from a dom0 perspective first before
continuing the hunt for weird and uncommon file system corruption
issues in the domU.
In the dom0, make sure your lvm is active, e.g. marked with an 'a'
rather than a 'd'
in the output
I suggest checking this from a dom0 perspective first before continuing the
hunt for weird and uncommon file system corruption issues in the domU.
In the dom0, make sure your lvm is active, e.g. marked with an 'a' rather than
a 'd'
in the output of lvm lvs. I suspect you couldn't even get a d
initialize mem_clusters; sparse_dumps disabled
> Supported file systems: union umap tmpfs smbfs puffs ptyfs procfs overlay
> null ntfs nfs msdos mfs lfs kernfs fdesc ext2fs ffs coda cd9660
> no file system for xbd0 (dev 0x8e00)
> cannot mount root, error = 79
> root device (default
s nfs msdos mfs lfs kernfs fdesc ext2fs ffs coda cd9660
no file system for xbd0 (dev 0x8e00)
cannot mount root, error = 79
root device (default xbd0a):
That domU used to boot / work peacefully, but for an unknown reason, the
virtual block device is not recognized anymore. When trying to mount that
d
