On Wed, 25 Feb 2015 17:11:02 -0600, Ashley M. Kirchner ashley@pcraft.com wrote:
Add "rdblacklist=MODULE_NAME" to your append line in pxelinux.conf file.
Trying that next. It'll have to wait till tomorrow as we're under a serious blizzard/snow event right now and I'd like to get home before all of hell freezes over. However, question, if I blacklist the module, that means during kickstart it doesn't know it's there either, which would cause a 'network' definition for that interface to fail (and kickstart to stop) ... I think.
It will if you try to configure the now non-existent interface.
This should get you into a usable state post-install so you can setup
additional interfaces.
My hope is that I don't have to do anything after it's done and reboots. The whole purpose of me doing this is in case something happens with the drive and I'm not here, someone can shove a new one in, reboot and let it go through the kickstart and be operational ten minutes later without them having done anything else. Maybe I'm aiming too damn high.
No, your not. One thing you might be doing though is being to concerned about ordering. The actual numbering of interfaces is, in most cases, purely cosmetic. So if you do not have another reason for needing a nice, logical ordering you should ignore it. Your use case is almost exactly why I went the route I did in the first place.
Since this appears to be a recovery plan for a specific system then your best course is to accept the ordering as kickstart sees it and adjust your network config lines to compensate. As long as you have a udev rules file the ordering will not change on reboot.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos