Bug 452865

triaged

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.

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

Still present with F9, 11.4.0.82 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.

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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.

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.

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.

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-11.4.0.82 

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) {
             startNewt();
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);  
 	    exit(1);
 	}
     }
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);
             getKickstartFile(&loaderData);
         if (FL_KICKSTART(flags) && 
             (ksReadCommands((ksFile)?ksFile:loaderData.ksFile)!=LOADER_ERROR)) {
+            logMessage(INFO, "JV sleep 5 secs ld.c 2");
+            sleep(5);
             runKickstart(&loaderData);
         }
     }

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.

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....

Attachment 139362 [details] of bug 212146 also contains a patch like this one. It looks like a solution/feature would be nice.

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.

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.

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.