Nikita Kipriyanov's questions

Todo mundo parece estar usando o GRUB para inicializar máquinas UEFI via PXE da rede. Embora funcione, falta um recurso importante para poder direcionar imediatamente determinados clientes conhecidos. GRUB apenas solicita grub/grub.cfgimediatamente.

O PXELINUX possui a seguinte funcionalidade: antes de carregar a configuração "default", ele tenta alguns nomes especiais, derivados do endereço MAC e do endereço IP do cliente. Por exemplo, para um cliente que possui IP 172.31.1.38(que é hexadecimal AC1F0126) e MAC BC:24:11:21:4D:14ele tentará carregar uma configuração do servidor TFTP na seguinte ordem:

pxelinux.cfg/01-bc-24-11-21-4d-14
pxelinux.cfg/AC1F0126
pxelinux.cfg/AC1F012
pxelinux.cfg/AC1F01
pxelinux.cfg/AC1F0
pxelinux.cfg/AC1F
pxelinux.cfg/AC1
pxelinux.cfg/AC
pxelinux.cfg/A
pxelinux.cfg/default

Portanto, com o PXELINUX posso criar arquivos de configuração dedicados para determinados clientes conhecidos, onde posso incluir uma referência a um script de pré-configuração ou kickstart que foi especialmente criado para esse cliente. Ele realizaria uma instalação totalmente autônoma do sistema, e tudo isso seria usado na automação (tanto para gerar VMs quanto para preparar servidores bare metal). Quando a instalação é iniciada, ele apenas remove a configuração do bootloader dedicado, então da próxima vez a máquina inicializará pela rede, mas agora irá acessar o defaultarquivo de configuração que instrui a inicializar a partir de um disco rígido local. Na verdade, administrei essa infraestrutura por mais de 10 anos e foi incrível.

Mas hoje em dia precisamos ter o mesmo para clientes UEFI, e o PXELINUX parece não funcionar com UEFI.

Existe uma maneira de ter funcionalidade semelhante ao GRUB PXE, para poder fazer a mesma coisa com clientes UEFI, para solicitar um arquivo de configuração dedicado ou para usar uma opção de menu de inicialização "padrão" específica do cliente de um comum arquivo de configuração?

Ou talvez exista outro bootloader UEFI PXE que seja capaz de fazer isso assim?

Na maioria dos casos, esta é uma mensagem inofensiva. Neste caso, esta conexão SSH existe apenas para encaminhar portas TCP (e usa uma chave dedicada que é restrita apenas para poder fazer isso) e deverá falhar se não puder (então o gerenciador de serviço tentará conectar novamente até encaminhar consegue).

Como forçar o SSH a considerar todos os encaminhamentos especificados obrigatórios e falhar fortemente se algum deles não tiver êxito?

O sistema é Debian 11 e SSH é OpenSSH 8.4p1, se isso for importante.

A configuração de algumas ferramentas oferece suporte a diretórios suspensos para alterar ou anexar a configuração sem alterar o arquivo de configuração distribuído, por exemplo, /etc/sudoers.de assim por diante.

Eu queria saber, o Yum suporta isso? Há /etc/yum.conf, e há diretório drop do repositório, /etc/yum.repos.d, existe um equivalente como yum.conf.ddestinado a adicionar coisas em sua [main]seção?

Isso deve funcionar no Oracle Linux 7.9, se isso for importante

O sistema é o CentOS 7. Ele foi instalado em dois discos rígidos com MD RAID, um drive morreu. Decidimos mudar para dois SSDs de tamanho apenas um pouco maior. Quando eles foram conectados e o sistema foi inicializado, sdaparecia ser um disco rígido antigo com duas partições, sda1participa md126de 500M que é /boot, e sda2participa de md127qual é o LVM PV que contém todo o resto. sdbe sdcsão novos SSDs.

Comecei a mover arrays de discos rígidos para SSDs. Eu particionei os novos dispositivos como os antigos e os adicionei em arrays, então os arrays cresceram para conter 3 dispositivos:

mdadm --add /dev/md126 /dev/sd[bc]1
mdadm --add /dev/md127 /dev/sd[bc]2
mdadm --grow -n 3 /dev/md126
mdadm --grow -n 3 /dev/md127

Depois de algum tempo, verifiquei que todos os RAIDs estavam totalmente sincronizados, removi o disco rígido dos arrays e os configurei de volta para conter 2 dispositivos cada:

mdadm -f /dev/md126 /dev/sda1
mdadm -r /dev/md126 /dev/sda1
mdadm -f /dev/md127 /dev/sda2
mdadm -r /dev/md127 /dev/sda2
mdadm --grow -n 2 /dev/md126
mdadm --grow -n 2 /dev/md127

Ambas as matrizes estão limpas. Fui instalar o bootloader em dispositivos recém-instalados:

[root@master ~]# grub2-install /dev/sdc
Installing for i386-pc platform.
grub2-install: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
grub2-install: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
grub2-install: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
grub2-install: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
Installation finished. No error reported.

Não fiquei muito feliz ao ver esses avisos e ainda não tenho certeza de que foi instalado nos dispositivos corretos. Verifiquei /boot/grub2/device.map, se referia a unidades antigas, então consertei, agora é:

# this device map was generated by anaconda
(hd0)      /dev/sdb
(hd1)      /dev/sdc
(hd2)      /dev/sda

A unidade restante será eventualmente removida e, esperançosamente, reutilizada, então eu deveria limpá-la de todos os dados (para não vazá-la):

dd if=/dev/zero of=/dev/sda bs=8k

Terminou, então tentei novamente reinstalar o grub nos SSDs, só para ter certeza:

[root@master ~]# grub2-install /dev/sdb
Installing for i386-pc platform.
grub2-install: error: disk `mduuid/85faee0a366da795c6ac33a7c4a48ae8' not found.

A primeira linha apareceu instantaneamente, a mensagem de erro foi atrasada em 10 segundos. O mesmo para o segundo SSD.

Se eu fizer o /dev/sda1novamente e adicioná-lo ao array, aumentando-o adequadamente para 3 dispositivos, ele mostrará:

[root@master /]# grub2-install /dev/sdb
Installing for i386-pc platform.
grub2-install: error: unknown filesystem.

Tenho certeza de que contém um sistema de arquivos de inicialização válido. Separei do RAID e verifiquei, está lá:

[root@master /]# blkid -p /dev/sda1
/dev/sda1: UUID="85faee0a-366d-a795-c6ac-33a7c4a48ae8" UUID_SUB="bc7af7ca-09f2-f533-3a79-53d98f5dd09a" LABEL="master.service.intrid.ru:boot" VERSION="1.0" TYPE="linux_raid_member" USAGE="raid" PART_ENTRY_SCHEME="dos" PART_ENTRY_TYPE="0xfd" PART_ENTRY_FLAGS="0x80" PART_ENTRY_NUMBER="1" PART_ENTRY_OFFSET="2048" PART_ENTRY_SIZE="1046528" PART_ENTRY_DISK="8:0" 
[root@master /]# tune2fs -l /dev/md126 | grep feat
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
[root@master /]# mdadm -f /dev/md126 /dev/sda1
mdadm: set /dev/sda1 faulty in /dev/md126
[root@master /]# mdadm -r /dev/md126 /dev/sda1
mdadm: hot removed /dev/sda1 from /dev/md126
[root@master /]# tune2fs -l /dev/sda1 | grep feat
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize

Muito estranho.

Agora estou preso. O sistema funciona bem, todos os sistemas de arquivos estão bem, atende clientes. Por exemplo, /bootestá montado e está disponível, eu desmontei e verifiquei, depois montei novamente.

A Internet está cheia de sugestões para reiniciar o sistema a partir da mídia ao vivo de resgate, ou até mesmo como corrigir isso depois que o grub foi colocado no shell de resgate na reinicialização. Alguns dos recursos que verifiquei:

• https://ahelpme.com/linux/grub2-grub-install-error-disk-mduuid-not-found-even-after-the-partition-has-bios_grub-on/
• erro grub2-install - disco não encontrado (que não é respondido, a propósito)
• https://linoxide.com/fix-grub-filesystem-type-unknown-error-on-centosredhat/
• https://www.linuxquestions.org/questions/linux-newbie-8/centos-7-error-unknown-filesystem-grub-rescue-4175687414/

No entanto, ainda não o reiniciei e não quero, até ter certeza de que ele será inicializado, porque é remoto e as pessoas ao redor não poderão consertar o bootloader. Já troquei dispositivos assim várias vezes antes, não me lembro desses problemas, porém isso sempre foi feito com Gentoo ou Debian que costumam ter softwares mais recentes que o CentOS.

Então, é possível corrigir o bootloader do sistema, remotamente, sem inicializar a mídia de recuperação? Provavelmente, dizendo ao grub para não verificar nada e apenas escrever as coisas necessárias em locais apropriados na mídia?

Ajudará se eu despejar um /bootsistema de arquivos, recriar a matriz que o contém do zero e gravar a imagem de volta? Como faço para recriar o initramfs depois?