Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 452865

Summary: Anaconda stage 1 Kickstart Usb Install Delay/Sleep Needed
Product: [Fedora] Fedora Reporter: Nick Hecht <nick.hecht>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 8CC: astrand, dsd, jvonau3, kitgerrits, ndevos
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-11-26 18:22:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Nick Hecht 2008-06-25 14:09:52 UTC
Description of problem:

Using Fedora 8 DVD images to build a complete hands off kickstart installation.
during stage 1 after anaconda loads the usb-storage module the usb key is
unmounted and remounted. because anaconda looks for the kickstart file right
after this it cannot find it displays a dialog to enter the location of the
kicstart file this requires input from the user. However because the kicstart
file is there, the user can just wait a few seconds and press enter with out
changing the location of the kickstart file and the installation proceeds.

How reproducible:

Steps to Reproduce:
1. create a complete usb installation key
2. try to install via the usb key
Actual results:
user input required because anaconda cannot find the kicstart fils 

Expected results:
More tolerant stage 1 procedure that try's to give the system more time to mount
the usb key before looking for any files on it.

Comment 1 John Poelstra 2008-06-27 03:16:46 UTC

Comment 2 Chris Lumens 2008-08-28 20:32:00 UTC
What's the status of this bug with F9 or F10 Alpha?  The module loading code has undergone quite a bit of work since F8, and we are no longer doing the silly load/unload usb-storage module thing that we used to do.

Comment 3 Nick Hecht 2008-08-28 20:47:41 UTC
actually I have made various usb keys using F8 and F9 and I am still having issues with anaconda not finding my kickstart... and i think is is because the usb key is not (yet) mounted

Comment 4 Jerry Vonau 2008-09-04 23:25:00 UTC
Still present with F9, fails to find ks file on usb stick, brings up error screen, hitting enter with no changes results in finding of the ks file and the kickstart install continuing.

Comment 5 Bug Zapper 2008-11-26 10:55:23 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  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 WONTFIX if it remains open with a Fedora 
'version' of '8'.

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 prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here:

Comment 6 Kit Gerrits 2008-11-26 14:54:44 UTC
I am currently running into the same 'problem' with a Fedora 9 DVD.
ks=hd:sdb1/ks.cfg gives an anaconda error.
If I wait a few seconds before hitting [Enter], setup continues as planned.\

Please change the package version, as I am unable to do so myself.

Comment 7 Andy Lindeberg 2008-11-26 18:22:51 UTC
Without more information from the kernel, which we're not getting, anaconda has no way of knowing when a USB device is ready to be used, or how long to wait until it is. If you would like to take this up with the kernel folks, please feel free.

Comment 8 Kit Gerrits 2008-11-26 18:53:28 UTC
Please let me know what you want to know and how I can find/provide such information.
I don't know if there's already a console available at such time, 
  I'll check it out when I get back to the machine.

Comment 9 Jerry Vonau 2008-11-27 15:37:14 UTC
I'm going to call BS on this one, adding in some sleeps here and there allows usb disks to be found for me, diff against anaconda- 

diff -up ./loader2/hdinstall.c.orig ./loader2/hdinstall.c
--- ./loader2/hdinstall.c.orig	2008-09-13 18:38:44.000000000 -0500
+++ ./loader2/hdinstall.c	2008-09-13 19:22:37.000000000 -0500
@@ -539,6 +543,8 @@ int kickstartFromHD(char *kssrc) {
     kspath = np+1;
     logMessage(INFO, "Loading ks from device %s on path %s", ksdev, kspath);
+    sleep(5);
+    logMessage(INFO, "JV Sleeping 5 seconds USB hd.c");
     if ((rc=getKickstartFromBlockDevice(ksdev, kspath))) {
         if (rc == 3) {
diff -up ./loader2/init.c.orig ./loader2/init.c
--- ./loader2/init.c.orig	2008-09-13 13:38:48.000000000 -0500
+++ ./loader2/init.c	2008-09-13 13:40:45.000000000 -0500
@@ -542,6 +542,8 @@ int main(int argc, char **argv) {
 	printf("starting udev...");
 	if (fork() == 0) {
 	    execl("/sbin/udevd", "/sbin/udevd","--daemon",NULL);
+            printf("sleeping udev 5 secs...JV");
+            sleep(5);  
diff -up ./loader2/kickstart.c.orig ./loader2/kickstart.c
diff -up ./loader2/loader.c.orig ./loader2/loader.c
--- ./loader2/loader.c.orig	2008-09-13 11:52:32.000000000 -0500
+++ ./loader2/loader.c	2008-09-13 18:58:09.000000000 -0500
@@ -1721,14 +1721,17 @@ int main(int argc, char ** argv) {
     /* JKFIXME: loaderData->ksFile is set to the arg from the command line,
      * and then getKickstartFile() changes it and sets FL_KICKSTART.  
-     * kind of weird. */
+     * kind of weird. JV is confused too...*/
     if (loaderData.ksFile || ksFile) {
         logMessage(INFO, "getting kickstart file");
         if (!ksFile)
+            logMessage(INFO, "JV sleep 5 secs ld.c 1");
+            sleep(5);
         if (FL_KICKSTART(flags) && 
             (ksReadCommands((ksFile)?ksFile:loaderData.ksFile)!=LOADER_ERROR)) {
+            logMessage(INFO, "JV sleep 5 secs ld.c 2");
+            sleep(5);

Comment 10 Chris Lumens 2008-12-02 16:14:27 UTC
Sure, five seconds works for your particular kernel version and your particular hardware.  That's not guaranteed to work for every install, and what should we do in those cases?  Sleep longer?  Sleep until something happens?  The problem is there's no event that indicates the discovery is over and we can stop sleeping.

Comment 11 Jerry Vonau 2008-12-02 18:17:36 UTC
That was with the kernel that was used with the F9 installer.... No, it may not work for every install that was having usb issues. It just might fix the issue for 10%, maybe 90%, but we'll never know now will we.... Wait, I'll pass the fix to OLPC for their server spin (the issue was noted there also) and gather the feedback for you, will that help? 10% less users having issues is better that doing *nothing* IMHO....

Comment 12 Niels de Vos 2009-03-02 10:06:54 UTC
Attachment 139362 [details] of bug 212146 also contains a patch like this one. It looks like a solution/feature would be nice.

Comment 13 Daniel Drake 2009-10-06 05:10:26 UTC
Actually this problem boils all the way down to the hardware level: the nature of USB means that the USB host controller driver never knows when the hardware has finished enumerating all the hubs and buses. Same for SCSI (although enumeration is much faster there so this problem is rarely seen).

So if you want to be robust, anaconda really should do something here. You're right that there's no way to know how long to wait, but at the very least a boot option could be added, allowing the user to choose a delay, e.g. "diskdelay=5" would cause anaconda to wait 5 seconds before looking for the ks file. That would be satisfactory for us in the OLPC school server world at least, and I can't imagine it would be an intrusive change to anaconda.

As a more advanced solution, I would recommend examining what dracut does, which must be facing these problems too.

Comment 14 Chris Lumens 2009-10-06 13:42:02 UTC
The point isn't that it's terribly intrusive.  The point is that it's yet another goofy hardware hack parameter that provides yet another path that'll go untested.  If anaconda's to do anything here, it needs to be totally automatic so users don't even need to know.

Comment 15 Daniel Drake 2009-10-07 09:27:08 UTC
OK, fair point. But have I convinced you that doing something would be sensible? If so, I'd like to reopen this bug :)

I took a quick look at dracut and how it handles this problem. Here's what it does:

It has a "initqueue" system which is a mechanism that basically allows the modules that are responsible for getting things ready for the rootfs mount to report that they aren't ready yet.

In the case of the rootfs-block module, if the /dev/root symlink has not yet been created then it reports in the initqueue that it is not ready. (udev and the initqueue will race to create /dev/root once the appropriate disk has appeared, but this race is OK)

Dracut runs the initqueue up to 20 times, with a 0.5 second delay at the end of each iteration.

After the initqueue events have finished successfully, it breaks out of the loop and goes on to do the actual mount.

If it fails 20 times, it exits with an error, halting the boot process.

I think it would be reasonable for anaconda to implement something similar, although it doesn't have to be as complex. If the ks file doesn't exist, print a message, wait 1 second, and try again. Pop up the existing error message dialog after 10 tries, or something like that.