From: Bruce S. <bw...@re...> - 2012-03-24 01:28:47
|
I'm installing DL 1.6.0-RC3 on a new firewall and it assigns eth0 & eth1 to different network cards depending if I cold boot (power on) vs. a warm reboot. The script that writes /etc/udev/rules.d/70-persistent-net.rules doesn't seem to exist any longer, and that file is never getting created automatically. I had to create it manually to fix the random NIC name assignment problem. Is this a bug, or are we handling the naming of NIC's differently now? BTW, I tried assigning the module names in setup, instead of using autoselect. That made no difference, and did not assign the names as I specified. - BS |
From: Serge L. <ser...@gm...> - 2012-03-24 02:14:29
|
Hi Bruce, you are right... We missed "--enable-rule_generator" in udev script. Will test the script during weekend. BTW: There is a problem with 2 instances of devfs (/dev/, /shm/dev). A quick research shows that we should change init scripts a bit, i.e. --- pre_init 2012-03-23 19:06:49.000000000 -0700 +++ pre_init 2012-03-23 19:07:55.000000000 -0700 @@ -58,7 +58,8 @@ # this won't completely umount, because the loop device is still using it # that's why we use the lazy option umount /initrd -l &> /dev/null -umount /shm/dev &> /dev/null +# it will fail because /shm/dev/console is locked +#umount /shm/dev &> /dev/null echo "Freeing InitRD memory" freeramdisk /dev/ram0 and --- etc/init.d/boot 2012-03-23 19:12:17.000000000 -0700 +++ /etc/init.d/boot 2012-03-23 19:11:28.000000000 -0700 @@ -49,6 +49,10 @@ /sbin/udevadm settle evaluate_retval +# unmount "old" devtmpfs and remove the dir +umount /shm/dev &> /dev/null +rm -rf /shm/dev &> /dev/null + # ls /dev/ if [ -f /proc/sys/kernel/sysrq ]; then Sincerely, Serge On 03/23/2012 06:28 PM, Bruce Smith wrote: > I'm installing DL 1.6.0-RC3 on a new firewall and it assigns eth0& > eth1 to different network cards depending if I cold boot (power on) > vs. a warm reboot. > > The script that writes /etc/udev/rules.d/70-persistent-net.rules > doesn't seem to exist any longer, and that file is never getting > created automatically. I had to create it manually to fix the random > NIC name assignment problem. > > Is this a bug, or are we handling the naming of NIC's differently now? > > BTW, I tried assigning the module names in setup, instead of using > autoselect. That made no difference, and did not assign the names as > I specified. > > - BS > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > |
From: Bruce S. <bw...@re...> - 2012-03-24 12:05:51
|
> OK, the brief update. "--enable-rule_generator" works (adds persistent-net and > persistent-cd). OK, good. Are you going to commit that change? And do we need to add anything in the boot scripts to run the script that creates persistent-net? > During the testing (in KVM) I found the following lines in > persistent_net_generator which floored me: > > # ignore KVM virtual interfaces > ENV{MATCHADDR}=="52:54:00:*", GOTO="persistent_net_generator_end" > # ignore VMWare virtual interfaces > ENV{MATCHADDR}=="00:0c:29:*|00:50:56:*", GOTO="persistent_net_generator_end" > # ignore Hyper-V virtual interfaces > ENV{MATCHADDR}=="00:15:5d:*", GOTO="persistent_net_generator_end" > > I have no idea why persistent_net should not work in virtualized environments. > For me it looks like a bug/mistake. > I'd be happy if you share your opinion. I did a little research and it sounds like many virtualized environments reuse MAC address ranges assigned to other manufacturers, so I guess they don't want a conflict. Is there a file in /lib/udev/rules.d/ that has a rule to omit KVM devices? (like "75-persistent-net-generator.rules") If so, I'd be okay with editing the file to remove the VM rules, or just removing that file. - BS |
From: Bruce S. <bw...@re...> - 2012-03-24 22:13:04
|
>> I did a little research and it sounds like many virtualized >> environments reuse MAC address ranges assigned to other manufacturers, >> so I guess they don't want a conflict. > I'd say if we have more than 1 NIC in a VM, we have to fixate name <-> mac > regardless of possible conflict (if there is a conflict, we have to re-generate > mac addresses - but it's a bit different story). To be honest, I don't > understand the reason of ignoring NIC name persistence in VM, but those line > were intentionally added - so, the reason apparently exists. It goads my > curiosity :) I don't understand it either. Does KVM keep the same Mac address every time it boots the same VM? (if not, then it makes sense) >> Is there a file in /lib/udev/rules.d/ that has a rule to omit KVM >> devices? (like "75-persistent-net-generator.rules") If so, I'd be >> okay with editing the file to remove the VM rules, or just removing >> that file. > Yes, it's exactly "75-persistent-net-generator.rules" file. Done as a patch > because we cannot remove the rules file. Why can't the file just be removed in the install script? - BS |
From: Serge L. <ser...@gm...> - 2012-03-24 10:15:59
|
Hi, OK, the brief update. "--enable-rule_generator" works (adds persistent-net and persistent-cd). During the testing (in KVM) I found the following lines in persistent_net_generator which floored me: # ignore KVM virtual interfaces ENV{MATCHADDR}=="52:54:00:*", GOTO="persistent_net_generator_end" # ignore VMWare virtual interfaces ENV{MATCHADDR}=="00:0c:29:*|00:50:56:*", GOTO="persistent_net_generator_end" # ignore Hyper-V virtual interfaces ENV{MATCHADDR}=="00:15:5d:*", GOTO="persistent_net_generator_end" I have no idea why persistent_net should not work in virtualized environments. For me it looks like a bug/mistake. I'd be happy if you share your opinion. Serge On 03/23/2012 07:14 PM, Serge Leschinsky wrote: > Hi Bruce, > > you are right... We missed "--enable-rule_generator" in udev script. > Will test the script during weekend. > > BTW: There is a problem with 2 instances of devfs (/dev/, /shm/dev). > A quick research shows that we should change init scripts a bit, i.e. > > --- pre_init 2012-03-23 19:06:49.000000000 -0700 > +++ pre_init 2012-03-23 19:07:55.000000000 -0700 > @@ -58,7 +58,8 @@ > # this won't completely umount, because the loop device is still using it > # that's why we use the lazy option > umount /initrd -l &> /dev/null > -umount /shm/dev &> /dev/null > +# it will fail because /shm/dev/console is locked > +#umount /shm/dev &> /dev/null > > echo "Freeing InitRD memory" > freeramdisk /dev/ram0 > > and > > --- etc/init.d/boot 2012-03-23 19:12:17.000000000 -0700 > +++ /etc/init.d/boot 2012-03-23 19:11:28.000000000 -0700 > @@ -49,6 +49,10 @@ > /sbin/udevadm settle > evaluate_retval > > +# unmount "old" devtmpfs and remove the dir > +umount /shm/dev &> /dev/null > +rm -rf /shm/dev &> /dev/null > + > # ls /dev/ > > if [ -f /proc/sys/kernel/sysrq ]; then > > > > Sincerely, > Serge > > > On 03/23/2012 06:28 PM, Bruce Smith wrote: >> I'm installing DL 1.6.0-RC3 on a new firewall and it assigns eth0& >> eth1 to different network cards depending if I cold boot (power on) >> vs. a warm reboot. >> >> The script that writes /etc/udev/rules.d/70-persistent-net.rules >> doesn't seem to exist any longer, and that file is never getting >> created automatically. I had to create it manually to fix the random >> NIC name assignment problem. >> >> Is this a bug, or are we handling the naming of NIC's differently now? >> >> BTW, I tried assigning the module names in setup, instead of using >> autoselect. That made no difference, and did not assign the names as >> I specified. >> >> - BS >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> Devil-linux-develop mailing list >> Dev...@li... >> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop >> > |
From: Serge L. <ser...@gm...> - 2012-03-24 21:53:16
|
On 03/24/2012 05:05 AM, Bruce Smith wrote: >> OK, the brief update. "--enable-rule_generator" works (adds persistent-net and >> persistent-cd). > > OK, good. Are you going to commit that change? Yes. > > And do we need to add anything in the boot scripts to run the script > that creates persistent-net? No. > I did a little research and it sounds like many virtualized > environments reuse MAC address ranges assigned to other manufacturers, > so I guess they don't want a conflict. I'd say if we have more than 1 NIC in a VM, we have to fixate name <-> mac regardless of possible conflict (if there is a conflict, we have to re-generate mac addresses - but it's a bit different story). To be honest, I don't understand the reason of ignoring NIC name persistence in VM, but those line were intentionally added - so, the reason apparently exists. It goads my curiosity :) > Is there a file in /lib/udev/rules.d/ that has a rule to omit KVM > devices? (like "75-persistent-net-generator.rules") If so, I'd be > okay with editing the file to remove the VM rules, or just removing > that file. Yes, it's exactly "75-persistent-net-generator.rules" file. Done as a patch because we cannot remove the rules file. Serge |
From: Serge L. <ser...@gm...> - 2012-03-25 01:52:32
|
On 03/24/2012 03:12 PM, Bruce Smith wrote: >>> I did a little research and it sounds like many virtualized >>> environments reuse MAC address ranges assigned to other manufacturers, >>> so I guess they don't want a conflict. >> I'd say if we have more than 1 NIC in a VM, we have to fixate name<-> mac >> regardless of possible conflict (if there is a conflict, we have to re-generate >> mac addresses - but it's a bit different story). To be honest, I don't >> understand the reason of ignoring NIC name persistence in VM, but those line >> were intentionally added - so, the reason apparently exists. It goads my >> curiosity :) > > I don't understand it either. Hmm. I'll ask udev developers. > > Does KVM keep the same Mac address every time it boots the same VM? > (if not, then it makes sense) It's configurable. Usually mac addresses are "static" for each VM. > >>> Is there a file in /lib/udev/rules.d/ that has a rule to omit KVM >>> devices? (like "75-persistent-net-generator.rules") If so, I'd be >>> okay with editing the file to remove the VM rules, or just removing >>> that file. >> Yes, it's exactly "75-persistent-net-generator.rules" file. Done as a patch >> because we cannot remove the rules file. > > Why can't the file just be removed in the install script? Technically it's not a problem to remove a file, but it is a rule (configuration) file for write_net_rules which generates /etc/udev/rules.d/70-persistent-net.rules. It's a pretty big config, we removed only a small part from it. If we delete the file, write_net_rules will work incorrectly. Serge |
From: Bruce S. <bw...@re...> - 2012-03-25 02:02:18
|
>> I don't understand it either. > Hmm. I'll ask udev developers. Let us know what they say. I'm curious too. >>> Yes, it's exactly "75-persistent-net-generator.rules" file. Done as a patch >>> because we cannot remove the rules file. >> >> Why can't the file just be removed in the install script? > Technically it's not a problem to remove a file, but it is a rule > (configuration) file for write_net_rules which generates > /etc/udev/rules.d/70-persistent-net.rules. It's a pretty big config, we removed > only a small part from it. If we delete the file, write_net_rules will work > incorrectly. Okay. - BS |