Created attachment 336331 [details] anaconda logs (including Screenshot).tgz Description of problem: Forcing a traceback, and attempting to test SaveToUSB fails. The inserted USB key is visible in dmesg, but not selectable from the exception dialog in anaconda. Version-Release number of selected component (if applicable): anaconda-11.5.0.35 How reproducible: everytime Steps to Reproduce: 1. Force a traceback by booting with updates=http://jlaska.fedorapeople.org/traceback.img 2. When traceback hits, insert formatted USB key 3. Select Save 4. Select "Local disk" Actual results: Inserted USB drive (sdd in this case) is not available for saving the traceback Expected results: I should see the USB drive as a valid option for saving the traceback Additional info: See attached log files ... -rw-r--r-- root/root 39784 2009-12-27 18:47 tmp/X.log -rw-r--r-- root/root 4576 2009-12-27 18:45 tmp/anaconda.log -rw-r--r-- root/root 54 2009-12-27 18:45 tmp/program.log -rw-r--r-- root/root 1906 2009-12-27 18:45 tmp/storage.log -rw-r--r-- root/root 56941 2009-12-27 18:47 tmp/syslog -rw-r--r-- root/root 31870 2009-12-27 18:47 tmp/anaconda-screenshots/screenshot-0000.png ^^^ screenshot demonstrating the failure screen The remaining files are part of the traceback that I am injecting for testing. -rw-r--r-- root/root 73663 2009-12-27 18:45 tmp/anacdump.txt drwxr-xr-x root/root 0 2009-12-27 18:45 tmp/updates/ drwxr-xr-x root/root 0 2009-12-27 18:45 tmp/updates/iw/ -rw-r--r-- root/root 1354 2009-12-27 18:45 tmp/updates/iw/welcome_gui.pyc -rw-r--r-- root/root 1444 2009-12-27 18:45 tmp/updates/iw/kbd_gui.py -rw-r--r-- root/root 1539 2009-12-27 18:45 tmp/updates/iw/welcome_gui.py
*** Bug 491142 has been marked as a duplicate of this bug. ***
*** Bug 494784 has been marked as a duplicate of this bug. ***
I had similar problems, although my original bug report (marked duplicate to this, 494784 outlines some additional problems I had. I created the directory /mnt/floppy and manually mounted a vfat formatted floppy there. When attempting to save the file on the local file system, clicking OK after selecting a location and file name did nothing, and locked me in the dialog for selecting a location. I had similar results when attempting to initialize the network via the utility to upload the traceback via scp. The network initialized, and then nothing happened. I waited about 20 minutes before shutting down the system to try again and nothing was ever sent, although it did appear to initialize the network properly. The only way I was able to get the utility to work, was to do a vnc install, so that the network connection was already up and running, and then choose to send the traceback via scp. That worked as expected.
Created attachment 339490 [details] anaconda-logs.tgz (from anaconda-11.5.0.44) There appears to be a fix in 11.5.0.44-1 "Rescan the devices when we are saving a traceback. (jgranado)" but the fix appears incomplete as the "Finding storage devices" dialog appears be never goes away (see screenshot http://jlaska.fedorapeople.org/savetobugzilla.png).
Joel's got this working, at least on real hardware. It sounds like there's still troubles in virt land.
I also changed this to use the devicetree structures. This might have fixed the bug that is seen in virtual machines.
Retested, no longer seeing the original traceback. But also not able to save the traceback to the USB key. The USB key currently is formatted with a vfat partition. Should it be visible to anaconda? Or is this another bug?
Not sure - could be a continuation of the original problem, or it could be something different. Joel - any thoughts here? Want to look into it again?
Created attachment 343494 [details] /tmp/anaconda.log (11.5.0.51) 18:07:28 ERROR : Error when probing exception disks: global name 'disk' is not defined
I've looked at the code and the disk global name is not present anymore. Additionally I added a patch that "takes care" of the situations where the devices have a FS and not a partition table. Anaconda will ask the user to initialize the device (create a partition table) its not the best solution but It should take care of that corner case.
These are the results of my tests: 1. With ext3 fs no partition table: The scan disks ask the user to initialize the disk. If the user chooses to initialize the disk, a partition table is created with no partitions and the disk is not put into the list of the possible locations for putting the traceback as it does not have a partiton nor a FS. 2. With vfat. If you use mkfs.vfat to create the file system this command will create a partition table with no partition present. This will cause the installer to ignore the device as it does not have any partitions. 3. with an msdos partition table and with an ext3 fs on the first partition, anaconda finds the partition. also finds the fs in the partition and puts the trace back in detected partition. 4. with an msdos partition table and a vfat fs on the first partition, it has the same behavior as 3.
Created attachment 345096 [details] anaconda-11.5.0.54 logs (/tmp/*log*) * I've just tested (anaconda-11.5.0.54) steps#4 (vfat) and I am not able to see my USB device in the list of partitions at the anaconda exception screen. I have 2 partitions: ============================= sh-4.0# parted /dev/sdb -s p Model: USB Flash Disk (scsi) Disk /dev/sdb: 507MB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 512B 100MB 100MB primary fat16 lba 2 100MB 200MB 100MB primary ext2 lba ============================= /dev/sdb1 is where I intend to save the traceback, however the traceback screen lists no valid devices to save to. Attaching /tmp/*log* * I have tested step#3 (ext3) and it works, but only once. If I repeat the test with the same formatted partition setup ... my ext3 partition is no longer available for saving the traceback.
Follow-up to comment#12. I can get both step#3 (ext3) and step#4 (vfat) to work. But something isn't quite right with the workflow. I have to remove the USB key and reinsert it one, or more, times ... then click Save ... and the partition is recognized. I think the remaining issues I'm seeing are around: * Booting with "updates" to load an updates.img from a partition on a USB key. Then I attempt to save teh traceback to another partition. I am required to remove and reinsert the USB key for the partition to be recognized. * When booting without "updates" (or any need for a the USB key), I click "Save" and the USB partition(s) are not recognized. I have to remove and re-insert the USB key ... then the partitions are recognized. Is this behavior different from the originally reported problem? Should I file this issue separately. My expectation is that I should not have to remove and re-insert the USB key. If that is a requirement, a message may need ot be added so that the USER knows what to do.
(In reply to comment #13) > * Booting with "updates" to load an updates.img from a partition on a USB key. > Then I attempt to save teh traceback to another partition. I am required to > remove and reinsert the USB key for the partition to be recognized. I'm going to have to test this to see exactly what is going on. > > * When booting without "updates" (or any need for a the USB key), I click > "Save" and the USB partition(s) are not recognized. I have to remove and > re-insert the USB key ... then the partitions are recognized. The usb has to be recongnized by the kernel and that takes some seconds. Could it be that you pressed "save" to fast? This consistently works for me if I give it some time to read. > > Is this behavior different from the originally reported problem? Should I file > this issue separately. Well, its still save traceback to usb problem. I think keeping it in this bug is ok
I followed the first problem "cant see usb while updated in one of the partitions" and found out that it is a udev related issue. The reproducer for this issue doesn't have to do with the update functionality. It occurs when using a usb from the beginning of the install. To reproduce: 0. make sure usb has partitions and a fs in a partition. 1. Connect usb to box before firing up installation. 2. when possible, change to tty2. 3. execute "udevadm info --query=all --name=DEV" 4. Note that the output does not contain the ID_FS_TYPE label 5. disconnect and reconnect usb 6. execute "udevadm info --query=all --name=DEV" once more. 7. Notice that the ID_FS_TYPE label has magically appeared. The Save to usb does not list the device because udev does not tell anaconda that there is a FS in one of the partitions; therefore, no device is listed. jlaska: The aforementioned behavior is indeed another bug.
Ok. I have a patch that solves the udev issue. see https://www.redhat.com/archives/anaconda-devel-list/2009-May/msg00312.html. I have created an updates image (http://jgranado.fedorapeople.org/anaconda/ui/udev_trigger.img) that contains an error and the fix. This will make testing the fix easier.
I have tested the udev_trigger.img. * Boot with "updates" * Anaconda prompts and finds the updates.img from sdb1 * Traceback presented (as expected) * Click Save * Local devices not found I repeat the Save step several times ... no local devices found I remove and re-insert the USB key (and wait 30 seconds) ... local devices are found. I think we should move this issue off to a new bz and discuss further there. THoughts?
(In reply to comment #17) ... > * Local devices not found > > I repeat the Save step several times ... no local devices found Darn, no clue whats going on. > > I remove and re-insert the USB key (and wait 30 seconds) ... local devices are > found. The trigger thing should work. > > I think we should move this issue off to a new bz and discuss further there. > THoughts? Sure, I'm for moving it to another bug. I have created https://bugzilla.redhat.com/show_bug.cgi?id=503144 to track this issue. I'll leave the fate of this bug to you.
Changing this bug go CLOSED RAWHIDE (it's fixed in F11 as well). Adding the keyword CommonBugs so that I (or someone in the QA group) adds a note that users may need to remove/reinsert the USB storage media when attempting to save to a USB key.