Це, мабуть, слід оновити, оскільки велика кількість наданої тут інформації вводить в оману і, можливо, ніколи не була всебічно коректною.
https://bootlin.com/blog/find-root-device/
Щодо / точки монтажу, тобі просто сказали, що вона відповідає / dev / root, що не є реальним пристроєм, який ти шукаєш.
Звичайно, ви можете подивитися в командному рядку ядра і побачити, на якій початковій кореневій файловій системі Linux було доручено завантажуватись (кореневий параметр):
$ cat / proc / cmdline mem = 512M console = ttyS2,115200n8 root = / dev / mmcblk0p2 rw rootwait
Однак це не означає, що ви бачите поточний кореневий пристрій. Багато систем Linux завантажуються на проміжні кореневі файлові системи (наприклад, initramdisks та initramfs), які просто використовуються для доступу до остаточної.
Одне, на що вказується, було те, що річ у / proc / cmdline не обов'язково є фактичним кінцевим кореневим пристроєм.
Це від людей зайнятих, які, напевно, знають, про що вони говорять, коли справа стосується завантажувальних ситуацій.
https://www.linuxquestions.org/questions/slackware-14/slackware-current-dev-root-688189/page2.html
Другий корисний ресурс, який я знайшов, - це дуже стара програма Slackware щодо питання / dev / root, з епохи цієї теми ми бачимо, що всі варіанти завжди були присутніми, але я вважаю, що у більшості дистрибутивів використовувались символічні метод посилання, але це був простий перемикач компіляції ядра, він міг зробити один, або не зробити його, якщо я правильно зрозумів плакати, тобто переключити його в один бік і readlink / dev / root повідомляти про справжнє ім’я пристрою, переключити його інший, і це не так.
Оскільки головна тема цієї теми полягала в тому, як позбутися / dev / root, вони мусили вникнути в те, що воно є насправді, що це робить, тощо. Це означає, що вони повинні були зрозуміти це, щоб позбутися.
gnashly це добре пояснив:
/ dev / root - це загальний пристрій, який можна використовувати у fstab. Можна також використовувати "rootfs". Це робить певну перевагу тим, що дозволяє бути менш конкретними. Що я маю на увазі, якщо кореневий розділ знаходиться на зовнішньому диску, він не завжди може відображатися як той самий пристрій і успішно монтувати його, як / вимагає змінити fstab, щоб відповідати правильному пристрою. Використовуючи / dev / root, він завжди відповідатиме будь-яким пристроєм, вказаним у параметрах завантаження ядра від lilo або grub.
/ dev / root завжди був віртуальною точкою кріплення, навіть якщо ви його ніколи не бачили. Так само є rootfs (порівняйте це зі спеціальними віртуальними пристроями, такими як proc і tmpfs, які не мають попереднього / dev)
/ dev / root - це віртуальний пристрій на зразок 'proc' або / dev / tcp '. Немає вузла пристрою в / dev для цих речей - він вже є в ядрі як віртуальний пристрій.
Це пояснює, чому символічне посилання не обов'язково існує. Я здивований, що ніколи до цього не звертався до цього питання, враховуючи, що я підтримую деякі програми, які мають знати цю інформацію, але краще пізно, ніж ніколи.
Я вважаю, що деякі запропоновані тут рішення "часто" спрацюють, і, мабуть, я буду робити це, але вони не є справжнім справжнім рішенням проблеми, яке, як зазначив автор зайнятої скриньки, значно складніше реалізувати в дуже надійний спосіб.
[ОНОВЛЕННЯ:} Після отримання даних про тестування користувачів, я переходжу до методу кріплення, який, здавалося б, у деяких випадках нормально. / Proc / cmdline не був корисним, оскільки варіантів занадто багато. У першому прикладі ви бачите старий метод. Це все рідше і рідше, оскільки сильно не рекомендується використовувати його (оригінальний синтаксис / original / dev / sdx [0-9]), оскільки ці шляхи можуть динамічно змінюватися (міняти порядок диска, вставляти новий диск тощо) і раптом / dev / sda1 стає / dev / sdb1).
root=/dev/sda1
root=UUID=5a25cf4a-9772-40cd-b527-62848d4bdfda
root=LABEL=random string
root=PARTUUID=a2079bfb-02
VS дуже чистий і простий для розбору:
mount
/dev/sda1 on / type ext4 (rw,noatime,data=ordered)
Що стосується cmdline, ви побачите, єдиний варіант, який є правильним "відповіддю" в теорії, це перший, застарілий, оскільки ви не повинні посилати корінь на рухому ціль типу / dev / sdxy
Наступні два потребують виконання подальших дій для отримання символічного посилання з цього рядка або в / dev / disk / by-uuid або / dev / disk / by-label
Останнє вимагає, я вважаю, використовуючи parted -l, щоб знайти те, на що вказує цей розділений ідентифікатор.
Це лише ті варіанти, які я знаю і бачив, цілком можуть бути й інші, наприклад GPTID.
Тому рішення, яке я використовую, таке:
спочатку подивіться, чи / dev / root є символічним посиланням. Якщо це так, переконайтеся, що це не / dev / disk / by-uuid або by-label, якщо це так, вам потрібно зробити другий крок обробки, щоб отримати останній реальний шлях. Залежить від інструменту, який ви використовуєте.
Якщо у вас нічого немає, тоді перейдіть на гору і подивіться, як це. Як останній випадок, який я не використовую, тому що аргументи, подані проти нього, навіть не обов'язково фактичний розділ чи пристрій, про які йдеться, досить хороші для мене, щоб відхилити це рішення для моєї програми. mount не є надійним рішенням, і я впевнений, що даючи достатньо зразків, було б легко знайти випадки, коли це зовсім не так, але я вважаю, що ці два випадки охоплюють "більшість" користувачів, що все, що мені потрібно.
Найприємнішим, найчистішим та найнадійнішим рішенням було б ядро просто завжди робити символічне посилання, яке б нікому і нікому не зашкодило, і називати це хорошим, але це не так, як це спрацювало в реальному світі. .
Я не розглядаю жодне з них як «хороші чи надійні» рішення, але, можливо, варіант кріплення задовольняє «досить хороший» варіант, і якщо потрібне справді надійне рішення, використовуйте речі, які рекомендується зайняти.