After upgrading the other day (eix-sync && emerge -uDN @world) I noticed there was a news item to be read (eselect news list then eselect news read # replacing # with the news item you wish to read). Seems a bit of work is required after updating to =sys-fs/udev-200.
I strongly recommend you read the news item yourself and the other sources I cite, I take no responsibility if the following results in a broken system.
Make sure that your kernel has CONFID_DEVTMPFS=y enabled, to check simply grep your /usr/src/linux/.config…
grep DEVTMPFS /usr/src/linux/.config CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y
…if not add it, recompile your kernel as you normally wold.
Next you're instructed to ensure that if you have a /dev entry in /etc/fstab to ensure that this has the devtmpfs file system (that you have just checked is enabled in your kernel). I found this a little cryptic as I've lots of /dev entires in my /etc/fsab every hard drive I mount is a dev after all! What it actually means is if you have an entry for a mountpoint for /dev (i.e. the second column). I don't, but the news item indicates that its not actually needed as devtmpfs is mounted automatically, and lo and behold when I checked the output of df to see what I have mounted it is indeed there…
df -h | grep 'devtmpfs' devtmpfs 3.0G 0 3.0G 0% /dev
I rarely tinker deeply with interface naming rules so this was what worried me. I noted under item 4 of the news item that I do not having anything but comments in /etc/udev/rules.d/80-net-name-slot.rules so that meant that new names would be disabled and kernel will do all the interface naming. However under item 3 it indicated that because I have /etc/udev/rules.d/70-persistent-[cd|net].rules (i.e. one for CD-drives and one for my network interfaces) that they need to be modified or removed. Rather than modify them I opted to hide them (rather than remove just in case I needed them!). After reading the comments in /etc/udev/rules.d/80-net-name-slot.rules I also opted to hide that too…
mv /etc/udev/rules.d/70-persistent-cd.rules /etc/udev/rules.d/.70-persistent-cd.rules mv /etc/udev/rules.d/70-persistent-net.rules /etc/udev/rules.d/.70-persistent-net.rules mv /etc/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/.80-net-name-slot.rules
…essentially making them hidden files.
This was the last step and involves first removing udev-postmount scripts from runlevels. This caused me some confusion as I've only two udev init scripts…
ls -l /etc/init.d/udev* -rwxr-xr-x 1 root root 4271 Mar 22 08:13 /etc/init.d/udev -rwxr-xr-x 1 root root 2046 Mar 22 08:13 /etc/init.d/udev-mount
A bit of poking around on my system revealed that there were some very old archived config udev-postmount files almost a year old so I was happy that I'd removed udev-postmount as it wasn't in any of my current run-levels…
ls -l /etc/config-archive/etc/init.d/udev-postmount* -rwxr-xr-x 1 root root 1358 Mar 21 2012 /etc/config-archive/etc/init.d/udev-postmount -rwxr-xr-x 1 root root 1335 Dec 11 2011 /etc/config-archive/etc/init.d/udev-postmount.1 -rwxr-xr-x 1 root root 1279 Dec 6 2011 /etc/config-archive/etc/init.d/udev-postmount.2 -rwxr-xr-x 1 root root 837 Oct 12 2010 /etc/config-archive/etc/init.d/udev-postmount.3 -rwxr-xr-x 1 root root 838 Jul 13 2010 /etc/config-archive/etc/init.d/udev-postmount.4 -rwxr-xr-x 1 root root 808 May 18 2010 /etc/config-archive/etc/init.d/udev-postmount.5 -rwxr-xr-x 1 root root 805 May 4 2010 /etc/config-archive/etc/init.d/udev-postmount.6 -rwxr-xr-x 1 root root 805 Jan 20 2010 /etc/config-archive/etc/init.d/udev-postmount.7 -rwxr-xr-x 1 root root 685 Oct 30 2009 /etc/config-archive/etc/init.d/udev-postmount.8 -rwxr-xr-x 1 root root 1350 Mar 22 2012 /etc/config-archive/etc/init.d/udev-postmount.dist rc-update show | grep postmount
The final thing was to ensure there was an initscript for the new name my network card would receive which is the output from…
udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null ID_NET_NAME_MAC=enx001fd0207979 ID_OUI_FROM_DATABASE=GIGA-BYTE TECHNOLOGY CO.,LTD. ID_NET_NAME_PATH=enp5s0
…so I created a symlink and added it to the default run-level…
ln -s /etc/init.d/net.lo /etc/init.d/net.enp5s0 ls -l /etc/init.d/net.* lrwxrwxrwx 1 root root 18 Apr 2 19:31 /etc/init.d/net.enp5s0 -> /etc/init.d/net.lo lrwxrwxrwx 1 root root 6 Oct 1 2009 /etc/init.d/net.eth0 -> /etc/init.d/net.lo -rwxr-xr-x 1 root root 16919 Dec 9 15:18 /etc/init.d/net.lo rc-update add net.enp5s0 default * service net.enp5s0 added to runlevel default
I purposefully left the old init script for net.eth0 in the default run-level just in case.
On my laptop I tend to use the WiFi card to connect to networks and as such I DON'T explicitly bring up the wlan0 interface by adding a symbolic link to the loopback device (ln -s /etc/init.d/net.lo /etc/init.d/net.wlan0) and then adding it to the default run level (rc-update add net.wlan0 default). Instead I have NetworkManager (rc-update add NetworkManager default) in the default run-level and it would seem that it is smart enough to detect the new name of the wireless card on re-booting (after removing /etc/udev/rules.d/80-net-name-slot.rules which only had comments in it anyway). I'm yet to test it with a wired connection as the adapter isn't at home but suspect that since NetworkManager handled that too everything will be fine.