Hi all,
I'm having a bit of trouble with something and was wondering if anyone else has encountered this or knows what the problem is.
I have one computer I would like to kickstart a centos 5.0 or 5.1 install.
I have another computer which is the tftpboot server and contains the centos 5.0 and centos 5.1 install directories
I wish to do the kickstart over nfs and my network is using MTU of 4500. The machine will kickstart to the point of fetching the kickstart script from the server, but soon after stop responding.
The machine is not locked but seems to be waiting on network traffic.
Are there any known issues with kickstarting over nfs with jumbo frames?
Thanks! Adam
Adam Miller wrote:
Are there any known issues with kickstarting over nfs with jumbo frames?
Is the system your kickstarting configured with jumbo frames? Last I checked I didn't see an option to enable jumbo frames during kickstart.
If not, are you able to force TCP for NFS? UDP doesn't have MTU discovery as far as I know, so traffic will likey fail.
Any reason not to use HTTP for kickstart? Faster, simpler, runs over TCP..
On my networks I only run jumbo frames on dedicated interfaces and VLANs, not on the main network, causes too many compatibility problems otherwise. Curious why your using a MTU of 4500? Seems like an unusual number, common MTU for jumbo is 9000.
nate
According to these docs an MTU can be specified in the kickstart script. It doesn't say much more than that though.
http://www.centos.org/docs/5/html/Installation_Guide-en-US/s1-kickstart2-opt...
The reason for nfs and an mtu of 4500 is complicated and not in my control. This is being used in a beowulf cluster environment.
The process I'm following is currently working for kickstarting Fedora Core 4 installs, so I am hopeful it will work in centos.
Adam
On Tue, 29 Jan 2008, nate wrote:
Adam Miller wrote:
Are there any known issues with kickstarting over nfs with jumbo frames?
Is the system your kickstarting configured with jumbo frames? Last I checked I didn't see an option to enable jumbo frames during kickstart.
If not, are you able to force TCP for NFS? UDP doesn't have MTU discovery as far as I know, so traffic will likey fail.
Any reason not to use HTTP for kickstart? Faster, simpler, runs over TCP..
On my networks I only run jumbo frames on dedicated interfaces and VLANs, not on the main network, causes too many compatibility problems otherwise. Curious why your using a MTU of 4500? Seems like an unusual number, common MTU for jumbo is 9000.
nate
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
nate wrote:
Are there any known issues with kickstarting over nfs with jumbo frames?
Is the system your kickstarting configured with jumbo frames? Last I checked I didn't see an option to enable jumbo frames during kickstart.
If not, are you able to force TCP for NFS? UDP doesn't have MTU discovery as far as I know, so traffic will likey fail.
Any reason not to use HTTP for kickstart? Faster, simpler, runs over TCP..
Doesn't this take a considerable amount of setup work on the server side per-distro/per-version? For NFS you only have to download images into directories under an nfs export.
Doesn't this take a considerable amount of setup work on the server side per-distro/per-version? For NFS you only have to download images into directories under an nfs export.
not when using cobbler is doesn't
Tom Brown wrote:
Doesn't this take a considerable amount of setup work on the server side per-distro/per-version? For NFS you only have to download images into directories under an nfs export.
not when using cobbler is doesn't
Cobbler doesn't take any setup?
not when using cobbler is doesn't
Cobbler doesn't take any setup?
not a 'considerable amount' nope - its quick, easy and very good at simplifying things so that additional builds are very easy
Les Mikesell wrote:
Doesn't this take a considerable amount of setup work on the server side per-distro/per-version? For NFS you only have to download images into directories under an nfs export.
It takes a bit of work, mount the iso image, copy contents to a directory, repeat for the rest. I like the contents of the images exposed, so if I need to find stuff later it's pretty easy. Initial setup time is about 15 minutes.
The work needed pales in consideration to the work needed to customize a new distro or version, and test it, which today is a solid week or two. For a new major version(e.g. I recently deployed CentOS 5 vs CentOS 4), I had to compile custom RPMS for about 80 packages, two thirds of which(mostly support files for Ruby on Rails), don't come in SRPMS.
Then there are about 6 different kickstart configs for each distro/version depending on the features(which console, software raid(if any), virtualized(or not).
And prior to CentOS 4.5 for example, there was a significant amount more work as we had to hack the kickstart image itself, build custom driver modules and insert them into the installation images. Fortunately since 4.5, all of the drivers we need have been included in the stock kernel/install images.
So yeah, takes some time, but for me it's peanuts in comparison to what else has to be done to make the distribution "perfect".
nate
nate wrote:
Doesn't this take a considerable amount of setup work on the server side per-distro/per-version? For NFS you only have to download images into directories under an nfs export.
It takes a bit of work, mount the iso image, copy contents to a directory, repeat for the rest. I like the contents of the images exposed, so if I need to find stuff later it's pretty easy. Initial setup time is about 15 minutes.
That's 15 minutes wasted as far as I'm concerned - plus it probably took you a lot longer the first time and you've duplicated the disk space. Getting the contents of an nfs-shared iso is as simple as loopback mounting it - in the unlikely event that you'd want to.
So yeah, takes some time, but for me it's peanuts in comparison to what else has to be done to make the distribution "perfect".
But what's the point, when the installer knows how to deal with images directly and if you want a package later you'll probably let yum get a current version from the repositories anyway?
Les Mikesell wrote:
But what's the point, when the installer knows how to deal with images directly and if you want a package later you'll probably let yum get a current version from the repositories anyway?
Actually I almost never use yum. Thought about it on occasion, RPMS are installed via cfengine so I can ensure all of the versions are the same on all systems. Bulk upgrades I run yum update on a test system, collect the rpms, and push out a script via cfengine which does a bulk upgrade with rpm.
We tried setting up our own repository for stuff but it seemed more difficult to manage than it was worth at the time.
nate
nate wrote:
But what's the point, when the installer knows how to deal with images directly and if you want a package later you'll probably let yum get a current version from the repositories anyway?
Actually I almost never use yum. Thought about it on occasion, RPMS are installed via cfengine so I can ensure all of the versions are the same on all systems.
I've never had any particular problem with this, but I usually start with disk image copies of an initial setup, followed by subsequent yum updates. I haven't had any surprises from the Centos repositories.
-
Adam Miller -
Les Mikesell -
nate -
Tom Brown