Bug 530894

Summary: Existing GRUB trashed when installing GRUB to /boot
Product: [Fedora] Fedora Reporter: Markku Kolkka <markku.kolkka>
Component: anacondaAssignee: Martin Sivák <msivak>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 12CC: atriallogin, hdegoede, jvonau3, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-26 06:31:48 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
anaconda.log
none
program.log
none
storage.log
none
device.map none

Description Markku Kolkka 2009-10-25 17:54:45 EDT
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
Comment 1 Martin Sivák 2009-10-26 10:58:50 EDT
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)
Comment 2 Markku Kolkka 2009-10-28 05:07:25 EDT
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?
Comment 3 Jerry Vonau 2009-10-28 21:08:38 EDT
For F12, look in /mnt/sysimage/var/log/ for anaconda.log storage.log and program.log. Attach those if you can.
Comment 4 Jerry Vonau 2009-10-28 21:25:11 EDT
and /mnt/sysimage/boot/grub/device.map
Comment 5 Markku Kolkka 2009-10-29 10:40:50 EDT
Created attachment 366630 [details]
anaconda.log
Comment 6 Markku Kolkka 2009-10-29 10:41:24 EDT
Created attachment 366631 [details]
program.log
Comment 7 Markku Kolkka 2009-10-29 10:41:58 EDT
Created attachment 366632 [details]
storage.log
Comment 8 Markku Kolkka 2009-10-29 10:42:25 EDT
Created attachment 366633 [details]
device.map
Comment 9 Martin Sivák 2009-11-03 07:02:23 EST
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
Comment 10 Markku Kolkka 2009-11-03 08:03:09 EST
(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.
Comment 11 Martin Sivák 2009-11-03 08:36:07 EST
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.
Comment 12 Markku Kolkka 2009-11-03 08:59:27 EST
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...@f.D.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
Comment 13 Martin Sivák 2009-11-03 10:25:34 EST
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..
Comment 14 Markku Kolkka 2009-11-04 04:25:56 EST
(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.
Comment 15 Bug Zapper 2009-11-16 09:19:00 EST
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
Comment 16 Markku Kolkka 2009-11-25 06:19:15 EST
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
Comment 17 Martin Sivák 2009-11-25 08:52:36 EST
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.
Comment 18 Jerem 2009-11-25 17:02:13 EST
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
Comment 19 Hans de Goede 2009-11-26 06:31:48 EST
(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 ***