[PATCH] Always ignore hostname-only network lines in kickstart (#968034)
David Shea
dshea at redhat.com
Tue Mar 4 15:22:47 UTC 2014
On 03/04/2014 09:58 AM, Radek Vykydal wrote:
> On 03/03/2014 08:25 PM, David Shea wrote:
>> On 03/03/2014 02:07 PM, David Shea wrote:
>>> + # If the only argument is a hostname, skip this line
>>> + hostname_state = False
>>> + for arg in args[1:]:
>>> + # If this argument is --hostname without the '=', the
>>> hostname is the
>>> + # the next argument, so set the state to skip that one too
>>> + if arg == '--hostname':
>>> + hostname_state = True
>>> + elif hostname_state:
>>> + hostname_state = False
>>> + elif not arg.startswith('--hostname='):
>>> + break
>>> + else:
>>> + return None
>>
>> It just occurred to me that a line containing only "network" is
>> perfectly valid, and if that's the first line would be (should be?)
>> accepted as equivalent to ip=dhcp. So let's pretend I wrapped this
>> whole block in "if args[1:]:"
>
> Unfortunately hostname-only line shouldn't probably be ignored always.
> If ksdevice boot option is present, first line with hostname only
> should configure ksdevice with ks default values. I cared to take this
> case into account in a patch (exactly the lines you are removing I
> think) for a BZ requiring this (legacy) behavior. (Generally if
> --device is not specified in first line, ksdevice value should be used).
>
> So forfirst network command
>
> network --hostname blah
>
> with having ksdevice boot option defined we are configuring ksdevice
> with ks defaults.
>
> It is a bit grey area but I'd prefer to keep this behavior. Sorry for
> making troubles with such a patch.
>
> For the network only line, I have no idea what the expected behavior
> is, I don't remember seeing it anywhere, but I think we should also
> configure the ksdevice with default ks values.
>
> It feels also a bit strange (hard to read) to me to use loop with
> state, I'd use something like I'm attaching.
Good point. I got halfway there with realizing that "network" as a first
command is valid, but it didn't occur to me that "network --hostname
hostname" is valid for the same reason.
I like your patch better.
More information about the anaconda-patches
mailing list