Как я могу получить доступ к поврежденной файловой системе Ubuntu 14.04?
Конфигурация:
Экземпляр AWS t2.micro (name:webserver) настроенный с Ubuntu 14.04 LTS; этот экземпляр останавливается, и объем EBS (name:broken) содержащий экземпляр (name:webserver) был смонтирован в /mnt на втором экземпляре AWS t2.micro (name:recovery) под управлением Ubuntu 14.04 LTS (та же ОС как остановленный экземпляр).
Вопрос: Как я получаю доступ к файловой системе Ubuntu в смонтированном объеме EBS (name:broken)? Каталоги и файлы, которые я ищу, на этот список, взятый с сервера (name: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
Те же каталоги и файлы должны быть где-нибудь в смонтированном объеме (name: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 и файлы - без успеха.
Моя цель в преследовании этой темы состоит в том, чтобы заставить доступ к поврежденному конфигурационному файлу в изображении (name:webserver) восстанавливать его и (надо надеяться) восстанавливать изображение, таким образом, это снова применимо.
Я рассмотрел документацию 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
Да, обнаружил плохую строку, исправил его и выписал исправленный файл.
Следующие шаги:
- размонтировать восстановленный том,
- остановить экземпляр восстановления,
- отсоединить восстановленный том от экземпляра восстановления, [ 1115] присоедините восстановленный том к исходному экземпляру (обязательно укажите имя блочного устройства как
- перезапустите исходный экземпляр и подтвердите, что он функционирует правильно.
/dev/sda1 - используйте что-нибудь еще, ЭТО НЕ РАБОТАЕТ), Я неправильно ввел нужную запись, /dev/sda1 (пробовал /dev/sda, /dev/xvda и т. Д. - не ходил) и некоторое время не находил ее. Таким образом, хотя том снова подключен, он не был распознан как загрузочный том. Как только я ввел / dev / sda1 в качестве имени блочного устройства, оно было принято, распознано как загрузочный том, и все просто заработало . ТАК РАД, ЭТО СДЕЛАНО! Это был настоящий опыт обучения. Я надеюсь, что это поможет кому-то еще, кто сталкивается с этими типами проблем.