SL6.2 install fails, SL Installation Problems

[SLexist]

I attempted to install SL6.2, but it failed during the install with an error concerning an internal python bug; a second attempt seemed to complete, but the host would no longer boot.

My environment:
Dual core Athlon II 265 with 4GB memory.
RAID1 file systems (except swap) built on 3 physical SATA drives (2 + 1 spare)
Four partitions: swap (non-RAID), target 25GB RAID1 fs, CentOS6.2 25GB RAID1 fs, LVM2 410GB PV with various LV file systems including one for VirtualBox VMs
8GB USB drive with SL-62-i386-2012-02-16-LiveCD.iso created with native SL6.2 USB live CD creator

Full background: before attempting an actual install, I decided to try it out running under VirtualBox 4.1.14. That install went pretty much without a hitch (other than being a little slower than I expected), and it booted up after the install without a problem. I played with it a little bit, and after having read the praises of SL, I felt it was time to do the install for real. I waited until Saturday to give myself plenty of time in case issues arose. That turned out to be good thinking.

I built a USB Live CD from the SL6.2 CD image using the native SL6.2 tool from inside the VM. I don't see why building the Live CD from inside the VM should present a problem, but I am open to any criticism of this approach. I just thought that was the best way to do it given my environment. Mainly I was trying to avoid hunting down a blank CD... (lazy unix people...hmmmph!)

The first attempt to install to the "target" (2nd) partition of the host (not VirtualBox, not VM!) got through to the point just after I selected the time zone. It failed with a message about a python internal failure in what I guess is the anaconda scripts. I attempted the install a second time; this time the script did not break even though I performed all the same steps.

However, when the install completed, my machine would not reboot. It seemed like grub was not correctly installed. (I did not see the grub menu, but that in itself may not be a worry since by default, grub's menu can be suppressed on boot.) The machine continually rebooted to the BIOS after the POST routine and a pause, which I presume to be the time while the bootloader is starting to execute.

Some research shows that another user on this forum ran into the first problem (see http://scientificlinuxforum.org/index.php?showtopic=871). It turns out that the install script may fail if you select a hostname/domainname other than the default. I don't see why that should happen, and I would think that kind of error would have been teased out of the release long ago by sheer number of users downloading and installing it. It is also quite reasonable to override the host/domain name since that would be a typical use in a lot of production environments.

I ended up pulling out my LinuxRescueCD and using that to re-install grub. After that, my CentOS install came up again. Whew. Thank goodness for LinuxRescueCD! I never start a host install without a recent copy nearby, exactly for this reason. There was no real data loss, although I may have lost a few more of my precious hairs still on my head.

I suppose I should try burning an old-fashioned CD from the ISO image and try it again. I just don't want to go through "losing" the whole system again. I know how to get it back, but I'd really prefer not to do things that way. So if anyone is pretty sure they know why grub didn't install, I'd appreciate your sharing it. Thanks. (And I acknowledge this could be pilot error.)

[zxq9]

I've had a few issues with Anaconda from LiveCD installs myself, but lately haven't messed with it so I'm not sure what could be causing your problems. As far as general installation guidance, though, some of the SL iso releases have had a few issues on installation (which is ironic, because the systems, once installed, tend to behave themselves quite well, which is opposite of CentOS where the installers tend to be flawless and the system has occasional issues).

RPM being what it is, though, I've found the simple answer to be PXE booting any stock install image of a version that has a well-tested installer (I think 6.1 is my most recent PXE image) and then upgrading from there. In other words, if 6.2 is giving you trouble, try 6.1 or even 6.0, and then push your packages forward after install. You can also keep a local repo with all the latest stuff, and install that repo as an extra at install time and get your upgrade that way. SL upgrades have been phenomenally robust between minor versions, which is pretty amazing. Also note that I've only got EPEL and a private repo installed as extras, so I don't know what other repos or combinations of repos will break this method -- I'm certain there is some toxic combination possible, there always is.

I didn't address grub directly because I'm not clear on whether you're grub is in a VM or actually on the disk, and I have almost no experience troubleshooting VMs. When grub fails to get moving I tend to suspect device label issues before anything else, and sometimes this can be difficult to fix if you're totally in the dark about what an arbitrary block device's name should be.

[SLexist]

QUOTE (zxq9 @ May 13 2012, 12:35 AM)

I've had a few issues with Anaconda from LiveCD installs myself, but lately haven't messed with it so I'm not sure what could be causing your problems. As far as general installation guidance, though, some of the SL iso releases have had a few issues on installation (which is ironic, because the systems, once installed, tend to behave themselves quite well, which is opposite of CentOS where the installers tend to be flawless and the system has occasional issues).

The problem I experienced with anaconda appears to be intermittent. The first time, I got the traceback from python indicating a problem; the second time, I did not get that error. I find it rather frightening to experience such random behavior, especially given this is booting off a completely solid-state device! That is, I've never had any problems with this USB device, or any other, in terms of data integrity. But something is wiggling around somehow from attempt to attempt...

QUOTE

RPM being what it is, though, I've found the simple answer to be PXE booting any stock install image of a version that has a well-tested installer (I think 6.1 is my most recent PXE image) and then upgrading from there. In other words, if 6.2 is giving you trouble, try 6.1 or even 6.0, and then push your packages forward after install.

I'm a bit confused here. PXE is a medium, like USB or CD, whereas rolling a release after successful install is a different matter. What does the medium used have to do with the release to be installed?
Are you, rather, suggesting installing 6.1 on my USB drive, then rolling IT forward? Or are you saying that the ability to roll forward is dependent on using PXE only?

QUOTE

You can also keep a local repo with all the latest stuff, and install that repo as an extra at install time and get your upgrade that way. SL upgrades have been phenomenally robust between minor versions, which is pretty amazing. Also note that I've only got EPEL and a private repo installed as extras, so I don't know what other repos or combinations of repos will break this method -- I'm certain there is some toxic combination possible, there always is.

Why not get the latest from the official repo? It will be more up to date, not take up space on the local disk, and be less maintenance. Not sure why I would want to do this at all. Especially since grub was the whole issue here.

QUOTE

I didn't address grub directly because I'm not clear on whether you're grub is in a VM or actually on the disk, and I have almost no experience troubleshooting VMs. When grub fails to get moving I tend to suspect device label issues before anything else, and sometimes this can be difficult to fix if you're totally in the dark about what an arbitrary block device's name should be.

If you carefully read my OP, you will see that I only created the boot USB within a VM. I then stated I used that USB drive to install to the physical host. But thanks for your help.