[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#414287: me too



reassign 414287 udev 0.125-7+lenny3
tags 414287 + patch
thanks

On Thu, May 21, 2009 at 10:50:51PM +0100, Daniel Pocock wrote:
> My box had lenny (installed in December, before the official
> release), I just did:
> 
>  apt-get dist-upgrade
> 
> It upgraded the box from 2.6.26-1 to 2.6.26-2
> 
> I did a reboot to get the new kernel
> 
> On booting, eth0 became eth0_rename_ren
> 
> I looked at:
> 
>   /etc/udev/rules.d/70-persistent-net.rules
> 
> and found each MAC listed multiple times, with variations of
> eth0_rename and eth0, etc
> 
> I deleted the file completely, rebooted again, and found the
> interfaces eth1, eth0_rename, eth2_rename and eth3_rename on my
> system, and each of these describe once in
> /etc/udev/rules.d/70-persistent-net.rules
> 
> I edited the file by hand, remove _rename from each of the names,
> rebooted again and now I have eth0, eth1, eth2, eth3
> 
> Now for another reboot - and I still have eth0, eth1, eth2, eth3 now.
> 
> My biggest concern is that booting without any
> /etc/udev/rules.d/70-persistent-net.rules gave me three interfaces
> with _rename appended to their names.
> 
> One other comment, not sure if it could be related to the issue in any
> way, but this is a Xen dom0 box, and Xen does it's usual tricks
> renaming interfaces, but not until after the udev setup.

I have seen this issue before, and the culprit was having a stale
70-persistent-net.rules file in the initrd.  It happened to us when we
added a network interface and didn't re-build the initrd, but the
symptoms look the same.  The attached patch fixed the issue for us.

-- 
+----------------------------------------------------------+
| John Wright <john.wright@hp.com>                         |
| HP Mission Critical OS Enablement & Solution Test (MOST) |
+----------------------------------------------------------+
Cleanly handle when new network interfaces are added to the system

 * Don't put the persistent-net rules in the initrd.
   - Users can easily modify persistent-net.rules on the system without
     running update-initramfs, and there's no point in setting up
     interfaces twice anyway.
   - More importantly, suppose we have set up rules for eth0 and eth1 in
     our persistent-net.rules.  Then, we add another interface, which
     the kernel happens to see as eth0.  Without
     persistent-net-generator.rules (or rather, without write_net_rules,
     which isn't included in the initrd), the new interface will never
     be renamed away from eth0.  So the process that tries to rename our
     previously configured interface to eth0 will sit for 30 seconds
     waiting for this to happen before finally giving up (and leaving an
     ethN_rename interface behind).

Index: udev/extra/initramfs.hook
===================================================================
--- udev.orig/extra/initramfs.hook	2009-06-15 18:33:30.000000000 -0600
+++ udev/extra/initramfs.hook	2009-06-15 18:33:50.000000000 -0600
@@ -18,6 +18,8 @@
 
 cp -a /etc/udev/ $DESTDIR/etc/
 rm -f $DESTDIR/etc/udev/rules.d/75-cd-aliases-generator.rules
+rm -f $DESTDIR/etc/udev/rules.d/75-persistent-net-generator.rules
+rm -f $DESTDIR/etc/udev/rules.d/70-persistent-net.rules
 if [ -e /etc/scsi_id.config ]; then
   cp /etc/scsi_id.config $DESTDIR/etc/
 fi

Reply to: