Hi List:
In anaconda, when it is time to write the mdadm.conf file, it is done by each device object "ent.device.mdadmLine()". This is all good, but when other mdN devices that are not in the object list (for whatever reason, look at bug :), are needed to boot the system properly after update or install, this method might present a problem. I just say: "use mdadm". Patch attached.
/me gets prepared to get screamed at for missing something completely obvious. :)
Regards.
Hi, we're trying to kickstart centos 5 on machines with broadcom 5704's, using jumbo mtu's (mtu=4500).
We're setting the option mtu=4500 which is being passed to the kernel by pxelinux, and then we also set mtu=4500 in the ks.cfg.
Perhaps I'm looking in the wrong place, but from looking at loader2/loader.c, I think we're doing things properly (this worked with FC4's anaconda, but is failing in Cent5).
If I set it to dhcp in the pxelinux config file AND set the mtu=4500, it dhcp's, but forgets the mtu. If I set a static IP/netmask/mtu in the pxelinux config file, it works as expected.
Is this to be expected? Is this a bug?
Thanks, Paul
Paul Armor wrote:
Hi, we're trying to kickstart centos 5 on machines with broadcom 5704's, using jumbo mtu's (mtu=4500).
We're setting the option mtu=4500 which is being passed to the kernel by pxelinux, and then we also set mtu=4500 in the ks.cfg.
Perhaps I'm looking in the wrong place, but from looking at loader2/loader.c, I think we're doing things properly (this worked with FC4's anaconda, but is failing in Cent5).
If I set it to dhcp in the pxelinux config file AND set the mtu=4500, it dhcp's, but forgets the mtu. If I set a static IP/netmask/mtu in the pxelinux config file, it works as expected.
Is this to be expected? Is this a bug?
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.
Kind regards,
Jeroen van Meeuwen -kanarip
Hi,
On Wed, 30 Jan 2008, Jeroen van Meeuwen wrote:
Paul Armor wrote:
Hi, we're trying to kickstart centos 5 on machines with broadcom 5704's, using jumbo mtu's (mtu=4500).
We're setting the option mtu=4500 which is being passed to the kernel by pxelinux, and then we also set mtu=4500 in the ks.cfg.
Perhaps I'm looking in the wrong place, but from looking at loader2/loader.c, I think we're doing things properly (this worked with FC4's anaconda, but is failing in Cent5).
If I set it to dhcp in the pxelinux config file AND set the mtu=4500, it dhcp's, but forgets the mtu. If I set a static IP/netmask/mtu in the pxelinux config file, it works as expected.
Is this to be expected? Is this a bug?
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?
Thanks, Paul
On Wed, 30 Jan 2008 17:59:29 -0600 (CST) Paul Armor parmor@gravity.phys.uwm.edu wrote:
Hi,
On Wed, 30 Jan 2008, Jeroen van Meeuwen wrote:
Paul Armor wrote:
Hi, we're trying to kickstart centos 5 on machines with broadcom 5704's, using jumbo mtu's (mtu=4500).
We're setting the option mtu=4500 which is being passed to the kernel by pxelinux, and then we also set mtu=4500 in the ks.cfg.
Perhaps I'm looking in the wrong place, but from looking at loader2/loader.c, I think we're doing things properly (this worked with FC4's anaconda, but is failing in Cent5).
If I set it to dhcp in the pxelinux config file AND set the mtu=4500, it dhcp's, but forgets the mtu. If I set a static IP/netmask/mtu in the pxelinux config file, it works as expected.
Is this to be expected? Is this a bug?
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.
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
On Wed, 30 Jan 2008 20:09:26 -0600 (CST) Paul Armor parmor@gravity.phys.uwm.edu 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?
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.
Joel Andres Granados wrote:
Hi List:
In anaconda, when it is time to write the mdadm.conf file, it is done by each device object "ent.device.mdadmLine()". This is all good, but when other mdN devices that are not in the object list (for whatever reason, look at bug :), are needed to boot the system properly after update or install, this method might present a problem. I just say: "use mdadm". Patch attached.
/me gets prepared to get screamed at for missing something completely obvious. :)
Regards.
Did some further testing and this solution seems sane for installs as well. (not only for updates). Any comments greatly appreciated. Regards.
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Wed, 2008-01-30 at 20:58 +0100, Joel Andres Granados wrote:
In anaconda, when it is time to write the mdadm.conf file, it is done by each device object "ent.device.mdadmLine()". This is all good, but when other mdN devices that are not in the object list (for whatever reason, look at bug :), are needed to boot the system properly after update or install, this method might present a problem. I just say: "use mdadm". Patch attached.
Like I said on IRC yesterday, this sounds sane to me. So let's try it, we'll see if anything breaks :-)
Jeremy
Jeremy Katz wrote:
On Wed, 2008-01-30 at 20:58 +0100, Joel Andres Granados wrote:
In anaconda, when it is time to write the mdadm.conf file, it is done by each device object "ent.device.mdadmLine()". This is all good, but when other mdN devices that are not in the object list (for whatever reason, look at bug :), are needed to boot the system properly after update or install, this method might present a problem. I just say: "use mdadm". Patch attached.
Like I said on IRC yesterday, this sounds sane to me. So let's try it, we'll see if anything breaks :-)
Jeremy
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
I guess if anybody runs into an install (with raid) that is not bootable, its probably, my fault. So feel free to scream at me :)
Regards
anaconda-devel@lists.fedoraproject.org
-
David Cantrell -
Jeremy Katz -
Jeroen van Meeuwen -
Joel Andres Granados -
Paul Armor