user-mode-linux-user Mailing List for User-mode Linux kernel port (Page 796)

On Thu, 19 Oct 2000, Jeff Dike wrote:
> hea...@em... said:
> > Has anyone tried doing networking with ppp over a pseudo-tty instead
> > of using slip?  
> 
> Not that I know of.  I chose slip over ppp when I first did the
> umn driver and I can't remember why.
> 
> Anyway, ethertap-type interface are preferable to slip/ppp.

How will ethertap function in combination with IP masquerading?

I suspect a lot of UML users will have only ONE ipv4 address
for their machine and will be using private addresses for the
UMLs...

> > It seams to me that this would be more desirable. 
> 
> Why?

Better IP address setup stuff?

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/		http://www.surriel.com/

em...@mi... said:
> (gdb) bt 
> #0  panic (fmt=0x1010cd80 "Kernel mode fault at addr 0x%lx, ip 0x%lx")
>     at panic.c:54 
> #1  0x1009f010 in segv (address=1, ip=1, is_write=0, is_user=0)
>     at trap_kern.c:66 
> #2  0x1009f89a in segv_handler (sig=11) at trap_user.c:265 

That's the stack I wanted.

And I hate these.  The thing to do is figure out how it tried to branch to 1 
(or 0 in your last example).  Find the esp value in *sc in the segv_handler 
frame and look at that general area of memory.  Make sure it looks kind of 
stack-like, and isn't all zeros.

If the stack looks ok, then look at current_task.thread.process_regs and see 
if the values there look right (e.g. both eip and esp should be in userspace).

Then look at the most recent stuff in signal_record.  This is a circular 
buffer whose end is signal_index - 1.  What I normally do is this:
	set $i=signal_index - 1
	p signal_record[$i--]
hit return until I've seen enough

If this is always reproducable at the same point every time, then the last 
dozen or so entries probably cover the problem and you can piece together what 
happened from them.

If this doesn't always happen the same way, then look for a SIGIO, SIGVTALRM, 
or SIGALRM entry (signals 29, 26, and 14).  Then reproduce the bug a bunch of 
times and see what is always the same.

				Jeff

Ok, sorry about that.  I don't know if this helps anymore, but I did
actually get the backtrace in panic().

Emil

Breakpoint 2, panic (fmt=0x1010cd80 "Kernel mode fault at addr 0x%lx, ip 0x%lx") at
panic.c:54
54              va_start(args, fmt);
(gdb) bt
#0  panic (fmt=0x1010cd80 "Kernel mode fault at addr 0x%lx, ip 0x%lx")
    at panic.c:54
#1  0x1009f010 in segv (address=1, ip=1, is_write=0, is_user=0)
    at trap_kern.c:66
#2  0x1009f89a in segv_handler (sig=11) at trap_user.c:265
#3  0x100a6198 in __restore ()
    at ../sysdeps/unix/sysv/linux/i386/sigaction.c:125
#4  0x1e8 in ?? ()
#5  0x0 in ?? ()


On Mon, 23 Oct 2000, Jeff Dike wrote:

> em...@mi... said:
> > (gdb) bt 
> > #0  0x100ab9f1 in __libc_nanosleep () 
> > #1  0x100ab9b1 in __sleep (seconds=10) at
> >  ../sysdeps/unix/sysv/linux/sleep.c:78 
> > #2 0x100a0edb in do_idle () at process_kern.c:431 
> > #3  0x100a0f76 in cpu_idle () at process_kern.c:457 
> > #4  0x100e3307 in start_kernel () at init/main.c:591 
> > #5  0x1009f948 in start_kernel_proc (unused=0x0) at um_arch.c:70 
> > #6  0x1009f3a3 in signal_tramp (arg=0x1009f910) at trap_user.c:49 
> 
> That wasn't it.  That's the normal idle thread stack.
> 
> Try putting a breakpoint in panic and getting the stack from there.
> 
> 				Jeff
> 
> 

em...@mi... said:
> (gdb) bt 
> #0  0x100ab9f1 in __libc_nanosleep () 
> #1  0x100ab9b1 in __sleep (seconds=10) at
>  ../sysdeps/unix/sysv/linux/sleep.c:78 
> #2 0x100a0edb in do_idle () at process_kern.c:431 
> #3  0x100a0f76 in cpu_idle () at process_kern.c:457 
> #4  0x100e3307 in start_kernel () at init/main.c:591 
> #5  0x1009f948 in start_kernel_proc (unused=0x0) at um_arch.c:70 
> #6  0x1009f3a3 in signal_tramp (arg=0x1009f910) at trap_user.c:49 

That wasn't it.  That's the normal idle thread stack.

Try putting a breakpoint in panic and getting the stack from there.

				Jeff

On Mon, 23 Oct 2000, Jeff Dike wrote:

> > I didn't change any of the configuration settings from the way they
> > came out of the box.  I'm running with 2 processors, if that helps.
> 
> Does this mean you are running it on a 2 processor SMP box or you turned on 
> SMP in UML, got it to compile, and it panics when you run it?  That first 
> sentence seems to say that you didn't, but "running with 2 processors" is how 
> I describe running a 2 processor SMP UML.

Sorry, I meant that my machine has 2 processors and that UML is not
compiled for SMP.

> If you turned on SMP, then I need to see the changes you made to get it to 
> compile.
> 
> If you didn't, then I need stack traces from the panics.

Kernel panic: Kernel mode fault at addr 0x0, ip 0x0
	
(gdb) bt
#0  0x100ab9f1 in __libc_nanosleep ()
#1  0x100ab9b1 in __sleep (seconds=10) at
../sysdeps/unix/sysv/linux/sleep.c:78
#2  0x100a0edb in do_idle () at process_kern.c:431
#3  0x100a0f76 in cpu_idle () at process_kern.c:457
#4  0x100e3307 in start_kernel () at init/main.c:591
#5  0x1009f948 in start_kernel_proc (unused=0x0) at um_arch.c:70
#6  0x1009f3a3 in signal_tramp (arg=0x1009f910) at trap_user.c:49

If you need any more info, just let me know.  This is very reproducible.

Thanks,
Emil

> I didn't change any of the configuration settings from the way they
> came out of the box.  I'm running with 2 processors, if that helps.

Does this mean you are running it on a 2 processor SMP box or you turned on 
SMP in UML, got it to compile, and it panics when you run it?  That first 
sentence seems to say that you didn't, but "running with 2 processors" is how 
I describe running a 2 processor SMP UML.

If you turned on SMP, then I need to see the changes you made to get it to 
compile.

If you didn't, then I need stack traces from the panics.

				Jeff

Most of the time when I run the kernel, I get kernel panics on boot.  For
example: 

ssl receive thread is pid 5325
devfs: v0.102 (20000622) Richard Gooch (rg...@at...)
devfs: devfs_debug: 0x0
devfs: boot_options: 0x2
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Kernel panic: Kernel mode fault at addr 0x0, ip 0x0

Occasionally, I get 

Kernel panic: Kernel mode fault at addr 0x1, ip 0x1

I didn't change any of the configuration settings from the way they came
out of the box.  I'm running with 2 processors, if that helps.  Also, the
frequency of the panics seems to go down when running in debug mode.

Any ideas?

Thanks,
Emil

Jeff Dike wrote:

> ke...@ca... said:
> > I don't remember reading that I needed to actually specify the linux
> > target to compile
>
> My 'compiling' page says in blue and white to 'make linux'...
>

:)


Now I can compile but the patch on the web page have the stack problem and
the source from cvs gets
--
INIT: version 2.78 booting
Kernel panic: Kernel mode fault at addr 0x14, ip 0x100a2acd
--
First I thought that I did something wrong as I build my own root system
but I get almost the same when running the small tomsrtbt root from the web
page. But it happens later, I sometimes get a login promt and can try to
login.

I'am going to try gdb on this to see if I can understand whats happening
but I got a little confused. why is it that I need to start gdb by sending
a signal to linux? And why is the PID not important??  I would like to use
ddd as a fron as that one has better source navigation but since
linux(maybe we should change the name to uml or something less confusing)
starts gdb itself that is not possible and when I changed the code to start
ddd instead of gdb I can't attach to pid1 (as I would have expected from
gdb also)

Well I don't understnad the trix you used.

syp...@ya... said:
> You're right, in fact, I had applied a prepatch on the test8, which I
> didn't remembered.

Good.  That's a relief, but I figured that something like that is what 
happened.

				Jeff

and...@me... said:
> Program received signal SIGSEGV, Segmentation fault. 
> 0x10035830 in padzero (elf_bss=1073765049)
>     at /ext1/usermode/linux/include/asm/arch/string.h:418 

All you need to do at that point is 'handle SIGSEGV pass nostop noprint'.

It looks like it would have booted fine without the debugger.

				Jeff

Jeff Dike wrote:

> Are you *sure* you see this on test9?
> 
> Yuri Pudgorodsky and Bill Stearns proved beyond any kind of doubt that this
> was caused by the ptrace fix that went into test8.  Bill turned test8 into a
> good host by backing out that fix.
> 
> It was removed in test9, so I really don't think you'll see it there.

You're right, in fact, I had applied a prepatch on the test8, which I
didn't remembered.
I thought it was a test9 when looking at include/linux/version.h (It
isn't specified that it is a prepatch there).

I tested it in the "real" test9, and it works fine.


Regards

	Sylvain

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Hello again,

Got a bit further this time. Used mknod to create ten pairs of ptyp
and ttyp and got past the previous problem. Now it falls over on devfs
in the UML instead. Doesn't matter if I pass the 'devfs=nomount'
parameter to the kernel or not, still fails. So I ran it in a debugger
and got the following.

~~~ in terminal window ~~~
[beast|605]/share/usermode $ gdb ./linux
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-pc-linux"...
(gdb) run ubd0=./root_fs no-xterm debug
Starting program: /share/usermode/./linux ubd0=./root_fs no-xterm debug

Program received signal SIGTRAP, Trace/breakpoint trap.
0x10001000 in _start ()
(gdb) continue
Continuing.
tracing thread pid = 10659
Linux version 2.4.0-test9-1um (anders@beast) (gcc version 2.95.2 19991024 (release)) #5 Thu Oct 19 20:04:28 BST 2000
On node 0 totalpages: 4096
zone(0): 0 pages.
zone(1): 4096 pages.
zone(2): 0 pages.
Kernel command line: ubd0=./root_fs no-xterm debug root=/dev/ubd0
Calibrating delay loop... 836.24 BogoMIPS
Memory: 16100k available
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
Initializing RT netlink socket
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: enabling 8 loop devices
User-mode Linux network interface 0.005 (eth0)
User-mode Linux network interface 0.005 (eth1)
User-mode Linux network interface 0.005 (eth2)
User-mode Linux network interface 0.005 (eth3)
Initializing stdio console driver
Initializing software serial port version 0
serial line 0 assigned pty /dev/ptyp1
ssl receive thread is pid 10674
devfs: v0.102 (20000622) Richard Gooch (rg...@at...)
devfs: boot_options: 0x0
VFS: Mounted root (ext2 filesystem) readonly.
Mounted devfs on /dev

~~~ in the debug window ~~~
1c0000e
att 1
b start_kernel
c
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-pc-linux"...
(gdb) att 1
Attaching to program: /share/usermode/linux, Pid 1
0x100ac3c1 in __kill ()
(gdb) b start_kernel
Breakpoint 1 at 0x10102659: file init/main.c, line 515.
(gdb) c
Continuing.

Breakpoint 1, start_kernel () at init/main.c:515
515             setup_arch(&command_line);
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x10035830 in padzero (elf_bss=1073765049)
    at /ext1/usermode/linux/include/asm/arch/string.h:418
418     __asm__ __volatile__(
(gdb) bt
#0  0x10035830 in padzero (elf_bss=1073765049)
    at /ext1/usermode/linux/include/asm/arch/string.h:418
#1  0x10036109 in load_elf_interp (interp_elf_ex=0x50055d48, 
    interpreter=0x500db180, interp_load_addr=0x50055d18) at binfmt_elf.c:320
#2  0x100369ee in load_elf_binary (bprm=0x50055e1c, regs=0x0)
    at binfmt_elf.c:666
#3  0x10027f52 in search_binary_handler (bprm=0x50055e1c, regs=0x0)
    at exec.c:809
#4  0x10028174 in do_execve (filename=0x1010d4ed "/sbin/init", 
    argv=0x1013c140, envp=0x1013c180, regs=0x0) at exec.c:902
#5  0x100a0beb in execve1 (file=0x1010d4ed "/sbin/init", argv=0x1013c140, 
    env=0x1013c180) at exec_kern.c:77
#6  0x100a0c2b in um_execve (file=0x1010d4ed "/sbin/init", argv=0x1013c140, 
    env=0x1013c180) at exec_kern.c:87
#7  0x10001398 in init (unused=0x0) at init/main.c:768
#8  0x100a6458 in new_thread_proc (t=0x50054000) at process_kern.c:128
(gdb) up
#1  0x10036109 in load_elf_interp (interp_elf_ex=0x50055d48, 
    interpreter=0x500db180, interp_load_addr=0x50055d18) at binfmt_elf.c:320
320             padzero(elf_bss);
(gdb) 

~~~ end ~~~

Hope this means something to someone.

Cheers!

-- 
        Anders Karlsson
e-mail: and...@me...

Hello,

I am sorry if this is dead obvious to others but I have read the FAQ
and most other things at sourceforge and can not find anything that
describes what I am seeing with UMLinux.

Basically, I have downloaded the patch for 2.4.0-test9, applied and
followed instructions for how to configure and build the linux
executable. I also downloaded the root_fs_tomrtbt_1.7.205.bz2 image to
test with just in case my attempt at creating a boot image from ROCK
Linux was not correct.

Here is what I get in the terminal window from when I start UMLinux
with root_fs on ubd0.

~~~
[beast|580]/share/usermode $ ./linux ubd0=./root_fs 
tracing thread pid = 10007
Linux version 2.4.0-test9-1um (anders@beast) (gcc version 2.95.2 19991024 (release)) #5 Thu Oct 19 20:04:28 BST 2000
On node 0 totalpages: 4096
zone(0): 0 pages.
zone(1): 4096 pages.
zone(2): 0 pages.
Kernel command line: ubd0=./root_fs root=/dev/ubd0
Calibrating delay loop... 854.59 BogoMIPS
Memory: 16100k available
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
Initializing RT netlink socket
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: enabling 8 loop devices
User-mode Linux network interface 0.005 (eth0)
User-mode Linux network interface 0.005 (eth1)
User-mode Linux network interface 0.005 (eth2)
User-mode Linux network interface 0.005 (eth3)
Initializing stdio console driver
Initializing software serial port version 0
Kernel panic: Out of pty's in getmaster
Terminated
~~~

Now, I run ROCK Linux as the base Linux on my system, ROCK uses devfs
so there are no /dev/ptyXX unless you create them. I linked all 256 of
them into /dev but I still get this error.

Any pointers as to how I can fix this or if there is something else
that can be done to remedy this?

-- 
        Anders Karlsson
e-mail: and...@me...

hea...@em... said:
> Has anyone thought of or attempted to build UML on CygWin/Windows?
> This should support a lot of the calls necessary. 

People have thought about it.  There's also been some recent interest in this.

See http://www.geocrawler.com/lists/3/SourceForge/709/0/4523569/ and earlier 
-devel posts for more information and some code.

				Jeff

hea...@em... said:
> My idea - use the XFree frame buffer driver to allow access to /dev/
> fb0, the mouse device, keyboard device, etc. 

That's been suggested.  The problem is that the fb device will have to turn 
around and talk to X on the host, and fb -> X is a mapping that doesn't work 
very well.  I can't think of any good ways of doing it.

The alternative is to use Xnest as the display.  It's somewhat less secure, 
but it ought to work pretty well.

> Also, can you point the UML virtual disk devices to real devices, or
> can they only point to true files on the host system? 

Sure.  I do things like ubd1=/dev/cdrom and ubd2=/dev/fd0 and that works fine.

				Jeff

hea...@em... said:
> Has anyone tried doing networking with ppp over a pseudo-tty instead
> of using slip?  

Not that I know of.  I chose slip over ppp when I first did the umn driver and 
I can't remember why.

Anyway, ethertap-type interface are preferable to slip/ppp.

> It seams to me that this would be more desirable. 

Why?

				Jeff

OK - Here's an idea I had.  I have a system I want end-users to access but I
want it EXTREMELY secure.  Examples: kiosk, e-mail appliance, internet
appliance, etc.

My idea - use the XFree frame buffer driver to allow access to /dev/fb0, the
mouse device, keyboard device, etc.

This way if the UML process is hacked, who cares?  Just kill the UML process
and start another.

The only catch I've thought of is /dev/fg0 is a character device, not a
block device, and UML may not currently support it.

Also, can you point the UML virtual disk devices to real devices, or can
they only point to true files on the host system?

Heath Petersen
Hea...@Co...

FYI - I have not tried UML -YET-.  Sorry if the answers are
self-explanatory.


-----------------------------------------------
FREE! The World's Best Email Address @email.com
Reserve your name now at http://www.email.com

Has anyone thought of or attempted to build UML on CygWin/Windows?  This
should support a lot of the calls necessary.  For those not aware of CygWin,
check out http://sources.redhat.com/cygwin .


-----------------------------------------------
FREE! The World's Best Email Address @email.com
Reserve your name now at http://www.email.com

Has anyone tried doing networking with ppp over a pseudo-tty instead of
using slip?  It seams to me that this would be more desirable.


-----------------------------------------------
FREE! The World's Best Email Address @email.com
Reserve your name now at http://www.email.com

ke...@ca... said:
> I don't remember reading that I needed to actually specify the linux
> target to compile

My 'compiling' page says in blue and white to 'make linux'...

> Should it not default to the linux target ??

The arch Makefile doesn't have the ability to change the default target.

> I can't use cvs(anonymous) is this a know problem. cvs can't create
> the read lock.

Yup.  No idea why that's happening.  I'll ask SF admin about it.

				Jeff

Jeff Dike wrote:

> ke...@ca... said:
> > /work/kernel/user/linux-2.4.0-test9/include/asm/ptrace.h:8:
> > asm/arch/ptrace.h: No such file or directory
> > /work/kernel/user/linux-2.4.0-test9/include/asm/ptrace.h:14:
> > ../../arch/um/include/sysdep/ptrace.h: No such file or directory
>
> It should be finding arch/um/include/sysdep/ptrace.h.  If that's not there
> (sysdep should be a symlink to sysdep-i386, and arch should be a symlink to
> ../asm-i386), then your pool's messed up somehow.
>
> If that's fine, then run this from the root of the pool:
>

hmm you right. I looked over the makefiles and noticed that I need to do "make
linux" to create the links . I don't remember reading that I needed to actually
specify the linux target to compile but it's probably only my bad memory. Should
it not default to the linux target ??

Anyway now it works.

Ps. I can't use cvs(anonymous) is this a know problem. cvs can't create the read
lock.

ke...@ca... said:
> /work/kernel/user/linux-2.4.0-test9/include/asm/ptrace.h:8:
> asm/arch/ptrace.h: No such file or directory
> /work/kernel/user/linux-2.4.0-test9/include/asm/ptrace.h:14:
> ../../arch/um/include/sysdep/ptrace.h: No such file or directory 

It should be finding arch/um/include/sysdep/ptrace.h.  If that's not there 
(sysdep should be a symlink to sysdep-i386, and arch should be a symlink to 
../asm-i386), then your pool's messed up somehow.

If that's fine, then run this from the root of the pool:

gcc -D__KERNEL__ -I/home/dike/linux/2.4/um/include -Wall -Wstrict-prototypes 
-O2  -g  -U__i386__ -Ui386 -D__arch_um__ -DSUBARCH=\"i386\" -DNESTING=0 
-fno-strict-aliasing   -E init/main.c > x.i

and look for the sysdep/ptrace.h in x.i:

# 1 "/home/dike/linux/2.4/um/include/asm/../../arch/um/include/sysdep/ptrace.h"
 1

If that's not right, then your compiler (or something) is messed up.

Given that it barfed on headers which have links in their paths, I guess that 
the symlinks weren't set up.

				Jeff

What is "asm/arch/ptrace.h" supposed to be ? I have never seen that
before.

Is it supposed to be from the usermode source tree or from my real
kernel tree (glibc)?


gcc -D__KERNEL__ -I/work/kernel/user/linux-2.4.0-test9/include -Wall
-Wstrict-prototypes -O2  -g  -U__i386__ -Ui386 -D__arch_um__
-DSUBARCH=\"i386\" -DNESTING=0 -fno-strict-aliasing   -c -o init/main.o
init/main.c

In file included from
/work/kernel/user/linux-2.4.0-test9/include/linux/ptrace.h:24,
                 from
/work/kernel/user/linux-2.4.0-test9/include/linux/binfmts.h:4,
                 from
/work/kernel/user/linux-2.4.0-test9/include/linux/sched.h:9,
                 from
/work/kernel/user/linux-2.4.0-test9/include/linux/mm.h:4,
                 from
/work/kernel/user/linux-2.4.0-test9/include/linux/slab.h:14,
                 from
/work/kernel/user/linux-2.4.0-test9/include/linux/malloc.h:4,
                 from
/work/kernel/user/linux-2.4.0-test9/include/linux/proc_fs.h:5,
                 from init/main.c:15:
/work/kernel/user/linux-2.4.0-test9/include/asm/ptrace.h:8:
asm/arch/ptrace.h: No such file or directory
/work/kernel/user/linux-2.4.0-test9/include/asm/ptrace.h:14:
../../arch/um/include/sysdep/ptrace.h: No such file or directory

syp...@ya... said:
> But both test8 and test9 don't work for me.
> Have other people managed to get a test9 host running with uml? And
> has someone an idea what in the test8 breaks the uml ? 

Are you *sure* you see this on test9?

Yuri Pudgorodsky and Bill Stearns proved beyond any kind of doubt that this 
was caused by the ptrace fix that went into test8.  Bill turned test8 into a 
good host by backing out that fix.

It was removed in test9, so I really don't think you'll see it there.

				Jeff

yd...@al... said:
> Something like "If you intend to use one of the root filesystems we
> provide, you will need to built a kernel with devfs support, as
> devfs-specific paths are referenced in those archives (in /etc/
> fstab)." 

I added a warning to this effect to the download page.

> This sounds like a reasonable thing to mention in the networking page
> :)

Also done...

				Jeff