Bug#615600: BOOTIF= kernel commandline option does not work
Marc Haber <mh+debian-bugs@zugschlus.de> writes:
> On Wed, Mar 02, 2011 at 01:41:58AM +0100, Ferenc Wagner wrote:
>
>> 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.
>
> 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.
Maybe, I didn't try it on SMP. write_net_rules has some locking to
prevent such issues, though.
>> 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?
By renaming eth0 to something else, unless it isn't the boot interface.
>> 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.
Hey, thanks for maintaining Exim!
--
Regards,
Feri.
Reply to: