|
First of all, thanks for
responding, I was pretty sure that the issue had fallen into the
void. It doesn't *really* matter to me, as I've fixed it in my source
code, but I know that it's bitten other people, as it was originally
brought to my attention in the centos IRC channel. That's what I thought at first, because my test platform uses kickstart and updates over http, so I figured that it was just as you suspected, but I tried it with both the kickstart burned onto CD, and the ks=floppy boot method, and both times, it failed to configure the network. There's one scenario left that I haven't tested, which is to boot up on a network without a DHCP server (I haven't tested it for a couple of reasons[1]), and see if it asks for a network configuration. However based on my reading of the anaconda code; the fact that kickstart.py *always* calls dispatch.skipStep("network"), and the commit message from a commit that was subsequently retracted in the anaconda git repo[2], I'm sure that, no matter what I do, if kickstart is invoked, it will not ask me to configure the network. I guess I have to open up an enhancement request on Fedora to get this fixed to behave as I think it should... 1. I'd have to set up a virtual network on a private LAN, which would take too much time for a test that I know would fail, and it's kinda beside the point, just because the use case I'm envisioning separates install-time network configuration from permanent network config 2. http://preview.tinyurl.com/dyv7y9 and the commit message states: This patch adds support for a new network bootproto. The point of this isand the commit is reverted two weeks later. After reading the bug referenced the commit msg, I kinda understand what happened. (It's a confusing bug). Jeroen van Meeuwen wrote: On 03/25/2009 08:37 PM, Matt Rose wrote: |
_______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list
