find the device file of the root filesystem.

[33333]

Hi, this is a Linux question rather than a Fedora question, but Im not signed up to any other Linux related forum so... Sorry if not appropriate.

I need to find the device file name, that the root file system is on. For example the root file system mounted at / is on device /dev/sdcX - I want to find that out reliably in script. So far I have:

rootDev=`mount | egrep " on / " | egrep -o "^/dev/[^ ]*"`

This works some of the time but sometimes mount lists a UUID link such as:

/dev/disk/by-uuid/590b84ad-7322-4ca6-9176-e501bad00e43

I could use rootDev=`readlink -f $rootDev` to resolve this link, but I have noticed sometimes the UUID mount lists does not actually exist in /dev/disk/by-uuid/ (What the heck?)!. So I need a more reliable way of doing this.

Thanks in advance,

Sam.

---------- Post added at 11:33 PM ---------- Previous post was at 06:30 PM ----------

Hmmm seems like the answer is:

readlink -f /dev/root

Ha! Still dont know how reliable that is though - i.e. is /dev/root standard Linux? Also the non existent UUID thing maybe due to an outdated mtab, since `mount` just lists that.

Cheers.

[33333]

Update: The symlink /dev/root is generated by udev (from /dev/.udev/rules.d/99-root.rules on my system). So if udev is enabled it should be available. If its not its not. Another way is the rdev command (http://free-electrons.com/blog/find-root-device/)

[smr54]

Thanks for coming back with the updates. By the way, things that aren't specifically Fedora usually go in Linux chat. A mod may move this thread when they come across it.

[jpollard]

It really may depend on why you need that information.

on my system, the mount utility provides the root device.

You can also get it from /proc/mounts (where Fedora 15 and above get it).

If you get confused by a sometimes UUID, you can always cross check the UUID with blkid which lists device and UUID.

[stevea]

There is a semantic question here - "What is root ?"

In the normal bootup sequence for Fedora and most PC distro's the system boots up and the kernel's first root file system is a ramdisk image called initramfs. You can find these on disk under /boot.

After the startup sequence identifies your (usually disk based) file system you specify as "root=..." on the kernel command line, then it mounts this file system (on the ramdisk) as read-only and performs a 'pivot' operation. The pivot includes cleaning up and completing any outstanding work on the ramdisk, perform a chroot to the new root, and though some syscall voodoo - it even replaces pid=1 (the init process) with an entirely new process with the same pid !.

I've been playing around with 'kexec' (a syscall to directly boot a new kernel from within a kernel) recently and it gives yet another interesting set of mount entries in the kernel.

Each process has in it's kernel structures a notion of current working directory (cwd) and root directory (rootdir). 'cwd' should not be confused with the bash shell's notion of 'pwd' but it very similar. If you make a chdir() syscall you change your process's cwd. If you make a chroot() syscall you change your process's 'rootdir'.

When a new process is forked the child process inherits it's parent cwd and rootdir. So 99.9% of processes have the same rootdir as the (second) init process. That is the (usually disk based) file system spec'e in grub as "root=".

It's absolutely possible and not particularly hard to set the rootdir to any place in the file system for your processes. So perhaps you want a LOT of user isolation, you could copy all the /bin /usr/bin /etc/{passwd,shadow,group} and a bunch of gnome configs to /home/stevea, then you can arrange via the gdm or similar to perform a chroot to /home/stevea. Then there is zero chance that that user stevea can ever impact any of the directory tree above /home/stevea. Soft links outside of the new root will fail to resolve, though hard links will work as expected.

So we all understand that a pathname like "./foo/bar" is meaningless unless we know the 'cwd', but what is less obvious is that a pathname like /etc/fstab, even on the same system at the same time, is also meaningless unless we know the current 'rootdir' of the process. The meaning of "/" is dependent on the process context.


So when we say "root" we might mean -
1/ the first entry of the kernel's mount table (but this is usually the initramfs ramdisk !)
2/ the last file system that init performed a pivot to, that the a block device like your /dev/sda1
3/ the root directory of the current process.

All three are potentially different at any one time.
*Normally* we don't care much about 1/, and *typically* 2/ and 3/ are the same.

To get the decimal major:minor numbers for the items 2/ and 3/ respectively you can do this,
mountpoint -d $(readlink -f /proc/1/root)
mountpoint -d $(readlink -f /proc/self/root)
but the second one /proc/self/root is always the same as '/'.

Getting from there or a /dev entry (which may not exist, or there may be multiple block-special files for the device) is questionable.

You might search /dev like this this ...
ROOT="$(for d in $(find /dev -type b); do [ "$(mountpoint -d /)" = "$(mountpoint -x $d)" ] && echo $d && break; done)"
which will give the first of potentially several 'special device' nodes the refer to the mounted block device.
But will give a null string if there is no /dev/ entry.