I'm unable to install x86_64 on a host. The installer gets through the first part, asking for install type and it begins loading the images from whatever media was selected.
Then anaconda spills a series of cryptic messages ending in 'file not found' and the console on F2 is locked up. I've tried this with physical DVD media, PXE-HTTP and media-boot HTTP install. It happens every time.
This is a reinstall to this host. The weird thing is that I was able to install to this host from this media previously.
I've seen the note at bugs.centos.org regarding an incorrect .discinfo file but that doesn't seem to be it. The .diskinfo file:
1195929648.203590 Final x86_64 1,2,3,4,5,6,7 CentOS/base /home/buildcentos/CENTOS/5.1/en/x86_64/CentOS CentOS/pixmaps
Does anyone have any idea what's going on?
Kirk Bocek
On Tue, Jun 3, 2008 at 3:51 PM, Kirk Bocek t004@kbocek.com wrote:
I'm unable to install x86_64 on a host. The installer gets through the first part, asking for install type and it begins loading the images from whatever media was selected.
Then anaconda spills a series of cryptic messages ending in 'file not found' and the console on F2 is locked up. I've tried this with physical DVD media, PXE-HTTP and media-boot HTTP install. It happens every time.
This is a reinstall to this host. The weird thing is that I was able to install to this host from this media previously.
I've seen the note at bugs.centos.org regarding an incorrect .discinfo file but that doesn't seem to be it. The .diskinfo file:
1195929648.203590 Final x86_64 1,2,3,4,5,6,7 CentOS/base /home/buildcentos/CENTOS/5.1/en/x86_64/CentOS CentOS/pixmaps
Does anyone have any idea what's going on?
A little more detail, like what kind of hardware this is on, might help....
mhr
MHR wrote:
On Tue, Jun 3, 2008 at 3:51 PM, Kirk Bocek t004@kbocek.com wrote:
I'm unable to install x86_64 on a host. The installer gets through the first part, asking for install type and it begins loading the images from whatever media was selected.
Then anaconda spills a series of cryptic messages ending in 'file not found' and the console on F2 is locked up. I've tried this with physical DVD media, PXE-HTTP and media-boot HTTP install. It happens every time.
This is a reinstall to this host. The weird thing is that I was able to install to this host from this media previously.
I've seen the note at bugs.centos.org regarding an incorrect .discinfo file but that doesn't seem to be it. The .diskinfo file:
1195929648.203590 Final x86_64 1,2,3,4,5,6,7 CentOS/base /home/buildcentos/CENTOS/5.1/en/x86_64/CentOS CentOS/pixmaps
Does anyone have any idea what's going on?
A little more detail, like what kind of hardware this is on, might help....
mhr
Sure. It's a Asus DSEB-DG motherboard with dual Xeon E5440 CPUS. 8 GB RAM. All the storage is via a 3Ware 9650SE RAID controller.
I didn't provide the details because it was strange that the installation failed at the same point regardless of the booting method I used. It felt like some basic mistake or mis-setting in the OS. But hey, I've been wrong before.
I'm in the process of downloading a whole new DVD image even though the current image passes the SHA1 checksums.
Kirk Bocek
Kirk Bocek wrote:
I didn't provide the details because it was strange that the installation failed at the same point regardless of the booting method I used. It felt like some basic mistake or mis-setting in the OS. But hey, I've been wrong before.
Anything interesting on vc#1,3,4,5 ? how about run remote syslog and see if anything interesting gets in there....
Karanbir Singh wrote:
Kirk Bocek wrote:
I didn't provide the details because it was strange that the installation failed at the same point regardless of the booting method I used. It felt like some basic mistake or mis-setting in the OS. But hey, I've been wrong before.
Anything interesting on vc#1,3,4,5 ? how about run remote syslog and see if anything interesting gets in there....
I modified the kickstart file to include the line "logging --host=logginghostname". I added '-r' to the syslog options on the logging host and restarted syslog. I PXE booted into a new install.
It crashed a the usual way, right after the "Anaconda Starting" message. A few lines of what I believe are Python display but scroll off of the console. The last messages displayed are:
Install exited abnormally [1/1] You may safely reboot
On vc3, three warnings:
No floppy device found but we'll try fd0 Graphical install unavailable ((I gave the 'text' option at startup)) Unable to find temp path, going to use ramfs path
On vc4, nothing seemed special, last message:
No IPv6 routers present
vc5 and vc6 are blank.
I could not find any messages regarding this installation on the remote logging host. I've never done this remote logging before. Is there a step I missed setting it up?
Thanks, Kirk Bocek
Karanbir Singh wrote:
Kirk Bocek wrote:
I didn't provide the details because it was strange that the installation failed at the same point regardless of the booting method I used. It felt like some basic mistake or mis-setting in the OS. But hey, I've been wrong before.
Anything interesting on vc#1,3,4,5 ? how about run remote syslog and see if anything interesting gets in there....
Karanbir: After rebooting many times and trying different things, I was able to get a bit more information. I was able to get the Anaconda error message by *not* using text mode. X starts up but then kicks back into text mode when this error pops up.
Some of the lines are not quite complete as I had to copy them by hand.
Traceback (most recent call last) File "/usr/bin/anaconda", line 900, in ? iutil.makeDriveDeviceNodes() File /usr/bin/anaconda/iutil.py", line 264, ... isys.makeDevInode(... File "/usr/bin/anaconda/isys.py", line 422 ... isys.mkdevinode... System Error: (2, 'No such file or directory')
Does this provide any help?
Thanks, Kirk Bocek
Karanbir Singh wrote:
Kirk Bocek wrote:
I didn't provide the details because it was strange that the installation failed at the same point regardless of the booting method I used. It felt like some basic mistake or mis-setting in the OS. But hey, I've been wrong before.
Anything interesting on vc#1,3,4,5 ? how about run remote syslog and see if anything interesting gets in there....
After wandering in the dark for two days, I found this posting:
http://www.centos.org/modules/newbb/viewtopic.php?topic_id=13334
This reminded me that although this is an all SATA system, I also have a PATA tape drive installed.
The solution in the posting was to temporarily unplug the tape drive. Rather than pull this host out of the rack for the umpteenth time, I simply added to the installer's command line:
hda=none hdb=none
For some reason, the tape drive is installed as /dev/hdb. I'm not sure what's at /dev/hda. If it's the DVD drive and I was installing from physical media, that might be a problem. However, my PXE-boot install is now flying along.
Kirk Bocek
on 6-4-2008 3:12 PM Kirk Bocek spake the following:
Karanbir Singh wrote:
Kirk Bocek wrote:
I didn't provide the details because it was strange that the installation failed at the same point regardless of the booting method I used. It felt like some basic mistake or mis-setting in the OS. But hey, I've been wrong before.
Anything interesting on vc#1,3,4,5 ? how about run remote syslog and see if anything interesting gets in there....
After wandering in the dark for two days, I found this posting:
http://www.centos.org/modules/newbb/viewtopic.php?topic_id=13334
This reminded me that although this is an all SATA system, I also have a PATA tape drive installed.
The solution in the posting was to temporarily unplug the tape drive. Rather than pull this host out of the rack for the umpteenth time, I simply added to the installer's command line:
hda=none hdb=noneFor some reason, the tape drive is installed as /dev/hdb. I'm not sure what's at /dev/hda. If it's the DVD drive and I was installing from physical media, that might be a problem. However, my PXE-boot install is now flying along.
Kirk Bocek
With PATA the device ID is based on location. Hdb is the primary slave (slave on first port). There doesn't have to be a hda.
Scott Silva wrote:
With PATA the device ID is based on location. Hdb is the primary slave (slave on first port). There doesn't have to be a hda.
I thought the point of master/slave in the IDE world was that the master was acting as the controller for the slave. If that's the case, how can you have a slave without a master?
On Wed, 2008-06-04 at 16:56 -0700, Kirk Bocek wrote:
Scott Silva wrote:
With PATA the device ID is based on location. Hdb is the primary slave (slave on first port). There doesn't have to be a hda.
I thought the point of master/slave in the IDE world was that the master was acting as the controller for the slave. If that's the case, how can you have a slave without a master?
It's not truly any relationship like that. It's just (in the old days) a device ID selected on the cable by jumpers on the drive. The "control" is nothing more than the IDE controller selecting either "0" or "1" device ID for commands and data. The drive with the matching ID responds while the other ignores.
In todays world, cable select might provide the ID assignment.
I'm not sure how "master" and "slave" came to be used in this scenario, unless it had to do with BIOS boot processes back in the old days.
<snip select stuff>
William L. Maltby wrote:
It's not truly any relationship like that. It's just (in the old days) a device ID selected on the cable by jumpers on the drive. The "control" is nothing more than the IDE controller selecting either "0" or "1" device ID for commands and data. The drive with the matching ID responds while the other ignores.
In todays world, cable select might provide the ID assignment.
I'm not sure how "master" and "slave" came to be used in this scenario, unless it had to do with BIOS boot processes back in the old days.
Well, right you are. Scroll down to "Master and Slave Clarification":
http://en.wikipedia.org/wiki/Integrated_Drive_Electronics
I had been laboring under the impression that the 'master' drive controlled both drives on a single cable. Now I've learned the truth just in time for SATA to take over. :)
On Thursday 05 June 2008 17:55:23 Kirk Bocek wrote:
William L. Maltby wrote:
It's not truly any relationship like that. It's just (in the old days) a device ID selected on the cable by jumpers on the drive. The "control" is nothing more than the IDE controller selecting either "0" or "1" device ID for commands and data. The drive with the matching ID responds while the other ignores.
In todays world, cable select might provide the ID assignment.
I'm not sure how "master" and "slave" came to be used in this scenario, unless it had to do with BIOS boot processes back in the old days.
Well, right you are. Scroll down to "Master and Slave Clarification":
http://en.wikipedia.org/wiki/Integrated_Drive_Electronics
I had been laboring under the impression that the 'master' drive controlled both drives on a single cable. Now I've learned the truth just in time for SATA to take over. :)
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi kirk Better late than never ;-) I got a draw full of old 10 - 40 Gb IDE hard drives and 4 old boxes with 333 - 550mhz cpu's. I'm never board. Got one with an old scsi sheet feed scanner. and isa modem set up as a fax / answer machine connected to my phone line at home. All bits begged or borrowed! John
-
John Bowden -
Karanbir Singh -
Kirk Bocek -
MHR -
Scott Silva -
William L. Maltby