Description of problem: I have a ASUS Eee PC 1000HE. It dual boots Fedora and Win7, and I keep my /home in it's own partition. I have been running Fedora on it since Fedora 11, and each time I clean install while retaining my /home directory without issue. With Fedora 16, at the end of the installation when it attempts to install the boot loader, it fails with the error 'The bootloader failed to install. Your system may not boot" And it doesn't boot. I'm sure this is related to the change to grub2. I tried just too see if it would make any difference using a Win7 disc to install Microsoft's boot loader and then have Fedora 16 try to install the bootloader again, I received the same message. Version-Release number of selected component (if applicable): 16 How reproducible: Everytime Steps to Reproduce: 1.Boot Fedora 16 i386 DVD on external USB CD-ROM drive 2. Install and select customer partitioning. 3. Map /boot, /, and swap to existing LVM partitions from previous Fedora install and format ext4, and map /home and do not format. 4. Install prceeds and at the point the bootloader installs at the end of installation, receive the error 'The bootloader failed to install. Your system may not boot. Actual results: Bootloader is not installed, and the system fails to boot. Expected results: Bootloader installs normally and system is bootable. If there is a way to extract some type of log or something I would be glad to do that.
Sorry, I failed to do a media check before posting my bug. I have since performed a media check and it did pass.
I've tried three different BIOS settings which has made no difference. Regardless of the setting, the bootloader still fails to install. In the BIOS, under Advanced: ATA/IDE Configuration: [Enhanced] Configure SATA as: [ACHI] or ATA/IDE Configuration: [Enhanced] Configure SATA as: [IDE] or ATA/IDE Configuration: [Compatible] The first set of options is the default, and is what I have always used under previous installs of Fedora. The BIOS is the last release: ASUS 1000HE ACPI BIOS Revision 1104
Booted the system with rescue media: tait of /root/install.log grubby fatal error: unable to find suitable template grubby: doing this would leave no kernel entries. Not writing out new config.
Found this in anaconda.program.log, I will attach all the anaconda logs. 13:53:18,854 INFO program: Running... grub2-mkconfig -o /boot/grub2/grub.cfg 13:53:20,800 ERR program: Generating grub.cfg ... 13:53:21,539 ERR program: Found linux image: /boot/vmlinuz-3.1.0-7.fc16.i686.PAE 13:53:21,609 ERR program: Found initrd image: /boot/initramfs-3.1.0-7.fc16.i686.PAE.img 13:53:28,238 ERR program: Found Windows 7 (loader) on /dev/sda1 13:53:29,937 ERR program: done 13:53:31,174 INFO program: Running... grub2-install --no-floppy (hd0) 13:53:36,585 ERR program: /sbin/grub2-setup: warn: Your embedding area is unusually small. core.img won't fit in it.. 13:53:36,588 ERR program: /sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. 13:53:36,589 ERR program: /sbin/grub2-setup: error: will not proceed with blocklists.
Created attachment 533382 [details] All anaconda logs from the failed install
Created attachment 533392 [details] Generated grub2 config
So I discovered /dev/sda was too close to the front of the disk not leaving enough room to install the grub2 bootloader. I re-sized the partition and moved it back from the disk, then re-installed grub2 and success! Fedora 16 now boots. As for Win7, it didn't survive the re-size and I'm going to delete it as it sucks anyway.
Heh, that was a nice story with a happy ending ;-) You have /boot on LVM? I would say that the idea of having a separate /boot is that it should be as simple as possible so it can be used to bootstrap /usr & co which might reside on more complex devices and file systems. With /boot on LVM the boot loader has to do more work will thus take up more space that has to be somewhere else, and the only place that is left is the gap at the beginning of the disk. If /boot had been on ext2 and there wasn't enough space in the gap then anaconda would have used the "insecure" block lists. So what is left in this issue? A request for better handling and explanation of what is going on? Should this be mareked as a duplicate of Bug 737508?
My /boot is a primary partition. It was like this: 1. NTFS 2. /boot 3. LVM Nothing left on this issue really. Sorry, this started out as a bug report, and ended up being a sounding board for my troubleshooting. Maybe some type of note on the common bugs page is in order, although it's not really a bug. Or a more descriptive error? I'm not much of a coder or I would volunteer.
Did you have _very_ little free space on /dev/sda? Or how big is your core.img? If no lvm is involved in /boot then core.img should be < 30k and fit within the 63 sectors that usually are free.
I don't know unfortunately. The NTFS partition was factory installed by ASUS, and I didn't think to check the size of the gap or the size of core.img before I blew it away.
*** This bug has been marked as a duplicate of bug 737508 ***
Bug #782144 solves the problem for me.