重启后 LVM 未启动,无法找到具有 uuid 的设备

重启后 LVM 未启动,无法找到具有 uuid 的设备

有一个虚拟机,直到最近都可以正常工作,但在进行一些配置更改后需要重新启动。然而,重新启动后,虚拟机没有恢复,并表示找不到根设备(这是 /dev/mapper 下的 LVM 卷)。

启动进入恢复模式,我看到 /dev/mapper 和 /dev/dm-* 下的文件系统确实不存在。

文件系统应该布局为

  • /dev/sda1作为启动分区
  • /dev/sda2扩展分区包含
  • /dev/sda5以及/dev/sda6LVM 分区
  • /dev/sda{5,6}两个 PV 都在一个 VG 中
  • 有 2 个 LV 用于根 FS 和交换

做一个lvm pvshow给了我:

  Couldn't find device with uuid '8x38hf-mzd7-xTes-y6IV-xRMr-qrNP-0dNnLi'.
  Couldn't find device with uuid '8x38hf-mzd7-xTes-y6IV-xRMr-qrNP-0dNnLi'.
  Couldn't find device with uuid '8x38hf-mzd7-xTes-y6IV-xRMr-qrNP-0dNnLi'.
  --- Physical volume ---
  PV Name               unknown device
  VG Name               of1-server-lucid
  PV Size               19.76 GiB / not usable 2.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              5058
  Free PE               0
  Allocated PE          5058
  PV UUID               8x38hf-mzd7-xTes-y6IV-xRMr-qrNP-0dNnLi

  --- Physical volume ---
  PV Name               /dev/sda6
  VG Name               of1-server-lucid
  PV Size               100.00 GiB / not usable 2.66 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              25599
  Free PE               0
  Allocated PE          25599
  PV UUID               cuhP6R-QbiO-U7ye-WvXN-ZNq5-cqUs-VVZpux

因此它看起来好像/dev/sda5没有被列为 PV 并且导致了错误。

fdisk -l:

Disk /dev/sda: 128.8 GB, 128849018880 bytes
255 heads, 63 sectors/track, 15665 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00044a6c

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          32      248832   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2              32       15665   125579256+   5  Extended
/dev/sda5              32        2611    20722970   8e  Linux LVM
/dev/sda6            2612       15665   104856223+  8e  Linux LVM

所以我可以看到该/dev/sda5设备存在,但blkid没有报告任何内容:

~ # blkid
/dev/sda1: UUID="d997d281-2909-41d3-a835-dba400e7ceec" TYPE="ext2" 
/dev/sda6: UUID="cuhP6R-QbiO-U7ye-WvXN-ZNq5-cqUs-VVZpux" TYPE="LVM2_member" 

拍摄磁盘快照后,我尝试从存档配置中恢复 PV:

~ # pvremove -ff /dev/sda5
Labels on physical volume "/dev/sda5" successfully wiped
~ # pvcreate --uuid=8x38hf-mzd7-xTes-y6IV-xRMr-qrNP-0dNnLi /dev/sda5 --restorefile=/etc/lvm/archive/of1-dev-server_00000.vg
Couldn't find device with uuid '8x38hf-mzd7-xTes-y6IV-xRMr-qrNP-0dNnLi'.
  Physical volume "/dev/sda5" successfully created
~ # vgchange -a y
2 logical volume(s) in volume group "of1-dev-server" now active"

所以至少现在该设备有一个blkid

/dev/sda1: UUID="d997d281-2909-41d3-a835-dba400e7ceec" TYPE="ext2" 
/dev/sda6: UUID="cuhP6R-QbiO-U7ye-WvXN-ZNq5-cqUs-VVZpux" TYPE="LVM2_member" 
/dev/sda5: UUID="8x38hf-mzd7-xTes-y6IV-xRMr-qrNP-0dNnLi" TYPE="LVM2_member" 

现在执行pvdisplay也会显示正确的设备:

  --- Physical volume ---
  PV Name               /dev/sda5
  VG Name               of1-dev-danr-lucid
  PV Size               19.76 GiB / not usable 2.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              5058
  Free PE               0
  Allocated PE          5058
  PV UUID               8x38hf-mzd7-xTes-y6IV-xRMr-qrNP-0dNnLi

  --- Physical volume ---
  PV Name               /dev/sda6
  VG Name               of1-dev-danr-lucid
  PV Size               100.00 GiB / not usable 2.66 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              25599
  Free PE               0
  Allocated PE          25599
  PV UUID               cuhP6R-QbiO-U7ye-WvXN-ZNq5-cqUs-VVZpux

并且映射器设备存在:

crw-rw----    1 root     root      10,  59 Jul 10 10:47 control
brw-rw----    1 root     root     252,   0 Jul 10 11:21 of1--dev--server-root
brw-rw----    1 root     root     252,   1 Jul 10 11:21 of1--dev--server-swap_1

LVM 似乎也列出正确:

~ # lvdisplay
  --- Logical volume ---
  LV Name                /dev/of1-dev-danr-lucid/root
  VG Name                of1-dev-danr-lucid
  LV UUID                pioKjE-iJEp-Uf9S-0MxQ-UR0H-cG9m-5mLJm7
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                118.89 GiB
  Current LE             30435
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:0

  --- Logical volume ---
  LV Name                /dev/of1-dev-danr-lucid/swap_1
  VG Name                of1-dev-danr-lucid
  LV UUID                mIq22L-RHi4-tudV-G6nP-T1e6-UQcS-B9hYUF
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                888.00 MiB
  Current LE             222
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:1

但尝试挂载根设备时出现错误:

~ # mount /dev/mapper/of1--dev--server-root /mnt2
mount: mounting /dev/mapper/of1--dev--server-root on /mnt2 failed: Invalid argument

所以我尝试了磁盘一致性检查:

~ # fsck.ext4 -f /dev/mapper/of1--dev--server-root
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/mapper/of1--dev--server-root
[...]

所以我尝试了另一个超级块:

~ # mke2fs -n /dev/mapper/of1--dev--server-root
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
7798784 inodes, 31165440 blocks
1558272 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
952 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872
~ # fsck.ext4 -y -b 23887872 /dev/mapper/of1--dev--server-root

我收到了数量可笑的错误,我看到的主要错误是:

  • Superblock 的日志无效
  • 一个或多个块组描述符校验和无效。
  • 截断孤立 inode ()
  • 在孤立 inode 中发现已清除的块 #0 ()
  • /dev/mapper/of1--dev--server-root 包含有错误的文件系统,强制检查
  • 调整索引节点大小无效。重建
  • 根 inode 不是目录。
  • 保留 inode 3 () 具有无效模式
  • HTREE 目录 inode 的根节点无效
  • inode,i_blocks,应该是0。
  • 未连接的目录 inode

发了很多信息后,就说已经完成了。按照上面的方式挂载目录工作正常,但是该目录是空的,目录中lost+found充满了文件,大多数只是数字,有些文件名与曾经存在的文件模糊相关。

那么,如何恢复虚拟机呢?

每当我看到磁盘错误时,我的第一反应就是创建快照,这样事情就不会变得更糟,所以我在第一次看到错误时重新启动后就有了快照。

我知道数据在某处,因为虚拟机工作没有问题,直到我重新启动。用户不记得最近更改了文件系统上的任何内容,但当我重新启动它时,它已经运行了近一年,因此从那时起,可能会发生各种情况。

不幸的是,我们也没有备份,因为 Puppet 已在此节点上禁用。

最初的操作系统是 Ubuntu Lucid,在 VMWare 上运行。

答案1

如果我理解正确,您已经修复了卷,即使您的lost+found目录可能包含也可能不包含关键文件。

现在发生了什么阻止虚拟机启动?还是找不到启动设备?

你的fdisk -l输出对我来说似乎有点不对劲。有没有考虑过只有分区表损坏的可能性?在这种情况下,您的快照可能会有所帮助,并且在最好的情况下您甚至不需要(另一个)fsck。但我们需要一些东西来尝试找到分区偏移量 - 我已经使用过测试盘成功不止一次。

在最坏的情况下,如果您需要从卷中删除任何内容,取证工具如摄影记录或者尸检/侦探工具包可能会被证明是有用的。

如果这些都不起作用,请lsblk -o NAME,RM,SIZE,RO,TYPE,MAJ:MIN -fat也给我们一个(这些标志只是为了显示尽可能多的信息)以及相关dmesg输出(如果有)。

相关内容