# devfs switching to udev, tries to mount devfs during initrd

## DataPath

I'm trying to switch to udev from devfs.  I followed Decibel's UDEV setup page, and followed the directions meticulously.

The problem is, every time I try it, it does this:

```

<snip>

RAMDISK: Compressed image found at block 0

VFS: Mounted root (ext2 filesystem) read-only.

Freeing unused kernel memory: 152k freed

>> Loading modules...

<snip>

>> Mounting filesystems...

mount: Mounting devfs on /dev failed: No such device

Error opening file: ".devfsd"   No such file or directory

>> Determining root device...

Block device /dev/hda3 is not a valid root device

```

as best as I can tell, the initrd seems to require devfs for some reason.

pertinent package versions:

baselayout-1.10.1-r2

udev 30

gentoo-dev-2.6.7-r11[/code]

----------

## bennettp

Did you disable devfs in your kernel config? Try adding "devfs=nomount" to your kernel arguments.

----------

## DataPath

I've tried it both ways

Four ways, actually - 

devfs enabled in kernel config, with the grub option gentoo=nodevfs and without that option

devfs disabled in kernel config, gentoo=nodevfs, and then later added devfs=nomount

----------

## Decibels

Since it is even complaining about devfs, seems that it wasn't changed to NO in /etc/conf.d/rc (default setting from Gentoo)

```
# Set to "yes" if you want to save /dev to a tarball on shutdown

# and restore it on startup. This is useful if you have a lot of

# custom device nodes that udev do not handle/know about.

# (ONLY used by UDEV enabled systems!)

RC_DEVICE_TARBALL="yes"

# Set to "yes" if you want devfsd to start upon bootup. This is

# the default for Gentoo.

# Set to "no" only if you understand the full implications. A

# number of files may need to be altered (i.e. /etc/inittab,

# /etc/fstab, etc.).

# Also note that it does _NOT_ start for UDEV enabled systems,

# even if RC_DEVFSD_STARTUP="yes" ...

RC_DEVFSD_STARTUP="yes"
```

Is RC_DEVFSD_STARTUP="no"

in there? Otherwise it will complain that devfs isn't mounting cause you told it not to in the kernel append line. Pretty sure that you didn't enable devfs to boot automatically in the kernel or you probably wouldn't have even booted up.

Been so long since tried it can't remember, but if the above is set right. You could try enable devfs in the kernel. Just don't enable it to automatically load at boot. 

Some people have mentioned that they had to do that or got complaints, I've never experienced it though (set or not set in the kernel)

----------

## DataPath

from my grub.conf:

```

# For booting GNU/Linux nForce safe

title  Gentoo Linux 2.6.7-r11 nForce safe udev

root (hd0,0)

kernel /kernel-2.6.7-gentoo-r11 root=/dev/ram0 init=/linuxrc real_root=/dev/hda3 vga=0x317 noapic nolapic gentoo=nodevfs devfs=nomount

initrd /initrd-2.6.7-gentoo-r11

```

from my /etc/conf.d/rc

```

# Set to "yes" if you want to save /dev to a tarball on shutdown

# and restore it on startup.  This is useful if you have a lot of

# custom device nodes that udev do not handle/know about.

# (ONLY used by UDEV enabled systems!)

RC_DEVICE_TARBALL="no"

# Set to "yes" if you want devfsd to start upon bootup.  This is

# the default for Gentoo.

# Set to "no" only if you understand the full implications.  A

# number of files may need to be altered (i.e. /etc/inittab,

# /etc/fstab, etc.).

# Also note that it does _NOT_ start for UDEV enabled systems,

# even if RC_DEVFSD_STARTUP="yes" ...

RC_DEVFSD_STARTUP="no"

```

from my /usr/src/linux/.config

```

#

# Pseudo filesystems

#

CONFIG_PROC_FS=y

CONFIG_PROC_KCORE=y

CONFIG_SYSFS=y

# CONFIG_DEVFS_FS is not set

CONFIG_DEVPTS_FS_XATTR=y

# CONFIG_DEVPTS_FS_SECURITY is not set

CONFIG_TMPFS=y

# CONFIG_HUGETLBFS is not set

# CONFIG_HUGETLB_PAGE is not set

CONFIG_RAMFS=y

# CONFIG_SUPERMOUNT is not set

```

I'll try enabling it in the kernel, and leaving everything else as-is.

Can't figure out why it's given me so much trouble.

This is about my third time trying udev, twice on your instructions, and once using someone else's.  This time I tried it on the rumor that some people had more success going udev-only than building both, and starting it with boot-time selection.

----------

## DLF

I had the same problem as you in attempting to get a 'pure' udev system working.  I was playing around with my USB memory stick and it was apparent udev wasn't working as advertised.  After much hacking around adding diagnostics to scripts it seems that initrd insists on trying to start devfs.  My solution was to stop using initrd.  All kernel modules (apart from nvidia) are still automagically loaded at startup and as a bonus I no longer need to compile ext2 support into the kernel (for the ram disk) .

----------

## Decibels

Somewhere in the back of my clouded head, remember problem with initrd also.  Seeing that I am not using it, and have gotten no reports from anyone on it. Can't put something in the Primer if don't know about it. 

The problem is I also, want concise information. Not the problem where ends up someone forgot to do something or did something wasn't suppose to and ....

But looks like you have covered all your p's and q's. So:

Try two things:

1) Go ahead and add devfs (NOT automatic mount at boot though, don't want to hear about you thinking your system is toast) and see if that works with initrd. 

2) If that works fine. Guess no need to do without initrd, cause Know that works. But if doesn't, then drop the initrd and see if your system works correctly. Then we know just not to use it and perhaps write a bug report.

Then I should have the information necessary to add to the Primer. I agree with DLF, that is most likely the issue.

----------

## DataPath

same config files as before, but with devfs compiled in, and it now boots.

Is initrd necessary to get the full bootsplash lovin'?  If I don't need it to bring up any special modules early in the boot process, can I just cut it out?

Now if only they would patch the nForce2 ehci/forcedeth issue, I'd be happy as anything.

----------

## Decibels

So it would appear then that if you use initrd you have to compile devfs into the kernel. Correct?

Have heard that may not be true if using the tarball. So your still using a Pure Udev system correct!?  

Did you try that DLF when messing with your system. (ie leave your initrd and just compile devfs into the kernel).

Just want to make sure I have this 98% correct. Then will add it to the primer.  Thanks.

----------

## DLF

 *Decibels wrote:*   

> So it would appear then that if you use initrd you have to compile devfs into the kernel. Correct?
> 
> Have heard that may not be true if using the tarball. So your still using a Pure Udev system correct!?  
> 
> Did you try that DLF when messing with your system. (ie leave your initrd and just compile devfs into the kernel).
> ...

 

My recollections on attempting to get a pure udev system working:

- Devfs in kernel and using initrd equals a bootable system but not a udev system; 

- No devfs in kernel and using initrd does not equal a happy bootable system;

- No initrd and no devfs in kernel equals a working udev system.

----------

## Decibels

Well, that confuses the heck of it. 

 *Quote:*   

> - Devfs in kernel and using initrd equals a bootable system but not a udev system;

 

So, that would mean that people using initrd think their using udev and not?

----------

## DLF

 *Decibels wrote:*   

> Well, that confuses the heck of it. 
> 
>  *Quote:*   - Devfs in kernel and using initrd equals a bootable system but not a udev system; 
> 
> So, that would mean that people using initrd think their using udev and not?

 

I am sure this is the case.  All the handbook says about initrd is "The initrd will be started immediately after booting to perform hardware autodetection", nothing about how.  When trying to fathom it out I put diagnostics in /bin/rc and defvs was started before the rc was executed.  I didn't investigate further but simply created an extra boot option in my boot.config to boot the same kernel without initrd.  Apart from having to add nvidia to /etc/modules.autoload.d/kernel-2.6 the remaining modules were autodetected and loaded the udev way.

----------

