Bug 948921

Created attachment 731918 [details]
dd USB netinstall with TC5 anaconda 19.16 minimal install fails

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.

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.

(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

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

It looks like the first failure here was a case of 906031 . Not sure about the second. satellit, what's the current status here?

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)

Test1
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

Test2
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

test3
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

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

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.

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

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.

TC3 works for me