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

Bug#615600: BOOTIF= kernel commandline option does not work

Marc Haber <mh+debian-bugs@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.  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.

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.

> 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

Reply to: