SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I would be grateful if somebody would explain or provide links why Current (12.2 RC1) mounts the root partition as /dev/root. I never have seen this before. How and why does this happen? I guess I missed that day in school.
/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.
I'm not sure that it still works, but you used to be able to use /dev/fd2 the same way.
I'm not sure -I don't use udev, but I suspect that is where it is happening. Do you also have a device node to the real device name? Does your fstab show /dev/root or the real device name? Maybe this is part of the changes with the kernel-2.6.27 and the switch to persistent device names -I mean using /dev/sd? instead of /dev/hd?
This usage should be good nes for some as it will make it much easier to mount external devices, although it is less informative when looking at /dev and at the fstab, if indeed the fstab is alos using /dev/root.
Distribution: slackware64 13.37 and -current, Dragonfly BSD
Posts: 1,810
Rep:
I've been looking into this as well. On my test system (12.2 rc1) the /dev/root entry symlinks to /dev/hda12 which is my root parition. I can't see a udev rule to create this and wonder whether this is internal to udev or perhaps a kernel change ? It's not in my fstab either.
Google has found me information on rootfs and the /usr/src/linux/Documentation/devices.txt mentions /dev/root in the Locally defined links section. I've not had much luck tracking down what's creating this in -current though. It would be interesting to know what process creates the link.
My fstab remains configured for the actual device partition: /dev/hda10.
Boot loader still points to /dev/hda10.
There is a new device node /dev/root pointing to the root partititon: /dev/hda10.
The remapping does not occur with 12.1. There is no /dev/root in 12.1.
I simply want to understand how this now happens and how to revert to the old way. I don't recall anything specific in the change log or changes and hints.
There was mention about CONFIG_PATA_LEGACY, but I do not have that option set in my kernel. I use the huge kernel in my VM for testing Current and I see /dev/root -> /dev/hda1. In my non virtual testing partitions, /dev/root -> /dev/sda7 but I do not have CONFIG_PATA_LEGACY set in my recompiled 2.6.27.7 kernel.
I've been searching the web but have yet to find anything.
Personally, I would be happy that it does that -it means you can just always use /dev/root in your fstab and depend on the kernel boot params to dtermine the real partition to mount as root. Remember all the trouble a couple of people have had recently getting their system to boot from an external drive(with and without using partition labels)?. I suggested to them then, that instead of using a label and going to the trouble of getting that to work, to just put 'rootfs' (or /dev/root/) in the fstab. It also makes it a snap to clone an installation to another partition and not have to change the fstab for it to work.
Last night I too saw that section in rc.udev. I commented out the echo command to /dev/.udev/rules.d and rebooted my test machine. No effect as the root partition still got mapped to /dev/root. Black magic.
Last night I too saw that section in rc.udev. I commented out the echo command to /dev/.udev/rules.d and rebooted my test machine. No effect as the root partition still got mapped to /dev/root. Black magic.
A little something from 'devices.txt' in the kernel documentation:
Quote:
4 block Aliases for dynamically allocated major devices to be used
when its not possible to create the real device nodes
because the root filesystem is mounted read-only.
0 = /dev/root
For what it's worth, I use udev in a fresh -current installation and my fstab shows /dev/root.
Does that imply a kernel compile option that can be disabled?
I went looking through compile options in my kernel (2.6.26) last night but didn't see anything that explicitly mentioned it. This is just an indication that while udev works with it, its origin must be elsewhere. If I have time today, I'll look through the -current ChangeLog.
I contacted Pat about this anomaly and the mysterious messages I reported in another thread. Here is what he wrote:
I'll start by saying that both of these issues will not happen when an initrd and the generic kernel are used. Piter Punk first notified me of the kernel change to using /dev/root in places, and while I thought it was not necessarily a good idea, it falls into the "get used to it" category. It seems that HP-UX and other systems have been doing this for quite some time, but I'm still hazy on what the benefit is. At least /dev/root points to the actual device name after some changes to udev.
When the kernel is booted without an initrd, it will often use /dev/root for the root partition name in /etc/mtab, though this may not be true in all cases. I have found that it's possible to make "mount" output the correct name like this:
Edit /etc/mtab, removing the line with /dev/root
Run mount like this: mount -f /
In a more brutal fashion, this also seems to do the trick:
rm /etc/mtab ; mount -a
But there are some side effects, such as any partition not mounted through /etc/fstab not showing up. There may be other problems with this.
As far as I am aware, there is no straightforward way to return the old behavior. It's probably advisable to figure out workarounds for any problems with /dev/root that don't involve trying to get mount to produce the old output. Or, if you use the generic kernel and an initrd, you should get the old output.
With that said, I tested the following in rc.S at line 256:
Code:
# Restore the mount command reporting the actual device node rather than /dev/root.
ROOTFS="$(readlink /dev/root)"
if [ -n $ROOTFS ]; then
/bin/sed -i -e '/\/dev\/root/d' /etc/mtab
/bin/mount -f /
fi
The mount command then reports the old way. At that point in rc.S, none of the non-root partitions are yet mounted, avoiding the concerns addressed by Pat. This snippet could also work in rc.local, but then the mount list would show the root partition at the bottom of the list rather than the top as many of us are accustomed because mtab by then is populated with all the mount points.
When I asked about making this change permanent, Pat wrote:
It's not a change that I would have decided to make personally, but it's probably in everyone's best interests now to just go along with it (if it's not too annoying).
I still would like to know how this black magic occurs.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.