Re: no file system for xbd0 (dev 0x8e00)

[Harry Waddell <waddell%caravan-epub.com@localhost>]

On Thu, 30 May 2013 13:27:44 +0200 (CEST)
"Emile `iMil' Heitor" <imil%home.imil.net@localhost> 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:
> #        size    offset     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