Scopri quale dispositivo /dev/root rappresenta in Linux?

Analizza il root= parametro da /proc/cmdline .

Sui sistemi che ho esaminato, /dev/root è un collegamento simbolico al dispositivo reale, quindi readlink /dev/root (o readlink -f /dev/root se vuoi il percorso completo), lo farà.

Questo dovrebbe probabilmente essere aggiornato, perché molte delle informazioni fornite qui sono fuorvianti e potrebbero non essere mai state completamente corrette.

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

Per il punto di montaggio /, ti viene semplicemente detto che corrisponde a /dev/root, che non è il vero dispositivo che stai cercando.

Naturalmente, puoi guardare la riga di comando del kernel e vedere su quale filesystem root iniziale Linux è stato istruito ad avviarsi (parametro root):

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

Tuttavia, ciò non significa che ciò che vedi sia l'attuale dispositivo root. Molti sistemi Linux si avviano su filesystem root intermedi (come initramdisks e initramfs), che sono usati solo per accedere a quello finale.

Una cosa che questo sottolinea è che la cosa in /proc/cmdline non è necessariamente l'effettiva root del dispositivo finale su cui effettivamente vive.

Viene dalle persone di busybox, che presumo sappiano di cosa parlano quando si tratta di situazioni di avvio.

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

La seconda risorsa utile che ho trovato è un thread Slackware molto vecchio sulla questione di /dev/root, dall'età di questo thread, possiamo vedere che tutte le varianti erano sempre presenti, ma credo che "la maggior parte" delle distribuzioni utilizzasse il simbolico link metodo, ma quello era un semplice switch di compilazione del kernel, potrebbe crearne uno o non crearne uno se ho capito correttamente i poster, ovvero cambiarlo in un modo e readlink /dev/root riporta il nome del dispositivo reale, cambialo l'altro, e non lo fa.

Poiché l'argomento principale di quel thread era come sbarazzarsi di /dev/root, dovevano entrare in ciò che effettivamente è, cosa lo rende, ecc., il che significa che dovevano capirlo per sbarazzarsene.

gnashly l'ha spiegato bene:

/dev/root è un dispositivo generico che può essere utilizzato in fstab. Si può usare anche 'rootfs'. Questa operazione offre alcuni vantaggi in quanto consente di essere meno specifici. Quello che voglio dire è che, se la partizione root si trova su un'unità esterna, potrebbe non essere sempre visualizzata come lo stesso dispositivo e montarla correttamente come / richiederebbe la modifica di fstab in modo che corrisponda al dispositivo corretto. Usando /dev/root corrisponderà sempre a qualunque dispositivo sia specificato nei parametri di avvio del kernel da lilo o grub.

/dev/root è sempre stato presente come punto di montaggio virtuale, anche se non l'hai mai visto. Così ha rootfs (confrontalo con gli speciali dispositivi virtuali come proc e tmpfs che non hanno /dev precedente)

/dev/root è un dispositivo virtuale come 'proc' o /dev/tcp'. C'è un nodo nodevice in /dev per queste cose:è già nel kernel come dispositivo virtuale.

Questo spiega perché un collegamento simbolico non esiste necessariamente. Sono sorpreso di non aver mai riscontrato questo problema prima d'ora, dato che mantengo alcuni programmi che devono conoscere queste informazioni, ma meglio tardi che mai.

Credo che alcune delle soluzioni offerte qui funzioneranno "spesso" e sono probabilmente ciò che farò, ma non sono la vera soluzione effettiva al problema, che come ha notato l'autore di busybox, è significativamente più complicato da implementare in modo molto modo robusto.

[UPDATE:} Dopo aver ottenuto alcuni dati di test utente, vado con il metodo di montaggio, che sembrava essere ok almeno per alcuni casi. La /proc/cmdline non è stata utile perché ci sono troppe varianti. Nel primo esempio, vedi il vecchio metodo. Questo è sempre meno comune perché è fortemente sconsigliato usarlo (la sintassi del tipo /dev/sdx[0-9] originale) perché quei percorsi possono cambiare dinamicamente (cambiare l'ordine del disco, inserire un nuovo disco, ecc., e improvvisamente /dev/ sda1 diventa /dev/sdb1).

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

VS molto pulito e facile da analizzare:

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

Nel caso di cmdline, vedrai, l'unica variante che è la "risposta" giusta in teoria è la prima, deprecata, dal momento che non dovresti riferire root a un bersaglio mobile come /dev/sdxy

I due successivi richiedono l'ulteriore azione di ottenere il collegamento simbolico da quella stringa in /dev/disk/by-uuid o /dev/disk/by-label

L'ultimo richiede credo di utilizzare parted -l per trovare a cosa punta l'id parted.

Queste sono solo le varianti che conosco e che ho visto, potrebbero essercene altre, come GPTID, per esempio.

Quindi la soluzione che sto usando è questa:

per prima cosa, verifica se /dev/root è un collegamento simbolico. Se lo è, verifica che non sia /dev/disk/by-uuid o by-label, se lo è, devi eseguire una seconda fase di elaborazione per ottenere l'ultimo percorso reale. Dipende dallo strumento che usi.

Se non hai niente, allora vai alla cavalcatura e guarda com'è. Come ultimo caso di fallback, uno che non sto usando perché gli argomenti forniti contro di esso non sono nemmeno necessariamente la partizione o il dispositivo effettivo in questione sono abbastanza buoni da farmi rifiutare quella soluzione per il mio programma. mount non è una soluzione completamente robusta e sono sicuro che, dati abbastanza campioni, sarebbe facile trovare casi in cui non è affatto corretto, ma credo che questi due casi coprano "la maggior parte" degli utenti, il che è tutto ciò di cui avevo bisogno.

La soluzione più bella, più pulita e più affidabile sarebbe stata che il kernel creasse sempre il collegamento simbolico, che non avrebbe danneggiato niente e nessuno, e lo definisse buono, ma non è così che ha funzionato nel mondo reale.

Non considero nessuna di queste soluzioni "buone o robuste", ma l'opzione di montaggio sembra soddisfare "abbastanza buono" e, se è richiesta la soluzione veramente robusta, usa le cose consigliate da busybox.