In upgraded fro fc6 to fc7. I am using a raid1 to feed a lvm system. The system now kernel panics with device-mapper: table 253:0: mirror: Device lookup failure
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