Description of problem: I've not managed to get a KVM kickstart install completed and booted successfully. The problems seem to be caused by bootloader kickstart configuration. Either I'm not properly specifying what is needed, or a bug may be lurking. Version-Release number of selected component (if applicable): * anaconda-16.14-1 How reproducible: Steps to Reproduce: 1. Attempt a KVM kickstart install using the following part lines ... # NOTE: bootloader was commented out so the installer would prompt me, but it doesn't seem to change the result. With or without the bootloader command, I get the error # bootloader --location=mbr clearpart --all --initlabel part /boot --fstype=ext4 --size=500 part swap --recommended part / --size=4000 --grow --fstype=ext4 Actual results: ┌──────────────────┤ Warning ├──────────────────┐ │ │ │ There was an error installing the bootloader. │ │ The system may not be bootable. │ │ │ │ ┌────┐ │ │ │ OK │ │ │ └────┘ │ │ │ │ │ └───────────────────────────────────────────────┘ Expected results: Install completes successfully, and I'm able to boot into the installed system. Additional info: * Full kickstart available at http://jlaska.fedorapeople.org/ks-autoqa-i386.cfg * sh-4.2# tail /tmp/anaconda.log 20:21:25,685 INFO anaconda: removing libuser.conf at /tmp/libuser.kbPvIO 20:21:25,686 INFO anaconda: created new libuser.conf at /tmp/libuser.kbPvIO with instPath="/mnt/sysimage" 20:21:29,992 INFO anaconda: dispatch: leaving (1) step writeconfig 20:21:29,993 INFO anaconda: dispatch: moving (1) to step firstboot 20:21:29,993 DEBUG anaconda: dispatch: firstboot is a direct step 20:21:29,994 INFO anaconda: dispatch: leaving (1) step firstboot 20:21:29,994 INFO anaconda: dispatch: moving (1) to step instbootloader 20:21:29,994 DEBUG anaconda: dispatch: instbootloader is a direct step 20:21:29,995 INFO anaconda: bootloader stage1 target device is vda 20:21:30,012 INFO anaconda: bootloader stage2 target device is vda1 * sh-4.2# tail /tmp/program.log 20:21:30,175 INFO program: Running... grub2-mkconfig -o /boot/grub2/grub.cfg 20:21:31,774 ERR program: Generating grub.cfg ... 20:21:32,489 ERR program: Found linux image: /boot/vmlinuz-3.0.0-1.fc16.i686.PAE 20:21:32,581 ERR program: Found initrd image: /boot/initramfs-3.0.0-1.fc16.i686.PAE.img 20:21:35,403 ERR program: No volume groups found 20:21:36,025 ERR program: done 20:21:36,196 INFO program: Running... grub2-install (hd0) 20:21:44,631 ERR program: /usr/sbin/grub2-setup: warn: This GPT partition label has no BIOS Boot Partition; embedding won't be possible!. 20:21:44,633 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.. 20:21:44,634 ERR program: /usr/sbin/grub2-setup: error: will not proceed with blocklists.
Created attachment 516390 [details] /tmp/anaconda.log
Created attachment 516391 [details] /tmp/program.log
Created attachment 516392 [details] /tmp/syslog
*** Bug 727837 has been marked as a duplicate of this bug. ***
Can you try blanking the disk first? My first guess is that this disk was previously configured as GPT, and right now something is going wrong with using GPT+grub2+BIOS.
(In reply to comment #5) > Can you try blanking the disk first? My first guess is that this disk was > previously configured as GPT, and right now something is going wrong with using > GPT+grub2+BIOS. I retested a kickstart install using the following disk-related commands ... clearpart --all --initlabel zerombr part /boot --fstype=ext4 --size=500 part pv.01 --grow --size=500 part pv.02 --grow --size=500 volgroup vg_autoqa --pesize=32768 pv.01 pv.02 logvol swap --name=lv_swap --vgname=vg_autoqa --recommended logvol / --fstype=ext4 --name=lv_root --vgname=vg_autoqa --grow --size=1024 I'm still seeing the same outcome... │ There was an error installing the bootloader. │ │ The system may not be bootable. │ # tail /tmp/anaconda.log 16:08:41,417 INFO anaconda: dispatch: moving (1) to step firstboot 16:08:41,418 DEBUG anaconda: dispatch: firstboot is a direct step 16:08:41,419 INFO anaconda: dispatch: leaving (1) step firstboot 16:08:41,420 INFO anaconda: dispatch: moving (1) to step instbootloader 16:08:41,420 DEBUG anaconda: dispatch: instbootloader is a direct step 16:08:41,421 INFO anaconda: bootloader stage1 target device is vda 16:08:41,439 INFO anaconda: bootloader stage2 target device is vdc1 # tail /tmp/program.log 16:08:53,152 INFO program: Running... grub2-install (hd0) 16:09:05,475 ERR program: /usr/sbin/grub2-setup: warn: This GPT partition label has no BIOS Boot Partition; embedding won't be possible!. 16:09:05,484 ERR program: /usr/sbin/grub2-setup: error: embedding is not possibll e, but this is required for cross-disk install.
(In reply to comment #5) > Can you try blanking the disk first? My first guess is that this disk was > previously configured as GPT, and right now something is going wrong with using > GPT+grub2+BIOS. It happens even in a new created guest without any data.
The following worked for me on f16alpharc3 with one caveat. The system would not reboot. I had to use vmm gui andforce stop and restart the system after anaconda completed. # The following is the partition information you requested # Note that any partitions you deleted are not expressed # here so unless you clear all partitions first, this is # not guaranteed to work clearpart --all --drives=vda part biosboot --fstype=biosboot --size=1 part /boot --fstype=ext4 --size=500 part / --fstype=ext4 --grow --maxsize=51200 --size=1024 part swap --grow --maxsize=1984 --size=992 bootloader --location=mbr --append="rhgb quiet"
*** Bug 730960 has been marked as a duplicate of this bug. ***
You aren't creating a BIOS boot partition, which you need. We show a warning for this case if you're doing custom interactive partitioning, but since you're doing kickstart the warning is only written to storage.log. /me goes to make sure the install guide has been updated to say you need a BIOS boot partition.
(In reply to comment #10) > /me goes to make sure the install guide has been updated to say you need a BIOS > boot partition. Please make sure you update also this documentation: http://fedoraproject.org/wiki/Anaconda/Kickstart#bootloader Thanks.
*** Bug 733491 has been marked as a duplicate of this bug. ***
I'm experiencing this same problem, and I'm unclear on why Anaconda is creating a GPT partition table instead of an MBR partition table. Am I missing something obvious?
(In reply to comment #13) > I'm experiencing this same problem, and I'm unclear on why Anaconda is creating > a GPT partition table instead of an MBR partition table. Am I missing > something obvious? Anaconda now creates GPT disklabels by default. If you are determined to use MSDOS disklabels you can create one in %pre and/or use clearpart --linux instead of --all.
Hmm. I don't see anything about this in the Release Notes: http://fedoraproject.org/wiki/Fedora_16_Alpha_release_notes nor in the release notes section of the Grub2 feature page: http://fedoraproject.org/wiki/Features/Grub2#Release_Notes Also, as far as I can tell, there are some serious compatibility concerns since Windows 7 can only boot from GPT disks if using UEFI: http://msdn.microsoft.com/en-us/windows/hardware/gg463525 I'm just a little confused about all of the consequences of this change, but I'm having trouble finding information.
(In reply to comment #15) > Also, as far as I can tell, there are some serious compatibility concerns since > Windows 7 can only boot from GPT disks if using UEFI: Is it possible to install Windows 7 into a partition on an already partitioned disk containing a linux installation?
(In reply to comment #16) > > Is it possible to install Windows 7 into a partition on an already partitioned > disk containing a linux installation? I don't know, since I don't install Windows as often as I used to.
It turns out you can install Windows 7 to an existing partition. So, for GPT disklabel to be a problem for you you would need to install Fedora such that it creates a GPT disklabel for you and then later try to install Windows 7 on the same disk. That's a narrow enough segment that I'm not overly concerned. I _might_ be open to an option to the kickstart clearpart command to specify disklabel type, but I am opposed to adding user interface elements to provide this choice. (That might change with a UI redesign, but it might not.) Either measure would require some indication that a real demand exists, of course.
(In reply to comment #10) > You aren't creating a BIOS boot partition, which you need. I have spent quite some time figuring out how to do that, because I have found no relevant info: https://fedoraproject.org/wiki/Anaconda/Kickstart#part_or_partition only to find out someone already added invisible remark here: https://fedoraproject.org/wiki/Anaconda/Kickstart#bootloader I have made that remark more visible. I'll leave the proper changes (of #part command) up to you.
Here's the line you need: part biosboot --fstype=biosboot --size=1
anaconda-16.16-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/anaconda-16.16-1.fc16
anaconda-16.16-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
David, what exactly changed in anaconda-16.16-1? I understood that this whole bug was just a missing documentation issue. Did you change the behavior somehow?
I think I mistakenly referenced this bug in a different bios boot related commit. One thing that is different with anaconda-16.16-1 is that you are now required to create a bios boot partition on bios systems when installing the bootloader to the mbr. This means that you will encounter a fatal error in this situation if you have not specified a bios boot partition, instead of having the bootloader installation fail in mysterious ways. I am considering a patch (already written) to automatically add a bios boot partition when one is needed, but only in kickstart installs that include custom partitioning.
Is it not a valid use case to perform kickstart installation without the partitioning setup in the kickstart file? Thereby getting the GUI screen to set that part up. I have always done that to automate the install apart from partitioning.