Visão geral do problema
Recentemente atualizei meu contrato de servidor remoto com IONOS, aumentando meu espaço no disco rígido de 8 GB para 80 GB. Eu tenho um sistema operacional Ubuntu rodando o bash.
Em seguida, estendi minha partição de trabalho, seguindo um tutorial aqui: https://www.ryadel.com/en/resize-extend-disk-partition-unallocated-disk-space-linux-centos-rhel-ubuntu-debian/
Tudo estava bem, escrevi um novo mapa de partição e reiniciei meu sistema. Esperei um ou dois minutos e tentei ssh
entrar no meu servidor como de costume. Problema. Minha conexão ssh trava, até finalmente sair com um arquivo time out
.
Tentativas de solução
A princípio, pensei que o processo de reinicialização após uma alteração no mapa de partição poderia levar algum tempo e essa foi a causa do tempo limite. Depois de mais algumas ssh
tentativas, isso não parecia provável.
Usei um 'Console KVM' fornecido em meu console IONOS - aqui, o shell está no estado (initramfs)
.
Na tentativa de diagnosticar o problema, tentei o seguinte:
- Correndo:
fsck /dev/sda1
Resultado:/dev/sda1: clean, 312/124672 files, 26890/124672 blocks
- Correndo:
fsck /dev/sda1
Resultado:fsck: error 2 (No such file or directory) while executing fsck.ext2 for /dev/sda2
- Correndo:
blkid
Resultado:
/dev/sda1: UUID="longString" TYPE="ext4" PARTUUID="520f1760-01"
/dev/sda2: PARTUUID="520f1760-02"
- A execução de todos os comandos a seguir retorna
sh: command name: not found
. Estes são:
- vgdisplay -v vg00
- parted -l /dev/sda
- livre -m
- cfdisk
- lvdisplay -v
- fdisk /dev/sda
- redimensionar /dev/sda2
- A saída de
cat proc/partitions
é:
major minor #blocks name
8 0 83886080 sda
8 1 498688 sda1
8 2 83386368 sda2
11 0 1048575 sr0
Pelo exposto, estou confuso por que (2) retorna no such file or directory
- a entrada sda2
está listada no diretório dev
.
- A saída de
cat /proc/cmdline
é:BOOT_IMAGE=/vmlinuz-5.4.0-132-generic root=/dev/mapper/vg00-lv01 ro apparmor=0
- Depois de inserir
lvm
e entãovgscan -ccc
, a saída é:
....
Start of output not visible in terminal window due to no scrolling
....
filter caching bad /dev/loop5
Opened /dev/loop6 RO O_DIRECT
/dev/loop6: size is 0 sectors
Closed /dev/loop6
/dev/loop6: Skipping: Too small to hold a PV
filter caching bad /dev/loop6
Opended /dev/loop7 RO O_DIRECT
/dev/loop7: size is 0 sectors
Closed /dev/loop7
/dev/loop7: Skipping: Too small to hold a PV
filter caching bad /dev/loop7
Will scan 3 devices skip 0
Checking fd limit for num_devs 3 want 35 soft 1024 hard 4096
Scanning 3 devices for VG info
Scanning submitted 3 reads
Processing data from device /dev/sda 8:0 fd 4 block 0x55b511a17cd0
Scan filtering /dev/sda
/dev/sda: using cached size 167772160 sectors
/dev/sda: Skipping: Partition table signature found
filter caching bad /dev/sda
/dev/sda: Not processing filtered
Processing data from device /dev/sda1 8:1 fd 5 block 0x55b511a17d10
Scan filtering /dev/sda1
/dev/sda1: using cached size 997376 sectors
/dev/sda1: Device is a partition, using primary device sda for mpath component detection
/dev/sda1: using cached size 997376 sectors
filter caching good /dev/sda1
/dev/sda1: No lvm label detected
Processing data from device /dev/sda2 8:2 fd 6 block 0x55b511a17d50
Scan filtering /dev/sda2
/dev/sda2: using cached size 166772736 sectors
/dev/sda2: Device is a partition, using primary device sda for mpath component detection
/dev/sda2: using cached size 166772736 sectors
filter caching good /dev/sda2
Label checksum incorrect on /dev/sda2 - ignoring
/dev/sda2: No lvm label detected
Scanned devices: read errors 0 process errors 0 failed 0
Found VG info for 0 VGs
Obtaining the complete list of VGs to process
No volume groups found
Unlocking /run/lock/lvm/P_global
_undo_flock /run/lock/lvm/P_global
Dropping VG info
lvmcache has no info for vgname "#orphans_lvm2" with VGID #orphans_lvm2.
lvmcache has no info for vgname "#orphans_lvm2".
lvmcache: Initialised VG #orphans_lvm2.
Completed: vgscan -vvv
- O diretório
/etc/lvm/backup
existe e contém:vg00
O diretório/etc/lvm/archive
existe e contém:vg00_00000-1647277590.vg vg00_00001-1228658393.vg
(3) e (5) dão-me esperança - a localização parece ser reconhecida, o que isto sugere?
Etapas específicas antes da reinicialização
Em resumo, as etapas que executei antes de reiniciar meu sistema foram:
- executei
fdisk /dev/sda
e anotei os pontos inicial e final dos sistemas de arquivos digitandop
. - Excluiu o mapa do sistema de arquivos inserindo
d
e selecionandosda2
com2
- Criou um novo mapa de partição digitando
n
. Definir o tipo de partição comoprimary
. - Em seguida, inseri os locais de início e fim da nova partição, conforme observado na etapa (1).
- Alterei o tipo de partição digitando
t
e selecionando a segunda partição digitando2
. - Especifiquei o tipo de partição como 'Linux LVM' inserindo o código HEX
8e
. - Antes de gravar no disco, certifiquei-me de que os pontos inicial e final estavam listados corretamente digitando
p
. O ponto inicial correspondeu ao da partição original. O ponto final correspondeu ao ponto final do disco. - Eu escrevi o mapa de partição no disco digitando
w
. - Eu reinicio o sistema com
reboot
.
O resultado da execução lvm p
antes das alterações no mapa de partição foi:
Neste ponto, não tenho certeza de como proceder - já encontrei um problema no sistema de arquivos e fiquei preocupado com a perspectiva de perder todos os meus arquivos. Em última análise, nesse caso, os arquivos ainda estavam presentes. A partir dessa experiência, estou restringindo minha suposição de que tudo está perdido.
Alguém tem alguma sugestão ou dica para oferecer em termos de depuração desta situação? Fique à vontade para perguntar se deseja informações adicionais sobre minha configuração.
Atualizar
Consegui inicializar em um CD knoppix no meu servidor remoto. Aqui, executei fdisk -l
quais saídas:
Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram1: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram2: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram3: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram4: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram5: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram6: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram7: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram8: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram9: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram10: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram11: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram12: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram13: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram14: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram15: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/cloop0: 1.83 GiB, 1960312832 bytes, 3828736 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/cloop1: 9.63 GiB, 10335027200 bytes, 20185600 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/zram0: 1.45 GiB, 1560817664 bytes, 381059 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/sda: 80 GiB, 85899345920 bytes, 167772160 sectors
Disk model: Virtual disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x520f1760
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 999423 997376 487M 83 Linux
/dev/sda2 999424 167772159 166772736 79.5G 8e Linux LVM
Sinto que as linhas de saída finais, exibindo o mapa de partição para sda1
e sda2
, são interessantes. Acredito que o tipo de sda2
está correto como 8e
(um LVM Linux), e o Start
valor cai corretamente após o End
de sda1
.
Atualização II
Antes de tentar as etapas abaixo, criei um instantâneo para fazer backup do sistema ao seu estado atual. Agora voltei a este instantâneo.
Tentando restaurar a partir do /etc/lvm/backup/vg00
arquivo (initramfs), primeiro executei o pvcreate --restorefile /etc/lvm/backup/vg00 --uuid R5VWXg-jamB-5dWM-PpwY-7a49-LRz7-Vrvdl2 /dev/sda2
. Isso retornou:
WARNING: Couldn't find device with uuid `R5VWXg-jamB-5dWM-PpwY-7a49-LRz7-Vrvdl2.
Failed to clear hint file.
Physical volume "/dev/sda2" successfully created.
Então, corri vgcfgrestore --file /etc/lvm/backup/vg00
que retornou:
No command with matching syntax recognised.
Nearest similar syntax command has syntax:
vgfcgrestore -f:--file String VG
Restore VG metadata from specified file.
Parece haver um problema aqui.
Você deve examinar o arquivo de backup de metadados do LVM VG
/etc/lvm/backup/vg00
e encontrar o PV UUID original a/dev/sda2
partir daí. É um arquivo de texto e o UUID do PV deve estar em um local como este: ([...]
indica algumas linhas omitidas por questões de brevidade)Once you know the PV UUID, you can use the backup file and the UUID to restore the PV UUID like this: (commands prefixed with
lvm
for use in initramfs environment; if you have extracted the VG metadata backup file from initramfs and do this in Knoppix, you can omit thelvm
prefixes)Once the PV UUID is restored, you can restore the rest of VG metadata with:
After this, the VG should be good for activation:
If the VG activates successfully, and the filesystem within it can be mounted (with e.g.
mount /dev/mapper/vg00-lvol1 /mnt
), you should now be able to boot normally.Once the system is running normally, you'll need two commands as root to achieve your original goal:
Depois disso,
pvs
deverá indicar que osda2
PV foi redimensionado com sucesso evgs
deverá indicar que agora há bastante espaço não alocado no arquivovg00
. Para finalmente fazer uso dele:e agora
df
deve indicar que o sistema de arquivos raiz tem bastante espaço livre novamente.Existe o comando
growpart
(parte docloud-guest-utils
pacote no Debian, pode ser empacotado separadamentecloud-utils-growpart
ou apenasgrowpart
em outras distribuições) que é feito especificamente para estender partições com segurança e rapidez, geralmente sem necessidade de reinicialização.Neste caso específico, a extensão poderia ter sido alcançada com apenas três comandos: