Bug 948921 - dd USB netinstall with TC5 anaconda 19.16 minimal install fails
Summary: dd USB netinstall with TC5 anaconda 19.16 minimal install fails
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 19
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-04-05 14:25 UTC by satellitgo
Modified: 2013-05-06 15:16 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-05-03 00:21:56 UTC
Type: Bug

Attachments (Terms of Use)
dd USB netinstall with TC5 anaconda 19.16 minimal install fails (486.83 KB, image/jpeg)
2013-04-05 14:26 UTC, satellitgo
no flags Details
dd USB TC5 DVD anaconda failure on install of default desktop to USB HD (741.92 KB, image/jpeg)
2013-04-05 22:04 UTC, satellitgo
no flags Details

Description satellitgo 2013-04-05 14:25:20 UTC
Description of problem:
dd USB install with TC5 anaconda 19.16 minimal install fails

Version-Release number of selected component (if applicable):
TC5 anaconda 19.16

How reproducible:

Steps to Reproduce:
Actual results:
error accessing file for config %s ' %... (see screen shot attached)

Expected results:

Additional info:

Comment 1 satellitgo 2013-04-05 14:26:03 UTC
Created attachment 731918 [details]
dd USB netinstall with TC5 anaconda 19.16 minimal install fails

Comment 2 Chris Lumens 2013-04-05 14:29:08 UTC
Please attach the complete /tmp/anaconda-tb-* file to this bug report.  A picture of the first two frames of the traceback really isn't helpful.

Comment 3 satellitgo 2013-04-05 19:20:47 UTC
I do not know how to do this from a dd USB installer. when anaconda fails all I can do is exit. Bugzilla is not functional in this netinstall.

Comment 4 satellitgo 2013-04-05 19:22:00 UTC
(In reply to comment #3)
> I do not know how to do this from a dd USB installer. when anaconda fails
> all I can do is exit. Bugzilla is not functional in this netinstall.

I am re downloading this .iso and will try a 2nd install to try to reproduce

Comment 5 satellitgo 2013-04-05 22:04:42 UTC
Created attachment 732035 [details]
dd USB TC5 DVD anaconda failure on install of default desktop to USB HD

screen trace of dd USB TC5 DVD anaconda failure on install of default desktop to USB HD   Not possible to get /tmp files as computer shutdown here

Comment 6 Adam Williamson 2013-04-17 16:17:11 UTC
It looks like the first failure here was a case of 906031 . Not sure about the second. satellit, what's the current status here?

Comment 7 Leslie Satenstein 2013-04-27 21:39:43 UTC
Here is a new failure and the tests that I have performed to verify that there is a problem with pointers or similar in anaconda.

Using Real hardware CPUs. 
Using DVD 64bit image (5 gig) which is larger than a physical DVD (4.7g)

a) Verify *iso against CHECKSUM using sha256sum
b) Using dd if=alpha-f19,iso of=/dev/sde bs=8196  # create DVD image
c) Using system Intel E7300.  Memory approx 3.8 gig available from 4gig
   cannot complete test.  Crashes after a count of 9.00%
d) Ignoring count, attempting installation by going directly
    system says it cannot start x and falls into text mode
e)  I have tested with two different 8gig flashdrives
f) text mode fais when attempting to display disk ids with Panel Lockup

Using the identical flashdrive for test1, 
system is I94gnt  Intel system with 3gigs memory
system test count proceeds to 100% and gui anaconda is launched
Installation can proceed and does complete

Download the I386 DVD image, verify CHECKSUM (chksum matches  iso)
Create DVD image on flashdrive (replacing 64bit image)
Anaconda boots from the flashdrive and installation is underway

Create new 64bit image using 2nd system (I945gnt system), and repeat test1 and test 2

When anaconda falls into text mode, in text mode, there is a journal, but I do not know how to get it to a second flashdrive as it is a file in the ram disk. how do I add a mount of a second flashdrive to be able to dump the image for attaching to this bug report. (what /dev/sdx to use)  

Note, I have verified USB ports as functioning 100% using sha256sum 
I have verified that there are no bad memory bits in either machine (using memtest (see anaconda install image troubleshooting memetest)

(This is a wierd problem. At some time last week, the installation worked flawlessly. I went away and the system was fully powered off. 
Problem started on my return when I wanted to install Fedora to a gpt drive (my sdd 256gig sata dedicated to testing).

I thought I had a hardware failure, but all usb ports are working at 100%, flashdrives are error free (100%) and memory tests OK on both systems.

Comment 8 Adam Williamson 2013-05-03 00:21:56 UTC
leslie: your bug clearly has nothing to do with this one. No idea what's going on, indeed, but it's not this bug. Can you file your issue separately? I honestly have no idea what against, but...

I'm gonna close this one, since we know 906031 is fixed, satellit didn't respond to my needinfo, and validation testing of Alpha RC4 didn't indicate any bugs in this area.

Comment 9 Leslie Satenstein 2013-05-03 14:50:54 UTC
I have a problem.  The problem is that when you ask individuals to test a new version of software, You should explain what to collect for the test, and what to do when things go wrong. 

As I stated above, and I repeat 
I have two dual core Intel systems. One I use for 64bit Fedora 18 software and the second for 32bit   
I have a validated sha256sum of the iso images (a 64bit image and a 32bit image).  I should clarify that I only installed the 64bit F19 version.

I used dd to create a copy onto two different flash drives, one flashdrive created from the 64 bit system, and the second flashdrive from the second system. Repeat -- I used  two systems to create the two Flashdrives 

I have no way to verify that the flash drive is a true replica of the iso image, except via the self-test during the installation procedure. 
What I found is:

With Gnome terminal, the flash drive gets created with corruption. Self-test stops at 8% or 9% on the 64bit system with a drop to text mode. The text mode installation fails with lockout (dead terminal). 

After much experimenting, I discovered that with using F18 and KDE terminal, the flash drive gets created and passes the self test. It installs F19 as one anticipates.

I did not try using F18 with virtual terminal (Ctl-alt-f2) to create the F19 flash drive.

Because of all the problems with crashes, I validated the usb hardware and drivers, by copying the iso image to the flash drive directly and then taking the sha256sum. The sha256sum of that iso image passed with zero errors. (I spent a good few hours verifying my hardware because of the crashes).

Be aware, that since the problem was with F18 Gnome terminal running dd and F18, I would ask, "is the problem with F18 Gnome terminal, or with a bug in dd?"  

With F18 and Gnome and a different hardware memory size, this appeared to change the location of the flashdrive F19 selftest crash.

My own software compiles and tests just fine with F19 after having created a clean bootable flashdrive.

I was prepared to do some additional testing, but the response I was expecting was "Can you run this again and do this and that and collect these files for us".  I can do that, if it is worth putting the time in.

Comment 10 Adam Williamson 2013-05-03 17:21:52 UTC
I did not have any trouble understanding your explanation, so you really didn't need to type it out again.

The point is that whatever problem you're hitting is not the same as the problem satellit reported. That's why I asked you to file another bug.

Comment 11 Leslie Satenstein 2013-05-06 15:16:36 UTC
TC3 works for me

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