no file system for xbd0 (dev 0x8e00)
Hi,
Since yesterday, a NetBSD 6.0.1/amd64 domU of mine can't mount its root fs
anymore:
boot device: xbd0
root on xbd0a dumps on xbd0b
Your machine does not 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 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
device in another virtual machine, I get the following:
[~] mount -o log /dev/xbd1a /mnt
mount_ffs: /dev/xbd1a on /mnt: incorrect super block
Whereas disklabel indicates:
[~] disklabel /dev/xbd1
# /dev/xbd1d:
type: unknown
disk: Xen Virtual ESD
label:
flags:
bytes/sector: 512
sectors/track: 2048
tracks/cylinder: 1
sectors/cylinder: 2048
cylinders: 20480
total sectors: 41943040
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # microseconds
track-to-track seek: 0 # microseconds
drivedata: 0
16 partitions:
#sizeoffset fstype [fsize bsize cpg/sgs]
a: 37748736 0 4.2BSD 2048 16384 0 # (Cyl. 0 - 18431)
b: 4194304 37748736 swap # (Cyl. 18432 - 20479)
c: 41943040 0 unused 0 0# (Cyl. 0 - 20479)
d: 41943040 0 unused 0 0# (Cyl. 0 - 20479)
The virtual block device is a LVM logical volume, I use that setup in almost
all of the domUs I run, it is declared very simply in domU's configuration
file:
disk = [ 'phy:/dev/mapper/vg1-webserver,hda,w' ]
Running fsck_ffs gives:
[~] fsck_ffs /dev/xbd1a
** /dev/rxbd1a
BAD SUPER BLOCK: CAN'T FIND SUPERBLOCK
/dev/rxbd1a: CANNOT FIGURE OUT SECTORS PER CYLINDER
And specifying another superblock doesn't change anything:
[~] fsck_ffs -b 32 /dev/xbd1a
Alternate super block location: 32
** /dev/rxbd1a
BAD SUPER BLOCK: MAGIC NUMBER WRONG
Any idea on what can I try in order to recover that virtual drive?
--
Emile `iMil' Heitor .°. imil@{home.imil.net,NetBSD.org,gcu.info}
_
| http://imil.net| ASCII ribbon campaign ( )
| http://www.NetBSD.org | - against HTML email X
| http://gcu.info| vCards / \
Re: no file system for xbd0 (dev 0x8e00)
On Thu, 30 May 2013 13:27:44 +0200 (CEST) Emile `iMil' Heitor i...@home.imil.net wrote: Hi, Since yesterday, a NetBSD 6.0.1/amd64 domU of mine can't mount its root fs anymore: boot device: xbd0 root on xbd0a dumps on xbd0b Your machine does not 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 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 device in another virtual machine, I get the following: [~] mount -o log /dev/xbd1a /mnt mount_ffs: /dev/xbd1a on /mnt: incorrect super block Whereas disklabel indicates: [~] disklabel /dev/xbd1 # /dev/xbd1d: type: unknown disk: Xen Virtual ESD label: flags: bytes/sector: 512 sectors/track: 2048 tracks/cylinder: 1 sectors/cylinder: 2048 cylinders: 20480 total sectors: 41943040 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0# microseconds drivedata: 0 16 partitions: #sizeoffset fstype [fsize bsize cpg/sgs] a: 37748736 0 4.2BSD 2048 16384 0 # (Cyl. 0 - 18431) b: 4194304 37748736 swap # (Cyl. 18432 - 20479) c: 41943040 0 unused 0 0# (Cyl. 0 - 20479) d: 41943040 0 unused 0 0# (Cyl. 0 - 20479) The virtual block device is a LVM logical volume, I use that setup in almost all of the domUs I run, it is declared very simply in domU's configuration file: disk = [ 'phy:/dev/mapper/vg1-webserver,hda,w' ] Running fsck_ffs gives: [~] fsck_ffs /dev/xbd1a ** /dev/rxbd1a BAD SUPER BLOCK: CAN'T FIND SUPERBLOCK /dev/rxbd1a: CANNOT FIGURE OUT SECTORS PER CYLINDER And specifying another superblock doesn't change anything: [~] fsck_ffs -b 32 /dev/xbd1a Alternate super block location: 32 ** /dev/rxbd1a BAD SUPER BLOCK: MAGIC NUMBER WRONG Any idea on what can I try in order to recover that virtual drive? 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 disklabel if it wasn't, but it can't hurt to check the lvm status in dom0 anyway. I'd also suggest in dom0 dd'ing the lvm's raw device to /dev/null to make sure there are no i/o errors. Good luck! Harry Waddell
Re: no file system for xbd0 (dev 0x8e00)
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 disklabel if it
wasn't, but it can't hurt to check the lvm status in dom0 anyway.
I'd also suggest in dom0 dd'ing the lvm's raw device to /dev/null to make sure
there are no i/o errors.
lvs output, from the dom0, seems ok:
webserver vg1 owi-ao 20.00g
The `o'rigin attribute is set because I've just done a snapshot just in case..
dd from the vbd to /dev/null went well also.
I have a bad feeling about this...
--
Emile `iMil' Heitor .°. imil@{home.imil.net,NetBSD.org,gcu.info}
_
| http://imil.net| ASCII ribbon campaign ( )
| http://www.NetBSD.org | - against HTML email X
| http://gcu.info| vCards / \
Re: no file system for xbd0 (dev 0x8e00)
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 of lvm lvs. I suspect you couldn't even get a disklabel if it wasn't, but it can't hurt to check the lvm status in dom0 anyway. I'd also suggest in dom0 dd'ing the lvm's raw device to /dev/null to make sure there are no i/o errors. lvs output, from the dom0, seems ok: webserver vg1 owi-ao 20.00g The `o'rigin attribute is set because I've just done a snapshot just in case.. dd from the vbd to /dev/null went well also. I have a bad feeling about this... 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 operations from dom0's backend (like trying to overwrite the disk's disklabel after a silent corruption). -- Jean-Yves Migeon
Re: no file system for xbd0 (dev 0x8e00)
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
operations from dom0's backend (like trying to overwrite the disk's disklabel
after a silent corruption).
I finally fixed the domU's fs, it appears that the superblock list given by
newfs -N was wrong, and I found a working alternative superblock. Luckily,
only the /dev directory and a couple of files have been wiped by fsck(8)
and I've been able to boot the virtual machine and put it to work again.
Nevertheless, that story is a bit frightening, because no error message has
never showed neither on the domU nor on the dom0, the fs corruption just
happened silently, just like you said.
Thanks for your help anyway!
--
Emile `iMil' Heitor .°. imil@{home.imil.net,NetBSD.org,gcu.info}
_
| http://imil.net| ASCII ribbon campaign ( )
| http://www.NetBSD.org | - against HTML email X
| http://gcu.info| vCards / \
