Por que essa alteração torna meu Dispositivo de Bloco não inicializável?

Question

Estou trabalhando com o Amazon Linux na AWS e tentando configurar vários sistemas de arquivos em um único volume do EBS (dispositivo de bloco) por motivos de conformidade. Estou fazendo isso montando um Volume do EBS em uma Instância do EC2 já em execução, executando uma série de comandos, desmontando-o, criando um instantâneo e, em seguida, transformando-o em uma AMI.

Posso fazer com que tudo funcione com um conjunto "básico" de comandos que simplesmente excluem e adicionam novamente uma partição existente. Mas quando adiciono uma segunda partição, não consigo mais iniciar nenhuma Instância do EC2 dessa AMI. Em vez disso, usando a funcionalidade "Obter captura de instâncias" na AWS, a instância do EC2 nunca inicializa e vejo isso:

Quando executo os seguintes comandos de uma instância do EC2 do host na qual montei um volume do EBS, tudo funciona conforme o esperado :

# Make a tar of the current EBS Volume
umount -l /mnt/ebs-volume
mount -o ro /dev/xvdf1 /mnt/ebs-volume
tar -cf /tmp/ebs.tar --exclude='./dev/*' --exclude='./proc/*' --exclude='./sys/*' /mnt/ebs-volume
umount /mnt/ebs-volume

# Replace the old partition with one new partition and format it as ext4
sgdisk --delete 1 /dev/xvdf
sgdisk --new 1:0:+7800M /dev/xvdf && sgdisk --change-name 1:Linux
/sbin/mkfs.ext4 -F -m0 -O ^64bit /dev/xvdf1 && e2label /dev/xvdf1 /

# Mount the new partition and restore the snapshot
mount /dev/xvdf1 /mnt/ebs-volume
cd / && tar -xf /tmp/ebs.tar --acls --selinux --xattrs && rm /tmp/ebs.tar

# I don't make any updates to the /etc/fstab file

Mas quando executo esses comandos, a Instância do EC2 falha ao inicializar como mostrado acima:

# Make a tar of the current EBS Volume
umount -l /mnt/ebs-volume
mount -o ro /dev/xvdf1 /mnt/ebs-volume
tar -cf /tmp/ebs.tar --exclude='./dev/*' --exclude='./proc/*' --exclude='./sys/*' /mnt/ebs-volume
umount /mnt/ebs-volume

# Replace the old partition with two new partitions and format them as ext4
sgdisk --delete 1 /dev/xvdf
sgdisk --new 1:0:+7800M /dev/xvdf && sgdisk --change-name 1:Linux
sgdisk --new 2:0:+100M /dev/xvdf
/sbin/mkfs.ext4 -F -m0 -O ^64bit /dev/xvdf1 && e2label /dev/xvdf1 /
/sbin/mkfs.ext4 -F -m0 -O ^64bit /dev/xvdf2

# Mount the new partitions and restore the snapshot
mount /dev/xvdf1 /mnt/ebs-volume
mkdir -p /mnt/ebs-volume/boot && mount /dev/xvdf2 /mnt/ebs-volume/boot
cd / && tar -xf /tmp/ebs.tar --acls --selinux --xattrs && rm /tmp/ebs.tar

# I now execute commands that write the below /etc/fstab file to the volume at /mnt/ebs-volume/etc/fstab

/ etc / fstab:

LABEL=/     /               ext4    defaults,noatime    1   1
/dev/xvda2  /boot           ext4    defaults,noatime    0   0
tmpfs       /dev/shm        tmpfs   defaults            0   0
devpts      /dev/pts        devpts  gid=5,mode=620      0   0
sysfs       /sys            sysfs   defaults            0   0
proc        /proc           proc    defaults            0   0

Por que adicionar um sistema de arquivos separado para /boot causaria esse erro? Estou faltando alguma coisa no meu /etc/fstab ou talvez outro arquivo em algum lugar, pois suponho que essa nova configuração não seja mais a mesma que a configuração original.

    

Answer 1

Isso pode exigir um pouco da pré-história da seqüência de inicialização do PC para explicar completamente. (PCs modernos com UEFI fazem as coisas de maneira diferente, mas a lógica é semelhante).

Então, vamos olhar para os anos 80, quando os PCs começaram a ter discos rígidos.

O BIOS carregaria o primeiro setor do disco rígido. Isso continha o registro mestre de inicialização (MBR), que era uma combinação de código e a tabela de partição. Havia apenas 512 bytes para armazenar tudo isso, então a codificação era pequena.

O MBR examinaria a tabela de partições e descobriria qual partição estava ativa e onde começou. Em seguida, carregaria um sistema de inicialização secundário , que estava armazenado dentro dessa partição. (Historicamente, isso significava que o carregador de inicialização secundário tinha que estar dentro dos primeiros 504 MB de disco). Este código sabia sobre o sistema de arquivos e poderia carregar o sistema operacional (normalmente IO.SYS, MSDOS.SYS, COMMAND.COM). E assim, o DOS inicializou. Um PC tipicamente novo exigiria "fdisk / mbr" para instalar este setor de inicialização primário.

O fato de ser um software no MBR tornou o processo de inicialização flexível e permitiu carregadores de inicialização alternativos. Um carregador de inicialização inicial para Linux era o LILO ("Linux Loader"). Este tinha um carregador primário, um carregador secundário. Ele sabia sobre sistemas de arquivos Linux padrão e era capaz de inicializar Linux e DOS (e Windows).

Mais tarde, o GRUB (e depois o GRUB2) apareceu. Mas todos seguem o processo de boot loader principal / secundário.

Agora, o que você está fazendo é mover o processo de inicialização secundário ao modificar a partição / boot. O boot loader primário (mudo) não sabe onde encontrar a parte inteligente. E, assim, sua VM não inicializa.

O que você precisa fazer é o equivalente moderno do antigo processo "fdisk / mbr"; você precisa dizer ao seu MBR onde encontrar o carregador secundário.

Como você faz isso depende de qual carregador de inicialização você está usando. Pode ser "grub-install" ou "grub2-install" ou "lilo". Vai depender da variante do sistema operacional (CentOS, Ubuntu, Debian, Amazon ... eles podem ser diferentes).

Isso não diz a você o que faz para consertar sua compilação, mas pelo menos, agora, você deve entender por que seu sistema operacional falha ao inicializar!

    

Answer 2

Observe que o volume de inicialização no AWS é especial, não consegui encontrar um local para confirmá-lo e explicar por quê, mas o volume raiz está anexado como sda1 (xvda1), observe o número de partição 1 em No final, consulte o link . Acho que essa pode ser a razão pela qual o BIOS não inicializa a partir de uma partição que contém uma tabela de partição e mais partições.

Eu não acho que você possa evitar usar mais de um volume se precisar de mais de uma partição (sem usar truques feios, como dispositivos de loop, anexados a arquivos grandes na partição raiz: D).