# udev won't start, says I need devtmpfs=y in kernel but it is

## roytheman

Hello Gentoo Forums,

I have upgraded Gentoo and am having problems with udev not starting (upgrading udev from version 171 to 197).

Below is a news item that describes the problem and what to do:

```

Upgrading udev from 171 (or older) to 197 will require special attention:

- Remove udev-postmount from runlevels.

- The need of CONFIG_DEVTMPFS=y in the kernel; need to verify the fstype for

  possible /dev line in /etc/fstab is devtmpfs (and not, for example, tmpfs)

- The case of predictable network interface names; if the file

  /etc/udev/rules.d/70-persistent-net.rules is being used for renaming

  network interface names to already existing names, then you need to

  read following bug[1] because it's no longer possible. This won't

  be a problem with the new predictable network interface name scheme[2].

  [1] http://bugs.gentoo.org/453494

  [2] http://www.freedesktop.org/wiki/Software/systemd/

      PredictableNetworkInterfaceNames

- Support for older kernels than 2.6.39 is dropped. If you need older kernel

  we recommend you to look into sys-fs/eudev or use local overlay for keeping

  the old ebuild. Remember to also get the distfiles where the patchsets are.

  The upgrade into current stable version of gentoo-sources is recommended.

- The case of separate /usr; if it worked for you with 171 it will continue

  to work for you with 197. We still recommend initramfs with separate /usr

  mounting capabilities because you might need packages like sys-apps/kbd

  (keymaps in /usr) or net-wireless/bluez (possible keyboard) in early boot.

And read every message printed by the emerge of udev and udev-init-scripts

to ensure the system is in order before booting as this news item might

not be complete.

Apologies if this news came too late for you.

```

I have followed the above instructions but udev still still gives an error when starting saying I need config-devtmpfs=y in the kernel as well as config-devtmpfs-mount=y but these two items are turned on in the kernel.

I have also passed the alternative "devtmpfs.mount=0" to the kernel at boot time but I still get the errors.

Do I need to put devtmpfs in ftab? If so, how do I do it?

Why does the error message say I need these two items turned on in the kernel even though I DO have them turned on in the kernel?

Please help me.

Regards,

RoyLast edited by roytheman on Wed Feb 20, 2013 11:25 am; edited 2 times in total

----------

## NeddySeagoon

roytheman,

When did you build the kernel with those options on?

What does

```
uname -a
```

show?

devtmpfs.mount=0 tells the kernel not to mount devtmpfs, so you don't want that.

No entries in /etc/fstab are needed

----------

## roytheman

Thanks for the reply NeddySeagoon,

I turned on these two items in the kernel yesterday and uname -r says 3.5.7-gentoo. I did upgrade the kernel the other day and kept the old one (3.3.8-gentoo) but I'm positive I am booting into the same kernel I made the changes to. Just to be extra sure, I also turned on these two items in the old kernel  (3.3. :Cool:  and booted into that kernel, but the problem exists with either kernel.

I passed devtmpfs.mount=1 to the kernel instead of devtmpfs.mount=0 at boot time but it did not make any difference. Udev still would not start, saying that devtmpfs needs to be turned on in the kernel.

Regards,

Roy

----------

## albright

what does 

zgrep DEVTMPFS /proc/config.gz

show?

----------

## roytheman

Thanks for the reply albright,

zgrep DEVTMPFS /proc/config.gz  shows devtmpfs is NOT set.

But in /usr/src/linux/.config, devtmpfs is set.

I'm beginning to feel hope.

Regards,

Roy

----------

## BillWho

roytheman,

The only explanation that I can think of is you're not running the latest compiled kernel. Check the dates:

```
bill@stable /boot $ ls -l

total 5162

-rw-r--r-- 1 root root 1860003 Feb 13 09:21 System.map-3.6.11-gentoo

-rw-r--r-- 1 root root   84535 Feb 13 09:21 config-3.6.11-gentoo

lrwxrwxrwx 1 root root      21 Dec 27 23:34 kernel -> vmlinuz-3.6.11-gentoo

-rw-r--r-- 1 root root 3315680 Feb 13 09:21 vmlinuz-3.6.11-gentoo

bill@stable /boot $ uname -a

Linux stable 3.6.11-gentoo #5 SMP Wed Feb 13 09:20:53 EST 2013 x86_64 AMD Phenom(tm) 9150e Quad-Core Processor AuthenticAMD GNU/Linux

```

The date should be the same and the time very close.

----------

## NeddySeagoon

roytheman,

You are not running the kernel you think you are.  We all do that from time to time. Thats why I was asking for uname -a

It shows the kernel build date and time.

```
$ uname -a

Linux NeddySeagoon 3.7.1-gentoo #1 SMP PREEMPT Wed Dec 26 16:00:43 GMT 2012 x86_64 AMD Phenom(tm) II X6 1090T Processor AuthenticAMD GNU/Linux
```

For me its

```
Wed Dec 26 16:00:43 GMT 2012
```

The #1 shows its the first build of this kernel, unlike my Raspberry Pi

```
$ uname -a

Linux Pi_Net 3.6.11+ #346 PREEMPT Fri Dec 28 00:50:33 GMT 2012 armv6l ARMv6-compatible processor rev 7 (v6l) BCM2708 GNU/Linux
```

----------

## roytheman

Thanks for the replies NeddySeagoon and BillWho,

I ran uname -a  and this is the output:

Linux Localhost 3.5.7-Gentoo #1 SMP Sat Jan26 06:34:28 EST 2013 i686 Intel Core (TM) i5-2320 CPU @3.00 ghz Genuine Intel GNU/Linux

The date is wrong. I compiled that kernel yesterday, Feb.15, 2013 so the date is three weeks off but that might be my clock was off or something.

In the boot directory I have the following:

```

roy@localhost /boot $ ls -l

total 17064

-rw-r--r-- 1 root root 1603641 Sep 12 06:05 System.map-genkernel-x86-3.3.8-gentoo

-rw-r--r-- 1 root root 1631805 Jan 26 06:34 System.map-genkernel-x86-3.5.7-gentoo

-rw-r--r-- 1 root root 4053191 Sep 12 06:15 initramfs-genkernel-x86-3.3.8-gentoo

-rw-r--r-- 1 root root 4073665 Jan 26 06:44 initramfs-genkernel-x86-3.5.7-gentoo

-rw-r--r-- 1 root root 3005520 Sep 12 06:05 kernel-genkernel-x86-3.3.8-gentoo

-rw-r--r-- 1 root root 3068624 Jan 26 06:34 kernel-genkernel-x86-3.5.7-gentoo

```

In both kernel versions I have devtmpfs set.

I used the new Grub with the latest version os-prober to auto-detect the kernels and Grub detected both of them and placed them in my Grub boot menu pre-POST. So I *should* be booting into the correct kernel of my choosing.

I am stumped. I'll need time to figure this one out but I'm always open to more suggestions.

Kindest Regards,

RoyLast edited by roytheman on Sat Feb 16, 2013 10:05 pm; edited 1 time in total

----------

## NeddySeagoon

roytheman,

Sat Jan26 06:34:28 EST 2013 is the build date of the running kernel.

Now I'm confused.  If you are using grub2, it does not use the file grub.conf.

Please post the output of

```
ls -l /boot
```

, either by copy/paste or with wgetpaste.

I want the file names and the timestamps on the files.

If your clock had stepped backwards, the init system would give you lots of warnings about files dated in the future and clock skew detected. 

You would not have missed it.

----------

## roytheman

roy@localhost /boot $ ls -l

total 17064

-rw-r--r-- 1 root root 1603641 Sep 12 06:05 System.map-genkernel-x86-3.3.8-gentoo

-rw-r--r-- 1 root root 1631805 Jan 26 06:34 System.map-genkernel-x86-3.5.7-gentoo

-rw-r--r-- 1 root root 4053191 Sep 12 06:15 initramfs-genkernel-x86-3.3.8-gentoo

-rw-r--r-- 1 root root 4073665 Jan 26 06:44 initramfs-genkernel-x86-3.5.7-gentoo

-rw-r--r-- 1 root root 3005520 Sep 12 06:05 kernel-genkernel-x86-3.3.8-gentoo

-rw-r--r-- 1 root root 3068624 Jan 26 06:34 kernel-genkernel-x86-3.5.7-gentoo

Here is part of my grub.cfg from the OS that handles the bootloader, which is Linux Mint (I have multiboot):

```

menuentry 'Linux Mint 13 MATE 32-bit, 3.2.0-23-generic (/dev/sda5) -- recovery mode' --class linuxmint --class gnu-linux --class gnu --class os {

   recordfail

   insmod gzio

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos5)'

   search --no-floppy --fs-uuid --set=root f9691268-cd43-44fc-a88b-e62d7ab382a9

   echo   'Loading Linux 3.2.0-23-generic ...'

   linux   /boot/vmlinuz-3.2.0-23-generic root=UUID=f9691268-cd43-44fc-a88b-e62d7ab382a9 ro recovery nomodeset 

   echo   'Loading initial ramdisk ...'

   initrd   /boot/initrd.img-3.2.0-23-generic

}

### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/10_lupin ###

### END /etc/grub.d/10_lupin ###

### BEGIN /etc/grub.d/20_linux_xen ###

### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/20_memtest86+ ###

menuentry "Memory test (memtest86+)" {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos5)'

   search --no-floppy --fs-uuid --set=root f9691268-cd43-44fc-a88b-e62d7ab382a9

   linux16   /boot/memtest86+.bin

}

menuentry "Memory test (memtest86+, serial console 115200)" {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos5)'

   search --no-floppy --fs-uuid --set=root f9691268-cd43-44fc-a88b-e62d7ab382a9

   linux16   /boot/memtest86+.bin console=ttyS0,115200n8

}

### END /etc/grub.d/20_memtest86+ ###

### BEGIN /etc/grub.d/30_os-prober ###

menuentry "Windows 7 (loader) (on /dev/sda1)" --class windows --class os {

   insmod part_msdos

   insmod ntfs

   set root='(hd0,msdos1)'

   search --no-floppy --fs-uuid --set=root 2EA067230273A8D9

   chainloader +1

}

menuentry "Gentoo Base System release 2.1 (on /dev/sda6)" --class gnu-linux --class gnu --class os {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos6)'

   #search --no-floppy --fs-uuid --set=root ef5fa8a5-dc16-46ec-ace7-ff05a25b626d

   linux /boot/kernel-genkernel-x86-3.3.8-gentoo root=/dev/sda6

   initrd /boot/initramfs-genkernel-x86-3.3.8-gentoo

}

menuentry "Gentoo Base System release 2.1 (on /dev/sda6)" --class gnu-linux --class gnu --class os {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos6)'

   #search --no-floppy --fs-uuid --set=root ef5fa8a5-dc16-46ec-ace7-ff05a25b626d

   linux /boot/kernel-genkernel-x86-3.5.7-gentoo root=/dev/sda6

   initrd /boot/initramfs-genkernel-x86-3.5.7-gentoo

}

menuentry "Gentoo Base System release 2.1 (on /dev/sda7)" --class gnu-linux --class gnu --class os {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos7)'

   #search --no-floppy --fs-uuid --set=root ef5fa8a5-dc16-46ec-ace7-ff05a25b626d

   linux /boot/kernel-genkernel-x86-3.3.8-gentoo root=/dev/sda7

   initrd /boot/initramfs-genkernel-x86-3.3.8-gentoo

}

menuentry "Gentoo Base System release 2.1 (on /dev/sda7)" --class gnu-linux --class gnu --class os {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos7)'

   #search --no-floppy --fs-uuid --set=root ef5fa8a5-dc16-46ec-ace7-ff05a25b626d

   linux /boot/kernel-genkernel-x86-3.5.7-gentoo root=/dev/sda7

   initrd /boot/initramfs-genkernel-x86-3.5.7-gentoo

}

### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/30_uefi-firmware ###

### END /etc/grub.d/30_uefi-firmware ###

### BEGIN /etc/grub.d/40_custom ###

# This file provides an easy way to add custom menu entries.  Simply type the

# menu entries you want to add after this comment.  Be careful not to change

# the 'exec tail' line above.

### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###

if [ -f  $prefix/custom.cfg ]; then

  source $prefix/custom.cfg;

fi

### END /etc/grub.d/41_custom ###

```

Last edited by roytheman on Mon Feb 18, 2013 12:55 pm; edited 2 times in total

----------

## NeddySeagoon

roytheman,

There are no files from Feb 15 there, so lets follow the kernel build tree.

What does 

```
readlink /usr/src/linux
```

 show ?

We need to know we are looking in the right tree ...

Now check the dates on the following files, I have listed them in order ... oldest first.

/usr/src/linux/.config    everything starts here, this is the file used to guide the build of the kernel, writtem by make menuconfig

/usr/src/linux/arch/x86/boot/bzimage   this is the as built kernel binary, that should be copied to boot

If the datestamp is Feb 15, the copy to boot went wrong.

With boot not mounted, what do you have in /boot?

The right answer is nothing but you do have files there, what are they and what are their timestamps. Do not deleted them.

Now mount /boot and you should get what was in your last post.

----------

## roytheman

I ran ls -a -l in /usr/src/linux and this is what I got:

localhost linux # ls -a -l

total 42864

drwxr-xr-x  24 root root     4096 Jan 26 06:43 .

drwxr-xr-x   4 root root     4096 Dec 29 10:23 ..

-rw-r--r--   1 root root   105224 Jan 26 05:59 .config

-rw-r--r--   1 root root   105181 Dec 29 06:08 .config--2012-12-29--06-08-15.bak

-rw-r--r--   1 root root   105170 Jan 26 04:58 .config--2013-01-26--04-58-06.bak

-rw-r--r--   1 root root   105170 Jan 26 05:11 .config--2013-01-26--05-11-42.bak

-rw-r--r--   1 root root   105224 Jan 26 05:59 .config--2013-01-26--05-59-28.bak

-rw-r--r--   1 root root   105224 Jan 26 05:59 .config.old

-rw-r--r--   1 root root     1014 Jul 21  2012 .gitignore

-rw-r--r--   1 root root     4465 Jul 21  2012 .mailmap

-rw-r--r--   1 root root      420 Jan 26 06:34 .missing-syscalls.d

-rw-r--r--   1 root root  1631805 Jan 26 06:34 .tmp_System.map

-rw-r--r--   1 root root   501696 Jan 26 06:34 .tmp_kallsyms1.o

-rw-r--r--   1 root root   501696 Jan 26 06:34 .tmp_kallsyms2.o

drwxr-xr-x   2 root root    36864 Jan 26 06:42 .tmp_versions

-rwxr-xr-x   1 root root  8782207 Jan 26 06:34 .tmp_vmlinux1

-rwxr-xr-x   1 root root  9281671 Jan 26 06:34 .tmp_vmlinux2

-rw-r--r--   1 root root        2 Jan 26 06:34 .version

-rw-r--r--   1 root root       87 Jan 26 06:34 .vmlinux.cmd

-rw-r--r--   1 root root    18693 Jul 21  2012 COPYING

-rw-r--r--   1 root root    94956 Jul 21  2012 CREDITS

drwxr-xr-x  97 root root    12288 Dec 27 13:48 Documentation

-rw-r--r--   1 root root     2536 Jul 21  2012 Kbuild

-rw-r--r--   1 root root      252 Jul 21  2012 Kconfig

-rw-r--r--   1 root root   213163 Dec 27 13:48 MAINTAINERS

-rw-r--r--   1 root root    47155 Dec 27 13:48 Makefile

-rw-r--r--   1 root root   567607 Jan 26 06:42 Module.symvers

-rw-r--r--   1 root root    17766 Jul 21  2012 README

-rw-r--r--   1 root root     3371 Jul 21  2012 REPORTING-BUGS

-rw-r--r--   1 root root  1631805 Jan 26 06:34 System.map

drwxr-xr-x  30 root root     4096 Jan 26 06:34 arch

drwxr-xr-x   3 root root     4096 Jan 26 06:35 block

drwxr-xr-x   3 root root    20480 Jan 26 06:43 crypto

drwxr-xr-x 104 root root     4096 Jan 26 06:42 drivers

drwxr-xr-x  37 root root     4096 Jan 26 06:43 firmware

drwxr-xr-x  71 root root    12288 Jan 26 06:43 fs

drwxr-xr-x  25 root root     4096 Jan 26 06:31 include

drwxr-xr-x   2 root root     4096 Jan 26 06:34 init

drwxr-xr-x   2 root root     4096 Jan 26 06:34 ipc

drwxr-xr-x  10 root root    12288 Jan 26 06:34 kernel

drwxr-xr-x   9 root root    16384 Jan 26 06:43 lib

drwxr-xr-x   2 root root     4096 Jan 26 06:34 mm

-rw-r--r--   1 root root     4909 Jan 26 06:42 modules.builtin

-rw-r--r--   1 root root    49449 Jan 26 06:42 modules.order

drwxr-xr-x  55 root root     4096 Jan 26 06:42 net

drwxr-xr-x  12 root root     4096 Dec 27 13:48 samples

drwxr-xr-x  13 root root     4096 Jan 26 06:34 scripts

drwxr-xr-x   9 root root     4096 Jan 26 06:34 security

drwxr-xr-x  22 root root     4096 Jan 26 06:43 sound

drwxr-xr-x  15 root root     4096 Dec 27 13:48 tools

drwxr-xr-x   2 root root     4096 Jan 26 06:34 usr

drwxr-xr-x   3 root root     4096 Dec 27 13:48 virt

-rwxr-xr-x   1 root root  9281671 Jan 26 06:34 vmlinux

-rw-r--r--   1 root root 10239555 Jan 26 06:34 vmlinux.o

localhost linux # 

Then I ran ls -al in /usr/src/linux/arch/x86/boot and this is what I got:

localhost linux # ls -a -l

total 42864

drwxr-xr-x  24 root root     4096 Jan 26 06:43 .

drwxr-xr-x   4 root root     4096 Dec 29 10:23 ..

-rw-r--r--   1 root root   105224 Jan 26 05:59 .config

-rw-r--r--   1 root root   105181 Dec 29 06:08 .config--2012-12-29--06-08-15.bak

-rw-r--r--   1 root root   105170 Jan 26 04:58 .config--2013-01-26--04-58-06.bak

-rw-r--r--   1 root root   105170 Jan 26 05:11 .config--2013-01-26--05-11-42.bak

-rw-r--r--   1 root root   105224 Jan 26 05:59 .config--2013-01-26--05-59-28.bak

-rw-r--r--   1 root root   105224 Jan 26 05:59 .config.old

-rw-r--r--   1 root root     1014 Jul 21  2012 .gitignore

-rw-r--r--   1 root root     4465 Jul 21  2012 .mailmap

-rw-r--r--   1 root root      420 Jan 26 06:34 .missing-syscalls.d

-rw-r--r--   1 root root  1631805 Jan 26 06:34 .tmp_System.map

-rw-r--r--   1 root root   501696 Jan 26 06:34 .tmp_kallsyms1.o

-rw-r--r--   1 root root   501696 Jan 26 06:34 .tmp_kallsyms2.o

drwxr-xr-x   2 root root    36864 Jan 26 06:42 .tmp_versions

-rwxr-xr-x   1 root root  8782207 Jan 26 06:34 .tmp_vmlinux1

-rwxr-xr-x   1 root root  9281671 Jan 26 06:34 .tmp_vmlinux2

-rw-r--r--   1 root root        2 Jan 26 06:34 .version

-rw-r--r--   1 root root       87 Jan 26 06:34 .vmlinux.cmd

-rw-r--r--   1 root root    18693 Jul 21  2012 COPYING

-rw-r--r--   1 root root    94956 Jul 21  2012 CREDITS

drwxr-xr-x  97 root root    12288 Dec 27 13:48 Documentation

-rw-r--r--   1 root root     2536 Jul 21  2012 Kbuild

-rw-r--r--   1 root root      252 Jul 21  2012 Kconfig

-rw-r--r--   1 root root   213163 Dec 27 13:48 MAINTAINERS

-rw-r--r--   1 root root    47155 Dec 27 13:48 Makefile

-rw-r--r--   1 root root   567607 Jan 26 06:42 Module.symvers

-rw-r--r--   1 root root    17766 Jul 21  2012 README

-rw-r--r--   1 root root     3371 Jul 21  2012 REPORTING-BUGS

-rw-r--r--   1 root root  1631805 Jan 26 06:34 System.map

drwxr-xr-x  30 root root     4096 Jan 26 06:34 arch

drwxr-xr-x   3 root root     4096 Jan 26 06:35 block

drwxr-xr-x   3 root root    20480 Jan 26 06:43 crypto

drwxr-xr-x 104 root root     4096 Jan 26 06:42 drivers

drwxr-xr-x  37 root root     4096 Jan 26 06:43 firmware

drwxr-xr-x  71 root root    12288 Jan 26 06:43 fs

drwxr-xr-x  25 root root     4096 Jan 26 06:31 include

drwxr-xr-x   2 root root     4096 Jan 26 06:34 init

drwxr-xr-x   2 root root     4096 Jan 26 06:34 ipc

drwxr-xr-x  10 root root    12288 Jan 26 06:34 kernel

drwxr-xr-x   9 root root    16384 Jan 26 06:43 lib

drwxr-xr-x   2 root root     4096 Jan 26 06:34 mm

-rw-r--r--   1 root root     4909 Jan 26 06:42 modules.builtin

-rw-r--r--   1 root root    49449 Jan 26 06:42 modules.order

drwxr-xr-x  55 root root     4096 Jan 26 06:42 net

drwxr-xr-x  12 root root     4096 Dec 27 13:48 samples

drwxr-xr-x  13 root root     4096 Jan 26 06:34 scripts

drwxr-xr-x   9 root root     4096 Jan 26 06:34 security

drwxr-xr-x  22 root root     4096 Jan 26 06:43 sound

drwxr-xr-x  15 root root     4096 Dec 27 13:48 tools

drwxr-xr-x   2 root root     4096 Jan 26 06:34 usr

drwxr-xr-x   3 root root     4096 Dec 27 13:48 virt

-rwxr-xr-x   1 root root  9281671 Jan 26 06:34 vmlinux

-rw-r--r--   1 root root 10239555 Jan 26 06:34 vmlinux.o

localhost linux # 

So it looks like the time stamp for .config is Jan. 26 and the timestamp for bzimage is Jan. 26.

I'm afraid I am fixing to show my ignorance, but I do not know what you mean by unmounting boot. But when boot is mounted, I can run ls -al and this is what I get:

roy@localhost /boot $ ls -l

total 17064

-rw-r--r-- 1 root root 1603641 Sep 12 06:05 System.map-genkernel-x86-3.3.8-gentoo

-rw-r--r-- 1 root root 1631805 Jan 26 06:34 System.map-genkernel-x86-3.5.7-gentoo

-rw-r--r-- 1 root root 4053191 Sep 12 06:15 initramfs-genkernel-x86-3.3.8-gentoo

-rw-r--r-- 1 root root 4073665 Jan 26 06:44 initramfs-genkernel-x86-3.5.7-gentoo

-rw-r--r-- 1 root root 3005520 Sep 12 06:05 kernel-genkernel-x86-3.3.8-gentoo

-rw-r--r-- 1 root root 3068624 Jan 26 06:34 kernel-genkernel-x86-3.5.7-gentoo

I hope I am helping you so you can help me.

Regards,

Roy

----------

## NeddySeagoon

roytheman,

Well, its all self consistent, if a bit odd.

What does the date command show on your system now ?

----------

## roytheman

localhost boot # date

Sat Feb 16 13:24:28 EST 2013

My clock keeps getting 6 or 7 hours off from time to time but that will be one of my future projects to fix it.

Thanks for your help and for your time, and please, I am still open for suggestions.

Best regards,

Roy

----------

## NeddySeagoon

roytheman,

Fix your clock now.  That can be the cause of your issue. Heres how.

make is lazy.  It looks at the timestamps on the output file its being asked to make.

If the output file is newer than all of the input files, then make does nothing as the output files exists and none of the files that contribute to it have changed, so the output file is still good.

Now suppose your clock goes back six or seven hours. You change something in the kernel, like the .config tree.  make can think that there is nothing to do ....

Thats simplifed but you get the picture.

Having told you to fix your clock, heres the emergency fallback work around.

Go into the kernel and remove all of the output files.  This forces make to make everything, so clock issues won't matter, just this once.

```
cd /usr/src/linux

make clean
```

now build and install the kernel in the normal way.

Check menuconfig for the devtmpfs settings before you build.

----------

## roytheman

Thanks for the reply NeddySeagoon,

I changed to the linux directory (cd /usr/src/linux) and ran "make clean" then ran "genkernel --menuconfig all" but the problem still persists.

Thank you for your help and time. I'm still open for suggestions.

Best regards,

Roy

----------

## NeddySeagoon

roytheman,

Now boot into Mint and tell the bootloader to pick up your new kernel

----------

## SamuliSuominen

The last person with this type of problem was that genkernel was reading wrong .config file. The location has either changed or the user had some old config in wrong place.

----------

## roytheman

Hello Again Gentoo Forum,

I finally realized that not only can I not set DEVTMPFS=y but I can not make ANY changes to the kernel whatsoever. The changes simply won't stick. The .config file in /usr/src/linux would show the changes fine, but the changes would not show up in /dev/proc using the command "zgrep DEVTMPFS /proc/config.gz".

But I was blown away this morning by realizing that if I want to make changes to the kernel, I need to make those changes in a different installation of Gentoo on a different partition! I have two installations of Gentoo on my multi-boot system, each on a separate partition, and both of them use the same version kernel (3.5.7) and the installation of Gentoo I was having problems with was on sda6 and the installation of Gentoo that works fine is on sda7, so I realized if I turned on DEVTMPFS in the installation of Gentoo that works fine (sda7), it would also turn on DEVTMPFS in the installation of Gentoo I was having my problem in (sda6). In other words, any changes I make to the kernel on sda7 will also make the same changes to the kernel on sda6!

Even though my problem is now "fixed" (udev now starts fine), I am reluctant to mark this thread solved because I don't know why what I did this morning fixed the problem.

I *think* the reason for this strange behavior is because in Grub2, the entries for both installations of Gentoo are identical except for the device node (one is sda6 and the other is sda7) as shown below (from grub.cfg which is located at /boot/grub in Linux Mint). Even the UUIDs are the same.

```

menuentry "Gentoo Base System release 2.1 (on /dev/sda6)" --class gnu-linux --class gnu --class os {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos6)'

   search --no-floppy --fs-uuid --set=root ef5fa8a5-dc16-46ec-ace7-ff05a25b626d

   linux /boot/kernel-genkernel-x86-3.3.8-gentoo root=/dev/sda6

   initrd /boot/initramfs-genkernel-x86-3.3.8-gentoo

}

menuentry "Gentoo Base System release 2.1 (on /dev/sda6)" --class gnu-linux --class gnu --class os {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos6)'

   search --no-floppy --fs-uuid --set=root ef5fa8a5-dc16-46ec-ace7-ff05a25b626d

   linux /boot/kernel-genkernel-x86-3.5.7-gentoo root=/dev/sda6

   initrd /boot/initramfs-genkernel-x86-3.5.7-gentoo

}

menuentry "Gentoo Base System release 2.1 (on /dev/sda7)" --class gnu-linux --class gnu --class os {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos7)'

   search --no-floppy --fs-uuid --set=root ef5fa8a5-dc16-46ec-ace7-ff05a25b626d

   linux /boot/kernel-genkernel-x86-3.3.8-gentoo root=/dev/sda7

   initrd /boot/initramfs-genkernel-x86-3.3.8-gentoo

}

menuentry "Gentoo Base System release 2.1 (on /dev/sda7)" --class gnu-linux --class gnu --class os {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos7)'

   search --no-floppy --fs-uuid --set=root ef5fa8a5-dc16-46ec-ace7-ff05a25b626d

   linux /boot/kernel-genkernel-x86-3.5.7-gentoo root=/dev/sda7

   initrd /boot/initramfs-genkernel-x86-3.5.7-gentoo

}

### END /etc/grub.d/30_os-prober ### 

```

I am very curious exactly causes this behavior. Is somebody able to explain it to me? I do not want to have to make changes in the Gentoo installation on sda7 in order to make changes on sda6. Why can't I make changes to the kernel on sda6 while I am booted into that partition? The way it is now, I have to boot into sda7, run "genkernel --menuconfig all" to make changes to sda6!

Thanks for your help,

Roy

----------

## NeddySeagoon

roytheman,

You have  

```
set root='(hd0,msdos6)' 
```

for one install and  

```
set root='(hd0,msdos7)' 
```

so grub2 should load the kernel from different places

----------

## roytheman

Hello Again Gentoo Forum,

I solved my problem. The problem was with the way Grub2 configured the boot entries.

I had to comment out the lines in the grub.cfg file that contained the UUID in Grub2 which was located in the boot directory of Linux Mint (I have a multi-boot configuration and the OS that contained Grub2 was located on Linux Mint). Grub2 was reading the UUID and nothing else, and since the UUIDs were the same for both installations of Gentoo, the same kernel was being used for both installations of Gentoo, and  since both kernels were the same version they could be interchanged.

```

menuentry "Gentoo Base System release 2.1 (on /dev/sda6)" --class gnu-linux --class gnu --class os {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos6)'

  #search --no-floppy --fs-uuid --set=root ef5fa8a5-dc16-46ec-ace7-ff05a25b626d

   linux /boot/kernel-genkernel-x86-3.3.8-gentoo root=/dev/sda6

   initrd /boot/initramfs-genkernel-x86-3.3.8-gentoo

}

menuentry "Gentoo Base System release 2.1 (on /dev/sda6)" --class gnu-linux --class gnu --class os {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos6)'

  #search --no-floppy --fs-uuid --set=root ef5fa8a5-dc16-46ec-ace7-ff05a25b626d

   linux /boot/kernel-genkernel-x86-3.5.7-gentoo root=/dev/sda6

   initrd /boot/initramfs-genkernel-x86-3.5.7-gentoo

}

menuentry "Gentoo Base System release 2.1 (on /dev/sda7)" --class gnu-linux --class gnu --class os {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos7)'

  #search --no-floppy --fs-uuid --set=root ef5fa8a5-dc16-46ec-ace7-ff05a25b626d

   linux /boot/kernel-genkernel-x86-3.3.8-gentoo root=/dev/sda7

   initrd /boot/initramfs-genkernel-x86-3.3.8-gentoo

}

menuentry "Gentoo Base System release 2.1 (on /dev/sda7)" --class gnu-linux --class gnu --class os {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos7)'

  #search --no-floppy --fs-uuid --set=root ef5fa8a5-dc16-46ec-ace7-ff05a25b626d

   linux /boot/kernel-genkernel-x86-3.5.7-gentoo root=/dev/sda7

   initrd /boot/initramfs-genkernel-x86-3.5.7-gentoo

}

### END /etc/grub.d/30_os-prober ### 

```

It appears that when I booted up into the Gentoo installation where udev would not start, I was using the kernel from my OTHER Gentoo installation, which resides on a different partition. That would explain why any changes I made in the kernel from the Gentoo that had the problem would not stick because the OS was not using the kernel I was compiling. It was using the kernel from the OTHER Gentoo installation.

In summary, it looks like there is a bug in os-prober, which is a dependency of Grub2.

I want to thank everybody who helped me solve this problem.

Sincerely,

Roy

----------

## roytheman

Hello Again Gentoo Forum,

As it turned out, there was NOT a bug in os-prober. I used the command "tune2fs -U random /dev/sda6" to generate a new UUID for the partition that contained the Gentoo that was having the problem, then I ran "update-grub" from Linux Mint to make the changes take effect, and viola, no more problem. Now I do not have to comment out the UUIDs mentioned in the above post. I fixed the problem the correct way.

The reason the UUIDs were identical for both sda6 and sda7 is because sda6 used to reside on sda7 but I moved the partition to another location (sda6) a while back, and as a result, the UUIDs stayed the same on both partitions, thus causing the problem. So the reason for the problem was due to my ignorance, not a bug.

As seen below, the UUIDs are now different for sda6 and sda7.

```

menuentry "Gentoo Base System release 2.1 (on /dev/sda6)" --class gnu-linux --class gnu --class os {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos6)'

   search --no-floppy --fs-uuid --set=root bcab7e59-c67e-40c2-b354-d21cd02dffd4

   linux /boot/kernel-genkernel-x86-3.3.8-gentoo root=/dev/sda6

   initrd /boot/initramfs-genkernel-x86-3.3.8-gentoo

}

menuentry "Gentoo Base System release 2.1 (on /dev/sda6)" --class gnu-linux --class gnu --class os {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos6)'

   search --no-floppy --fs-uuid --set=root bcab7e59-c67e-40c2-b354-d21cd02dffd4

   linux /boot/kernel-genkernel-x86-3.5.7-gentoo root=/dev/sda6

   initrd /boot/initramfs-genkernel-x86-3.5.7-gentoo

}

menuentry "Gentoo Base System release 2.1 (on /dev/sda7)" --class gnu-linux --class gnu --class os {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos7)'

   search --no-floppy --fs-uuid --set=root ef5fa8a5-dc16-46ec-ace7-ff05a25b626d

   linux /boot/kernel-genkernel-x86-3.3.8-gentoo root=/dev/sda7

   initrd /boot/initramfs-genkernel-x86-3.3.8-gentoo

}

menuentry "Gentoo Base System release 2.1 (on /dev/sda7)" --class gnu-linux --class gnu --class os {

   insmod part_msdos

   insmod ext2

   set root='(hd0,msdos7)'

   search --no-floppy --fs-uuid --set=root ef5fa8a5-dc16-46ec-ace7-ff05a25b626d

   linux /boot/kernel-genkernel-x86-3.5.7-gentoo root=/dev/sda7

   initrd /boot/initramfs-genkernel-x86-3.5.7-gentoo

}

```

The moral to this whole story is that if you ever move a partition with an OS installed to a different partition, make sure you assign the newly located partition with a new UUID or you will have the same problems like I had (duplicate UUIDs). I know this post got a little off topic from udev not starting to assigning new UUIDs, but that is what it took to get my probem solved.

Linux Rocks.

Roy

----------

## NeddySeagoon

roytheman,

Take care with the use of the word 'partition'

Filesystems certainly have UUIDs

The partitions they reside on can have their own UUIDs too.

The UUID for the partition and the filesystem it contains are not the same, at least, not unless you are really really unlucky.

----------

## srs5694

 *NeddySeagoon wrote:*   

> Take care with the use of the word 'partition'
> 
> Filesystems certainly have UUIDs
> 
> The partitions they reside on can have their own UUIDs too.

 

To elaborate: The GUID Partition Table (GPT) assigns every partition its own GUID, which is a particular type of UUID. The older Master Boot Record (MBR) partitioning system does not assign GUIDs or UUIDs to partitions, though. I just did a test by looking at the /dev/disk/by-partuuid/ directory on my Gentoo system. I found that when I inserted a USB flash drive with an MBR, no no entry appeared; but when I converted that flash drive to use GPT, a new entry appeared in /dev/disk/by-partuuid, reflecting the partition on the disk. By contrast, /dev/disk/by-uuid/ showed a new UUID for the filesystem whether the flash drive used MBR or GPT. Also note that filesystem UUIDs are truly UUIDs for Linux filesystems; but Linux identifies non-UUID serial numbers as UUIDs for FAT, NTFS, and probably some other filesystems. One more point: Every GPT partition actually has TWO GUIDs: One is a unique partition identifier and the other is a code for the partition type (similar to the one-byte MBR code, like 0x83 for a Linux filesystem). Most utilities hide the GPT type code or translate it to something else, like a "flag" in libparted tools or a two-byte code in gdisk.

Note that there's a similar distinction in the /dev/disk directory tree for filesystem labels and partition labels (/dev/disk/by-label and /dev/disk/by-partlabel, respectively). Even outside of that directory tree, some tools (gdisk, recent versions of parted) show partition labels, whereas others (GParted, older versions of parted) show filesystem labels. As with GUIDs, MBR doesn't support partition labels. Some partitioning tools don't bother to set them even on GPT disks.

You can use filesystem UUIDs or labels in /etc/fstab, but AFAIK you can't use partition GUIDs or labels in /etc/fstab.

Although the availability of GUIDs and partition labels can be a great benefit in many ways, the fact that these GUIDs and labels at least partially overlap with the uses of filesystem UUIDs and filesystem labels can be, as you imply, confusing.

----------

