Red Hat Bugzilla – Bug 730915
grub2 refuses to install to a partition's boot block, yet anaconda allows users to try
Last modified: 2011-11-10 04:01:19 EST
Description of problem:
I could boot the F16 Alpha RC4, then running "install to harddisk" (target was the extended partition /dev/sda5). The install was performed completely, but installing the grub loader to /dev/sda5 failed. I will attach
Version-Release number of selected component (if applicable):
Several trials failed
Steps to Reproduce:
Created attachment 518424 [details]
Created attachment 518425 [details]
Created attachment 518426 [details]
Created attachment 518427 [details]
Created attachment 518428 [details]
this info is probably in the logs, but: was this a DVD, net or live install? what arch? what partition layout did you select? and what was the pre-existing layout on the disk you tried to install to? thanks!
Fedora Bugzappers volunteer triage team
(In reply to comment #6)
> this info is probably in the logs, but: was this a DVD, net or live install?
> what arch? what partition layout did you select? and what was the pre-existing
> layout on the disk you tried to install to? thanks!
> It was an "install to harddisk" to logical partition /dev/sda5 after booting the live CD
> Arch: x86_64
> I selected the custom install
> Partitions (listed by cfdisk):
Disk Drive: /dev/sda
Size: 500107862016 bytes, 500.1 GB
Heads: 255 Sectors per Track: 63 Cylinders: 60801
Name Flags Part Type FS Type [Label] Size (MB)
sda1 Primary ext4 [tmp] 20003.89
sda2 Primary ext4 [disk2] 29997.60
sda3 Primary swap [SWAP] 2500.52*
sda5 Boot, NC Logical ext4 [_Fedora-16-Alpha] 50001.45*
sda6 Logical ext4 [vbox] 100002.96
sda7 Logical ext4 [/F15] 109996.67
Logical Free Space 187604.80*
so, you used the 'custom layout' option to set up that partition layout? if so we're outside alpha scope, but it's still a worrying bug.
(In reply to comment #8)
> so, you used the 'custom layout' option to set up that partition layout? if so
> we're outside alpha scope, but it's still a worrying bug.
So the best practice would be to wait for the first Beta RC?
well, wait until you get some feedback from the anaconda devs on this bug, I guess.
GRUB2 is not allowing install to a partition at this point. We are in discussions about the best course of action to resolve the issue.
Here's the command and its output in case you are curious:
12:23:10,338 INFO program: Running... grub2-install (hd0,5)
12:23:16,828 ERR program: /usr/sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea..
12:23:16,829 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..
12:23:16,830 ERR program: /usr/sbin/grub2-setup: error: will not proceed with blocklists.
In the meantime, if you want to install the bootloader to a partition you will have to do it yourself. You can use rescue mode to get your system mounted, then chroot into it and run this command:
grub2-install --force (hd0,5)
Thank you. Installation of the grub2 loader inside a rescue system did the trick. Now the installed F16 is chainloader bootable.
Just to add a note here, I get the same errors in the RC5 Alpha using an install to an existing partition on my disk full of various kernels which I multi-boot via chainloader. I wanted to get f16 alpha added to my collection and boot it by chainloading as well. I'll give the rescue disk --force option a try (but I gotta say, I'm having a hard time finding any advantages to the use of grub2 - I'd say it is suffering from an acute case of second system syndrome even in the name grub2 :-).
It is also a bit disconcerting to have anaconda give me to option to install in the root partition, then have grub refuse to obey.
The --force install worked for me as well. I didn't even really have to use rescue mode, just did a --bind mount of /dev in the f16 partition and chrooted into the f16 partition and ran grub2-install --force from there. I am now able to chainload and boot f16 alpha RC5.
(In reply to comment #13)
> Just to add a note here, I get the same errors in the RC5 Alpha using an
> install to an existing partition on my disk full of various kernels which I
> multi-boot via chainloader. I wanted to get f16 alpha added to my collection
> and boot it by chainloading as well. I'll give the rescue disk --force option a
> try (but I gotta say, I'm having a hard time finding any advantages to the use
> of grub2 - I'd say it is suffering from an acute case of second system syndrome
> even in the name grub2 :-).
Indeed, it is a perfect example of second system syndrome.
> It is also a bit disconcerting to have anaconda give me to option to install in
> the root partition, then have grub refuse to obey.
Alpha software is allowed to do things that you find disconcerting.
Perhaps the reason it claims it is a bad idea is that it doesn't stick :-).
I tried the same chainload boot that worked yesterday again today and
it once again refused to boot. Had to redo the chroot and forced
grub2-install before I could boot again.
Since then though I've installed updates and booted a couple of more times to
check that it worked, and it has worked each time so far.
Tom Horsley> Perhaps the reason it claims it is a bad idea is that it doesn't stick :-).
Just curious, what filesystem you have /boot on? Can it be related to a kind of online defragmentation or btrfs CoW feature?
Created attachment 519853 [details]
Remove "a BAD idea" message to keep users calm
grub1 had no "BAD idea" message. If nothing has really changed since grub1 except the message itself, then to keep users calm and not asking questions about "what's so bad in that BAD idea", it's easy to remove that message.
Attached patch does that.
Optionally the line can be patched to remove just the "This is a BAD idea." part, but that would require patching all the localization .po files as well.
This problem should be addressed somehow, since a lot of users would install fedora as a second OS and would have to install boot-loader to a boot-record.
It is just your ordinary old fashioned ext3 filesystem. I did edit some files
in the partition (like /etc/sysconfig settings) while I was booted back
in f15, but if it is going to be sensitive to that sort of thing it
is indeed broken :-).
Be interesting to see if it ever happens again or it was just some sort
of one time glitch.
A clue! I just did an update on my f16 partition which installed a new
kernel (and a new grub2 at the same time). When I tried to reboot and chainload
the f16 partition again, grub2 was busted once more and I couldn't
boot f16 (this time I got a grub2 rescue mode prompt).
I booted back to f15, chrooted to the f16 partition and did the
grub2-install --force /dev/sda2
trick again, and then I could once more boot into f16 via chainloading.
Perhaps the previous time grub2 became unstuck I also applied a
kernel update while it was up (can't remember for sure, but it seems
I just hit the problem where grub2 installed into a partition becomes unbootable after an update too. The grub2 package was updated, so I guess that explains it.
Note that if /boot is on a partition you need mount /boot and bind-mount /dev before installing grub2, e.g.:
# mount /dev/sda9 /mnt/f16
# mount /dev/sda3 /mnt/f16/boot
# mount --bind /dev /mnt/f16/dev
# chroot /mnt/f16
# grub2-install --force '(hd0,3)'
I just installed f16 from the Beta TC2 DVD iso image, and it allowed me to
install grub2 in the root partition (so I could chainload it) and even
worked correctly. I was able to chainload and boot the f16 install. So
the install at least is fixed in TC2. Time will tell if grub2 suddenly
stops booting again for some reason.
This was fixed in anaconda-16.16-1.
(In reply to the one month old comment #21)
> I just hit the problem where grub2 installed into a partition becomes
> unbootable after an update too. The grub2 package was updated, so I guess that
> explains it.
For the record: I assume that was an "old" grub2 update - they used to change files in /boot. The latest grub2 packages will no longer touch /boot, and /boot/grub2/core.img will now only be modified by grub2-install which also will update the blocklist in MBR. This should thus no longer be an issue.
When I installed from the f16 beta dvd, I installed grub2 to the /
partition, and there was a grub2 update later and nothing broke
for me, so at least for the newer stuff, I haven't see the problem