Bug 989255 - RFE: display graphical error alert instead of dracut shell when invalid kickstart URL is detected
RFE: display graphical error alert instead of dracut shell when invalid kicks...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
21
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Will Woods
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-28 15:59 EDT by Steve Tyler
Modified: 2015-12-02 11:05 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-01 21:54:35 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screenshot showing dracut shell after invalid kickstart URL is passed on kernel command line (15.98 KB, image/png)
2013-07-28 15:59 EDT, Steve Tyler
no flags Details
screencast that shows errors that don't really indicate the cause (138.42 KB, text/html)
2014-04-26 18:19 EDT, Dusty Mabe
no flags Details

  None (edit)
Description Steve Tyler 2013-07-28 15:59:12 EDT
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 ...
Comment 1 Dusty Mabe 2014-04-26 18:19:23 EDT
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
Comment 2 Fedora End Of Life 2015-01-09 14:07:59 EST
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.
Comment 3 Dusty Mabe 2015-02-11 10:53:18 EST
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.
Comment 4 Will Woods 2015-02-11 17:02:38 EST
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.
Comment 5 Dusty Mabe 2015-02-11 17:28:16 EST
(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?
Comment 6 Will Woods 2015-02-12 10:51:39 EST
(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).
Comment 7 Fedora End Of Life 2015-11-04 08:39:08 EST
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.
Comment 8 Fedora End Of Life 2015-12-01 21:54:39 EST
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.

Note You need to log in before you can comment on or make changes to this bug.