2

Проблема: у меня есть экземпляр AWS t2.micro (виртуальная машина) (имя: веб-сервер), настроенный с Ubuntu 14.04 LTS. Экземпляр непригоден из-за файла конфигурации, который я отредактировал неправильно и сохранил. Мне нужно получить доступ к файловой системе виртуальной машины, чтобы я мог исправить поврежденный файл конфигурации в экземпляре (имя: веб-сервер) и (надеюсь) восстановить экземпляр (ВМ), чтобы он снова мог использоваться.

Конфигурация: экземпляр AWS t2.micro (имя: веб-сервер), настроенный с Ubuntu 14.04 LTS. Этот экземпляр останавливается, и том EBS (имя: поврежден), содержащий экземпляр (имя: веб-сервер), был смонтирован в /mnt на втором экземпляре AWS t2.micro (имя: восстановление) под управлением Ubuntu 14.04 LTS (той же ОС, что и остановленный экземпляр). Используемая команда монтирования была:

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, как описано ниже.

Вопрос: Как получить доступ к файловой системе Ubuntu на смонтированном томе EBS (имя: поврежден)? Каталоги и файлы, которые я ищу, находятся в этом списке, взятом с сервера (имя: 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

Те же самые каталоги и файлы должны быть где-то на подключенном томе (имя: повреждено), но я не смог их найти.

Комментарий / статус: Когда я использую 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; и что команда связывания какой-либо формы даст мне доступ к ней. Пока, однако, я не вижу, где / как это сделать.

TIA за помощь в улучшении вопроса или реального ответа.

1 ответ1

-1

Хорошо, благодаря нескольким людям на этом и других форумах, я нашел ответ. Ключ должен знать тип файловой системы интересующего раздела. Команда lsblk показывает, где смонтирован том (имя: поврежден). Команда mount без параметров предоставляет необходимую информацию о типе файловой системы, в данном случае это 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

Да, нашел плохую строку, исправил ее и выписал исправленный файл.

Следующие шаги:

  1. размонтировать восстановленный том,
  2. остановить экземпляр восстановления,
  3. отсоедините восстановленный том от экземпляра восстановления,
  4. присоедините восстановленный том к исходному экземпляру (не забудьте указать имя блочного устройства как /dev /sda1 - используйте что-нибудь еще, ЭТО НЕ РАБОТАЕТ),
  5. перезапустите исходный экземпляр и убедитесь, что он работает правильно.

Я неверно ввел нужную запись, /dev /sda1 (пробовал /dev /sda, /dev /xvda и т.д. - не ходил) и некоторое время не находил ее. Таким образом, хотя том снова подключен, он не был распознан как загрузочный том. Как только я ввел /dev /sda1 в качестве имени блочного устройства, оно было принято, распознано как загрузочный том, и все просто заработало. ТАК РАД, ЭТО СДЕЛАНО! Это был настоящий опыт обучения. Я надеюсь, что это помогает кому-то еще, кто сталкивается с этими типами проблем.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .