Parsing root= parameter dari /proc/cmdline .
Pada sistem yang saya lihat, /dev/root adalah symlink ke perangkat sebenarnya, jadi readlink /dev/root (atau readlink -f /dev/root jika Anda menginginkan jalur lengkap), akan melakukannya.
Ini mungkin harus diperbarui, karena banyak informasi yang diberikan di sini menyesatkan, dan mungkin sebenarnya tidak pernah benar secara menyeluruh.
https://bootlin.com/blog/find-root-device/
Untuk / mount point, Anda hanya diberi tahu bahwa itu sesuai dengan /dev/root, yang bukan merupakan perangkat sebenarnya yang Anda cari.
Tentu saja, Anda dapat melihat baris perintah kernel dan melihat di mana sistem file root awal Linux diinstruksikan untuk melakukan booting (parameter root):
$ cat /proc/cmdline mem=512M console=ttyS2,115200n8root=/dev/mmcblk0p2 rw roottunggu
Namun, ini tidak berarti bahwa yang Anda lihat adalah perangkat root saat ini. Banyak sistem Linux mem-boot pada sistem file root perantara (seperti initramdisks dan initramfs), yang hanya digunakan untuk mengakses yang final.
Satu hal yang ditunjukkan di sini adalah bahwa hal di /proc/cmdline belum tentu root perangkat terakhir yang sebenarnya benar-benar aktif.
Itu dari orang-orang yang sibuk, yang menurut saya tahu apa yang mereka bicarakan tentang situasi booting.
https://www.linuxquestions.org/questions/slackware-14/slackware-current-dev-root-688189/page2.html
Sumber berguna kedua yang saya temukan adalah utas Slackware yang sangat lama tentang pertanyaan /dev/root, dari usia utas ini, kita dapat melihat bahwa semua varian selalu ada, tetapi saya yakin 'kebanyakan' distro menggunakan simbolik metode tautan, tetapi itu adalah saklar kompilasi kernel sederhana, itu bisa membuatnya, atau tidak membuatnya jika saya memahami posternya dengan benar, yaitu, alihkan satu arah, dan readlink /dev/root melaporkan nama perangkat asli, alihkan yang lain, dan ternyata tidak.
Karena topik utama dari utas itu adalah bagaimana menghapus /dev/root, mereka harus memahami apa itu sebenarnya, apa yang membuatnya, dll, yang artinya, mereka harus memahaminya untuk menyingkirkannya.
menjelaskannya dengan baik:
/dev/root adalah perangkat generik yang dapat digunakan di fstab. Seseorang juga dapat menggunakan 'rootfs'. Melakukan hal ini menawarkan beberapa keuntungan karena memungkinkan Anda menjadi kurang spesifik. Yang saya maksud adalah, jika partisi root ada di drive eksternal, mungkin tidak selalu muncul sebagai perangkat yang sama dan berhasil memasangnya karena / akan memerlukan perubahan fstab agar sesuai dengan perangkat yang benar. Dengan menggunakan /dev/root akan selalu cocok dengan perangkat apa pun yang ditentukan dalam parameter boot kernel dari lilo orgrub.
/dev/root selalu hadir sebagai mount point virtual, bahkan jika Anda tidak pernah melihatnya. Begitu juga rootfs (bandingkan ini dengan perangkat virtual khusus seperti proc dan tmpfs yang tidak memiliki /dev sebelumnya)
/dev/root adalah perangkat virtual seperti 'proc' atau /dev/tcp'. Ada nodevice node di /dev untuk hal-hal ini - sudah ada di kernel sebagai perangkat virtual.
Ini menjelaskan mengapa tautan simbolik belum tentu ada. Saya heran saya tidak pernah mengalami masalah ini sebelumnya, mengingat saya mengelola beberapa program yang perlu mengetahui informasi ini, tetapi lebih baik terlambat daripada tidak sama sekali.
Saya percaya beberapa solusi yang ditawarkan di sini akan 'sering' berhasil, dan mungkin itulah yang akan saya lakukan, tetapi itu bukanlah solusi sebenarnya yang sebenarnya untuk masalah tersebut, yang seperti dicatat oleh penulis busybox, secara signifikan lebih rumit untuk diterapkan dalam waktu yang sangat lama. cara yang kuat.
[UPDATE:} Setelah mendapatkan beberapa data pengujian pengguna, saya akan menggunakan metode mount, yang tampaknya cukup baik untuk beberapa kasus setidaknya. /proc/cmdline tidak berguna karena terlalu banyak varian. Pada contoh pertama, Anda melihat metode lama. Ini semakin jarang karena sangat tidak disarankan untuk menggunakannya (sintaks tipe /dev/sdx[0-9] asli) karena jalur tersebut dapat berubah secara dinamis (menukar urutan disk, memasukkan disk baru, dll, dan tiba-tiba /dev/ sda1 menjadi /dev/sdb1).
root=/dev/sda1
root=UUID=5a25cf4a-9772-40cd-b527-62848d4bdfda
root=LABEL=random string
root=PARTUUID=a2079bfb-02
VS sangat bersih dan mudah diuraikan:
mount
/dev/sda1 on / type ext4 (rw,noatime,data=ordered)
Dalam kasus cmdline, Anda akan melihat, satu-satunya varian yang merupakan 'jawaban' yang tepat dalam teori adalah yang pertama, yang tidak digunakan lagi, karena Anda tidak boleh merujuk root ke target bergerak seperti /dev/sdxy
Dua berikutnya membutuhkan tindakan lebih lanjut untuk mendapatkan tautan simbolik dari string itu di /dev/disk/by-uuid atau /dev/disk/by-label
Yang terakhir mengharuskan saya percaya menggunakan parted -l untuk menemukan apa yang ditunjuk oleh id parted itu.
Itu hanya varian yang saya tahu dan pernah lihat, mungkin ada yang lain, seperti GPTID misalnya.
Jadi solusi yang saya gunakan adalah ini:
pertama, lihat apakah /dev/root adalah tautan simbolik. Jika ya, verifikasi bukan ke /dev/disk/by-uuid atau by-label, jika ya, Anda harus melakukan langkah pemrosesan kedua untuk mendapatkan jalur nyata terakhir. Bergantung pada alat yang Anda gunakan.
Jika Anda tidak mendapatkan apa-apa, pergi ke mount, dan lihat bagaimana itu. Sebagai kasus mundur terakhir, yang tidak saya gunakan karena argumen yang diberikan menentangnya bahkan tidak harus menjadi partisi atau perangkat yang sebenarnya cukup baik bagi saya untuk menolak solusi itu untuk program saya. mount bukanlah solusi yang sepenuhnya kuat, dan saya yakin dengan sampel yang cukup, akan mudah untuk menemukan kasus yang tidak benar sama sekali, tetapi saya yakin kedua kasus ini mencakup pengguna 'sebagian besar', dan itulah yang saya butuhkan.
Solusi terbaik, terbersih, dan paling andal adalah agar kernel selalu membuat tautan simbolis, yang tidak akan merugikan apa pun atau siapa pun, dan menyebutnya baik, tetapi bukan itu cara kerjanya di dunia nyata ..
Saya tidak menganggap semua ini sebagai solusi 'baik atau tangguh', tetapi opsi pemasangan tampaknya memenuhi 'cukup baik', dan jika solusi yang benar-benar tangguh diperlukan, gunakan hal-hal yang direkomendasikan busybox.