Bug 491700

Summary: Save traceback to USB key does not work
Product: [Fedora] Fedora Reporter: James Laska <jlaska>
Component: anacondaAssignee: Joel Andres Granados <jgranado>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: awilliam, jturner, nospam, pjones, rmaximo, tcallawa, vanmeeuwen+fedora, vinagr3
Target Milestone: ---Keywords: CommonBugs
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: https://fedoraproject.org/wiki/Common_F11_bugs#usb-traceback-anaconda
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-29 10:05:47 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 495965    
Attachments:
Description Flags
anaconda logs (including Screenshot).tgz
none
anaconda-logs.tgz (from anaconda-11.5.0.44)
none
/tmp/anaconda.log (11.5.0.51)
none
anaconda-11.5.0.54 logs (/tmp/*log*) none

Description James Laska 2009-03-23 13:07:13 EDT
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
Comment 1 Chris Lumens 2009-03-23 13:33:04 EDT
*** Bug 491142 has been marked as a duplicate of this bug. ***
Comment 2 Joel Andres Granados 2009-04-09 07:42:44 EDT
*** Bug 494784 has been marked as a duplicate of this bug. ***
Comment 3 Jason 2009-04-09 09:14:05 EDT
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.
Comment 4 James Laska 2009-04-14 09:45:14 EDT
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).
Comment 5 Chris Lumens 2009-04-14 15:12:50 EDT
Joel's got this working, at least on real hardware.  It sounds like there's still troubles in virt land.
Comment 6 Joel Andres Granados 2009-04-16 05:34:40 EDT
I also changed this to use the devicetree structures.  This might have fixed the bug that is seen in virtual machines.
Comment 7 James Laska 2009-05-11 15:20:31 EDT
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?
Comment 8 Chris Lumens 2009-05-11 15:22:39 EDT
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?
Comment 9 James Laska 2009-05-11 15:26:07 EDT
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
Comment 10 Joel Andres Granados 2009-05-19 04:07:14 EDT
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.
Comment 11 Joel Andres Granados 2009-05-19 11:25:06 EDT
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.
Comment 12 James Laska 2009-05-22 10:28:25 EDT
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.
Comment 13 James Laska 2009-05-22 10:39:19 EDT
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.
Comment 14 Joel Andres Granados 2009-05-27 05:30:20 EDT
(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
Comment 15 Joel Andres Granados 2009-05-27 08:05:27 EDT
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.
Comment 16 Joel Andres Granados 2009-05-27 09:50:19 EDT
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.
Comment 17 James Laska 2009-05-28 16:56:23 EDT
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?
Comment 18 Joel Andres Granados 2009-05-29 05:05:54 EDT
(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.
Comment 19 James Laska 2009-05-29 10:05:47 EDT
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.