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