On Wed, Mar 02, 2011 at 01:41:58AM +0100, Ferenc Wagner wrote:
> Marc Haber <mh+debian-b...@zugschlus.de> writes:
> > On Tue, Mar 01, 2011 at 04:28:16PM +0100, Marc Haber wrote:
> >> I guess the following changes do kind of a job:
> >> etc/udev/rules.d/69-bootif.rules (inside the installer's initrd)
> >> ACTION=="add", SUBSYSTEM=="net", IMPORT{program}="bootif $attr{address}"
> >>
> >> Unfortunately, this seems to go a little too far. My test system comes
> >> up with the second interface being the bootif, so it's eth1 without
> >> these additions.
> >
> > This seems to be the fault of the additional rule which gives the
> > impression that the rule is actually doing something. Even when I
> > replace the bootif script with a call to true, I get multiple stanzas
> > per interface in 70-persistent-net.rules.
>
> In my limited testing (with two Qemu interfaces) this didn't happen
> after several
>
> # rm 70-persistent-net.rules
> # udevadm trigger --verbose --action=add --subsystem-match=net
>
> cycles.
Did you try with a multiprocessor VM? I guess that this is some
threading/multiprocessing issue that multiple interfaces get processed
at the same time, causing races.
> Actually, your rule worked perfectly well, despite that you don't
> reserve the eth0 name, just try to assign it even if it's taken
> already. Unless I overlook something, this should be fixed.
How do I reserve a name?
> I usually assign symbolic names instead of ethX ones, like wlan, utp,
> private, gb1 (chassis label) or similar; they usually work just fine,
> but sometimes break assumptions of some software (like Munin plugins).
> Maybe keeping the domain and the range of the mapping would help
> debugging this case as well.
I do this for my personal servers as well, but for the default
install, I'd rather follow the principle of least surprise for the
other admins that will use the servers deployed by me.
So it would really be nice to have ethx, starting at eth0 being the
right interfaces, with the other interfaces being consecutively
numbered as ethx.
> > Do I need to say in the 69-bootif.rules that this should be treated as
> > a no-op rule?
>
> I don't think so. But /lib/udev/write_net_rules activates set -x if
> udev logging is set to debug level, and while the output in
> /var/log/syslog is less than readable, it may prove some insight.
>
> # udevadm control --log-priority=debug
I'll try that and report back. Thanks for helping.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
