Descubra qual dispositivo / dev / root representa no Linux?

No Linux, há um /dev/rootnó de dispositivo. Este será o mesmo dispositivo de bloco que outro nó do dispositivo, como /dev/sdaX. Como posso resolver /dev/rooto nó do dispositivo 'real' nessa situação, para poder mostrar ao usuário um nome de dispositivo sensível?

Por exemplo, eu posso encontrar essa situação ao analisar /proc/mounts.

Estou procurando soluções que funcionem a partir de um script shell / python, mas não C.

Analise o root=parâmetro de /proc/cmdline.

Nos sistemas que eu observei, /dev/rootexiste um link simbólico para o dispositivo real; portanto readlink /dev/root(ou readlink -f /dev/rootse você quiser o caminho completo), o fará.

Bem, /dev/rooté apenas um link simbólico para o dispositivo real, para que você possa readlink(2)descobrir onde ele aponta em um programa ou readlink(1)fazer a mesma coisa em um script de shell.

Talvez esteja faltando alguma coisa, mas e quanto a:

mount|grep ' / '|cut -d' ' -f 1

Provavelmente, isso deve ser atualizado, porque muitas das informações fornecidas aqui são enganosas e, na verdade, talvez nunca tenham sido totalmente corretas.

https://bootlin.com/blog/find-root-device/

Para o ponto de montagem /, você acabou de dizer que corresponde a / dev / root, que não é o dispositivo real que você está procurando.

Obviamente, você pode olhar a linha de comando do kernel e ver em qual sistema de arquivos raiz inicial o Linux foi instruído a inicializar (parâmetro raiz):

$ cat / proc / cmdline mem = 512M console = ttyS2,115200n8 root = / dev / mmcblk0p2 rw rootwait

No entanto, isso não significa que o que você vê é o dispositivo raiz atual. Muitos sistemas Linux inicializam em sistemas de arquivos raiz intermediários (como initramdisks e initramfs), que são usados ​​apenas para acessar o final.

Uma coisa que ressalta é que a coisa em / proc / cmdline não é necessariamente a raiz final do dispositivo real.

Isso é do pessoal do busybox, que suponho que sabe do que está falando quando se trata de situações de inicialização.

https://www.linuxquestions.org/questions/slackware-14/slackware-current-dev-root-688189/page2.html

O segundo recurso útil que encontrei é um tópico muito antigo do Slackware sobre a questão de / dev / root. Desde a idade desse tópico, podemos ver que todas as variantes estavam sempre presentes, mas acredito que a maioria das distros usava o simbólico link, mas essa era uma opção simples de compilação do kernel; ela poderia criar uma, ou não, se eu entendesse os pôsteres corretamente, ou seja, alterne de uma maneira e o readlink / dev / root relate o nome real do dispositivo, alterne-o o outro, e não.

Como o tópico principal desse tópico era como se livrar do / dev / root, eles precisavam entender o que realmente é, o que o torna, etc., o que significa que eles tinham que entender para se livrar dele.

Gnashly explicou bem:

/ dev / root é um dispositivo genérico que pode ser usado no fstab. Pode-se também usar 'rootfs'. Isso oferece algumas vantagens, pois permite que você seja menos específico. O que quero dizer é que, se a partição raiz estiver em uma unidade externa, ela poderá nem sempre aparecer como o mesmo dispositivo e montá-la com êxito, pois exigiria a alteração do fstab para corresponder ao dispositivo correto. Ao usar / dev / root, ele sempre corresponderá a qualquer dispositivo especificado nos parâmetros de inicialização do kernel do lilo ou grub.

O / dev / root sempre esteve presente como um ponto de montagem virtual, mesmo que você nunca o tenha visto. Assim como o rootfs (compare isso com os dispositivos virtuais especiais, como proc e tmpfs, que não possuem / dev)

/ dev / root é um dispositivo virtual como 'proc' ou / dev / tcp '. Não existe um nó de dispositivo no / dev para essas coisas - ele já está no kernel como um dispositivo virtual.

Isso explica por que um link simbólico não existe necessariamente. Estou surpreso por nunca ter encontrado esse problema antes, já que mantenho alguns programas que precisam conhecer essas informações, mas antes tarde do que nunca.

Acredito que algumas das soluções oferecidas aqui 'frequentemente' funcionem, e provavelmente são o que farei, mas elas não são a verdadeira solução real para o problema, que, como observou o autor do busybox, é significativamente mais complicado de implementar de uma maneira muito maneira robusta.

[UPDATE:} Depois de obter alguns dados de teste do usuário, seguirei o método mount, que parecia estar bom em alguns casos, pelo menos. O / proc / cmdline não foi útil porque há muitas variantes. No primeiro exemplo, você vê o método antigo. Isso é cada vez menos comum, porque é fortemente desencorajado usá-lo (a sintaxe original do tipo / dev / sdx [0-9]) porque esses caminhos podem mudar dinamicamente (trocar a ordem do disco, inserir um novo disco etc.) e de repente / dev / sda1 se torna / dev / sdb1).

root=/dev/sda1
root=UUID=5a25cf4a-9772-40cd-b527-62848d4bdfda
root=LABEL=random string
root=PARTUUID=a2079bfb-02

VS muito limpo e fácil de analisar:

mount
/dev/sda1 on / type ext4 (rw,noatime,data=ordered)

No caso do cmdline, você verá que a única variante que é a 'resposta certa' na teoria é a primeira, obsoleta, pois você não deve referir raiz a um destino móvel como / dev / sdxy

Os próximos dois exigem executar a ação adicional de obter o link simbólico dessa sequência em / dev / disk / by-uuid ou / dev / disk / by-label

O último requer que eu acredite que use parted -l para encontrar o que esse id parted está apontando.

Essas são apenas as variantes que eu conheço e já vi; bem, pode haver outras, como o GPTID, por exemplo.

Portanto, a solução que estou usando é a seguinte:

primeiro, veja se / dev / root é um link simbólico. Se for, verifique se não é / dev / disk / by uuid ou by label, se for, você precisa executar uma segunda etapa de processamento para obter o último caminho real. Depende da ferramenta que você usa.

Se você não conseguiu nada, vá para a montagem e veja como é. Como último caso de fallback, um que não estou usando, porque os argumentos dados contra ele, nem mesmo sendo necessariamente a partição ou o dispositivo real em questão, são bons o suficiente para rejeitar essa solução para o meu programa. mount não é uma solução totalmente robusta e, com certeza, com amostras suficientes, seria fácil encontrar casos em que não está certo, mas acredito que esses dois casos abranjam a maioria dos usuários, o que é tudo o que eu precisava.

A solução mais legal, mais limpa e mais confiável seria o kernel sempre criar o link simbólico, o que não faria mal a ninguém ou a ninguém, e chamaria de bom, mas não foi assim que aconteceu no mundo real. .

Não considero nenhuma dessas soluções como 'boas ou robustas', mas a opção de montagem parece satisfazer as 'boas o suficiente' e, se a solução realmente robusta for necessária, use o material recomendado pelo busybox.