Description of problem: Installing FC17 with grub2 to a system with Windows 7 installed on software mirrored partition renders system unbootable for both Windows and FC17 Version-Release number of selected component (if applicable):grub2 from FC17 install DVD How reproducible:fails every time, both UEFI bios PC and vmware workstation 8 test install Steps to Reproduce: 1. Install Windows 7 on a two disk system 2. Mirror both windows 7 partitions (Small boot partition and C:) 3. Create raw partitions for linux on both disks 4. Boot from FC17 install image 5. Install FC17 on a LVM / Actual results: grub2 fails to install the boot record (There was an error installing the bootloader. The system mau nobe bootable.) popup window is shown After reboot Windows 7 boot but fails with 0x0000007b and no sign of grub/fc17 Expected results: Dual boot Windows 7/FC17 Additional info:
You mention UEFI and bios. Which of them are you using? Please attach the anaconda logs and the exact error message. Please also show the output from gdisk -l for each of your disks and describe your partitioning in more details.
I don't think we support dynamic disks at all. GRUB has some code for accessing them but to install on them you need some more which we don't have yet.
Ah well, to not support is one think, making working system unbootable is another :-) But here goes for the info anyway. I originally found this out an a PC with UEFI boot system, then tried it on a vmware virtual machine (host FC16, Vmware version i 8.03) which I believe uses BIOS. This test is on virtual machine with two 48Gb virtual disks gdisk -l on both disks show four partitions after clean windows 7 install and mirroring 1. 63-2047 4200 Windows LDM data 2. 2048-206847 4200 Windows LDM data # this is partition windows 7 installation creates 3. 206848-41943039 4200 Windows LDM data # this is my windows C: 4. 41943040-100661247 4200 Windows LDM data # this is what windows thinks is empty On FC17 install I do Create custom layout Change the Unknown sda4 and sdb4 to LVM and create root and swap volumes Then run the install checking the gdisk -l while install is running and it show four partitions as before but now the fourth is 8E00 Linux LVM When all the packages have been installed I get a popup windows saying Warning There was an error installing the bootloader. The system may not be bootable. On one of the virtual terminals I see /usr/sbin/grub2-bios-setup: warning: this LDM has no Embedding Partition; embedding won't be possible. /usr/sbin/grub2-bios-setup: error: embedding is not possible, but this is required for RAID and LVM install.
Modifying LDM (Dynamic disks) with anything not LDM-aware will break it. As for the message: it's because the code for LDM embedding isn't there yet.
So are you saying the the grub2, which clearly is aware this system has LDM disks, is not responsible for making the Win7 system unbootable? Touching the partition type maybe?
GRUB is LDM-aware and since it's aware that it can't install bootsector on this configuration yet, it bails out. Anaconda, on the other hand is not LDM-aware and so would happily change the partition type which makes LDM invalid.
grub2 is not used for EFI - if you see the problem on EFI too then it almost proves that the problem is elsewhere. Yes, it is most certainly anaconda that spoiled your disk by attempting to repartition it ... possibly by relying on fdisk. That is why we need the anaconda logs. Reassigning.
Created attachment 591539 [details] anaconda log from failed install
We'll want all the logs from /tmp/*log please. But I think the course of action here is to detect that it's an LDM setup and refuse to install on it unless the disks are getting completely cleared.
For the time being yes. While GRUB support is almost complete (it can be brought to completition pretty quick), we have no tools to modify LDM and currently we don't assemble LDM members automatically so you'd see components in disk tab which can lead to corruption if any of RAIDed components is mounted. In short sentence: we don't handle LDM well enough for it to be immediately usable.
Created attachment 591580 [details] All the logs from the install
As said originally, this same thing happend on a UEFI PC too, with exactly the same errors on the screen, so if it's not supposed to use grub with UEFI, there might be something related to LDM there too. Unfortunately that system has a fresh Windows 7 install again and I'm not willing to destroy it second time so I do not have the logs anymore..
I get this problem, but on an mdadm controlled IMSM fake raid. Dunno if I'm on UEFI Description of problem: Install runs fine (showing LVM disk lv partitions on top of MDADM which is on top of IMSM fake-RAID disks). At the last stage (writing bootloader) it reports that it failed to write bootloader and the system might not boot. At reboot the system does indeed not boot. I chose the default boot loader install point (the MDADM device, in this case /dev/md126) I get an error message in program.log about grub2-bios-setup not liking LDM Version-Release number of selected component (if applicable): How reproducible: Every time (tried Live and DVD versions) Steps to Reproduce: 1. RAID10 setup on IMSM as only disk, appears as /dev/md126 in Linux 2. install Windows 7 in primary partition(s) 2. Make extended partition with LVM pv and 250 MB log. partition for /boot 3. install F17 in volume groups from LVM, mounting /boot on logical partition 4. accept default choice for bootloader install: "/dev/md126." (with ., not ") 5. At end of install, warning "There was an error installing the bootloader" 6. click reboot (which is done, not like the bad old days) 7. get dropped into GRUB prompt Actual results: GRUB complains about unrecognised file system
Created attachment 592314 [details] tar -cj of /tmp/*log after install. Juicy error message in program.log
(In reply to comment #10) > For the time being yes. While GRUB support is almost complete (it can be > brought to completition pretty quick), we have no tools to modify LDM and > currently we don't assemble LDM members automatically so you'd see > components in disk tab which can lead to corruption if any of RAIDed > components is mounted. In short sentence: we don't handle LDM well enough > for it to be immediately usable. Well, I have this problem with mdadm controlled fake-raid which "Just Works[tm]" in that the installer starts it up correctly and for all I can tell the install is correct.
(In reply to comment #13) > I get this problem, but on an mdadm controlled IMSM fake raid. Dunno if I'm > on UEFI IMSM has absolutely nothing to do with LDM. Please file a separate bug
(In reply to comment #16) > (In reply to comment #13) > > I get this problem, but on an mdadm controlled IMSM fake raid. Dunno if I'm > > on UEFI > IMSM has absolutely nothing to do with LDM. Please file a separate bug Log indicates that you actually do have LDM on top of IMSM. Is it possible that you have "dynmaic disks" in addition to IMSM?
(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #13) > > > I get this problem, but on an mdadm controlled IMSM fake raid. Dunno if I'm > > > on UEFI > > IMSM has absolutely nothing to do with LDM. Please file a separate bug > > Log indicates that you actually do have LDM on top of IMSM. Is it possible > that you have "dynmaic disks" in addition to IMSM? First I've ever heard of it. I didn't hear anything about LDM when installing Fedora 16. How do I find out? On the Intel IMSM side, this is managed before installing Windows and once in Windows I use Intel software to play with the RAID set. I've never had to do anything that sounded like "dynamic disks."
Created attachment 592376 [details] Install logs from F16, same hardware, no bootloader install problem No appearance of "ldm" in any log file
(In reply to comment #19) > Created attachment 592376 [details] > Install logs from F16, same hardware, no bootloader install problem > > No appearance of "ldm" in any log file Please don't mix the bugreports then. By mixing youself into another person bugreport you colunteer to be ignored when original reporter's bug is fixed
I have exactly the same problem, but my system doesn't have mirrored dynamic disks. I tried to upgrade a working installation of FC15 to FC17, and grub wasn't able to find the Fedora installation, finding only the Windows 7 install. I tried to perform a fresh install of Fedora, in order to solve the problem, and got MBR completely blank now. I tried to restore grub by starting the system in rescue mode and typing the following line into the terminal: $ /sbin/grub2-install /dev/sda but it gave me the following message: $ warning: this LDM has no Embedding Partition; embedding won't be possible. $ warning: embedding is not possible. grub can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged. $ error: will not proceed with blocklists. What should I do now to get my system bootable again?
Mauren, that sounds familiar. My fix-it for this problem is to install Fedora 16 (from a KDE desktop CD, but I don't think that makes a difference). The Fedora install is going to die, but your Windows install comes back to life. The key point is that Fedora 16 install media seems to come with grub that doesn't barf at these diks. Use at your own recognizance. Maybe Fedora full DVD comes with a rescude system that will allow you to patch it up, I haven't tried that. Good luck.
Not a solution, but some people have reported a potential work-around grub2-install --force --recheck /dev/sda
(In reply to comment #23) > Not a solution, but some people have reported a potential work-around > > grub2-install --force --recheck /dev/sda it failed with the message "blocklists are invalid". I successfully installed Ubuntu 10.04 this evening in the same machine, but then when I tried to overwrite the Ubuntu install with Fedora, my grub went dead and showed me a grub rescue prompt.
(In reply to comment #22) > Mauren, that sounds familiar. > > My fix-it for this problem is to install Fedora 16 (from a KDE desktop CD, > but I don't think that makes a difference). The Fedora install is going to > die, but your Windows install comes back to life. > > The key point is that Fedora 16 install media seems to come with grub that > doesn't barf at these diks. Use at your own recognizance. Maybe Fedora full > DVD comes with a rescude system that will allow you to patch it up, I > haven't tried that. Good luck. Using the FC16 live CD I could get it working again. Thanks for the hint. However, the issue persists with the FC17 DVD.
FYI, it happens with F18 smoke 5.
Hi, Is this thread still live... I m facing the same issue with F18... and i dont have F16 or F17 or F18 DVD. Is there a fix without using DVD? Note: I have already instaled windowsXP and now i want to what F18 too in dual boot. Below is what i tried from LiveCD- [root@localhost liveuser]# mount --bind /dev /run/media/liveuser/_Fedora-18-x86_6/dev [root@localhost liveuser]# mount --bind /proc /run/media/liveuser/_Fedora-18-x86_6/proc [root@localhost liveuser]# chroot /run/media/liveuser/_Fedora-18-x86_6 [root@dhcppc0 /]# mount -t ext4 /dev/sda7 /boot [root@dhcppc0 /]# grub2-install /dev/sda /usr/sbin/grub2-bios-setup: warning: this LDM has no Embedding Partition; embedding won't be possible. /usr/sbin/grub2-bios-setup: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. /usr/sbin/grub2-bios-setup: error: will not proceed with blocklists. Then i tried to use the "Force" option grub2-install --force --recheck /dev/sda I get below mesage - /usr/sbin/grub2-bios-setup: warning: this LDM has no Embedding Partition; embedding won't be possible. /usr/sbin/grub2-bios-setup: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. Installation finished. No error reported. Initially i thought it worked but when i re-booted the PC entered the grub prompt... now i cant use WinXP and F18.
And 1 more thing... while installing F18 the bootloader installation failed with the same error i mentioned above in Comment 27
Can some one please explain to me what the error meassage "this LDM has no Embedding Partition" means?
(In reply to comment #29) > Can some one please explain to me what the error meassage "this LDM has no > Embedding Partition" means? Hi Denis, I don't know what does "this LDM has no Embedding Partition" mean, but I solved this issue in my old machine by extending the unallocated space in disk. I had about 1 MB of unallocated area, and I extended this area to about 10 MB using GParted. Then I tried to install grub using this command you wrote above and everything worked just fine.
Hi Mauren, Thanks for the reply. I added unallocated space (28Mb) in disk but i still get the same error. My disk is like this - - I have sda1, sda2, sda5, sda6, sda7, sda8. - sda7 is /boot - sda8 is Linux LVM I added space after sda8. Below is how i added the free space - - Deleted linux partitions from WinXP so that i will get about 50 GB free space - Then using F18 live CD is tried to reinstall F18. - During reinstall, at the time of setting up the partitions i ensured that there will be more than 20 Mb free space. - Note: the free space was created in the secondary partition (the primary partition as C: drive) - The installation failed with the same error as i got previously. - Then i again tried installing Grub2 from LiveCD as i did before... but that to failed with the same error... Please explain to me where you added the free space (was it at the end of the disk, like i did?)... May be that might be helpfull. Do you know any other workarounds that i can try?
Hi Denis, I added in the beginning of the disk, in the first sectors I could allocate. Maybe you could try to move this empty space through GParted. Try using SuperGrub Disk. I used this software to resize my partitions when I had this problem. Here's the thread that helped me to solve the issue: http://www.linuxquestions.org/questions/linux-newbie-8/problem-installing-fedora-17-in-dual-booting-with-windows-7-a-4175412439/page2.html Good luck. Post your results here, right after.
Hi Mauren, By "added in the beginning of the disk" you mean before C: drive? I was not able to move C: partition using Gparted but i can shrink the c: drive. But i m a bit hesitant of shrinking the c: drive. I have the below questions - 1. Can shrinking c: drive result into WinXP not functioning? 2. My c: drive starts at sector 63. How will i know that the space is not enough? how much space is required?
Hi Denis, yes, by "beginning of the disk" I meant the first sectors right after the MBR. I would not shrink the C: drive, since I don't know what could happen if you do so. I can't say for sure how many space is needed. I had about 10~12 MB and it was enough, but the guy in the thread I pasted above said he needed 100 MB. Maybe your problem isn't the unallocated space, but something else. Have you tried SuperGrub Disk to repair GRUB? Does your machine use BIOS or UEFI as firmware?
Hi Mauren, Thanks for your reply... I will be working on this in the coming week end... I need to do some more research before I play with my WinXP partitions. My PC has the capability to boot using BIOS or UEFI. I have not yet used SuperGrub. Did you use SuperGrub or SuperGrub2?
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.