Pré instalação do GNU/Linux em uma máquina virtual

[Lerub]

Depois de tentar instalar um sistema mega antigo, usando métodos que ferraram com a tabela de partição do meu HD (fazendo aparecer a mensagem "Can't have overlapping partition", eu resolvi pré-instalart o Arch Linux em uma máquina virtual (QEMU) e transferir para o host. No máximo, eu digito uns parâmetros que fará o QEMU emular uma máquina parecida com a minha.

 

Os dois modos que pretendo fazer:

 

• Usar o comando DD para criar uma partição, formatar e instalar o necessário para que eu possa fazer o restante (na máquina host) e usar o comando DD (em uma distro Live USB) para sobrescrever o HD com a nova partição ou;
• Fazer os anteriores, mas eu formato o HD e transfiro todos os arquivos da imagem RAW para o HD e instalo o GRUB.

 

Quais são as chances disso dar certo?

[Visitante]

@Lerub pra que? qual é o seu objetivo?

[Marcos FRM]

dd é péssima ferramenta para isso. Recomendo o FSArchiver (veja a man page, que é bem explicada) -- é meu favorito. As duas configurações que talvez sejam necessárias, após a restauração, é justamente o GRUB e o initramfs. Se precisar de ideias, olhe meu script que uso para fins parecidos.

 

O legal do FSArchiver é que preserva ao máximo, dentro do possível, as configurações do sistema de arquivos original, além de permitir trocar de sistema de arquivos (com algumas limitações) na restauração das imagens. Nessa parte, garanto que EXT e XFS estão bem servidos, pois andei, junto com o desenvolvedor principal, corrigindo bugs e adicionando recursos ao longo do tempo. Algo que eu gostaria de fazer é mudar o código para, ao usar mkfs=xfs restaurando imagem com outro sistema, fazê-lo criar XFS V5 ao invés de V4. Tenho que conversar com o Francois para ver que ele acha.

 

Atualização:

@Lerub Esqueci de dizer que o FSArchiver, para salvar sistema de arquivos, precisa que a origem seja um dispositivo de bloco. Portanto, para imagens raw, basta "losetup --show -f arquivo.raw" e usar o dispositivo loop criado como origem. Caso use qcow2, terá que converter para raw (veja a man page de qemu-img convert) para conseguir usar o losetup.

[Lerub]

3 horas atrás, Marcos FRM disse:

dd é péssima ferramenta para isso. Recomendo o FSArchiver (veja a man page, que é bem explicada) -- é meu favorito. As duas configurações que talvez sejam necessárias, após a restauração, é justamente o GRUB e o initramfs. Se precisar de ideias, olhe meu script que uso para fins parecidos.

 

O legal do FSArchiver é que preserva ao máximo, dentro do possível, as configurações do sistema de arquivos original, além de permitir trocar de sistema de arquivos (com algumas limitações) na restauração das imagens. Nessa parte, garanto que EXT e XFS estão bem servidos, pois andei, junto com o desenvolvedor principal, corrigindo bugs e adicionando recursos ao longo do tempo. Algo que eu gostaria de fazer é mudar o código para, ao usar mkfs=xfs restaurando imagem com outro sistema, fazê-lo criar XFS V5 ao invés de V4. Tenho que conversar com o Francois para ver que ele acha.

 

Atualização:

@Lerub Esqueci de dizer que o FSArchiver, para salvar sistema de arquivos, precisa que a origem seja um dispositivo de bloco. Portanto, para imagens raw, basta "losetup --show -f arquivo.raw" e usar o dispositivo loop criado como origem. Caso use qcow2, terá que converter para raw (veja a man page de qemu-img convert) para conseguir usar o losetup.

"dd=/dev/zero of=./partição.raw" É RAW. E eu pretendo (apenas) transferir a imagem para o HD. Creio que o DD já seja mais que o suficiente e não sei porque não usa-lo.

4 horas atrás, wagner2029 disse:

@Lerub pra que? qual é o seu objetivo?

Para economizar tempo. Tenho apenas um PC e isso facilita o processo.

[Marcos FRM]

Claro, para criar pode ser. Ou use "qemu-img create".

 

Estava falando em como transferir essa imagem para um disco físico. Com "dd if=./partição.raw of=/dev/sdxy" será apenas um processo "limpo" se a imagem tiver exatamente o mesmo tamanho da partição. O FSArchiver, por outro lado, é flexível e recriará o sistema de arquivos no momento da restauração mantendo as características básicas do original. Isso garante que o mesmo ocupará toda a área da partição sem precisar de redimensionamento posterior. Sistemas de arquivos como EXT e XFS têm desempenho piorado quando são redimensionados por várias ordens de magnitude.

 

Então, vamos supor que partição.raw tenha 8 GB e vá ser transferida para uma partição física de 500 GB. Com o dd, seria assim:

 

dd if=./partição.raw of=/dev/sdxy status=progress
resize2fs /dev/sdxy    # EXT2/3/4

 

Com o FSArchiver:

 

tmp_loop=$(losetup --show -f ./partição.raw)
fsarchiver savefs ./tmp_img.fsa $tmp_loop
losetup -d $tmp_loop

fsarchiver restfs ./tmp_img.fsa id=0,dest=/dev/sdxy
rm ./tmp_img.fsa

 

O sistema de arquivos em /dev/sdxy será novinho em folha e ocupará toda a área da partição, independente de seu tamanho.

[Visitante]

9 horas atrás, Lerub disse:

Para economizar tempo. Tenho apenas um PC e isso facilita o processo.

Não entendi

[Lerub]

11 horas atrás, Marcos FRM disse:

Claro, para criar pode ser. Ou use "qemu-img create".

 

Estava falando em como transferir essa imagem para um disco físico. Com "dd if=./partição.raw of=/dev/sdxy" será apenas um processo "limpo" se a imagem tiver exatamente o mesmo tamanho da partição. O FSArchiver, por outro lado, é flexível e recriará o sistema de arquivos no momento da restauração mantendo as características básicas do original. Isso garante que o mesmo ocupará toda a área da partição sem precisar de redimensionamento posterior. Sistemas de arquivos como EXT e XFS têm desempenho piorado quando são redimensionados por várias ordens de magnitude.

 

Então, vamos supor que partição.raw tenha 8 GB e vá ser transferida para uma partição física de 500 GB. Com o dd, seria assim:

 

dd if=./partição.raw of=/dev/sdxy status=progress
resize2fs /dev/sdxy    # EXT2/3/4

 

Com o FSArchiver:

 

tmp_loop=$(losetup --show -f ./partição.raw)
fsarchiver savefs ./tmp_img.fsa $tmp_loop
losetup -d $tmp_loop

fsarchiver restfs ./tmp_img.fsa id=0,dest=/dev/sdxy
rm ./tmp_img.fsa

 

O sistema de arquivos em /dev/sdxy será novinho em folha e ocupará toda a área da partição, independente de seu tamanho.

Eu não ligo se tiver que redimensionar. Mas como o DD vai piorar o desempenho? Me explique com mais detalhes isso, por favor.

8 horas atrás, wagner2029 disse:

Não entendi

Enquanto faço a pré-instalação, concluo tarefas pendentes. E sabe bem o trabalho que da instalar algumas ferramentas importantes. Deixo para fazer isso depois de concluir o que está pendente.

[Marcos FRM]

1 minuto atrás, Lerub disse:

Eu não ligo se tiver que redimensionar. Mas como o DD vai piorar o desempenho? Me explique com mais detalhes isso, por favor.

 

 

Se a diferença for grande demais, algumas estruturas do sistema de arquivos não serão "adaptadas" ao novo tamanho. Por exemplo:

 

https://github.com/tytso/e2fsprogs/issues/74

 

(nesse link o processo falha... caso extremo é verdade: EXT4 com bloco de 1 KiB...)

 

Tenho o costume de ler, quando sobra tempo, as listas de desenvolvimento do EXT4 e XFS

 

https://www.spinics.net/lists/Linux-ext4/

https://www.spinics.net/lists/Linux-xfs/

 

e os caras são claros... quando possível, evitar redimensionar, ainda mais quando o novo tamanho é muito maior do que o original -- mas não só: outro ponto problemático é quando o sistema é redimensionado várias vezes ao longo do tempo, que não será o seu caso. Não tenho links; caso interesse, use a pesquisa do Google nas duas listas que geralmente aparece coisa interessante.

 

Resumindo, provavelmente nada crítico para uso doméstico. Deixo a dica mesmo assim caso queira ter um sistema de arquivos zero quilometro. Boa sorte.

[Lerub]

18 minutos atrás, Marcos FRM disse:

 

Se a diferença for grande demais, algumas estruturas do sistema de arquivos não serão "adaptadas" ao novo tamanho. Por exemplo:

 

https://github.com/tytso/e2fsprogs/issues/74

 

(nesse link o processo falha... caso extremo é verdade: EXT4 com bloco de 1 KiB...)

 

Tenho o costume de ler, quando sobra tempo, as listas de desenvolvimento do EXT4 e XFS

 

https://www.spinics.net/lists/Linux-ext4/

https://www.spinics.net/lists/Linux-xfs/

 

e os caras são claros... quando possível, evitar redimensionar, ainda mais quando o novo tamanho é muito maior do que o original -- mas não só: outro ponto problemático é quando o sistema é redimensionado várias vezes ao longo do tempo, que não será o seu caso. Não tenho links; caso interesse, use a pesquisa do Google nas duas listas que geralmente aparece coisa interessante.

 

Resumindo, provavelmente nada crítico para uso doméstico. Deixo a dica mesmo assim caso queira ter um sistema de arquivos zero quilometro. Boa sorte.

E quanto ao "BtrFS"? Ouvi coisas boas sobre. Se eu ainda optar por usar o "DD", essa é uma boa ideia?

[Marcos FRM]

O processo é sempre o mesmo se a imagem raw tiver um tamanho menor do que a partição: despeja o sistema de arquivos com o dd e depois roda a ferramenta de cada sistema para redimensionar: resize2fs (EXT2/3/4), xfs_growfs (XFS), ...

 

Com Btrfs não tenho experiência. Procurei por cima e nem achei ferramenta para redimensionar... mas talvez eu que não saiba coisa nenhuma dele.

[Lerub]

@Marcos FRM https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-filesystem

 

Usarei o GParted. Ou CFDisk.

 

Edit:

 

Aqui tem um canal oficial, para conversar com os devs.

 

https://web.libera.chat/

[Lerub]

Tem uma outra alternativa que pretendo testar. Pré-instalar em uma VM (QEMU) e montar a imagem como loop, formatar o HD com o mesmo filesystem e depois fazer a cópia de tudo. Pode dar certo?

[Lerub]

Aí ferra. Para bootar em UEFI eu preciso instalat umas coisas que confitam com dependencias do IBus (estudo lingua japonesa).

[Lerub]

Desisto. Não deu para bootar em UEFI. Mesmo usando esses parâmetros:

 

--enable-kvm --smbios type=0,uefi=on

 

Terá que ser do jeito tradicional.

 

Edit:

 

Consegui. E graças a esse cara.

 

Pergunta iniciante (só usei MBR até então). Sei que esse modo instala um firmware. Eu não vou saber explicar. Mas, o que quero saber, é se tem alguma coisa que muda de máquina para máquina? Ou o sistema instalado em EFI pode rodar em qualquer máquina (compativel) sem conflito de hardware?

[Lerub]

• Criei a partição EFI;
• Formatei em Fat32
• Montei em /boot/efi;
• Digitei os comandos "grub-install /dev/sda" e "grub-mkconfig -o /boot/grub/grub.cfg"

E agora aparece esse erro ao tentar inicializar o sistema.

 

[Lerub]

Tentei seguir esse passo-a-passo e deu o mesmo erro.

 

 

Vou falar uma coisa. Difícilmente eu tinha problemas com Slackware. Mas eu comecei a me ocupar mais com outras coisas e não ando com tanto tempo para fazer (quase) tudo pelo sistema.

[Marcos FRM]

Se o GUID da partição EFI estiver correto ("EFI System", C12A7328-F81F-11D2-BA4B-00A0C93EC93B) e /sys, /proc, /dev, estiverem montados, basta grub-install sem argumentos em UEFI. Isso, claro, com o sistema / (raiz) e /boot/efi já montados. Rode grub-install com arch-chroot, que cuida da tarefa de montar os sistema de arquivos virtuais necessários.

[Marcos FRM]

Hmm, lembrei de uma coisa. O grub-install não configura o bootloader "fallback". Copie-o para o local correto:

 

arch-chroot /mnt grub-install
arch-chroot /mnt install -Dp /boot/efi/EFI/arch/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI

 

/mnt é o ponto de montagem da instalação (raiz), com /mnt/boot/efi montado na partição EFI.

 

Talvez o QEMU precise dele...

[Lerub]

Resultados:

 

OS COMANDOS:

 

O RESULTADO:

 

Em alguns quesitos, a instalação EFI tem que melhorar.

 

Alias, isso não impede de instalar um sistema que só é possível instalr em MBR, né? Sem mudar o setor de boot, mas inserindo as entradas no grub.

[Marcos FRM]

Ahh, sim, /boot/efi/EFI/GRUB/grubx64.efi pois você deve ter seguido a Wiki e usado a opção "--bootloader-id=GRUB" do grub-install. Acho uma recomendação ruim, pois o grub-install por padrão usa, em UEFI, o nome da distribuição ("arch"), que é bem mais descritivo -- mas, enfim, não serei eu a ter esse embate lá.

 

Nota: tradicionalmente o GRUB espera a ESP (/dev/sda1 aí) estar em /boot/efi ao invés de /boot. Contudo, funciona também em /boot. Há um longo debate sobre isso, onde seria o ponto de montagem mais "correto".

 

1 hora atrás, Lerub disse:

Em alguns quesitos, a instalação EFI tem que melhorar.

 

Haha, Arch é assim mesmo. Bem-vindo! 

 

Observação: o Debian tem um patch no seu pacote adicionando a opção "--force-extra-removable" ao grub-install, que faz essa cópia automaticamente. É uma pena não trabalharem para adicionar ao GRUB upstream, para estar disponível em outras distribuições. A balcanização do ecossistema vem diminuindo, porém ainda existe né...

 

1 hora atrás, Lerub disse:

Alias, isso não impede de instalar um sistema que só é possível instalr em MBR, né? Sem mudar o setor de boot, mas inserindo as entradas no grub.

 

Não entendi.

[Lerub]

@Marcos FRM "Legacy Boot". Eu pretendo revisitar uma distro da qual eu não sei se tem supórte a EFI. Ainda é possível mandar o GRUB bootar Legacy, ou eu precisarei reinstalar o bootloader?

[Marcos FRM]

Esse mesmo GRUB do Arch em UEFI? Não sei. Tem que ver se nesse modo tem como o GRUB carregar o kernel via CSM (talvez usando linux16). Isso pressupondo que o QEMU ofereça emulação de CSM. Nunca tentei; chuto que não funcione, porém só passando trabalho para ter certeza. 

[Lerub]

@Marcos FRMEu já usei o GRUB (Legacy) instalado em meu HD para bootar uma imagem de disquete do MS-DOS (Win9x pra baixo) usando Linux16. Talvez, creio eu.

[Denis Bopp]

Essa instalação foi feita no virtual box? Tem um bug que falha o boot em instalações EFI.

[Lerub]

@Denis Bopp Denis, você tem que ler mais. Eu deixei claro no texto que usei o QEMU.