Bug 322421

What process did you use to upgrade ? dvd, kickstart etc. Hardware or software
RAID ?

I used a cdrom boot 
selected the first option, "install upgrade ..."
then did a network, httpd upgrade

Doing linux software raid, two drives raid 1

I booted under fc7 rescue and it can find the system with no problems.   It just
won't boot.

I looked over the sysimage, and I can't find anything which seems to be a problem.

One additional piece of information.   This machine did start out as a fc5
machine which was upgraded to fc6 about 2 months ago.   Then it was upgraded to
fc7.   Now I do run weekly standard updates via yum.   So the fc6 was pretty
much up to date.

I have already had a problem where the fc6 stuff (in this case rpm) was more
current than the stuff that was loaded by fc7.   So the fc6 stuff was kept, but
fc7 needed its stuff.  Could this possibly be the problem here?

More additional information.   These are two ide (pata or however you want to
phrase it) drives.

Also just reran up to the point of selecting of the drives to upgrade the
upgrade process and it can still find the drives.   So it appears that the
problem is somewhere in the boot process.

There are two problems here; the first is that there's nothing prohibiting FC6
updates from being released with newer versions than their F7 counterparts.  The
second is that anaconda currently can't use multiple repos during upgrades. 
Both need to be rectified, but for the time being I'm going to treat this bug as
the former.

Bodhi (the system used to push updates for F7+) handles broken upgrade paths
properly.  The FC6 updates system, however, does not.  Since FC6 is going away
real soon, it's not worth the effort to fix this in the old system.

So, the problem then lies within the latter point of Comment #6.  Re-assigning
to anaconda.

But what can I do in the mean time to get this to work.

The machine I reported this on is a backup router, and has been out of service.
  I could reload this from scratch with fc7.  BUT I also have the primary router
to upgrade.   This is more problematic.   It would be a really major deal to
completely reload it.   And yes they have about the same hardware.

Re-assigning to anaconda guys.

Peter, do you happen to know which package is the culprit, so we can push a
newer version in F7 to hopefully resolve Ray's problem ?

The good news is that if you get something you think fixes the problem, this is
as I said a backup server, so it would be a case of "Oh Well I tried to avoid
this" if it totally messed things up and I did have to reload.   So I might make
a good tester for anything.

Well I needed to get on with this.   So I reloaded the system with fc7 from
scratch.   Everything worked great.   Now I have all the config files saves to I
have those back and active and it is working.

Now I still have had one additional bad run at doing a cdrom based upgrade to a
system.   This one was a shelf standby system so normally I would have just
don't a scratch load, but I wanted to test it.

This one was also a failure.   But  whole new error.   This one failed to do
something to the boot configuration, and so was still trying to load the old
kernel.   Forcing a load ot the new kernel made it work, but then I did a
scratch load of FC7.

There definitely seems to be a problem in the cdrom method of upgrading the
system from previous version to FC7.

If needed I could test on additional shelf systems we have around.   But what do
we need to test?

Incidentally do a web search on this upgrade method and you will find a rather
large body of people saying they are having the same kinds of problems.

Has there been any movement on getting the cdrom method of upgrades to work?

OK I have been working on this a little myself.

As I said I have some old trashable computers.   So I could load fc6 and they
upgrade it over and over again.

OK if you are running ide drives plain and without any lvm or raiding everything
works great.

If you are running software raid with the default raid level 0 and no lvm again
no problems.   On the other hand why in the world would someone default to raid
0.  But that is an opinion.   I always think of raid in terms of data integraty,
and raid 1 just gives you very unreliable but extra huge strage units.

NOW TO THE FAILURE MODES.   And I can now get this to be consistent. 
(Consistent is good right ;-) )

Install FC6 overrideing the default configuration.  Eliminate LVM and do
software RAID but RAID level 1 (mirroring)

The system starts the install and proceeds to the boot loader page.   You get
the message that it needs to install a fresh boot loader and informs you that
this is the default, BUT!!!! it defaults to do not do anything to the boot
loader.   If you take this default you are trashed and I can't find a way to
then get the system working (Why no option to reinstall the boot loader off of
the install disks ???)   If you override the default and select to install a new
boot loader configuration it will then load properly and boot fine.   THE
DEFAULT HERE NEEDS A SERIOUS FIX.

If you install fc6 and take the default lvm setup you get the above sequence.

If on the other hand you install FC6 and use lvm but override the default
configuration (put in a larger swap file and then setaside half of the lvm as
unassigned so it can be played with later which is something we frequently do)
then you are really screwed as I can't find a way to actually upgrade to FC7
without copying off the data and reformating and doing a scrach install and then
copying the data back on.   Not a very workable upgrade path. :-(   :-(   :-(

The install system actually does default to the proper load boot loader setting.
  But then it fails with the errors above 100% of the time.   If I were to guess
from looking at it it appears that the problem is that the lvm definition still
has the HD instead of the SD stuff in it.   As taking two scsi disks and doing
the same exact setup otehrwise does work.

Tried the same thing going fc6-fc8 with the same results, hoping that maybe the
fc7 stuff had a problem which had been fix in fc8.

Is this a documentation problem where I am using the wrong instructions, or is
this an intrinsic problem?

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Does this issue persist with Fedora 9?

I don't have those machines anymore.  Well I have upgraded all but 1 with a new
install than a scratch reconfiguration.  That one is the one I have reported as
possibly be related to bug 430836.   

Now it was doing it for fc9 beta