Created attachment 501451 [details] Output of lspci -vvv Description of problem: Screen goes blank when rebooting after FC14 'preupgrade' to upgrade system to FC15. Nothing more happens. System appears frozen and has to be rebooted back to FC14. Ie: Upgrade fails. Version-Release number of selected component (if applicable): preupgrade-1.1.9-1.fc14.noarch Kernel 2.6.35.12-90.fc14.i686.PAE The system is completely up to date as of 28 May 2011. How reproducible: This always happens. Removing /boot/upgrade and the grub.conf entry has no effect. They are re-created with the same result. Steps to Reproduce: 1. Login as root. 2. Execute 'preupgrade'. 3. When system reboots, select "Upgrade to Fedora 15 (Lovelock)" Actual results: Packages are downloaded and preupgrade image/kernel added to Grub setup as expected. When system reboots grub option to upgrade is present. Selecting this does not boot as expected. The screen goes blank. Cursor appears top left corner. Nothing more happens. System appears frozen and has to be rebooted. Ie: Upgrade fails. Expected results: If working as expected the system should reboot into Anaconda and continue upgrade. This has worked for me on 2 other systems. Additional info: System being upgraded: FC14 2.6.35.12-90.fc14.i686.PAE OCZ Vertex 2 SSD with 2 partitions: Device Boot Start End Blocks Id System /dev/sda1 * 2048 1026047 512000 83 Linux /dev/sda2 1026048 117231407 58102680 83 Linux /dev/sda1 is mounted on / /dev/sda2 is mounted on /boot No LVM in use. See lspci -vvv attachment for further hardware config.
Same here. [root@localhost ~]# fdisk -l Disco /dev/sda: 500.1 GB, 500107862016 byte 255 testine, 63 settori/tracce, 60801 cilindri, totale 976773168 settori Unità = settori di 1 * 512 = 512 byte Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Identificativo disco: 0x00000147 Dispositivo Boot Start End Blocks Id System /dev/sda1 * 2048 1026047 512000 83 Linux /dev/sda2 1026048 976773119 487873536 8e Linux LVM Disco /dev/sdb: 122.9 GB, 122942324736 byte 255 testine, 63 settori/tracce, 14946 cilindri, totale 240121728 settori Unità = settori di 1 * 512 = 512 byte Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Identificativo disco: 0xef7fef7f Dispositivo Boot Start End Blocks Id System /dev/sdb1 * 63 240091424 120045681 7 HPFS/NTFS Disco /dev/dm-0: 53.7 GB, 53687091200 byte 255 testine, 63 settori/tracce, 6527 cilindri, totale 104857600 settori Unità = settori di 1 * 512 = 512 byte Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Identificativo disco: 0x00000000 Il disco /dev/dm-0 non contiene una tabella delle partizioni valida Disco /dev/dm-1: 6308 MB, 6308233216 byte 255 testine, 63 settori/tracce, 766 cilindri, totale 12320768 settori Unità = settori di 1 * 512 = 512 byte Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Identificativo disco: 0x00000000 Il disco /dev/dm-1 non contiene una tabella delle partizioni valida Disco /dev/dm-2: 439.6 GB, 439563059200 byte 255 testine, 63 settori/tracce, 53440 cilindri, totale 858521600 settori Unità = settori di 1 * 512 = 512 byte Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Identificativo disco: 0x00000000 Il disco /dev/dm-2 non contiene una tabella delle partizioni valida
Created attachment 501745 [details] lspci -vvv
My system hung for several minutes with a blank screen and blinking cursor... but then it came back to life and completed the install. I've seen other reports of similar several-minute recoverable hangs (http://forum.nginx.org/read.php?30,201464,201475). - Mike
I'm seeing an apparently similar problem (i.e. reboots hangs with a blinking cursor). It's not a several-minute hang (not unless overnight counts as several minutes). Actually, I think grub.conf is hosed (and perhaps initrd.img as well). It's also not a once-off failure, I've gone round the preupgrade merry-go-round three times, all with the same result. What preupgrade initially gave me in boot.conf: title Upgrade to Fedora 15 (Lovelock) kernel /upgrade/vmlinuz preupgrade repo=hd::/var/cache/yum/preupgrade ks=hd:UUID=f4733b9e-82f3-4b66-b027-8e0251ea43eb:/upgrade/ks.cfg initrd /upgrade/initrd.img This looks highly suspect, so I tried adding a root command: title Upgrade to Fedora 15 (Lovelock) root (hd0,0) kernel /upgrade/vmlinuz preupgrade repo=hd::/var/cache/yum/preupgrade ks=hd:UUID=f4733b9e-82f3-4b66-b027-8e0251ea43eb:/upgrade/ks.cfg initrd /upgrade/initrd.img same result. The hd:: looked a little suspicious to me (that is, I can't see where the system would find out that a particular lv was hd::/), so I tried working by analogy with my previous F14 boot line (I'm probably missing something here, but what the heck): title Upgrade to Fedora 15 (Lovelock) root (hd0,0) kernel /upgrade/vmlinuz preupgrade repo=/dev/mapper/vg_bobslinux-lv_root/var/cache/yum/preupgrade rd_LVM_LV=vg_bobslinux/lv_root ks=hd:UUID=f4733b9e-82f3-4b66-b027-8e0251ea43eb:/upgrade/ks.cfg initrd /upgrade/initrd.img Anyway, no joy. I also tried inputting the commands directly into grub as per the wiki: http://fedoraproject.org/wiki/PreUpgrade root(hd0,0) (worked fine) kernel /upgrade/vmlinuz (worked fine) initrd /upgrade/initrd.img (hung) So it looks like there might also be a problem with the initrd.img (or else with the documentation in the wiki). By the way, if anyone reading this has write access to the wiki, it would be great if you could correct the paths on the preupgrade page - /boot is repeatedly included in the paths, but I'm pretty sure it should not be there, root is not changed to / until after grub has completed. df -a Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/vg_bobslinux-lv_root 10384688 1918972 8360232 19% / proc 0 0 0 - /proc sysfs 0 0 0 - /sys devpts 0 0 0 - /dev/pts tmpfs 254404 272 254132 1% /dev/shm /dev/sda1 495844 165595 304649 36% /boot /dev/mapper/vg_bobslinux-lv_home 27867324 4508200 21943548 18% /home /dev/mapper/vg_bobslinux-lv_tmp 5063712 141248 4665236 3% /tmp /dev/mapper/vg_bobslinux-lv_usr 10095152 2451316 7131020 26% /usr /dev/mapper/vg_bobsextras-bobwin 51606140 48418828 565872 99% /bobwin /dev/mapper/vg_bobsextras-vbox 51606140 1078584 47906116 3% /VBOX /dev/mapper/vg_bobsextras-lv_hm 82569904 1222360 77153240 2% /tmp_hm none 0 0 0 - /proc/sys/fs/binfmt_misc fusectl 0 0 0 - /sys/fs/fuse/connections gvfs-fuse-daemon 0 0 0 - /home/rim/.gvfs Possibly relevant other info: /dev/sda is an ATA drive vg_bobslinux has a single PV which resides on /dev/sda2
I can confirm this here, the system just hangs with a blinking cursor instead of booting into anaconda.
(In reply to comment #5) > I can confirm this here, the system just hangs with a blinking cursor instead > of booting into anaconda. I take that back ... waiting for a bit did the trick ... anaconda started and sucessfully completed the upgrade.
@adel How long did you wait for it to come back?
(In reply to comment #7) > @adel How long did you wait for it to come back? ~ 15 minutes
Hmmmm... well, I just tried again and left the machine unattended for around 25 minutes. When I came back Anaconda had indeed booted and run but there was a "FIXME" error on the screen. Nevertheless, on system reboot I now have FC15. Not the best upgrade experience, but it seems to have worked.
It seems there may be two separate issues mixed up here. In some cases, it is just a matter of waiting long enough (it seems like a reasonable rule of thumb that 1 hour is required, if you didn't wait 1 hour, probably it wasn't long enough). However in my case, after seeing this part of the discussion, I waited 24 hours. Still no joy. Of course, it could be that the time required depends on disk speed, and with my ATA drives the required time is over 24 hours. I will restart the machine on Monday and leave for three or four days, just to make sure. Meantime, is there any other useful information I could supply to assist with debugging?
Well it did eventually come back, however, it had a popup error saying it could not mount /dev/mapper/via_... at /home (i have a dmraid volume mounted at /home) and said it was a fatal error, hit ok to reboot. So, not blinking cursor, but no luck on upgrade. Looking briefly back at the run of preupgrade this also showed on the console (could be unrelated): Probing devices to guess BIOS drives. This may take a long time. Unknown partition table signature. Unknown partition table signature. I'm going to try and unmount the dmraid volume and then run preupgrade, upgrade and mount again when i get to the other side, and see if that works.
It turns out my problem was bug 707481. I didn't discover this till now, because the error message on the screen only appears for about 1 minute around 25 minutes after reboot starts, then returns to a blank screen. This time, I just happened to be looking at the right time...
So I took /dev/mapper/via... out of the fstab, ran preupgrade. it successfully installed rebooted and upgraded. Then I manually added /dev/mapper/via... to the fstab and mounted by hand, and that worked as well. I then proceeded to reboot with /dev/mapper/via... in the fstab, and the reboot hung. So not really fixed.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. 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 '15' 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 15 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