Description of problem: First reported on 1008137, but seems to be different problem. Installed F20 Final TC3 on an LV without separate boot partition. Failed at bootloader installation. cmdline: /usr/bin/python /sbin/anaconda cmdline_file: initrd=initrd.img inst.stage2=hd:UUID=6cdb3bdc-1802-4c98-b650-7440cd7cab7d selinux=0 BOOT_IMAGE=vmlinuz hashmarkername: anaconda kernel: 3.11.9-300.fc20.x86_64 package: anaconda-20.25.11-1 product: Fedora reason: BootLoaderError: bootloader install failed release: Cannot get release name. version: 20-TC3 Version-Release number of selected component (if applicable): 20 TC3 How reproducible: Tried 2 times, both failed Steps to Reproduce: 1. Boot F20TC3 from usb key. 2. Select disks that make up raid 10 PV and disk that has MBR as boot disk. 3. Select LVM method and custom partitioning 4. Create 20 GB / LV on the PV. 5. Select existing /home LV to mount on new / 6. Select a couple more existing LVs to mount on new / 7. Did not create a separate /boot partition. 8. Done. 9. Select gnome DE. 10. Select start installation and create root password 11. Installation fails at installation of bootloader. Actual results: Installation failed at installation of bootloader Expected results: Normal installation with /boot on LV. Additional info: Fedora 18 installed ok using same method. Tried chroot into installed F20 and then grub2-install to /dev/sda, but it failed. Will try to recreate later to get exact error msg.
Created attachment 831578 [details] anaconda-tb-* As requested in comment 15, bz 1008137.
I am able to get to the F20 installation via a grub 40_custom on F18. When trying to install the bootloader to boot directly to F20 I get: [root@P5E-WSPRO ~]# grub2-install --no-floppy /dev/sda Path `/boot/grub2' is not readable by GRUB on boot. Installation is impossible. Aborting.
I didn't have time to follow the reproducer (it requires you to have RAID+LVM prior to installation, IIUIC), but I did something similar and reproduced the crash. It's in bug 1008137 comment 18.
Created attachment 831681 [details] anaconda-tb for comment 3
Discussed at 2013-12-02 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-02/f20-blocker-review-%234.2013-12-02-17.02.log.txt . Accepted as a blocker per Final criterion "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration." - kparal reproduced it using anaconda to create an LVM/RAID-10 layout, per his description in https://bugzilla.redhat.com/show_bug.cgi?id=1008137#c18 (and his anaconda-tb, which contains the same error as clyde's).
I can't reproduce as described by either this bug's description of bug 1008137 c18 with anaconda 20.25.11-1. 1. 4 empty disks selected 2. Manual Partitioning, create one mountpoint / set to device type LVM. 3. Go to Volume Group > Modify > RAID Level set to RAID10. Update settings. 4. Install Succeeds and boots. If this can be reproduced, I'd like to see the result from the anaconda.program.log grub2-install command with --debug added, capture the output and attach as a file. A ton of text is produced with --debug so it's best to use virsh console or enable sshd in the install environment.
I am not sure the summary change above is accurate. The /boot partition is on the root LV that is on an existing software raid 10 PV. The MBR is on an ordinary ms-dos disk. It doesn't make sense to specify raid10 during the creation of the LV since I specify the VG which is on the existing raid10. I used this method with F18 (skipped 19 on this machine).
sorry, i thought both reproducers so far involved RAID-10 and that seemed a key to hitting the bug.
Created attachment 832036 [details] debug output of grub for comment 9 (In reply to Chris Murphy from comment #6) > I can't reproduce as described by either this bug's description of bug > 1008137 c18 with anaconda 20.25.11-1. > > 1. 4 empty disks selected > 2. Manual Partitioning, create one mountpoint / set to device type LVM. > 3. Go to Volume Group > Modify > RAID Level set to RAID10. Update settings. > 4. Install > Succeeds and boots. I found the difference. I also downsized the / partition (after step 3). From 20 GB to 10 GB. If I don't downsize it, it really works. When I downsize it, it crashes with this error. Tested with empty disks. > If this can be reproduced, I'd like to see the result from the > anaconda.program.log grub2-install command with --debug added, capture the > output and attach as a file. Attached.
For the record, dlehman stated yesterday that he's proposing to simply disallow /boot-on-LVM along with /boot-on-btrfs as a big hammer way of dealing with this, https://bugzilla.redhat.com/show_bug.cgi?id=864198 , https://bugzilla.redhat.com/show_bug.cgi?id=1008137 , and any others - he considers this kind of '/boot on complex filesystem configuration' stuff to be corner case use that is not worth investing time in fixing, it's much more straightforward to just require it to be on a simple filesystem.
Please excuse me if I am being redundant, but I want to make sure folks are not looking into two different issues. I see some are creating VG/LVs and making them into the raid10 flavor. I am NOT doing that. My issue is that I am creating the LV on an existing VG that resides on a software raid10 device. Is there a difference? I believe so. Could someone tell me if my method is supported or not: 1. Using anaconda, select the disks that make up the 4 disk raid10 device and select the separate boot drive (as reported by the bios). 2. Creeate the installation / in the partitioner. Do not create a separate boot partition anywhere. 3. Start installation of software. 4. Installation of disk loader fails. So, if this method is not supported, then there should be a msg to that effects before software is installed. If booting to an LV is only supported from a standard ext4 partition, then that should be part of the msg. Doing some Googling on this it seems that others are creating /boot on a separate standard ext4 partition, then hacking around to copy it to the LV /boot and fixing up grub.cfg or grub.conf to boot directly into the LV. I did not install F19 on this machine, but I did install F18 on it and it boots directly into the LV without any separate ext4 /boot.
(In reply to Adam -Williamson from comment #10) > For the record, dlehman stated yesterday that he's proposing to simply > disallow /boot-on-LVM along with /boot-on-btrfs as a big hammer way of > dealing with this, https://bugzilla.redhat.com/show_bug.cgi?id=864198 , > https://bugzilla.redhat.com/show_bug.cgi?id=1008137 , and any others - he > considers this kind of '/boot on complex filesystem configuration' stuff to > be corner case use that is not worth investing time in fixing, it's much > more straightforward to just require it to be on a simple filesystem. Was commenting at the same time. I am ok with dlehman's suggestion for now since there is an easy workaround for the boot-on-lvm. However, I hope boot-on-btrfs is allowed with subsequent releases. Thanks for the hard work on this. From my perspective, this bz can be taken off the blocker list, but should be left open for resolution later.
Patch to disallow /boot on lvm posted for review.
(In reply to Kamil Páral from comment #9) > Attached. Could you run this and post the results? (This may fork into a grub2 bug, as it should be able to handle this use case even if anaconda dev decides to go with a simpler approach.) grub2-probe -t fs -v /boot/grub2
(In reply to Chris Murphy from comment #14) > Could you run this and post the results? (This may fork into a grub2 bug, as > it should be able to handle this use case even if anaconda dev decides to go > with a simpler approach.) > > grub2-probe -t fs -v /boot/grub2 grub2-probe: info: cannot open `/boot/grub2/device.map': No such file or directory. grub2-probe: info: changing current directory to /dev/mapper. grub2-probe: info: /dev/dm-0 is not DM-RAID. grub2-probe: info: Looking for /dev/mapper/live-rw. grub2-probe: info: /dev/dm-0 is not DM-RAID. grub2-probe: info: /dev/dm-0 is not DM-RAID. grub2-probe: info: /dev/dm-0 is not DM-RAID. grub2-probe: info: Looking for /dev/mapper/live-rw. grub2-probe: info: /dev/dm-0 is not DM-RAID. grub2-probe: info: /dev/dm-0 is not DM-RAID. grub2-probe: info: /dev/dm-0 is not DM-RAID. grub2-probe: info: Looking for /dev/mapper/live-rw. grub2-probe: info: /dev/dm-0 is not DM-RAID. grub2-probe: info: /dev/dm-0 is not DM-RAID. grub2-probe: error: cannot find a GRUB drive for /dev/mapper/live-rw. Check your device.map.
anaconda-20.25.14-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.25.14-1.fc20
Package anaconda-20.25.14-1.fc20, python-blivet-0.23.8-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-20.25.14-1.fc20 python-blivet-0.23.8-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-22800/python-blivet-0.23.8-1.fc20,anaconda-20.25.14-1.fc20 then log in and leave karma (feedback).
Note: as previously discussed, the 'fix' here is that we just don't allow /boot on LVM any more. So, be aware of that in your testing. If someone finds they can hit this bug without /boot being on LVM (or btrfs), it's not fixed, please panic as loudly as possible.
I tested F20 TC5 and I can't make the graphical installer use lvm/thinlvm/btrfs for /boot partition. So far the fix looks good. It would be also good if somebody tested these combination with a kickstart.
anaconda-20.25.14-1.fc20, python-blivet-0.23.8-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Kamil Páral from comment #15) > grub2-probe: error: cannot find a GRUB drive for /dev/mapper/live-rw. Check > your device.map. Was the grub2-probe command run in chroot /mnt/sysimage environment? It seems to pick up the live-rw location for /boot/grub2 which is read only, rather than the /mnt/sysimage/boot/grub2 which should be read writable. It's a minor point I guess due to the decision to not put /boot on an LV.
(In reply to Chris Murphy from comment #21) > Was the grub2-probe command run in chroot /mnt/sysimage environment? No, this didn't occur to me. I can reproduce the problem with chroot, if it is important.