Analise o parâmetro root= de /proc/cmdline .
No linux, há um nó de dispositivo /dev/root . Este será o mesmo dispositivo de bloco que outro nó de dispositivo, como /dev/sdaX . Como posso resolver /dev/root para o nó de dispositivo 'real' nessa situação, para que eu possa mostrar a um usuário um nome de dispositivo sensível?
Por exemplo, posso encontrar essa situação ao analisar /proc/mounts .
Estou à procura de soluções que funcionem a partir de um script shell / python, mas não de C.
Nos sistemas em que eu olhei, /dev/root é um link simbólico para o dispositivo real, então readlink /dev/root (ou readlink -f /dev/root se você quiser o caminho completo), irá fazê-lo.
Bem, /dev/root é apenas um link simbólico para o dispositivo real, portanto você pode usar readlink(2) para descobrir onde aponta de um programa ou readlink(1) para fazer a mesma coisa em um script de shell.
Talvez eu esteja sentindo falta de algo, mas e:
mount|grep ' / '|cut -d' ' -f 1
Isso provavelmente deve ser atualizado, porque muitas das informações aqui fornecidas são enganosas e, na verdade, nunca foram completamente corretas.
For the / mount point, you are just told that it corresponds to /dev/root, which is not the real device you are looking for.
Of course, you can look at the kernel command line and see on which initial root filesystem Linux was instructed to boot (root parameter):
$ cat /proc/cmdline mem=512M console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait
However, this doesn’t mean that what you see is the current root device. Many Linux systems boot on intermediate root filesystems (like initramdisks and initramfs), which are just used to access the final one.
Uma coisa que isso indica é que a coisa em / proc / cmdline não é necessariamente a raiz do dispositivo final real na verdade.
Isso é das pessoas do busybox, que eu presumo saber do que estão falando quando se trata de situações de inicialização.
O segundo recurso útil que eu encontrei é um thread muito antigo do Slackware sobre a questão de / dev / root, a partir da idade deste thread, podemos ver que todas as variantes estavam sempre presentes, mas acredito que a maioria das distribuições foi usando o método de link simbólico, mas que era um simples switch de compilação do kernel, ele poderia fazer um, ou não fazer um se eu entendi os posters corretamente, ou seja, mude de uma maneira, e readlink / dev / root reporta o nome real do dispositivo , mude o outro, e isso não acontece.
Como o tópico principal desse tópico era como se livrar de / dev / root, eles precisavam entender o que realmente é, o que faz isso, etc., o que significa que eles precisavam entendê-lo para se livrar dele. .
gnashly explicou bem:
/dev/root is a generic device which can be used in the fstab. One can also use 'rootfs'. Doing this offers some advantage in that it allows yout to be less specific. What I mean is, if the root partition is on an external drive, it may not always show up as the same device and successfully mounting it as / would require changing the fstab to match the correct device. By using /dev/root it will always match whatever device is specified in the kernel boot paramters from lilo or grub.
/dev/root has always been present as a virtual mount point, even if you never saw it. So has rootfs (compare this to the special virtual devices like proc and tmpfs which have no preceeding /dev)
/dev/root is a virtual device like 'proc' or /dev/tcp'. There is no device node in /dev for these things -it's already in the kernel as a virtual device.
Isso explica por que um link simbólico não existe necessariamente. Estou surpreso por nunca ter atingido 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 funcionarão "com frequência" e provavelmente são o que farei, mas não são a verdadeira solução para o problema, que, como observou o autor do busybox, é significativamente mais complicado de implementar de uma maneira muito robusta.
[UPDATE:} Depois de obter alguns dados de teste do usuário, eu vou com o método de montagem, que parecia estar ok para 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 é strongmente desencorajado usá-lo (a sintaxe original do tipo / dev / sdx [0-9]) porque esses caminhos podem mudar dinamicamente (trocar a ordem do disco, inserir novo disco, etc, e de repente / dev / sda1 torna-se / dev / sdb1).
root=/dev/sda1
root=UUID=5a25cf4a-9772-40cd-b527-62848d4bdfda
root=LABEL=random string
root=PARTUUID=a2079bfb-02
VS o 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' correta na teoria é a primeira, obsoleta, já que você não deve referenciar a raiz a um alvo em movimento como / dev / sdxy
Os próximos dois requerem a ação adicional de obter o link simbólico dessa string em / dev / disk / by-uuid ou / dev / disk / by-label
O último requer que eu acredite usar o parted -l para encontrar o que esse id separado está apontando.
Isso é apenas as variantes que eu conheço e tenho visto, pode haver outros, como o GPTID, por exemplo.
Portanto, a solução que estou usando é esta:
primeiro, veja se / dev / root é um link simbólico. Se estiver, verifique se não está em / dev / disk / by-uuid ou by-label, se estiver, é necessário executar uma segunda etapa de processamento para obter o último caminho real. Depende da ferramenta que você usa.
Se você não tem nada, então vá para o monte, e veja como isso é. Como último caso de fallback, um que não estou usando porque os argumentos fornecidos contra ele nem mesmo necessariamente sendo a partição ou dispositivo em questão são bons o suficiente para eu rejeitar essa solução para o meu programa. O mount não é uma solução totalmente robusta, e tenho certeza de que, com amostras suficientes, seria fácil encontrar casos em que não é certo, mas acredito que esses dois casos cubram a maioria dos usuários, o que é tudo que eu precisava. / p>
A solução mais agradável, mais limpa e mais confiável teria sido o kernel sempre fazer o link simbólico, que não teria machucado nada nem ninguém, e chamar isso de bom, mas não foi assim que funcionou na realidade mundo. .
Eu não considero nenhuma delas como soluções 'boas ou robustas', mas a opção de montagem parece satisfazer o 'bom o suficiente', e se a solução realmente robusta for necessária, use as coisas que o busybox recomenda.