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