问题：我有一个使用 Ubuntu 14.04 LTS 设置的 AWS t2.micro（虚拟机）实例（名称：webserver）。由于我错误地编辑并保存了配置文件，因此该实例无法使用。我需要访问虚拟机的文件系统，以便修复实例（名称：webserver）中损坏的配置文件，并（希望）恢复实例（VM）以便再次使用。
配置：使用 Ubuntu 14.04 LTS 设置的 AWS t2.micro 实例（名称：webserver）。此实例已停止，包含实例（名称：webserver）的 EBS 卷（名称：broken）已安装在运行 Ubuntu 14.04 LTS（与已停止的实例相同的操作系统）的第二个 AWS t2.micro 实例（名称：recovery）的 /mnt 上。使用的安装命令为：
sudo mount -t sysfs xvdf /mnt
我也尝试了其他 FS 类型 (ext2、ext4、auto)，但都没有效果。
fsblk 命令产生以下输出：
ubuntu@ip-172-xx-xx-xxx:~$ 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
使用以下命令挂载 xvdf1：
ubuntu@ip-172-xx-xx-xxx:~$ sudo mount -t sysfs xvdf1 /data
在 /data 中产生与 /mnt 目录中相同的内容，如下所述。
问题：如何访问已安装的 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 系统目录和文件 - 但未成功。
我查看了 AWS 文档和 Ubuntu 手册页，了解目录和文件以及对它们的访问。我还在 SuperUser、AskUbuntu 和 StackOverflow（以及其他论坛）中搜索过。到目前为止，我还没有找到答案，所以我向 SuperUser 的专家寻求帮助。
我怀疑 Ubuntu 文件系统的根目录是一个链接，位于 /mnt 结构中的某个位置；某种形式的 bind 命令可以让我访问它。但到目前为止，我还不知道在哪里/如何做到这一点。
TIA 帮助改进问题或提供真正的答案。
答案1
好的，感谢这个论坛和其他论坛上的一些人，我找到了答案。关键是要知道感兴趣的分区的文件系统类型。lsblk命令显示 (name:broken) 卷的安装位置。山不带参数的命令提供了有关文件系统类型（本例中为 ext4）的必要信息。请注意，其他几种文件系统类型中也包含数据，但这些数据并不是修复问题所需的数据。
ubuntu@ip-172-31-19-121:~$ 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
ubuntu@ip-172-31-19-121:~$ 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)
ubuntu@ip-172-31-19-121:~$
既然知道了这一点，请创建挂载点目录：
ubuntu@ip-172-31-19-121:~$ mkdir ./mnt
...挂载卷：
ubuntu@ip-172-31-19-121:~$ sudo mount -t ext4 /dev/xvdf1 ./mnt
...检查是否有正确的目录和文件：
ubuntu@ip-172-31-19-121:~$ 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
... 是的，所以现在是时候编辑损坏的文件了：
ubuntu@ip-172-31-19-121:~$ sudo nano ./mnt/etc/sudoers
是的，找到了错误的行，修复了它，并写出了更正后的文件。
下一步：
- 卸载恢复的卷，
- 停止恢复实例，
- 将恢复的卷从恢复实例中分离出来，
- 将恢复的卷附加到原始实例（确保将块设备名称指定为 /dev/sda1 - 使用其他任何名称都将不起作用），
- 重新启动原始实例，并确认其正常运行。
我输入了错误的条目 /dev/sda1（尝试了 /dev/sda、/dev/xvda 等——没有成功），并且一段时间内没有找到它。因此，虽然卷确实重新连接了，但它没有被识别为启动卷。一旦我输入 /dev/sda1 作为块设备名称，它就会被接受，被识别为启动卷，一切正常刚刚工作。很高兴这已经完成了！这是一次真正的学习经历。我希望这能帮助遇到此类问题的其他人。