Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start installation from USB DVD burner on USB bootable CPU board
2. Notice progress up to point where /sbin/loader is working.
3. Get bad exit and safe to reboot message
Trying both GUI and text installs failed on two different computers. The first
computer uses a PCISA-3716E2V CPU board and is capable of booting from USB-
CDROM via BIOS. The second computer contains a NOVA-7896RFW CPU board.
Both CPU versions were able to install FC5T2. This failure is a regression.
Expected to be able to upgrade from installed OS to FC5T3 without failure.
I tried text installation. I wiped out the previous installation and tried to
do a clean install. This problem is regression from FC5T2.
So it hangs at /sbin/loader if you have a USB cd/dvd drive connected. Ugh.
The problem is pretty bad for USB cd/dvd drives. I decided to setup FC5T2 again
where the problem does not happen and setup a local repo on the same USB DVD
drive. (no internet available to particular computer)
The yum install works fine off of the baseurl=file:///media/usbdvd to pull in
over 1000 packages and install 7 more. Hopefully the USB DVD drive bug is
squashed by release time.
I'm not sure if I made clear that the mediacheck portion of FC5T3 passed and
failed with the installation after continuing. The ejecting of the disc and
reseating of the disc worked during the media test.
If this information is any help for how the DVD reacts in FC5T2, it does not
automount. The permissions of /dev/scd0 are set properly to user though. I could
however create /media/usbdvd directory and then use mount /dev/scd0
/media/usbdvd to do a very unsupported upgrade.
Wait, so the hang isn't at "running /sbin/loader"? Where exactly is it failing
and what is being printed on the screen?
The failure happens shortly after either pressing enter and trying to do a GUI
install or typing linux text for entering the text mode installation.
I believe /sbin/loader was started followed by the error encountered safe to
reboot. The failure was on both a NOVA SBC and again on another SBC that uses a
Both computers are capable of booting from USB CDROM and FC5T2 installs fine on
the PCISA SBC unit.
Monday, I will report back on what is displayed on the computer screens. Since
it stopped at safe to reboot, I thought the computer was in a locked state.
There are less than ten lines of test displayed when the failure occurs.
Created attachment 125319 [details]
Serial capture - random
I setup a serial terminal to capture the output. I am unsure how to redirect
output from tty2 to ttyS0 to capture the information. Attached is what serial
output I could obtain.
Created attachment 125323 [details]
This is captured text for screen 1 before failure.
Created attachment 125327 [details]
two runs through system
This capture was created with console=ttyS0,9600n8 console=tty0 in order to
control the functions from the keyboard and CRT. I will cease for now until /
if any additional steps to capture test are described.
Created attachment 125338 [details]
Contains boot, installed packages, dmesg and lspci -vvv info
The attached captured test is on a system updated from FC5T2 to FC5T3 the hard
way and the capture to /dev/ttyS0 are boot, lspci, dmesg, anaconda upgrade
information and currently installed updates from the local repo and using FC5T3
DVD as yum rpm source.
Created attachment 125341 [details]
Cleaner lspci, FC5T3 installed, anaconda FC5T2 install and dmesg output.
New to capturing text via hypertrm. This log has previously captured text
cleared before the capture and echo entries as to what was being outputted to
/dev/ttyS0 for log information.
Looks like this was due to kudzu passing bogus devices into anaconda and has
been fixed since test3.
Dredged up a USB DVD drive and managed to reproduce and verify that it's fixed.
Thanks for the fixing up for USB DVD. Looking forward to installing FC5 directly.