USB configurado para / dev / sda em vez de / dev / sdb

Question

Eu tenho tentado usar um arquivo de kickstart para guiar o instalador do Red Hat (RHEL6.5) sem a intervenção do usuário. Ele procura corretamente pelo arquivo de kickstart em /dev/sdb/fs.cfg , mas como o USB é reconhecido como /dev/sda , ele está localizado em /dev/sda/fs.cfg . Eu posso apontar manualmente o instalador para este destino, mas o resto do arquivo de kickstart depende de ter o disco rígido nativo sendo sda . Eu gostaria de fazer isso sem editar os arquivos do kickstart, mas é o que é necessário, estou disposto a fazê-lo.

Existe alguma maneira de forçar o kernel a reconhecer o USB como sdb e o HD como sda (suponho que o kernel seja responsável pela confusão, mas não tenho certeza)? Parece muito estranho que escolha uma unidade externa (o USB) como sda e força o interno (HD) a sdb.

Observação: meu problema é muito semelhante a este , exceto que meu arquivo de kickstart depende absolutamente do HD sendo sda

Esse problema ocorre apenas para o instalador do RHEL6.5 e não para o instalador do RHEL5.X (não tentei nenhuma versão anterior do RHEL6.X). O que eu realmente quero saber é por que são mudanças entre versões.

    

Answer 1

Ok, aqui está a maneira como o processo de inicialização funciona:

• firmware > bootloader talvez > kernel ${parameters} > initramfs > userspace talvez

Em um disco de instalação do redhat, o sistema de scripts dracut é o que constrói e constitui o initramfs e seu sistema de instalação anaconda constitui o espaço do usuário final.

É udev que lida com a configuração do dispositivo - como em, ele nomeia os dispositivos em /dev . Mas isso quase sempre acontece duas vezes - uma vez no initramfs e novamente quando o init dentro encontrou seu dispositivo raiz de destino e está pronto para montar um devfs nele.

Então é assim que funciona:

• O carregador de inicialização (ou firmware) invoca o kernel com um conjunto de parâmetros opcional e uma imagem initramfs opcional. Este conjunto de parâmetros é salvo em /proc/cmdline e o kernel ignora todos os parâmetros que não entende.

• O initramfs é um espaço de usuário do linux em funcionamento. Se seu conteúdo / é descompactado de uma imagem entregue na invocação ou se eles são compilados não importa - desde o kernel 2.6, ele é sempre o primeiro sistema de arquivos raiz que o kernel do Linux monta. A partir deste ponto, o kernel do Linux deixa tudo para o espaço do usuário.

  • Normalmente (como é verdade para o dracut do redhat) o initramfs contém apenas o que é absolutamente necessário para encontrar um dispositivo raiz e montá-lo sobre si mesmo. Geralmente tudo o que está incluído é busybox e os módulos do kernel necessários para montar seu dispositivo raiz de destino.

  • Provavelmente precisa de udev para fazer isso, por isso udev é mais frequentemente incluído - com o seu próprio pequeno conjunto de regras.

  • Como mencionado, o initramfs é seu próprio sistema de arquivos raiz de linux completo. Um completo pode parecer com: /bin /etc /dev /new_root /proc /sys init . Geralmente não há nada muito incomum sobre qualquer conteúdo desses diretórios - quase sempre há um /bin/sh e um /etc/fstab .

  • A maioria dos init s irá analisar /proc/cmdline para quaisquer parâmetros de kernel que eles possam interpretar. Um muito comum é root=/dev/somedisk ou root=UUID=somediskUUID ou root=LABEL=somedisklabel . É o initramfs init que interpreta esses parâmetros root=... - não o kernel ou o% finalinit executado depois (embora o último possa muito bem interpretar outros) . Ele aceitará esse parâmetro e o montará em /new_root (ou qualquer outro nome usado para a montagem de preparação antes de switchroot s) . Se udev for incluído no initramfs, então é o conjunto de regras initramfs que decide a que a entrada /dev/... do disco de destino é nomeada agora, mas isso pode mudar.

  • Quando o initramfs init localiza e monta com êxito o dispositivo /new_root , ele geralmente procura algo em que o exec está - geralmente /new_root/bin/init - então, qualquer que seja o programa, ele se torna pid1. isso com o programa switch_root fornecido com busybox - que faz um exec enquanto monta simultaneamente /new_root sobre / . Seu processo é descrito nos documentos do kernel, assim :

  But initramfs is rootfs: you can neither pivot_root rootfs, nor umount it. Instead delete everything out of rootfs to free up the space (find -xdev / -exec rm '{}' ';'), overmount rootfs with the new root (cd /newmount; mount --move . /; chroot .), attach stdin/stdout/stderr to the new /dev/console, and exec the new init.

• O dispositivo root init apenas executado agora precisa preencher seu próprio sistema de arquivos raiz. Ele chama seu udev e monta seu próprio devfs on /dev com base em seu próprio conjunto de regras e faz todo o resto. Quando estiver pronto, você estará pronto para usar seu computador.

Desculpe pelo nível de detalhes, mas eu queria deixar claro o seguinte:

• qualquer parâmetro do kernel que você entregar do bootloader como root=/dev/sda não tem para ser o mesmo /dev/sda que você eventualmente acessará em /dev/sda depois que o initramfs /init for através.

Então, uma maneira de fazer isso, eu acho, é definir uma regra udev em seu disco anaconda - que é na verdade um arquivo squashfs, provavelmente - que instrui para configurar todos os discos usb Em outro lugar. Há um excelente exemplo aqui:

KERNEL=="sd*", SUBSYSTEMS=="scsi", ATTRS{model}=="USB 2.0 Storage Device", SYMLINK+="usbhd%n"

E seria uma coisa muito boa se você ler o restante desse link também. Você deve ser capaz de fazer isso para que seu dispositivo de disco usb seja /dev/sda para initramfs - para que você não precise alterar configurações de carregador de inicialização - mas depois cria um nó para o mesmo disco que /dev/usba para o sistema de instalação anaconda .

    

Answer 2

entre no BIOS do host e reorganize a ordem dos discos rígidos e das unidades removíveis. Isso ajustará a ordem como aparece no kernel do Linux.

    

Answer 3

No meu brilhante, porém antigo, laptop HP G60 de US $ 45, eu estava tendo o mesmo problema. Eu fiz o USB passar de /dev/sda para /dev/sdb colocando o novo SSD primeiro na ordem de inicialização. Então, na inicialização, pressione ESC como se estivesse entrando no BIOS, mas há um menu preBIOS. Então, ao invés de apertar F10 para entrar no BIOS, pressionei F9 para BOOT OPTIONS. Então, lá você pode escolher manualmente inicializar a partir do USB, independentemente do BOOT ORDER definido no BIOS. Obviamente eu escolhi o USB e depois na instalação meu SSD estava mostrando como /dev/sda .

Eu pesquisei e pesquisei e muitas pessoas têm problemas semelhantes, mas ninguém sugeriu isso. Muito mais simples do que qualquer outra coisa que encontrei. Eu descobri isso em um palpite.

    

Answer 4

A partir do RHEL6, você pode usar rótulos para a sua mídia de instalação, de modo que você acesse o drive / hd por um nome único e não pela nomenclatura inconsistente do kernel sdX.

Quando você cria os sistemas de arquivos na sua unidade USB, certifique-se de rotulá-los com algo como e2label ou as outras 101 maneiras de rotular o sistema de arquivos.

Uma vez marcado, você pode acessar o USB com esse nome ex: ks = hd: LABEL = seu_nome: /path/to/fs.ks

Lembre-se também que esse tipo de nomenclatura também pode ser usado para outros locais. instalar media, repos, etc ...