|
Red Hat Bugzilla – Full Text Bug Listing |
| Summary: | "Upgrade root not found" when using preupgrade to upgrade from Fedora 14 to Fedora 15 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Lei Zhou <lzhou5> | ||||||||||||
| Component: | preupgrade | Assignee: | Richard Hughes <richard> | ||||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||
| Priority: | unspecified | ||||||||||||||
| Version: | 14 | CC: | anton, joel_rees, maurizio.antillon, richard | ||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | Unspecified | ||||||||||||||
| OS: | Unspecified | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | Environment: | ||||||||||||||
| Last Closed: | 2012-08-16 11:19:16 EDT | Type: | --- | ||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||
| Documentation: | --- | CRM: | |||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
| Cloudforms Team: | --- | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Lei Zhou
2011-05-25 16:02:59 EDT
Created attachment 500931 [details]
dmesg
the last a few lines regarding /dev/dm-0 was the result of hand mounting.
[ 233.835829] EXT3-fs (dm-0): using internal journal
[ 233.835841] EXT3-fs (dm-0): mounted filesystem with ordered data mode
Created attachment 500932 [details]
program.log
The following ERRORs are found in the program.log
program.log:19:22:27,758 ERR program: mount: special device /var/cache/yum/preupgrade does not exist
program.log:19:22:42,807 ERR program: dumpe2fs 1.41.14 (22-Dec-2010)
program.log:19:22:42,875 ERR program: dumpe2fs 1.41.14 (22-Dec-2010)
program.log:19:22:42,907 ERR program: resize2fs 1.41.14 (22-Dec-2010)
program.log:19:22:45,766 ERR program: dumpe2fs 1.41.14 (22-Dec-2010)
program.log:19:22:45,767 ERR program: Journal superblock magic number invalid!
program.log:19:22:45,834 ERR program: dumpe2fs 1.41.14 (22-Dec-2010)
program.log:19:22:45,834 ERR program: Journal superblock magic number invalid!
program.log:19:22:45,868 ERR program: resize2fs 1.41.14 (22-Dec-2010)
program.log:19:22:46,945 ERR program: mdadm: stopped /dev/md0
program.log:19:22:48,510 ERR program: mdadm: /dev/md0 has been started with 2 drives.
program.log:19:22:48,993 ERR program: mount: wrong fs type, bad option, bad superblock on /dev/md0,
program.log:19:22:49,307 ERR program: mdadm: stopped /dev/md0
storage.log:19:22:47,367 ERR storage: failed to remove /etc/mdadm.conf: [Errno 2] No such file or directory: '/etc/mdadm.conf'
storage.log:19:22:47,369 ERR storage: failed to remove /etc/multipath.conf: [Errno 2] No such file or directory: '/etc/multipath.conf'
syslog:19:22:21,0 ERR udevd-work: device node '/dev/rtc' already exists, link to '/dev/rtc0' will not overwrite it
syslog:19:22:23,0 ERR udevd-work: device node '/dev/rtc' already exists, link to '/dev/rtc0' will not overwrite it
syslog:19:22:24,0 ERR NetworkManager: <error> [1306351345.912] [nm-session-monitor.c:349] nm_session_monitor_init(): Error loading /var/run/ConsoleKit/database: Error statting file /var/run/ConsoleKit/database: No such file or directory
syslog:19:22:25,0 ERR NetworkManager: <error> [1306351345.61871] [nm-device-ethernet.c:753] real_update_permanent_hw_address(): (p3p1): unable to read permanent MAC address (error 0)
syslog:19:22:48,992 ERR kernel:[ 71.156716] EXT4-fs (md0): no journal found
The first line implies that the upgrade rpms on /mnt/sysimage/var/cache/yum/preupgrade could not be found. This setting is in /boot/grub/grub.conf. I am testing about this.
It is weird that anaconda tried to mount /dev/md0, which was the RAID1 for data and should not be involved in upgrading. I will try disable/remove it to see if it will help.
Created attachment 500933 [details]
storage.log
Two look irrelevant errors:
19:22:47,367 ERR storage: failed to remove /etc/mdadm.conf: [Errno 2] No such file or directory: '/etc/mdadm.conf'
19:22:47,369 ERR storage: failed to remove /etc/multipath.conf: [Errno 2] No such file or directory: '/etc/multipath.conf'
Created attachment 500934 [details]
syslog
syslog
Proven that even have the soft raid drives physically removed, this bug is still reproduced.
Proven that even specify UUID in /boot/grub/grub.cfg as of:
title Upgrade to Fedora 15 (Lovelock)
kernel /upgrade/vmlinuz preupgrade repo=hd:UUID=ffeb3019-5c76-488b-b277-1ea36db95cd6:/var/cache/yum/preupgrade
ks=hd:UUID=6e6af18a-132a-4190-82fe-306d4272f5d6:/upgrade/ks.cfg
initrd /upgrade/initrd.img
this bug is still reproduced.
Even if you do not have a way to fix this, it is very appreciated to NOT allow anaconda to "Exit" after this error. A "retry" or "force continue" will be very helpful since the lvms can be hand mounted to rightful places. My attempts of work arounds resulted in vain. If I do not hand mount, it does not mount, and break. If I hand mount, it attempts to mount but cannot since "already mounted"/"mount point busy" and break. Reading all history of this since FC2, I'd say this is historical. To no longer use lvm as installation default since Fedora 15 is a wise move. The troubles LVM made are way more than the convenience it provided. Nevertheless I will just dd the / to a new HD without lvm and have this issue killed for all. Proven that this bug does not affect systems with / on soft RAID1 drives. For a virtual system, I have a / on a very complex RAID6, for testing purpose. This bug prevented it from upgrading. However, by applying %pre mdadm -A -s %end in /boot/upgrade/ks.cfg the preupgrading worked normally. Interesting. I'd retest this with lvm. Why this trick works for soft RAID but not for lvm? hit the same issue today while tried upgrade to f16beta. This also happens to me with preupgrade F15 -> F16 Beta. F15 installed on LVM (have been on LVM since FC6). I'm not in a position to migrate off LVM at the moment, so it looks like I'm unable to upgrade. Actually, my issue was related to Bug 748119. I had to copy /var/lib/rpm/* to the root LV before anaconda picked it up. Getting the same dialog (but in Japanese). preupgrade 15 to 16. Downloaded 3.5 Gb of packages. (Took 10 hours.) Rebooted to debian, did a grub configuration there and found the upgrade kernel for Fedora, congigured the grub on that disk to boot the Fedora kernel on the disk with Fedora. (I do this stupid trick every time I get a new kernel for Fedora.) Rebooted and started the upgrade process, went to scanning for storage devices. Then the message, as given in the title for this bug. System structure: First disk is an 80 G disk with (currently) Debian Squeeze. BIOS is set to boot this disk. Second disk is a 160 G disk with Fedora. I have installed Grub to the boot sector of this disk but it does not find Debian, so I don't use it. Also, Debian's grub2 does not successfully chain to Fedora on this disk. (Grub2 seems to assume chaining is only for MSWindblows? Something about BSD, but it does not successfully chain to openBSD, either, IIRC.) So I have to boot Debian and do a grub-update (or was it update-grub?) there, to find Fedora's kernel and add a direct reference to it. root is in a primary DOS type partition on the second drive, as is /boot. The rest of the system is in LVM. (Why can't we do labels like the BSDs, and just get ourselves free of the entire DOS primary/extended partition junk? Well, EUFI or whatever is going to "fix" that, too? Baloney.) (I have a third drive I'm using mostly for backup, but other than being unable to boot or chain that drive unless it's hung on the secondary channel with the second drive, it has no effect on the boot process.) (Direct booting a foreign kernel is a serious bug in grub, but that's a related-but-separate topic. Grub should default to chaining any multiboot, and chaining needs to be fixed in grub2. The reason for that is, for example, Debian's grub has no way of knowing that the kernel in the Fedora system has been updated until I boot Debian.) (Microsoft and Intel seem to have successfully re-directed all the productive engineers in the free/open-source movement in so many directions as to significantly reduce the technological threat, while they attack in the courts. We do ourselves no favors chasing their dreams.) My next step is to try yum upgrade or just burn a netinstall CD and abandon the cached packages that took all day to download. I'm more and more inclined, though, to let my next step be to move Debian in as my main OS and bring openBSD back as my rescue OS. Too much imitating MSWindows going on here. This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |