On 02/02/2012 12:19 PM, Darren Hart wrote:
On 02/02/2012 06:09 AM, William Mills wrote:
So on a non-volatile r/w filesystem this will assign a new random mac to
each interface on the first boot and reuse that MAC on each subsquent boot.
Correct.

On a volatile r/w filesystem this will use a new MAC addr for each
boot.  I guess thats better than nothing and not much to do on a
volatile system.
Correct. The alternative would be to try and sort out some kind of hash
based on unique data, maybe dmidecode data - but that's not very
consistent across platforms. I think there is something like this
available for the Beagleboard.


What does this do on a ro filesystem?  No network?  network with
0:0:0:0:0:0 MAC addr? (horror! but I suspect the kernel won't allow
that).  Certainly this script failing should not cause the rest of boot
to fail.
On a read only filesystem with genmac installed and RANDOM_MAC in the
interfaces file, genmac will run and NOT update interfaces. This was
written with the pch_gbe driver in mind. If no MAC is in the EEPROM, the
pch_gbe driver leaves the MAC as 00:00:00:00:00:00 and leaves the
interface down. It will fail any up command until the MAC has been set.
So the subsequent networking script will fail to bring up the relevant
interface. ifconfig -a will list the interface as down and with a MAC of
00:00:00:00:00:00.

Other drivers will assign a random MAC within the kernel, making this
all unnecessary, but David Miller refused this patch for this driver
(despite the precedent).

If you want to use a RO image on a platform with a pch_gbe nic and no
EEPROM, you need to hardcode the generated MAC in the interfaces file.

The alternative would be for me to call this pch_gbe_genmac and have it
call ifconfig directly instead of delegating it to the interfaces file.
But then I would still want to use a config file to store the
first-boot-generated MAC so it was the same across boots. Once I have to
generate a config file, I felt it made more sense to just use
interfaces, and then it makes sense to make it generic (not pch_gbe
specific), and that led me to this implementation.

Seem reasonable?


Yes I think so. Just wanted to make sure it failed gracefully. I think your doing the best that can be expected.

Thanks for the detail.

[I'm interested as I have a board that might need this. Not in OE yet, but someday ...]

_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Reply via email to