[PATCH] Always ignore hostname-only network lines in kickstart (#968034)
Radek Vykydal
rvykydal at redhat.com
Tue Mar 4 14:58:19 UTC 2014
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.
Radek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-alternate-patch.patch
Type: text/x-patch
Size: 1334 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/anaconda-patches/attachments/20140304/ccbd0093/attachment.bin>
More information about the anaconda-patches
mailing list