Description of problem: During dialogs for fresh install from DVD (Fedora 16 Alpha RC1), I chose to install boot loader to boot block of root partition. After all packages had been installed, I got a dialog box "Bootloader: An error occurred while installing the bootloader. The installed system might not be bootable." Indeed, chainloading the root partition /dev/sdc8 via rootnoverify (hd2,7) makeactive chainloader +1 got Error 12: Could not find device, and using a system booted from another partition showed that the boot block of /dev/sdc8 was all 0x0000. The tail of the installed /root/install.log has ----- 15:46:25 Installing ipw2100-firmware-1.3-12.fc15.noarch W: Skipping program kexec as it cannot be found and is flagged to be optional grubby fatal error: unable to find a suitable template grubby: doing this would leave no kernel entries. Not writing out new config. *** FINISHED INSTALLING PACKAGES *** ----- with no '\n' at the end of the last line. Version-Release number of selected component (if applicable): anaconda-16.14.2 grubby-8.1-1.fc16.x86_64 How reproducible: haven't tried Steps to Reproduce: 1. Fresh install from Fedora 16 Alpha DVD (RC1). 2. Format existing partition ext4 for root filesystem (/). 3. Choose Install bootloader to boot block of root partition. Actual results: After all packages have been installed, dialog box appears " Bootloader: An error occurred while installing the bootloader. The installed system might not be bootable." and no bootloader was installed. Expected results: success. Additional info: Installed system did boot properly by grub (grub1) after manually constructing a boot stanza using grub from MBR of /dev/sda.
Created attachment 517016 [details] /boot/grub2/grub.cfg This grub2 configuration was produced in /boot/grub2/grub.cfg.
Please attach the following logs individually: If you are in the installer: /tmp/anaconda.log /tmp/program.log /tmp/storage.log /tmp/syslog If you are on the newly installed system post-install: /var/log/anaconda/anaconda.log /var/log/anaconda/anaconda.program.log /var/log/anaconda/anaconda.storage.log /var/log/anaconda/anaconda.syslog Thanks.
FWIW in grub2 you don't subtract one from the partition number when forming the grub-specific device name like you do in grub1.
Created attachment 517254 [details] /var/log/anaconda.log anaconda.log after boot (grub1) into installed system.
Created attachment 517257 [details] /var/log/anaconda/anaconda.program.log anaconda.program.log after boot (grub1) into installed system.
Created attachment 517259 [details] /var/log/anaconda/anaconda.storage.log anaconda.storage.log after boot (grub1) into installed system.
Created attachment 517260 [details] /var/log/anaconda/anaconda.syslog anaconda.syslog after boot (grub1) into installed system.
Apparently grub2 does not want to let you install it to the first sector of your root partition: 15:48:48,124 INFO program: Running... grub2-install (hd2,8) 15:49:01,733 ERR program: /usr/sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.. 15:49:01,734 ERR program: /usr/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.. 15:49:01,734 ERR program: /usr/sbin/grub2-setup: error: will not proceed with blocklists.
I have grub2 installed in the boot block of three root partitions (Ubuntu 11.04, 10.10, 10.04.2) on the same box and it works just fine to chainload each of those boot blocks from grub1. This is deprecated is because such an installation of grub2 uses lists of disk block numbers instead of indirection through file names, which can become out-of-date if you modify or move any of the grub2 files. The log file for each Unbuntu install has a similar complaint to that of Comment #8, but the Ubuntu installer never reveals this complaint during the install itself. I dislike grub2 because it is more brittle for my usage. I need special parameters for each partition (Fedora, Ubuntu, CentOS, WinXX, *BSD, OpenSolaris), and the "automation" ("Do not edit this file.") provided by Ubuntu and grubby obscures what is going on, and gets in the way.
It goes so far as to issue an error saying it will not proceed with blocklists, so ignoring it would be a mistake. As far as grub2's (in)ability to smoothly handle multiple linux installations, I agree. It is tempting to just put everything in /etc/grub.d/40_custom and be done with it.
When I installed those three Ubuntu systems, I asked only to put the boot loader into the boot block of the root partition. It worked, and there was no feedback at the time. (Of course, I did have to construct the chainloader stanza for my "master" grub1.) By observing carefully, I noticed the grub2 complaint later, each time that I updated a Ubuntu kernel; but again there was no overt notification, and I didn't have to take any action, not even to ignore a warning. It just works, as long as I don't modify or move the partition or any grub2 stuff.
My request is for anaconda is: force the installation of grub2 to the boot block (including installation of everything in /boot/grub2), and keep the warning dialog box from anaconda. Then it will be as easy as possible for those who are brave to fix things up, while those who aren't so adventurous can be just as disappointed as now.
*** Bug 729457 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > Apparently grub2 does not want to let you install it to the first sector of > your root partition: > > 15:48:48,124 INFO program: Running... grub2-install (hd2,8) > 15:49:01,733 ERR program: /usr/sbin/grub2-setup: warn: Attempting to install > GRUB to a partitionless disk or to a partition. This is a BAD idea.. > 15:49:01,734 ERR program: /usr/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.. > 15:49:01,734 ERR program: /usr/sbin/grub2-setup: error: will not proceed with > blocklists. Using --force vice --grub-setup=/bin/true /dev/<16s boot parition> works (for me, at least). Is it ok to modify anaconda accordingly?
I have the same issue with F16 Alpha RC3 when choosing /boot which is on a separate partition /dev/sda2 as target for the boot loader. Note that the graphical installer by no means forbids this kind of setup during the configuration stage.
(In reply to comment #15) > <snip> > Note that the graphical installer by no means forbids this kind of setup during > the configuration stage. Proper in itself if it worked correctly. You just have to figure out how to run grub2-install to /dev/sda2 later. A thought experiment I had was to go to tty2 after the installer says finished and see if grub2-install works there.
Fixed by commit 9474d2c386aab25ede8, which will be in anaconda-16.16-1.
*** Bug 733185 has been marked as a duplicate of this bug. ***
Works for me in Fedora-16-Beta.TC1-x86_64-DVD.iso which announces that it uses anaconda-16.16.
Still fails for me in F16 TC2. Selected to install the bootloader to the /boot partition (/dev/sda2) and resulted in an error message about failed bootloader installation and no bootloader installed. Had to install it manually by running grub-setup --force /dev/sda2
(In reply to comment #20) > Still fails for me in F16 TC2. Selected to install the bootloader to the /boot > partition (/dev/sda2) and resulted in an error message about failed bootloader > installation and no bootloader installed. > > Had to install it manually by running grub-setup --force /dev/sda2 F16 Final TC2? Please attach /var/log/anaconda/anaconda.log and /var/log/anaconda/program.log to this bug as you should not see this bug anymore.
Yes F16 Final TC2. anaconda.program.log ends with 22:20:28,752 INFO program: Running... grub2-install --force --no-floppy (hd0,2) 22:20:30,901 ERR program: /sbin/grub2-setup: error: unable to identify a filesystem in hd0; safety check can't be performed.
Created attachment 529573 [details] F16 Final TC2 anaconda.log
Created attachment 529574 [details] F16 Final TC2 program.log
Oddly running the exact same command as reported in program.log from the console after reboot works fine.
Seems to work if ext4 is used for /boot, but not if /boot is using btrfs.
Henrik, yours is a different bug. Please file a separate report for it, and include the same logs. Thanks.
Done. Bug #748121.
I did Fedora 16 Respin iso install with all latest packages, including latest Anaconda package, and still had this issue. There were two ntfs partitions (Windows 7 + data partition) and 30 GB of free space. From 30GB free space I created /root # 200 MB, ext4 /swap # 2.5 GB, swap / # 8.0 GB, ext4 /home # 19 GB, btrfs grub2 install fails miserably :( Are there any updates regarding this bug?
This is a really mayor but and I don't understand it why it fails when I tried grub2-install --force then grub installs without issues!
(In reply to comment #29) > I did Fedora 16 Respin iso install with all latest packages, including latest > Anaconda package, and still had this issue. > > grub2 install fails miserably :( > > Are there any updates regarding this bug? Please open a separate bug. This one was fixed prior to F16 release. When you open your bug, attach the following log files from the installation, one at a time, as attachments of type text/plain: /tmp/anaconda.log (or /var/log/anaconda/anaconda.log) /tmp/storage.log (or /var/log/anaconda/anaconda.storage.log) /tmp/program.log (or /var/log/anaconda/anaconda.program.log) /tmp/syslog (or /var/log/anaconda/anaconda.syslog) Thanks.