Hi,
On Wed, 30 Jan 2008, David Cantrell wrote:
MTU is actually a valid setting a DHCP server can pass onto it's clients, so
I suspect this is expected behavior:
From http://linux.die.net/man/5/dhcp-options:
option interface-mtu uint16;
This option specifies the MTU to use on this interface. The minimum legal
value for the MTU is 68.
Yup, but it's not requested, so not offered.
anaconda's discover and requests ask for the following parameters (in the
following order):
1, 28, 2, 3, 15, 6, 12, 40, 41, 42
Anaconda does NOT ask for parameter 26 (Interface MTU).
So, what's one to do, if anaconda won't request parameter 26, nor will it
accept the "mtu=" passed to the kernel for an interface that's supposed to
dhcp?
It's not anaconda, it's libdhcp. Please file a bug.
OK, where do I do this?
But is this an expected change in behaviour of anaconda to either ignore
the "mtu=" option passed to the kernel from syslinux if the machine is
dhcp-ing, as compared to earlier releases?
As a long time RH user (personally, I've been kickstarting clusters in an
academic env since RH7.3, and our group has been doing so since RH6 (or
even 5?)), I feel compelled to mention that the docs for kickstarting and
anaconda are frustratingly sparse, and the "surprise" differences in
behaviour from release to release are downright annoying. BUT, that must
be tempered by my appreciation for the efforts that go into making
something that basically works (once the changes are discovered by
iterative black box investigation).
Thanks,
Paul
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
