On Wed, 30 Jan 2008 20:09:26 -0600 (CST) Paul Armor <parmor@xxxxxxxxxxxxxxxxxxxx> wrote: > 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? http://bugzilla.redhat.com File a bug for libdhcp in the Fedora development product (rawhide). > 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? Expected, no. Side-effect of many changes, yes. The parameters you pass to the installation program are a mix of valid kernel parameters and then ones we have for anaconda. If mtu= was a kernel parameter a long time ago, it's possible that it has changed or completely gone away. If it was an anaconda parameter...we messed up (either by accident or deliberately) by changing the behavior you were expecting. > 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). Apologies. Since Fedora started, a lot of changes have gone in to things like kickstart and the way anaconda does networking. Chris Lumens has completely rewritten our handling of kickstart in both Fedora and RHEL. We now have a Python module called pykickstart which has knowledge of many different versions of Fedora and RHEL so it can parse them and provide the information to anaconda (or, really, any tool that wants to use kickstart files). But with that change comes unexpected side effects. Not sure what changes you're seeing on the kickstart side, but I'm sure Chris can explain why. On the networking side, the biggest change came around FC-5 when I removed pump from the installer and replaced it with libdhcp (didn't write it, don't blame me). The main goal was adding IPv6 installation support to anaconda. pump never supported IPv6, so either adding that to pump needed to happen or a completely new library needed to show up. Since many people experienced boot time DHCP troubles with pump, but post-install things worked fine with dhclient, the new library project was started. It is far from perfect and I'm working on the replacement, but it's what we have now and it usually works ok. Not really any worse than pump. There were some corner cases with pump that didn't make it in to the new library and some people have gone way out of their way to complain about that, sometimes even providing patches. If you are trying to use a pump-ism that isn't supported, file a bug. For now, I'm putting those in to libdhcp. Don't expect libdhcp to be around much longer. It'll be in F-9, but I'm hoping that's the last release. -- David Cantrell <dcantrell@xxxxxxxxxx> Red Hat / Honolulu, HI
Attachment:
pgpXyIIDyPcpr.pgp
Description: PGP signature
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
