Lou Spironello wrote:
Dear Jim:
Please forgive me for not responding sooner. I began this reply the day
you sent me the message and got sidetracked.
That's alright, I have been wading through the current message load
regarding other problems like esd. So far, none of the other mentioned
problems effected my systems.
Thank you again for your lengthy, well thought out, consistent and
technically sound response!
Thanks!
I apologize if my responses were not clear. I beg you for great
forgiveness.
No need to apologize, my responses are somewhat vague when asking for help.
Again, all me methods I've used and you've suggested have been taken
because I've been under the assumption that anaconda saw remnants
of past lvm or raid devices based upon the docs in the installation guide
and I believe in the release notes.
Those that prepare the release notes have tough jobs. They also have
users, me included which do not read the content until they encounter
the problem and solution written up in the release notes.
I thoroughly read the article at www.issociate.de
<http://www.issociate.de>. I found a slew of pointers
which I can possibly use in the future and I tried to use some of the mdadm
command suggested there. however, since there are no physical
partitions associated
with the raid device /dev/md0 mdadm will not operate on that device.
Interesting, I assumed the raid information was kept within the device
used for raid. Raid sounds more complex than I thought it was with my
very limited knowledge of raid.
Moreover
the partitions originally associated with the device have been deleted.
I would think the information would be dynamically removed if the
partition had no reference regarding the raid or the user prompted as to
incomplete references for a raid array.
I've run find on my udev directories looking for "md" but nothing
appeared relative
to raid devices.
I have also noticed a complete md0 tree located in /sys/block/md0 and I
suspect
that anaconda might be reading that and thinking that an raid device exists.
re: the 4GB split on files.
I'm assuming that was mentioned with the intent to burn to a DVD.
I don't have a DVD burner nor a CD burner on my linux box. My cd
burner died a while back and I'm only using a CD reader. I only have
a CD burner on an older windows box.
Thanks for the info regarding the incremental label naming of partitions,
i.e. /usr1 etc.
They should work out better if you had to use pre-F7 kernels like some
postings referred to.
Re: the reference to the f7-updates.img.
it apparently found it across the net when I specified it
on the command line since anaconda prompted me for the IP address
of this local machine along with the gateway and dns which were both my
local
router. I'm assuming that since I didn't receive an error after that that
the f7-updates.img file was used but I'm only guessing.
I never used one of those images yet myself. I just recall some step
allowed updates to be selected during install.
Again please forgive me. The fstab I included in the previous e-mail
did not have label references for partitions on drive /dev/hdc or /dev/hdd even though
partition labels do exist for all parititions.
Well, I changed the physical device references for all partitions on
/dev/hdc and /dev/hdd,
neither of which have any OS software, and voila! I rebooted with the
rescue
CD and I eventually received the install / upgrade window! Hmm. I think
there should be some mention in anaconda as an informational message
or as an error message flagging that as a potential "non-install" issue.
It would be great for anaconda to provide such information as possible
causes of problems. If one knows they have an OS on their system that is
not recognized, maybe a manually enter information on other installed
but not detected OS versions would be useful.
The upgrade continued from there until it reached the
selinux-policy-targeted rpm at which point it appeared to have
stalled. I checked the drive light and apparently there was disk
activity and I assumed that selinux-policy-targeted was changing file
attributes or assembling policies for selinux, so I waited.
Good choice, SELinux restoring file content sometimes taks awhile to
complete. I almost aborted installs because of the delay but found
restorecon or a similarly named process active so waited.
I was
tempted to do a hard reset but I resisted. 1 1/2 hours had already
passed and the install was not finished yet. More than 2 hours later
and the install finally finished. The machine rebooted and I received
an error, in that it couldn't find my F7 install. So I rebooted again
and explicitly selected the F7 option from the grub boot menu (there
was only one other entry, that of the FC6) and the F7 boot continued
from there.
I recall hearing others encountering the fc6 kernel being removed but
the entry for the older kernel was not removed from the menu on earlier
postings. I assume this is a bug. I cannot recall if it was for xen
kernels or all kernel types that were effected by the bug.
I was then presented from pirut with over 975 upgrade
packages. So I spent most of Sunday wading through those. I'm now
checking through the package manager to ensure check for other
installs. I still have to wade through my rpm list for legacy fc6
rpms that F7 didn't remove.
I guess there is an ption for yum to --show-orphans. You might find this
a useful feature. On one of my upgraded systems I still had up2date
installed and nly removed it because of conflcts during upgrades. I
usually don'r remove orphans unless they cause problems during upgrade/
updates.
Thanks very much for your help.
No problem, I am glad that you finally were able to upgrd via the
installer. Enjoy F7, hopefully without a lot of problems now tht it is
installed.
Jim
Regards, Lou
--
That's the thing about people who think they hate computers. What they
really hate is lousy programmers.
- Larry Niven and Jerry Pournelle in "Oath of Fealty"
