I'd say yes. I have not done a thorough testing yet, but it seems to be working.
Serge
On 03/28/2012 01:29 PM, Heiko Zuerker wrote:
> Do we want to include the latest util-linux in the final 1.6 or should
> we wait?
>
> Heiko

>> 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

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

>> 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

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

> 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

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

Stefan,
> -----Original Message-----
> From: Stefan Engel [mailto:mail@...]
> Sent: Friday, March 16, 2012 6:58 AM
> To: devil-linux-develop@...
> Subject: [Devil-linux-develop] DL compile: some settings missing in kernel
> config?
>
> Hi,
>
> I have a small problem when trying to build DL from scratch (I am building
for
> x86_64). The build process stops in scripts/prepare when configuring the
> kernel.
>
> I have set up a fresh build environment and checked out the current HEAD
> revision from CVS without making any additional changes to the build
> infrastructure (except removing some unneeded applications during 'make
> menuconfig').
>
> make unpack, make menuconfig and make prepare are running without any
> problems.
>
> But when I run 'make build' then the first target (scripts/prepare) fails
when
> executing 'make oldconfig'.
>
> The last info in tmp/LOGS/build/prepare is:
>
> <<<snip>>>
> `/data/build/scripts/config/linux-3.x/config_linux.x86_64' ->
> `/data/build/tmp/linux-3.2/.config'
> ...
> executing set_all_kernel_options in drivers/hwmon ...
> scripts/kconfig/conf --oldconfig Kconfig
> .config:4108:warning: override: reassigning to symbol DEBUG_KERNEL ...
> *
> * Restart config...
> *
> *
> * Configure standard kernel features (expert users)
> *
> Configure standard kernel features (expert users) (EXPERT) [N/y/?] n
> Load all symbols for debugging/ksymoops (KALLSYMS) [Y/?] y
> Include all symbols in kallsyms (KALLSYMS_ALL) [N/y/?] (NEW)
<<<snip>>>
>
> So the base config file gets copied to tmp/linux-3.2/.config and then gets
> further patched by scripts/prepare. But something seems to be missing
here.
>
> If I manually run 'make oldconfig' in tmp/linux-3.2 then I have to step
through
> some additional config settings to get a valid kernel config file.
> KALLSYMS_ALL is only the first undefined setting.
>
> Using 'find . -type f -exec grep KALLSYMS_ALL {} \;' in /data/build after
make
> unpack && make prepare results only in hits in tmp/linux-3.2
> (documentation, default configs in 'arch'). So the missing config settings
do
> not come from any files/scripts in the DL source tree.
>
> I don't want to enable the line '(yes "" | make oldconfig)' in
scripts/prepare,
> because a lot of stuff gets enabled which I do not need/want (debugging,
> ...).
>
>
> So my question is: am I doing something wrong here? Or what kind of linux
> kernel config files are you using for building DL from scratch?
>
> Any help would be much appreciated.
It should run right through.
Can you email me your DL .config file? Send it to my directly, not the
mailinglist.
I'll see if I can reproduce your problem.
--
Regards
Heiko Zuerker
http://www.devil-linux.org

Hi,
I have a small problem when trying to build DL from scratch (I am
building for x86_64). The build process stops in scripts/prepare when
configuring the kernel.
I have set up a fresh build environment and checked out the current HEAD
revision from CVS without making any additional changes to the build
infrastructure (except removing some unneeded applications during 'make
menuconfig').
make unpack, make menuconfig and make prepare are running without any
problems.
But when I run 'make build' then the first target (scripts/prepare)
fails when executing 'make oldconfig'.
The last info in tmp/LOGS/build/prepare is:
<<<snip>>>
`/data/build/scripts/config/linux-3.x/config_linux.x86_64' ->
`/data/build/tmp/linux-3.2/.config'
...
executing set_all_kernel_options in drivers/hwmon
...
scripts/kconfig/conf --oldconfig Kconfig
.config:4108:warning: override: reassigning to symbol DEBUG_KERNEL
...
*
* Restart config...
*
*
* Configure standard kernel features (expert users)
*
Configure standard kernel features (expert users) (EXPERT) [N/y/?] n
Load all symbols for debugging/ksymoops (KALLSYMS) [Y/?] y
Include all symbols in kallsyms (KALLSYMS_ALL) [N/y/?] (NEW)
<<<snip>>>
So the base config file gets copied to tmp/linux-3.2/.config and then
gets further patched by scripts/prepare. But something seems to be
missing here.
If I manually run 'make oldconfig' in tmp/linux-3.2 then I have to step
through some additional config settings to get a valid kernel config
file. KALLSYMS_ALL is only the first undefined setting.
Using 'find . -type f -exec grep KALLSYMS_ALL {} \;' in /data/build
after make unpack && make prepare results only in hits in tmp/linux-3.2
(documentation, default configs in 'arch'). So the missing config
settings do not come from any files/scripts in the DL source tree.
I don't want to enable the line '(yes "" | make oldconfig)' in
scripts/prepare, because a lot of stuff gets enabled which I do not
need/want (debugging, ...).
So my question is: am I doing something wrong here? Or what kind of
linux kernel config files are you using for building DL from scratch?
Any help would be much appreciated.
Best regards,
Stefan

Andrzej,
Quoting Andrzej Odyniec <anody@...>:
> I wrote:
>> As I wrote, Console messages I sent just in case. As I mentioned at
>> the end, I
>> suspected that your patch fixes the problem. Now I'm building a new version.
>>
>> I'll let you know when I'll check the result.
>
> I tested new build last night. Now all interfaces was present and worked
> properly (in a short period of time, because after hour I reverted soft to
> 32-bit).
>
> But in real environment under 64-bit worked correct:
>
> -- dhcpd
> -- dnscache
> -- tinydns
> -- axfrdns
> -- ntpd
> -- arpwatch
> -- sshd
> -- openvpn with severe static tunnels
> -- zebra and bgpd
> -- vsftpd
>
> Only ntop did not start, maybe because of databases incompatibility. This is
> for check in my virtual environment.
Thanks for the testing!
I'm only aware of 2 other issues, one is that mysql doesn't start
after the boot (have to analyze it) and the other one that
install-on-usb doesn't support grub2.
I'm only intending to fix the mysql issue (don't have enough time for
the install-on-usb), then I'll release RC3 or maybe even name it 1.6.
--
Regards
Heiko Zuerker
http://www.devil-linux.org

I wrote:
> As I wrote, Console messages I sent just in case. As I mentioned at the end, I
> suspected that your patch fixes the problem. Now I'm building a new version.
>
> I'll let you know when I'll check the result.
I tested new build last night. Now all interfaces was present and worked
properly (in a short period of time, because after hour I reverted soft to
32-bit).
But in real environment under 64-bit worked correct:
-- dhcpd
-- dnscache
-- tinydns
-- axfrdns
-- ntpd
-- arpwatch
-- sshd
-- openvpn with severe static tunnels
-- zebra and bgpd
-- vsftpd
Only ntop did not start, maybe because of databases incompatibility. This is
for check in my virtual environment.
Best Regards
--
Andrzej Odyniec

Heiko Zuerker wrote:
> the errors you're seeing are caused by a bug in the "finalize" script.
> Update from CVS and a simple "make clean all" should generate you an
> ISO which works correctly.
Heiko,
As I wrote, Console messages I sent just in case. As I mentioned at the end, I
suspected that your patch fixes the problem. Now I'm building a new version.
I'll let you know when I'll check the result.
Best regards
--
Andrzej Odyniec

Andrzej,
the errors you're seeing are caused by a bug in the "finalize" script.
Update from CVS and a simple "make clean all" should generate you an
ISO which works correctly.
--
Regards
Heiko Zuerker
http://www.devil-linux.org