Não é possível obter o USB do Red Hat 7 fora do modo de Emergência, (vi / etc / fstab não mostrando nada)

0

Estou tendo um problema com um USB inicializável que eu fiz. Então este é um projeto em andamento no qual eu tenho trabalhado por um tempo agora. Basicamente, eu instalei o red hat 7 em um usb para que o usb seja essencialmente o sistema operacional. Em seguida, emiti os seguintes comandos para tentar capturar esse "live USB" em um arquivo .raw.gz para redistribuição:

  if=/dev/sda bs=10000 count=500000 status=progress | gzip > newredhat.raw.gz

A tarefa acima captura os primeiros 5GB do USB inicializável e os armazena em uma imagem chamada newredhat.raw.gz como um arquivo .raw compactado. O processo está funcionando como deveria, exceto por uma coisa. Em seguida, emita o seguinte comando para colocar essa imagem personalizada em outro USB que tenha sido formatado como fat32 e esteja 100% limpo:

 zcat newredhat.raw.gz > /dev/sdc

Após a extração / gravação ser feita, o novo USB inicializa como deveria, no entanto, ele é inicializado no modo de emergência. Eu tenho procurado horas sobre o que o raciocínio por trás disso poderia ser, mas vendo como este é sem dúvida um cenário muito original, não há muito sobre isso. Eu tentei o vi / etc / fstab e ele me diz que o / etc / fstab não existe e cria um novo arquivo para editar. Eu também olhei para o diário e a única coisa que volta é "falha em montar o sysroot". A ideia por trás de todo este projeto é que ele pode ser um simples extrato - vá clonar meus USBs e servidores baseados em Linux. O que é realmente estranho é que este método exato funcionou para o openSUSE. É algo a ver com a maneira como a Red Hat cria sua arquitetura após a instalação? Se este for o caso, há algum trabalho por aí? Agradecemos antecipadamente por toda a ajuda!

    
por RickwhoPrograms 23.07.2018 / 16:56

1 resposta

1

1) O parâmetro bs para dd é o tamanho do bloco . Se isso não for uma potência de dois e, em particular, se esse não for o tamanho do bloco do seu dispositivo, você está fazendo errado. Nesse caso, não use dd em primeiro lugar.

2) Dependendo de como você definiu exatamente o primeiro dispositivo USB (você não nos informou), os primeiros 5 GB podem ter perdido a tabela de partições no final.

A maneira segura de copiar entre mídias de armazenamento de tamanhos diferentes é criar uma tabela de partição em cada uma delas com uma única partição inicializável de tamanho idêntico (usando qualquer programa de partição desejado) e copiar a partição completa

gzip /dev/sda1 > newredhat.raw.gz
zcat newredhat.raw.gz > /dev/sdc1

Dessa forma, a tabela de partições pode compensar dispositivos de tamanhos diferentes.

Isso também funciona entre dispositivos USB e discos rígidos.

3) Para depurar o que acontece com o segundo pendrive, seria extremamente útil olhar as mensagens que ele mostra antes entrar no modo de emergência. dmesg ou logs ajudará se ele for rolado para rápido. Portanto, edite a pergunta com as mensagens verbatim que você vê antes de reclamar "falha ao montar o sysroot". Eu tenho um palpite é porque você estragou a tabela de partições (veja acima). E a tabela de partições detectada deve aparecer no dmesg / logs. E se "o mesmo método funcionou para o openSUSE", isso pode ser porque o openSUSE usou um esquema de particionamento diferente, e / ou seus pen drives USB eram do mesmo tamanho.

Editar

Um problema em apenas copiar o início de todo o dispositivo USB é que, por exemplo, um GPT também terá informações em o fim mesmo. Embora isso seja uma informação duplicada, pode causar problemas.

Então, novamente: Em vez de copiar apenas o primeiro 5G de um stick 32G para um stick 16G, faça uma partição de tamanho 5G no primeiro stick, faça uma partição exatamente do mesmo tamanho no segundo stick, então copie o < em> partition (/ dev / sda1), não o stick inteiro (/ dev / sda). Você pode criar partições com fdisk , gdisk , parted ou o que quiser. Você não precisa calcular nada, você só precisa garantir que as partições tenham exatamente o mesmo tamanho.

    
por 24.07.2018 / 09:18