Red Hat Bugzilla – Full Text Bug Listing
|Summary:||grub2 refuses to install to a partition's boot block, yet anaconda allows users to try|
|Product:||[Fedora] Fedora||Reporter:||Joachim Backes <joachim.backes>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||16||CC:||anaconda-maint-list, awilliam, horsley1953, jonathan, mads, mszpak, pascal.schott, sergemp, vanmeeuwen+fedora|
|Fixed In Version:||anaconda-16.16-1||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-09-28 13:09:06 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Joachim Backes 2011-08-16 04:43:44 EDT
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 04:52:27 EDT
Created attachment 518424 [details] /var/log/messages
Comment 6 Adam Williamson 2011-08-16 05:29:57 EDT
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 05:39:12 EDT
(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 12:49:07 EDT
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 02:34:01 EDT
(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 04:32:22 EDT
well, wait until you get some feedback from the anaconda devs on this bug, I guess.
Comment 11 David Lehman 2011-08-17 09:36:12 EDT
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 10:05:19 EDT
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 12:13:36 EDT
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 12:41:21 EDT
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 12:05:48 EDT
(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 18:41:00 EDT
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 09:12:04 EDT
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 09:56:11 EDT
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 09:58:39 EDT
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 19:01:05 EDT
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 06:31:06 EDT
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 17:21:53 EDT
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 13:09:06 EDT
This was fixed in anaconda-16.16-1.
Comment 24 Mads Kiilerich 2011-10-07 18:17:18 EDT
(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 18:35:59 EDT
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.