Bug 730915 - grub2 refuses to install to a partition's boot block, yet anaconda allows users to try
Summary: grub2 refuses to install to a partition's boot block, yet anaconda allows use...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-16 08:43 UTC by Joachim Backes
Modified: 2011-11-10 09:01 UTC (History)
9 users (show)

Fixed In Version: anaconda-16.16-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-28 17:09:06 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
/var/log/messages (255.88 KB, text/plain)
2011-08-16 08:52 UTC, Joachim Backes
no flags Details
anaconda.log (24.56 KB, text/plain)
2011-08-16 08:53 UTC, Joachim Backes
no flags Details
program.log (397.89 KB, text/plain)
2011-08-16 08:53 UTC, Joachim Backes
no flags Details
storage.log (758.54 KB, text/plain)
2011-08-16 08:54 UTC, Joachim Backes
no flags Details
storage.state (84.00 KB, text/plain)
2011-08-16 08:54 UTC, Joachim Backes
no flags Details
Remove "a BAD idea" message to keep users calm (1.08 KB, patch)
2011-08-25 13:56 UTC, Sergey
no flags Details | Diff

Description Joachim Backes 2011-08-16 08:43:44 UTC
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

/var/log/messages,
/tmp/anaconda.log
/tmp/program.log
/tmp/storage.state
/tmp/storage.log


Version-Release number of selected component (if applicable):
16.14.15-1

How reproducible:
Several trials failed

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Joachim Backes 2011-08-16 08:52:27 UTC
Created attachment 518424 [details]
/var/log/messages

Comment 2 Joachim Backes 2011-08-16 08:53:13 UTC
Created attachment 518425 [details]
anaconda.log

Comment 3 Joachim Backes 2011-08-16 08:53:54 UTC
Created attachment 518426 [details]
program.log

Comment 4 Joachim Backes 2011-08-16 08:54:23 UTC
Created attachment 518427 [details]
storage.log

Comment 5 Joachim Backes 2011-08-16 08:54:54 UTC
Created attachment 518428 [details]
storage.state

Comment 6 Adam Williamson 2011-08-16 09:29:57 UTC
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
https://fedoraproject.org/wiki/BugZappers

Comment 7 Joachim Backes 2011-08-16 09:39:12 UTC
(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*

Comment 8 Adam Williamson 2011-08-16 16:49:07 UTC
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.

Comment 9 Joachim Backes 2011-08-17 06:34:01 UTC
(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.

Thanx.

So the best practice would be to wait for the first Beta RC?

Comment 10 Adam Williamson 2011-08-17 08:32:22 UTC
well, wait until you get some feedback from the anaconda devs on this bug, I guess.

Comment 11 David Lehman 2011-08-17 13:36:12 UTC
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)

Comment 12 Joachim Backes 2011-08-17 14:05:19 UTC
Thank you. Installation of  the grub2 loader inside a rescue system did the trick. Now the installed F16 is chainloader bootable.

Comment 13 Tom Horsley 2011-08-20 16:13:36 UTC
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.

Comment 14 Tom Horsley 2011-08-20 16:41:21 UTC
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.

Comment 15 David Lehman 2011-08-22 16:05:48 UTC
(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.

Comment 16 Tom Horsley 2011-08-24 22:41:00 UTC
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.

Comment 17 Sergey 2011-08-25 13:12:04 UTC
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?

Comment 18 Sergey 2011-08-25 13:56:11 UTC
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.

Comment 19 Tom Horsley 2011-08-25 13:58:39 UTC
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.

Comment 20 Tom Horsley 2011-09-03 23:01:05 UTC
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
likely).

Comment 21 Chuck Ebbert 2011-09-10 10:31:06 UTC
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)'

Comment 22 Tom Horsley 2011-09-10 21:21:53 UTC
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.

Comment 23 David Lehman 2011-09-28 17:09:06 UTC
This was fixed in anaconda-16.16-1.

Comment 24 Mads Kiilerich 2011-10-07 22:17:18 UTC
(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.

Comment 25 Tom Horsley 2011-10-07 22:35:59 UTC
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
again.


Note You need to log in before you can comment on or make changes to this bug.