Slackware Current: /dev/root?
 

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. :scratch:

/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.

Where is this /dev/root method being implemented? The kernel? A udev rule?

How do I restore the old behavior?

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.

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. :scratch:

bgeddy: Your effort parallels mine.

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.

well it's not just the kernel, I just installed the 2.6.27.7 kernel from slackware-current on my slackware-12.1 and there is no /dev/root

And the problem is not solely udev. Last night I disabled udev and rebooted my test box. Same result. What black magic is this? :scratch:

Apparently it's coming from rc.udev:

Not sure where fstab got updated, but it's definitely a part of -current installs.

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:

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:

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.

/dev/root has always been present as a virtual mount point, even if you never saw it. So has rootfs (compare hthis to the special virtual devices like proc and tmpfs which have no preceeding /dev)
I'm sure Pat understands some of this as he used to use a similar trick with zipslack -it came with a 'universal' pre-made fstab with / mounted on /dev/fd2 which did the same thing -that is it 'just worked', no matter what the real device was -the only thing that mattered was having the right entry in the bootloader conf file or giving the correct device at the boot prompt.

I'd really like to get to the bottom of this "/dev/root" business. In theory, it sounds great, I'd like to have a way of booting independent of what the boot device was. But in practice, it only adds a layer of complexity.

My fstab entry looks like this:
/dev/hda1 / reiserfs defaults,noatime 1 1

If I do: mount -l it shows this:
/dev/root on / type reiserfs (rw,noatime)

At Kinfocenter/Storage Devices I see:

Device: /dev/hda1 Type: reiserfs Size: N/A Mount Point: / Free: 0 B Full%: N/A
Device: /dev/root Type: ? Size: 8.0GB Mount Point: / Free: 5.9 GB Full%: 26.5%

So it looks like the / mount point is "claimed" by both /dev/root and /dev/hda1.

I could live with that, except for LILO. If I go to Control Center/System Administration/Boot Manager (LILO)/Operating Systems and hit "Probe" then "Apply" I get: WARNING: the config file is currently NOT ok.

If then I do: Check Configuration I get:
Configuration NOT ok. LILO said:
LILO version 22.8 (test mode), Copyright (C) 1992-1998 Werner Almesberger
Development beyond version 21 Copyright (C) 1999-2006 John Coffman
Released 19-Feb-2007 and compiled at 12:43:17 on Nov 29 2008.
Reading boot sector from /dev/hda
Using MENU secondary loader
Calling map_insert_data
Fatal: Illegal 'root=' specification: /dev/root

At that point I can go to Expert and manually change all instances of /dev/root to /dev/hda1 then Apply that, and all is well. But why should I have to manually change it?

It appears to me that something else is missing. I should be able to get rid of /dev/hda1 once and for all. But if I change fstab to /dev/root instead of /dev/hda1 I cannot boot at all, in fact I get VERY stuck indeed, have to boot the slackware cd and re-run configure in order to get a working fstab.

Oh, also, there is NO symlink for /dev/root to anything.

I have done a LOT of Google searches but nothing that tells me how to proceed on this. Suggestions would be appreciated.

Sounds like a KDE problem, mostly.
/dev/root is a virtual device like 'proc' or /dev/tcp'. There is no device node in /dev for these things -it's already in the kernel as a virtual device.

I really wouldn't trust KDE's gui tools for system administration tasks. I've installed lilo with root=/dev/root entries as a test and it works fine.

That's weird - I have a symlink to /dev/sda2 - my root filesystem device.

There is a difference in the way the huge and the generic kernels handle this as mount returns in the generic and in the huge kernel. Both kernels however have the symlink /dev/root pointing to /dev/sda2. I have made entries with in the /etc/lilo.conf for both huge and generic and all works well.

As Gilbert says - this sounds like KDE messing things up.

All the above tests were done with the fstab root entry as /dev/sda2 / I then changed this to /dev/root / and it booted both huge and generic kernels ok. Mount still returned /dev/sda2 on / with the generic kernel however.

The only difference seems to be that you are using the reiser filesystem and I have ext3. Don't know if this would cause your behavior but I don't see why it should.

how would that work? I'd like to put Slackware in a USB HD, and still find it mystifying how it would know which drive is the root. Would I need to put /boot in the same partition as /?

First you need to realize that when you pass the root=/dev/whatever in your lilo.cong or grub menu.lst file, this option tells the bootloader where root is, not the kernel. Normally, this entry must agree with the entry in your fstab though. But, if you use a generic device like /dev/root or just 'rootfs' in your fstab, then a successful boot dpends only on the lilo or grub entry being the correct device and it doesn't have to ahve the same name as the generic device in the fstab.

As Gilbert says the /dev/root virtual device doesn't really help here. There was a long thread discussing ways round this here which may be useful to you. My examples were merely to show that /dev/root will work as a lilo and fstab option.

As an experiment I changed my fstab in a VM to /dev/root / and removed the swap file reference. I added root=/dev/root to lilo.conf and reinstalled. That booted ok as I already stated. Now for the fun bit - I changed the disk controller in the VM to be IDE primary master rather than SATA to force the device to change to /dev/hd? from /dev/sd? . Then at boot up I tabbed into the lilo menu and gave the kernel the additional boot time parameter of "root=/dev/hda2" and it booted ok mounting /dev/hda2 as the root file system device. So no real miracles there then. The obvious drawback being I needed to know about what device it was going to be given to tell the kernel. All the /dev/root symlink really solved was fstab entries. If I don't tell the kernel where the root device is I get a kernel panic "VFS: cannot open root device "802" or uknown-block(8,2) Please append a correct "root=" boot option" - and so on. Device 802 is /dev/sda2 on the system.

If I understand this correctly the USB boot disk may show as a different device on different machines. I don't have access to USB devices to play with this but the thread I linked to originally seems relevant.

I just tried again to change my fstab. The system absolutely will not boot up if either /dev/root or rootfs is in fstab. It doesn't matter whether /dev/hda1 is there or not. It also doesn't matter if LILO has root=/dev/root or root=/dev/hda1, it won't boot either way. I rescued fstab using the install cd, and now I'm back where I started.

I'm starting to think, as bgeddy suggested, that my problem is a result of using reiserfs, but I also don't see how.

Hate to be the bearer of bad news but to test out this theory I made a new install of Slackware 12.2 in a VM using reiserfs as the root filesystem. All my previous tests still worked with that filesystem so I think the problem must lie elsewhere.

Thanks for letting me know. I guess I'll have to look somewhere else.

I am using my own custom kernel, so I may have left out something there. Or perhaps there is a package I don't have installed that I need.

That is indeed the case. Seems like we still need to add udev to initrd.gz and boot using /dev/disk/by-uuid ...

In case anyone is having the same problems I was having, I now have figured out what I was doing wrong.

You have to have THIS configured in the kernel:

CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y

Without it, the symlink from /dev/root never gets created.

I now have LILO working correctly, with root=/dev/root, and my fstab entry looks like this:

/dev/root / reiserfs defaults,noatime 1 1

Hope this saves someone some time and hassle.

Thanks for letting us know. I've been looking for that for ages ! BTW, how did you discover that that was the setting to check ? By elimination perhaps ?

Incidentally - there has been an updated mkinitrd script posted in Slackware 12.2 patches that fixes /dev/root being added to an initial ram disk and causing problems with the generic kernels.

Yes. Once I realized that it worked with huge-smp, and didn't work with my custom kernel, it was just a matter of bisecting the differences.

I discovered another problem with this "/dev/root" syntax. The gparted utility does not recognize the root partition and therefore fails to lock the partition if mounted. I'm using gparted 0.41. I realize gparted is a graphical wrapper for parted, therefore perhaps the problem is with parted.