Created attachment 779408 [details] screenshot showing dracut shell after invalid kickstart URL is passed on kernel command line Description of problem: If the installer is passed an invalid kickstart URL, the user is eventually presented with the dracut shell and a screen full of log messages. Since the user is expecting to see the installer Welcome and Installation Summary screens, it would be better to display a graphical error alert reporting the problem and the curl error message. The dracut shell should be avoided for normal exceptions. Most users will have no idea what it is or what to do next. Also, any relevant error messages should be written to an anaconda log file. Getting error messages from the dracut shell is a chore, because it does not have scp, so you have to pre-format a disk to copy the dracut sosreport.txt log to. That severely impedes the collection of the error logs that anaconda developers invariably ask for. NB: curl displays the following with an invalid URL: $ curl --location http://no_such_place.org/ks.cfg curl: (7) Failed connect to localhost:80; Connection refused Version-Release number of selected component (if applicable): anaconda-19.30.13-1.fc19.x86_64 Fedora-19-x86_64-DVD.iso How reproducible: Always. Steps to Reproduce: 1. Start the installer: $ qemu-kvm -m 4096 -hda f19-test-2.img -cdrom ~/xfr/fedora/F19/Fedora-19-x86_64-DVD.iso -vga std -boot menu=on 2. Append this to the kernel command line: ks=http://no_such_place.org/ks.cfg 3. Begin installation. Actual results: The dracut shell is eventually displayed. See attached screenshot. Expected results: A graphical error alert is displayed with an informative error message. Additional info: Dracut is implemented with shell scripts, and anaconda is implemented with Python. That doesn't seem very convenient for integration ...
Created attachment 890118 [details] screencast that shows errors that don't really indicate the cause Installing a Fedora 20 guest I hit a similar issue where if the ks= parameter is specified incorrectly and is a specified as a file within the initrd then you get almost no indication of what really went wrong. The output you get looks something like: ############################################ [ OK ] Reached target Basic System. [ 3.368768] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3 [ 3.435091] tsc: Refined TSC clocksource calibration: 3392.375 MHz [ 186.826348] dracut-initqueue[489]: Warning: Could not boot. [ OK ] Started Show Plymouth Boot Screen. [ OK ] Reached target Paths. [ OK ] Reached target Basic System. [ 186.826348] dracut-initqueue[489]: Warning: Could not boot. [ 186.831278] dracut-initqueue[489]: Warning: /dev/root does not exist Starting Dracut Emergency Shell... Warning: /dev/root does not exist Generating "/run/initramfs/rdsosreport.txt" Entering emergency mode. Exit the shell to continue. ################################################# I was installing a F20 guest from a F19 host. The command I used is below: virt-install --name F20 --ram 2048 --vcpus 2 --disk path=/guests//F20.img,size=20 --disk device=cdrom,path=/home/dustymabe/Desktop/Fedora-20-x86_64-DVD.iso --accelerate --location /tmp/tmp.WAcoVRgohg/mnt --initrd-inject /tmp/tmp.WAcoVRgohg/ks.conf --graphics none --force --network bridge=virbr0 --extra-args=console=ttyS0 ks=file://doesnotexist.conf You can also view a screencast of this at the following address: http://dustymabe.com/content/RANDOM/BZ989255.html
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still an issue with Fedora-Server-DVD-x86_64-21.iso #################################################### [ OK ] Reached target Basic System. [ 141.791635] random: nonblocking pool is initialized [ 193.437103] dracut-initqueue[573]: Warning: Could not boot. [ OK ] Started Show Plymouth Boot Screen. [ OK ] Reached target Paths. [ OK ] Reached target Basic System. [ 193.437103] dracut-initqueue[573]: Warning: Could not boot. [ 193.447994] dracut-initqueue[573]: Warning: /dev/root does not exist Starting Dracut Emergency Shell... Warning: /dev/root does not exist Generating "/run/initramfs/rdsosreport.txt" Entering emergency mode. Exit the shell to continue. ################################################### If you can manage to get scrollback (not always the case) then you do see this though: [ 5.314450] dracut-cmdline[98]: Warning: inst.ks='file://ks.conf' [ 5.316705] dracut-cmdline[98]: Warning: can't find //ks.conf! I'll let others decide if this is good enough or not.
Making the error message more useful/visible is actually really easy - we just need to drop a script into the 'emergency' hookdir that prints more useful error messages. For example, see modules.d/99base/dracut-lib.sh:wait_for_mount(): wait_for_mount() { local _name _name="$(str_replace "$1" '/' '\\x2f')" printf '. /lib/dracut-lib.sh\nismounted "%s"\n' $1 \ >> "$hookdir/initqueue/finished/ismounted-${_name}.sh" { printf 'ismounted "%s" || ' $1 printf 'warn "\"%s\" is not mounted"\n' $1 } >> "$hookdir/emergency/90-${_name}.sh" } That's how that 'Warning: /dev/root does not exist' message gets printed.
(In reply to Will Woods from comment #4) > Making the error message more useful/visible is actually really easy - we > just need to drop a script into the 'emergency' hookdir that prints more > useful error messages. Using that mechanism would it be easy use it to deliver this type of message to the user? For example, if "Warning: can't find //ks.conf!" could be delivered using this mechanism to the user then it would tell them exactly what happened. Another question is: do we even need to wait_for_mount() in this case? We already know we had a failure so why can't we go ahead and fail rather than wait for something else to fail?
(In reply to Dusty Mabe from comment #5) > (In reply to Will Woods from comment #4) > > Making the error message more useful/visible is actually really easy - we > > just need to drop a script into the 'emergency' hookdir that prints more > > useful error messages. > > Using that mechanism would it be easy use it to deliver this type of message > to the user? For example, if "Warning: can't find //ks.conf!" could be > delivered using this mechanism to the user then it would tell them exactly > what happened. Yup. Here's where the existing code emits the warning messages you found: https://github.com/rhinstaller/anaconda/blob/master/dracut/parse-anaconda-kickstart.sh (patches/pull-requests are welcomed and encouraged!) > Another question is: do we even need to wait_for_mount() in this case? We > already know we had a failure so why can't we go ahead and fail rather than > wait for something else to fail? A missing kickstart is not necessarily fatal; some kickstarts just contain commands for, say, setting language and time-zone. The install can still be completed interactively without it, if we have enough information to find the installer runtime (LiveOS/squashfs.img). It could also be the case that the disk containing the kickstart hasn't appeared yet, or that we haven't gotten the network online yet. So in those cases, we need to wait. You might be right for this specific case, though: if a "ks=file://" argument was given, but we can't find that file *and* we have no other way to find the installer runtime, it's probably best to fail immediately (and, y'know, tell the user what actually happened).
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.