OK, graças a várias pessoas neste e em outros fóruns, encontrei a resposta. A chave é conhecer o tipo de sistema de arquivos da partição de interesse. O comando lsblk mostra onde o volume (name: broken) está montado. O comando mount sem parâmetros fornece as informações necessárias sobre o tipo de sistema de arquivos, que é ext4 nesse caso. Observe que vários outros tipos de sistemas de arquivos também possuem dados, mas não são os dados necessários para corrigir o problema.
$ 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)
Agora que isso é conhecido, crie o diretório do ponto de montagem:
$ mkdir ./mnt
... monte o volume:
$ sudo mount -t ext4 /dev/xvdf1 ./mnt
... verifique se os diretórios e arquivos corretos estão disponíveis:
$ 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
... eles estão, então agora é hora de editar o arquivo quebrado:
$ sudo nano ./mnt/etc/sudoers
Sim, encontrei a linha incorreta, corrigi-a e escrevi o arquivo corrigido.
Próximas etapas:
- desmontar o volume recuperado,
- interrompa a instância de recuperação,
- separe o volume recuperado da instância de recuperação,
- anexe o volume recuperado à instância original (não se esqueça de especificar o nome do dispositivo de bloco como
/dev/sda1- use qualquer outra coisa, então NÃO FUNCIONA), - reinicie a instância original e confirme se ela funciona corretamente.
Inseri mal a entrada necessária, /dev/sda1 (tentei /dev/sda , /dev/xvda , etc. - sem permissão) e não a encontrei por um tempo. Portanto, embora o volume tenha sido anexado novamente, ele não foi reconhecido como o volume de inicialização. Uma vez que eu digitei / dev / sda1 como o nome do dispositivo de bloco, ele foi aceito, reconhecido como o volume de inicialização e tudo acabou de funcionar . TÃO contente isso é feito! Foi uma experiência real de aprendizado. Espero que isso ajude alguém que enfrenta esse tipo de problema.