[SOLVED] FEdora 17 Bootloader Problem! I want have Fedora but it doesn't want to me!

[bakunin]

Okay.
I have a brand new Asus laptop. Asus n56vm. It has 1TB of harddisk. My disk was GPT when I bought it. I converted to MBR with windows convert mbr via DISKPART. Then installed Fedora 17 with xfce from DVD. When finishing installation it cannot installed bootloader!

I tried;
chroot /mnt/sysimage
grub2-mkconfig -o bind /boot/grub2/grub.cfg
grub2-install --force --recheck /dev/sda

Fedora Boys! I want to use it! I have no problem with any other distros about installing lilo or grub! What's the matter with Fedora?

[PabloEsc]

Why do You try do it by hand ?
Installer does it so let it install grub for you.

[bakunin]

Originally Posted by PabloEsc

Why do You try do it by hand ?
Installer does it so let it install grub for you.

I already let it installer. It gave me error. "There was an error installing the bootloader. The system may not be bootable "

[PabloEsc]

What is Your partition layout ?

[bakunin]

LVM
/lvm1 /root
/lvm2 /home
/lvm3 swap

/dev/sda
/dev/sda1 /boot 500mb
/dev/sda2 500000 mb lvm
/dev/sda3 500000 mb unlocalated for windows 7

[PabloEsc]

Setup seems ok. I've read that problem may be because of no not allocated space at the beginning of the disk.
Do commands which You've already tried :
grub2-mkconfig -o bind /boot/grub2/grub.cfg
grub2-install --force --recheck /dev/sda
result in any output. If so please, post them here

[weitjong]

I can think of one reason why Anaconda failed to install the Grub2 bootloader in the first place and also your subsequent failures to install Grub2 manually. Of course this is just my speculation. I believe it is due to your disk was originally using GPT partition table. It may originally have the first partition starts at low sector number (say sector 40 or 63). This is fine for GPT disk in a system booted with UEFI mode. But when you converted the disk from GPT to MSDOS partition table, you may face a problem to use the disk in the legacy BIOS mode. In the legacy BIOS mode, the bootloader resides in the MBR (the first sector). However, as Grub2 is too big to fit there, it usually takes the space between the MBR and first partition. But since your first partition starts at low sector number, the space in between is not enough for Grub2's core image.

There are two ways you can fix the problem:
1. (ALL DATA LOST) Repartition your disk using parted or gparted. Erase all the partitions and recreate the first partition from scratch. It should start the first partition at sector 2048, so you will have plenty of space in between MBR and 1st Partition for Grub2. Reinstall your OS again. You may want to install Windows first then Fedora to avoid rescuing Grub2 again. Trust me.
2. Since you have not use up all 4 primary partitions, you may want to reduce the intended partition size for Win7 by 1 MB and use the 1 MB to create partition 4 for the so called "BIOS Boot Partition". Leave this new BIOS Boot Partition as unformatted. After that boot into the Fedora rescue mode like you have done, then try the grub2-install command again. This time it should be able to install the Grub2's second stage or core image to the Bios Boot Partition.

HTH.

[bakunin]

Originally Posted by weitjong

I can think of one reason why Anaconda failed to install the Grub2 bootloader in the first place and also your subsequent failures to install Grub2 manually. Of course this is just my speculation. I believe it is due to your disk was originally using GPT partition table. It may originally have the first partition starts at low sector number (say sector 40 or 63). This is fine for GPT disk in a system booted with UEFI mode. But when you converted the disk from GPT to MSDOS partition table, you may face a problem to use the disk in the legacy BIOS mode. In the legacy BIOS mode, the bootloader resides in the MBR (the first sector). However, as Grub2 is too big to fit there, it usually takes the space between the MBR and first partition. But since your first partition starts at low sector number, the space in between is not enough for Grub2's core image.

There are two ways you can fix the problem:
1. (ALL DATA LOST) Repartition your disk using parted or gparted. Erase all the partitions and recreate the first partition from scratch. It should start the first partition at sector 2048, so you will have plenty of space in between MBR and 1st Partition for Grub2. Reinstall your OS again. You may want to install Windows first then Fedora to avoid rescuing Grub2 again. Trust me.
2. Since you have not use up all 4 primary partitions, you may want to reduce the intended partition size for Win7 by 1 MB and use the 1 MB to create partition 4 for the so called "BIOS Boot Partition". Leave this new BIOS Boot Partition as unformatted. After that boot into the Fedora rescue mode like you have done, then try the grub2-install command again. This time it should be able to install the Grub2's second stage or core image to the Bios Boot Partition.

HTH.

Should I convert my disk to GPT? Then install win7 then fedora 17? Then no problem? Or can I resize my /dev/sda1 ( there is mbr right? partition that windows was created. )

[weitjong]

I cannot help you to answer that. If you need more than 4 primary partitions then probably GPT is better. If your firmware supports UEFI mode and you want to experiment with UEFI/GPT combo then probably GPT is better. Note though that in UEFI mode, the current Fedora release (F17) will install legacy Grub instead of Grub2 as bootloader in the ESP (EFI System Partition) in GPT disk. If you don't need more than 4 primary partitions then the old MSDOS partition table should still fit your bill as your disk is less 2TB.

The issue here is not really whether it is GPT or MSDOS. If your issue is indeed as I speculated then it is simply because Grub2 cannot find space big enough to embed its second stage core image. If you convert back your disk from MSDOS to GPT with the current partition/sector allocation, you will face the same problem when you boot using legacy BIOS mode.

So, the fix is really just to find the space for grub2's second stage image. Besides the two options that I provide, you are spot on that you can also fix your issue by resizing the first partition /dev/sda1. But remember that free up empty space must be in the front of the /dev/sda1. Basically, changing the start sector of the first partition to higher sector number.

[DBelton]

Before you go looking at doing that, there is another thing that can be causing it.

Post the output of

gdisk -l /dev/sda

Most utilities for disk partitioning now will start your first partition in sector 2048 by default, which is more than enough space to put grub2's core.img file.

But, a lot of utilities that get rid of the GPT partitioning, Don't do it correctly. There is also a backup GPT at the end of the drive, and a lot of the utilities miss that one, and it will cause Fedora to error when installing the bootloader.

[bakunin]

This is gdisk

GPT fdisk (gdisk) version 0.8.5

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format.
***************************************************************


Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/sda: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 1445345A-F406-48B5-8783-546B8F7CB474
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 8-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          206847   100.0 MiB   0700  Microsoft basic data
   2          206848       530434047   252.8 GiB   0700  Microsoft basic data
   3       530434048      1937856567   671.1 GiB   8300  Linux filesystem
   4      1937856568      1953525167   7.5 GiB     8200  Linux swap

This is cfdisk

cfdisk (util-linux 2.21.2)

                              Disk Drive: /dev/sda
                      Size: 1000204886016 bytes, 1000.2 GB
             Heads: 255   Sectors per Track: 63   Cylinders: 121601

    Name        Flags      Part Type  FS Type          [Label]        Size (MB)
 ------------------------------------------------------------------------------
                                      Unusable                             1.05*
    sda1                    Primary   ntfs      [Sistem Ayr��ld��]       104.86*
    sda2                    Primary   ntfs                            271476.33*
    sda3        Boot        Primary   ext4                            720600.34*
    sda4                    Primary   swap                              8022.33*

Now can resize? How can I resize it?

[DBelton]

Yep, it appears that you have the "remnants" of the GPT table left on your drive. The backup GPT is still at the end of the drive.

start gdisk:

gdisk /dev/sda

Then x to get into the "extra functionality" menu

Then z to zap the GPT information.

After doing that, you should be able to install the bootloader. What is happening, is that grub2 is seeing your backup GPT information, and is thinking you have a GPT partitioned drive, which would require a BIOS_Boot partition. Not finding the BIOS_Boot partition, it can't install the bootloader.

You do have enough space between your MBR and the first partition for it to install the core.img file, so you shouldn't have any problems after clearing out the backup GPT.

[bakunin]

Okay. I did that. This is new output of gdisk -l /dev/sda

GPT fdisk (gdisk) version 0.8.5

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format.
***************************************************************


Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/sda: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 613B31B2-C761-45A5-AE61-CCFB82C154E9
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 8-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          206847   100.0 MiB   0700  Microsoft basic data
   2          206848       530434047   252.8 GiB   0700  Microsoft basic data
   3       530434048      1937856567   671.1 GiB   8300  Linux filesystem
   4      1937856568      1953525167   7.5 GiB     8200  Linux swap

[DBelton]

did you reboot before you ran gdisk again?

The partition information doesn't get updated unless you reboot or run partprobe to force the kernel to reload the partition information.

[bakunin]

Yes I reboot. Still it is unchanged.

These are the steps when I was doing that

Expert command (? for help): z
About to wipe out GPT on /dev/sda. Proceed? (Y/N): Y
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
Blank out MBR? (Y/N): N
MBR is unchanged. You may need to delete an EFI GPT (0xEE) partition
with fdisk or another tool.

EDIT: Now What I'm supposed to do? How can resize the partition for grub2? and exactly which partition?