☰

如何访问损坏的 Ubuntu 14.04 文件系统？

tag-icon • tag-icon 14.04 mount files directory aws
如何访问损坏的 Ubuntu 14.04 文件系统？

配置：
使用 Ubuntu 14.04 LTS 设置的 AWS t2.micro 实例（名称：webserver）；此实例已停止，并且包含实例（名称：webserver）的 EBS 卷（名称：broken）已安装在/mnt运行 Ubuntu 14.04 LTS（与已停止的实例相同的操作系统）的第二个 AWS t2.micro 实例（名称：recovery）上。

问题：如何访问已安装的 EBS 卷 (名称：broken) 中的 Ubuntu 文件系统？我要查找的目录和文件均来自此列表，取自服务器 (名称：recovery)。

total 84
drwxr-xr-x  22 root root  4096 Jul 27 05:35 .
drwxr-xr-x  22 root root  4096 Jul 27 05:35 ..
drwxr-xr-x   2 root root  4096 Mar 25 11:52 bin
drwxr-xr-x   3 root root  4096 Mar 25 11:52 boot
drwxr-xr-x  13 root root  4020 Jul 25 16:53 dev
drwxr-xr-x  89 root root  4096 Jul 25 21:37 etc
drwxr-xr-x   3 root root  4096 Jul 25 15:46 home
lrwxrwxrwx   1 root root    33 Mar 25 11:51 initrd.img -> boot/initrd.img-3.13.0-48-generic
drwxr-xr-x  21 root root  4096 Mar 25 11:51 lib
drwxr-xr-x   2 root root  4096 Mar 25 11:50 lib64
drwx------   2 root root 16384 Mar 25 11:53 lost+found
drwxr-xr-x   2 root root  4096 Mar 25 11:50 media
drwxr-xr-x   2 root root  4096 Mar 25 11:50 opt
dr-xr-xr-x 109 root root     0 Jul 25 15:46 proc
drwx------   3 root root  4096 Jul 25 15:46 root
drwxr-xr-x  18 root root   660 Jul 26 06:27 run
drwxr-xr-x   2 root root  4096 Mar 25 11:52 sbin
drwxr-xr-x   2 root root  4096 Mar 25 11:50 srv
drwxrwx---  13 root root     0 Jul 26 14:17 sys

相同的目录和文件应该位于已安装卷（名称：broken）的某个位置，但我无法找到它们。

评论/状态：当我使用时ls -al /mnt——我得到了虚拟机目录和文件的非常好的列表，如下所示。

total 4
drwxrwx--- 13 root root    0 Jul 26 14:17 .
drwxr-xr-x 22 root root 4096 Jul 27 05:35 ..
drwxr-xr-x  2 root root    0 Jul 25 15:46 block
drwxr-xr-x 28 root root    0 Jul 25 15:46 bus
drwxr-xr-x 46 root root    0 Jul 25 15:46 class
drwxr-xr-x  4 root root    0 Jul 25 15:46 dev
drwxr-xr-x 16 root root    0 Jul 25 15:46 devices
drwxr-xr-x  4 root root    0 Jul 25 15:46 firmware
drwxr-xr-x  7 root root    0 Jul 25 15:46 fs
drwxr-xr-x  5 root root    0 Jul 25 21:38 hypervisor
drwxr-xr-x  7 root root    0 Jul 25 15:46 kernel
drwxr-xr-x 92 root root    0 Jul 25 15:46 module
drwxr-xr-x  2 root root    0 Jul 25 21:38 power

这些目录和文件是运行 Ubuntu 14.04 的虚拟机的结构。据我所知，此文件结构中没有任何与 Ubuntu 文件系统本身相关的内容。我制作了完整的树状列表/mnt，并在其中搜索了 Ubuntu 系统目录和文件——但没有成功。

我研究这个主题的目的是为了访问图像中损坏的配置文件（名称：webserver）来修复它，并且（希望）恢复图像以便再次使用。

我查看了 AWS 文档和 Ubuntu 手册页，了解目录和文件以及对它们的访问。我还在 AskUbuntu 和 StackOverflow（以及其他论坛）中搜索过。到目前为止，我还没有找到答案，所以我向 AskUbuntu 的专家寻求帮助。TIA 寻求答案。

答案1

好的，感谢这个论坛和其他论坛上的一些人，我找到了答案。关键是要知道感兴趣的分区的文件系统类型。该lsblk命令显示 (name:broken) 卷的安装位置。mount不带参数的命令提供了有关文件系统类型的必要信息，在本例中为 ext4。请注意，其他几种文件系统类型中也有数据，但这不是解决问题所需的数据。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0  24G  0 disk
└─xvdf1 202:81   0  24G  0 part

$ mount
/dev/xvda1 on / type ext4 (rw,discard)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)

既然知道了这一点，请创建挂载点目录：

$ mkdir ./mnt

...挂载卷：

$ sudo mount -t ext4 /dev/xvdf1 ./mnt

...检查是否有正确的目录和文件：

$ ls -al ./mnt
total 100
drwxr-xr-x 22 root   root    4096 Jul 25 14:32 .
drwxr-xr-x  6 ubuntu ubuntu  4096 Jul 29 07:20 ..
drwxr-xr-x  2 root   root    4096 Mar 25 11:52 bin
drwxr-xr-x  3 root   root    4096 Mar 25 11:52 boot
drwxr-xr-x  5 root   root    4096 Mar 25 11:53 dev
drwxr-xr-x 89 root   root    4096 Jul 29 06:46 etc
drwxr-xr-x  4 root   root    4096 Jul 23 02:21 home
lrwxrwxrwx  1 root   root      33 Mar 25 11:51 initrd.img -> boot/initrd.img-3.13.0-48-generic
drwxr-xr-x 21 root   root    4096 Mar 25 11:51 lib
drwxr-xr-x  2 root   root    4096 Mar 25 11:50 lib64
drwx------  2 root   root   16384 Mar 25 11:53 lost+found
drwxr-xr-x  2 root   root    4096 Mar 25 11:50 media
drwxr-xr-x  2 root   root    4096 Apr 10  2014 mnt
drwxr-xr-x  2 root   root    4096 Mar 25 11:50 opt
drwxr-xr-x  2 root   root    4096 Apr 10  2014 proc
drwx------  3 root   root    4096 Jul 22 04:40 root
drwxr-xr-x  3 root   root    4096 Mar 25 11:53 run
drwxr-xr-x  2 root   root    4096 Mar 25 11:52 sbin
drwxr-xr-x  2 root   root    4096 Mar 25 11:50 srv
drwxr-xr-x  2 root   root    4096 Mar 13  2014 sys
drwxrwxrwt  2 root   root    4096 Jul 29 06:52 tmp
drwxr-xr-x 10 root   root    4096 Mar 25 11:50 usr
drwxr-xr-x 12 root   root    4096 Mar 25 11:52 var
lrwxrwxrwx  1 root   root      30 Mar 25 11:51 vmlinuz -> boot/vmlinuz-3.13.0-48-generic

... 是的，所以现在是时候编辑损坏的文件了：

$ sudo nano ./mnt/etc/sudoers

是的，找到了错误的行，修复了它，并写出了更正后的文件。

下一步：

  1. 卸载恢复的卷，
  2. 停止恢复实例，
  3. 将恢复的卷从恢复实例中分离出来，
  4. 将恢复的卷附加到原始实例（请务必指定块设备名称/dev/sda1- 使用其他任何名称，否则将不起作用），
  5. 重新启动原始实例，并确认其正常运行。

我输入了错误的必填项，/dev/sda1（尝试过/dev/sda，/dev/xvda等——没有成功），并且一段时间内没有找到它。因此，虽然卷确实重新连接了，但它没有被识别为启动卷。一旦我输入 /dev/sda1 作为块设备名称，它就会被接受，被识别为启动卷，一切正常刚刚工作。很高兴这已经完成了！这是一次真正的学习经历。我希望这能帮助遇到此类问题的其他人。

相关内容