Hide Forgot
Description of problem: When ksdevice=pci3#1 is passed, user is manually prompted to activate the network. But when ksdevice=em1 is passed, network activation succeeds. Version-Release number of selected component (if applicable): Anaconda-15.18-1.fc15 How reproducible: Easy Steps to Reproduce: 1. Boot into the Boot.iso from http://jlaska.fedorapeople.org/test-day/x86_64 2. Hit Tab and pass ksdevice=pci2#1 Actual results: Manually prompted to activate the network. Expected results:Anaconda should activate pci2#1 Additional info: Will upload /tmp/*.log shortly.
This is because your device name contains a "#", which is a shell metacharacter, therefore lots of programs are going to have a hard time processing this information. In the loader, we use g_shell_parse_argv to process the argument list and it treats "#" like it's a comment starter. I bet shlex.split that pykickstart uses will have similar problems.
(In reply to comment #1) > I bet > shlex.split that pykickstart uses will have similar problems. I think it'll be okay here. The shell doesn't consider a '#' character as the start of a comment, I *think* it considers ' #' the start of a comment. >>> shlex.split("pci2#4") ['pci2#4'] >>> shlex.split("pci2#4 #1") ['pci2#4', '#1']
(In reply to comment #1) > This is because your device name contains a "#", which is a shell > metacharacter, therefore lots of programs are going to have a hard time > processing this information. In the loader, we use g_shell_parse_argv to > process the argument list and it treats "#" like it's a comment starter. I bet > shlex.split that pykickstart uses will have similar problems. I had the same suspicion in my tests, but in my case it showed up that the problem was pre-anaconda processing - pxe configuration file. When I escaped the character, anaconda (loader) had no problems using pciX#Y name IIRC.
#!/bin/bash foo=abc#de echo $foo yields: abc#de # is a comment character, yes, but just because a # appears in a word does not mean that the rest of the line is ignored. There are lots of other uses of # within bash to mean other things than comments.
It's not just bash. anaconda and pykickstart depend on the Python shutil module as well as glib's g_shell_parse_argv() function, so we are limited by their specifications as well.
> It's not just bash. anaconda and pykickstart depend on the Python shutil > module as well as glib's g_shell_parse_argv() function, so we are limited by > their specifications as well. We appear to be okay from a shlex perspective: (Pdb) shlex.split("network --device=pci1#2") ['network', '--device=pci1#2'] More worrying, though, is this in pykickstart: # Remove any end-of-line comments. ind = self._line.find("#") if (ind > -1): h = self._line[:ind] else: h = self._line And sure enough if I feed "network --device=pci1#2" through ksvalidator and print the results: (Pdb) print handler.network # Network information network --bootproto=dhcp --device=pci1 --onboot=on
(In reply to comment #3) > I had the same suspicion in my tests, but in my case it showed up that the > problem was pre-anaconda processing - pxe configuration file. When I escaped > the character, anaconda (loader) had no problems using pciX#Y name IIRC. Yeah, scratch that, I was obviously wrong at that time.
(In reply to comment #6) > More worrying, though, is this in pykickstart: > > # Remove any end-of-line comments. > ind = self._line.find("#") I think that find might not be accurate though (see comment#2). Should it instead be self._line.find(" #")? From the bash man page: In a non-interactive shell, or an interactive shell in which the interactive_comments option to the shopt builtin is enabled (see SHELL BUILTIN COMMANDS below), a word begin‐ ning with # causes that word and all remaining characters on that line to be ignored. An interactive shell without the interactive_comments option enabled does not allow com‐ ments. The interactive_comments option is on by default in interactive shells. Does this mean it needs to be a regexp and look for a word boundary?
I don't think kickstart has ever promised what level of shell-like syntax it understands, so this is entirely up to our interpretation of what's valid and what's not. The current behavior has been in since March 2008, which means RHEL6 as well as many Fedora releases. And you know this is going to end up as a RHEL6 bug just as soon as someone gets around to it.
Created attachment 475675 [details] Screenshot.png
Created attachment 475676 [details] ks.cfg Attaching kickstart file used