Description of problem: While trying to install F12Beta in parallel of existing F8 installation, I chose to install GRUB in the first sector of F12 /boot partition. Instead of doing that, Anaconda destroyed the existing GRUB install and rendered the system unbootable. Version-Release number of selected component (if applicable): How reproducible: unknown Steps to Reproduce: 1. Install using the x86_64 DVD 2. create a new /boot partition and / LV 3. install GRUB to first sector of /boot partition Actual results: System doesn't boot after installation, only a blinking underline cursor is displayed. Expected results: System boots using the old GRUB and the F12 GRUB can be chainloaded after editing grub.conf Additional info: I have tried both F8 and F12 DVDs in rescue mode to restore booting, but neither of them works. Smolt info: http://www.smolts.org/client/show/?uuid=pub_b6451a8c-fbe5-48d9-a445-cb84f73a46ad
Where was the F8 grub installed to? MBR? Can you give us logs from that installation? (If you have access to the installed system using rescue CD - look for /mnt/sysimage/root/anaconda.log)
F8 grub is in MBR. There's no anaconda.log file in the F12 /root, only install.log and install.log.syslog. Do you want those files?
For F12, look in /mnt/sysimage/var/log/ for anaconda.log storage.log and program.log. Attach those if you can.
and /mnt/sysimage/boot/grub/device.map
Created attachment 366630 [details] anaconda.log
Created attachment 366631 [details] program.log
Created attachment 366632 [details] storage.log
Created attachment 366633 [details] device.map
Hmm the strange thing is that I see this in the program.log grub> root (hd1,6) Filesystem type is ext2fs, partition type 0x83 grub> install --stage2=/boot/grub/stage2 /grub/stage1 d (hd1,6) /grub/stage2 p (hd1,6)/grub/grub.conf This would suggest that GRUB was installed into the boot record of sdb7 so no modification to the MBR should have happened. When you run grub manually from rescue cd (just type grub) and try following commands what is the output? find /grub/stage2 find /boot/grub/stage2
(In reply to comment #9) > This would suggest that GRUB was installed into the boot record of sdb7 so no > modification to the MBR should have happened. It should have been written to 7th partition of the RAID 1 array, not just sdb7. > When you run grub manually from rescue cd (just type grub) and try following > commands what is the output? > > find /grub/stage2 > find /boot/grub/stage2 I restored the machine to pre-installation attempt state from an image backup, so I don't think those commands would return useful output.
Is the F8 grub really in MBR? Because if not, it is probably this bug #531745. I just can't see a way how we could have trashed MBR when the commands plainly state that the installation goes somewhere to extended partition.
Does this look like F8 grub?: # dd if=/dev/mapper/isw_bfghbfehhc_Volume0 bs=512 count=1 | hexdump -C 1+0 tietuetta sisään 1+0 tietuetta ulos 512 bytes (512 B) copied, 2,9707e-05 s, 17,2 MB/s 00000000 eb 48 90 d0 bc 00 7c 8e c0 8e d8 be 00 7c bf 00 |.H....|......|..| 00000010 06 b9 00 02 fc f3 a4 50 68 1c 06 cb fb b9 04 00 |.......Ph.......| 00000020 bd be 07 80 7e 00 00 7c 0b 0f 85 0e 01 83 c5 10 |....~..|........| 00000030 e2 f1 cd 18 88 56 00 55 c6 46 11 05 c6 46 03 02 |.....V.U.F...F..| 00000040 ff 00 00 20 01 00 00 00 00 02 fa 90 90 f6 c2 80 |... ............| 00000050 75 02 b2 80 ea 59 7c 00 00 31 c0 8e d8 8e d0 bc |u....Y|..1......| 00000060 00 20 fb a0 40 7c 3c ff 74 02 88 c2 52 be 7f 7d |. ..@|<.t...R..}| 00000070 e8 34 01 f6 c2 80 74 54 b4 41 bb aa 55 cd 13 5a |.4....tT.A..U..Z| 00000080 52 72 49 81 fb 55 aa 75 43 a0 41 7c 84 c0 75 05 |RrI..U.uC.A|..u.| 00000090 83 e1 01 74 37 66 8b 4c 10 be 05 7c c6 44 ff 01 |...t7f.L...|.D..| 000000a0 66 8b 1e 44 7c c7 04 10 00 c7 44 02 01 00 66 89 |f..D|.....D...f.| 000000b0 5c 08 c7 44 06 00 70 66 31 c0 89 44 04 66 89 44 |\..D..pf1..D.f.D| 000000c0 0c b4 42 cd 13 72 05 bb 00 70 eb 7d b4 08 cd 13 |..B..r...p.}....| 000000d0 73 0a f6 c2 80 0f 84 ea 00 e9 8d 00 be 05 7c c6 |s.............|.| 000000e0 44 ff 00 66 31 c0 88 f0 40 66 89 44 04 31 d2 88 |D..f1....1..| 000000f0 ca c1 e2 02 88 e8 88 f4 40 89 44 08 31 c0 88 d0 |........@.D.1...| 00000100 c0 e8 02 66 89 04 66 a1 44 7c 66 31 d2 66 f7 34 |...f..f.D|f1.f.4| 00000110 88 54 0a 66 31 d2 66 f7 74 04 88 54 0b 89 44 0c |.T.f1.f.t..T..D.| 00000120 3b 44 08 7d 3c 8a 54 0d c0 e2 06 8a 4c 0a fe c1 |;D.}<.T.....L...| 00000130 08 d1 8a 6c 0c 5a 8a 74 0b bb 00 70 8e c3 31 db |...l.Z.t...p..1.| 00000140 b8 01 02 cd 13 72 2a 8c c3 8e 06 48 7c 60 1e b9 |.....r*....H|`..| 00000150 00 01 8e db 31 f6 31 ff fc f3 a5 1f 61 ff 26 42 |....1.1.....a.&B| 00000160 7c be 85 7d e8 40 00 eb 0e be 8a 7d e8 38 00 eb ||..}.@.....}.8..| 00000170 06 be 94 7d e8 30 00 be 99 7d e8 2a 00 eb fe 47 |...}.0...}.*...G| 00000180 52 55 42 20 00 47 65 6f 6d 00 48 61 72 64 20 44 |RUB .Geom.Hard D| 00000190 69 73 6b 00 52 65 61 64 00 20 45 72 72 6f 72 00 |isk.Read. Error.| 000001a0 bb 01 00 b4 0e cd 10 ac 3c 00 75 f4 c3 00 00 00 |........<.u.....| 000001b0 00 00 00 00 00 00 00 00 ed ee 27 1c 00 00 80 01 |..........'.....| 000001c0 01 00 07 fe ff ff 3f 00 00 00 00 34 80 0c 00 00 |......?....4....| 000001d0 c1 ff 83 fe ff ff 3f 34 80 0c cd 2f 03 00 00 fe |......?4.../....| 000001e0 ff ff 8e fe ff ff 0c 64 83 0c 7e f5 7f 0c 00 00 |.......d..~.....| 000001f0 c1 ff 05 7e e5 ff 8a 59 03 19 1f ce 20 38 55 aa |...~...Y.... 8U.| 00000200
It does indeed look like GRUB... But then, with untouched MBR, at least stage1 of GRUB should have loaded and told you that something is broken. I'll look through the logs again, but without the corrupted system, I have probably no way of determining what exactly went wrong..
(In reply to comment #13) > It does indeed look like GRUB... But then, with untouched MBR, at least stage1 > of GRUB should have loaded and told you that something is broken. Then obviously the MBR wasn't "untouched" after F12beta installation.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I tried again with F12 final with same results: the system doesn't boot after installation. I think I found the cause, active/boot flag had been set for the F12 /boot partition (/dev/mapper/isw_bfghbfehhc_Volume0p7) and the Windows partition flag had been cleared. I thought GRUB ignores the boot flag so I don't quite understand (a) why does the installer change the boot flags or (b) why does this prevent the system from booting, but clearing the partition 7 boot flag and setting it back on for partition 1 restores the system to bootable condition. Apparently I'm not the only one whose system has been rendered unbootable by this bug: http://forums.fedoraforum.org/showthread.php?t=234875
We took a look at the situation again and we think we know why this prevents the system from booting. It seems that some versions if ISW (bios-emulated RAID systems) actually intercept the normal booting sequence and refuse to boot if there is no active boot flag in the main partition table (eg. on the first four master partitions). We will prepare a patch that won't change the boot flag if there already is one present or if it would be added to logical partition in msdos part table. Does that sound reasonable? PS: Sorry for the delays, but it took us a while to realize what is happening.. intercepting normal boot by BIOS is not something we encounter every day.
Hi, I confirm the behaviour of F12 described by Markku Kolkka it his comment#16: I installed Fedora-12-x86_64 and its grub in a logical partition sda14. Then when I booted, the system displayed "DISK BOOT FAILURE, INSERT SYSTEM DISK AND PRESS ENTER" instead of starting Vista Boot Loader as before. Fortunately I could run Gparted from a Parted Magic Live USB I to see what happened: as uncredible as this may appear, the boot flag was on the logical partion sda14, no more the first primary partition Vista. Moreover, the extended partition had been shortened to the end of sda14, instead of reaching the end of the disk as it was before. I have reset the boot flag on the first primary partition again, that allowed me to run Vista Boot Loader and run EasyBCD to declare the Linux F12 entry. F12 now runs. Notice before installation sda14 was NTFS formatted and as F12 setup did not propose to reformat it to ext4, I did it under Gparted in Ubuntu. I also experienced Vista that going to a blue or black screen at boot time when there is a logical partition starting beyond the boundary of exactly one TiB, even if it is aligned on a MiB boundary or/and on a cylinder. I'm not so far to suppose that the Bios may be responsible for this, as this system was originally shipped with a Western Digital 640 GB disk that I have replaced by a Seagate 1500 GB. Then perhaps F12 could also be upset by this Bios ? The Bios is : Phoenix - Award WorkstationBIOS v6.00PG, An energy Star Ally V.R01A4Aug.14.2008 The partitions are (sorry in french) [root@machin jer]# fdisk -l Disque /dev/sda: 1500.3 Go, 1500301910016 octets 255 têtes, 63 secteurs/piste, 182401 cylindres Unités = cylindres de 16065 * 512 = 8225280 octets Identifiant de disque : 0x3ac031da Périphérique Amorce Début Fin Blocs Id Système /dev/sda1 * 1 4463 35839996 7 HPFS/NTFS /dev/sda2 4463 9253 38482944 7 HPFS/NTFS /dev/sda3 9254 116156 858698347+ f W95 Etendue (LBA) /dev/sda5 9254 10655 11261533+ 7 HPFS/NTFS /dev/sda6 10656 14860 33776631 7 HPFS/NTFS /dev/sda7 14861 110472 768003358+ 7 HPFS/NTFS /dev/sda8 110473 110485 104391 7 HPFS/NTFS /dev/sda9 110486 110498 104391 7 HPFS/NTFS /dev/sda10 110499 110504 48163+ 7 HPFS/NTFS /dev/sda11 110505 111809 10482381 82 Linux swap / Solaris /dev/sda12 111810 112853 8385898+ 83 Linux /dev/sda13 112854 114263 11325793+ 83 Linux /dev/sda14 114264 116156 15205491 83 Linux
(In reply to comment #18) > I have reset the boot flag on the first primary partition again, that allowed > me to run Vista Boot Loader and run EasyBCD to declare the Linux F12 entry. F12 > now runs. > Thanks for investigating this, the unwanted behavior of removing the boot flag from windows partitions has been fixed for F-13, see: http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=0c0559f6f187815521364cb6d5118ad9faf24cc9 Marking this as a duplicate of 533658 based on this analysis of the problem. *** This bug has been marked as a duplicate of bug 533658 ***