Как я могу получить доступ к сломанной файловой системе Ubuntu 14.04?

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

Вопрос: Как получить доступ к файловой системе 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 для каталогов и файлов, а также для доступа к ним. Я также искал в AskUbuntu и StackOverflow (и других форумах). Пока я не смог выяснить ответ, поэтому обращаюсь за помощью к экспертам из AskUbuntu. TIA для ответа.

Источник

1 ответ

Хорошо, благодаря нескольким людям на этом и других форумах, я нашел ответ. Ключ должен знать тип файловой системы интересующего раздела. lsblk Команда показывает, где смонтирован том (имя: поврежден). 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 в качестве имени блочного устройства, оно было принято, распознано как загрузочный том, и все просто заработало. ТАК РАД, ЭТО СДЕЛАНО! Это был настоящий опыт обучения. Я надеюсь, что это помогает кому-то еще, кто сталкивается с этими типами проблем.

Источник
Другие вопросы по тегам