init/do_mounts.c changed in 2.5.48, and booting with devfs
(and without initial ramdisk) has been impossible since then.
I experimented with do_mounts undoing the early devfs mount.
Devfs is mounted later anyway.
Feel free to test, but be warned that I am not an expert
on this part of the kernel. This made 2.5.49 work for
me though. I hope someone can comment on this.
If it isn't "the right way" please tell what is.
Helge Hafting
--- do_mounts.c.original 2002-11-25 12:41:48.000000000 +0100
+++ do_mounts.c 2002-11-25 13:34:58.000000000 +0100
@@ -846,10 +846,7 @@
{
int is_floppy;
-#ifdef CONFIG_DEVFS_FS
- sys_mount("devfs", "/dev", "devfs", 0, NULL);
- do_devfs = 1;
-#endif
+
md_run_setup();
>Does your patch break being able to mount root with things
>like "root=/dev/discs/disc0/part9"
>and/or "root=/dev/scsi/host0/bus0/id0/lun0/part9"? For people with devfs
>enable kernels those are valid boot entries and should not end up getting
>broken needlessly.
I have devfs, and my /etc/lilo.conf contains this:
boot=/dev/ide/host0/bus0/target0/lun0/disc
root=/dev/ide/host0/bus0/target0/lun0/part4
I haven't tried to put this in a command line
option, but it works fine from lilo.
The reason fro the patch is that I couldn't boot
with devfs anymore, I'd get a
"panic: couldn't mount root at 03:04"
or similiar, depending on which machine I used.
Now I don't get that, it just works.
Have you been able to boot a devfs-enabled
2.5.48 or later? On a machine where /dev
is only a empty directory - a mountpoint
for devfs use?
Helge Hafting
Ok, what I experienced is if I configured the kernel with:
CONFIG_UNIX98_PTYS = Y
CONFIG_DEVFS_FS = Y
CONFIG_DEVFS_MOUNT = Y
everything works correctly, but if I configure with only:
CONFIG_UNIX98_PTYS = N
CONFIG_DEVFS_FS = Y
CONFIG_DEVFS_MOUNT = Y
it gives me a panic:
VFS: Cannot open root device "hda2" or 03:02
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 03:02
Hope this helps
Mohamed
What you did was bypass devfs, and cause create_dev to mknod a file
with the device number of your root instead of creating a symlink
to the normal devfs node.
Is your booter translating the device name into a number? You can
check this by looking at the printed comand line in the dmesg, or
by cat /proc/cmdline .
If you see root=0304 then your booter is translating the device number
and therefore find_in_devfs is failing (possibly because of the previously
metioned patch to read_dir).
I notice that there are lots of hardcoded maxdepth of 64 characters for
the devfs path, but yours seems to be 39 and therefore should be ok.
milton