Created attachment 753676 [details] custom partitioning screen Description of problem: I installed F19b RC4 on my main PC and experienced a not so good issue. I selected a biosboot partition for 'reformat' and anaconda formatted it but anaconda also formatted the other 'spare' biosboot partition on the other disk, which was not selected for 'reformat'. I had to restore from file one of the biosboot partitions in order to boot back F17. The affected partiton was NOT selected for 'reformat' in anaconda. I setup a guest to reproduce the issue. Version-Release number of selected component (if applicable): F19b RC4 (19.30-1) How reproducible: always Steps to Reproduce: #1: Setup Details: (an explanation of my setup): Used disks: vda,vdb (both with a gpt disklabel) Other disks: vdc,vdd,vdc,vde (all have a gpt disklabel, but they were not selected in anaconda). * vda1 -> biosboot-main * vdb1 -> biosboot-spare There are two biosboot partitions, one in each disk. They are synchronized manually, that is why i call then main/spare. So, for this test, i decided to use biosboot-main (vda1) and leave biosboot-spare (vdb1) as a backup. Before the test, i performed a backup of both biosboot partitions and used sha256sum to verify that they were synchronized. (and they were). * vda2 -> root-fs-side-A-main * vdb2 -> root-fs-side-A-mirror * vda3 -> root-fs-side-B-main * vdb3 -> root-fs-side-B-mirror Yes, like a spacecraft, there are two possible locations for md mirrored '/' partitions. One (currently side-A) is used by F17, the other (side-B) is available for Fedora-Next (currently F19) for use as the / partition. * vda4 -> home-fs-main * vdb4 -> home-fs-mirror This is the /home md mirror, this belongs currently to F17. So: * 'root-fs-side-A' contains F17, my main os at the moment. This should not be touched. * 'home-fs' contains the home partition. This also should not be touched. * 'biosboot-spare' leave it intact, in case Anaconda messes up the main one. * I will install F19b RC4 to 'root-fs-side-B' and use 'biosboot-main' to store the bootloader. Steps to Reproduce: 0. Setup other Anaconda Spokes. 1. Enter Storage: Installation Destination 2. Selected 'vda' and 'vdb' only. 3. Choose 'standard partition' partition scheme and 'custom partitioning' 4. Selected 'biosboot-main' (vda1) and marked it 'reformat' 5. Selected 'root-fs-side-B' (md raid1 device) and marked it 'reformat' and set '/' for mount point. 6. In the Main Hub, i hit bug 966784. 7. I installed F19b RC4 without error, reboot and boot. 9. Both 'biosboot-main' and 'biosboot-spare' contains the F19b RC4 bootloader payload. Good luck i made a backup of those... I restored 'biosboot-spare' in order to boot F19. Actual results: 'biosboot-spare' (vdb1), while never ever selected for 'reformat', contains a copy of 'biosboot-main' which was selected for reformat. Anaconda formatted BOTH. I had to restore from file the 'biosboot-spare' in order to boot F17. Expected results: Do not 'reformat' partitions that were not select for 'reformat'. Additional info: The problem was worsened by the fact that there was no Fedora 17 option in the grub2 menu. This might be another bug, because F17 was not detected nor offered as a boot option for some reason.
Created attachment 753677 [details] summaty of changes I setup a guest and reproduced the issue.
Created attachment 753678 [details] anaconda.log On the KVM guest where i reproduced the issue.
Created attachment 753679 [details] storage.log On the KVM guest where i reproduced the issue.
Created attachment 753680 [details] On the KVM guest where i reproduced the issue.
Comment on attachment 753680 [details] On the KVM guest where i reproduced the issue. From program.log: 18:09:51,084 INFO program: Running... grub2-install --no-floppy /dev/vda 18:09:54,202 INFO program: Installation finished. No error reported. 18:09:54,204 DEBUG program: Return code: 0 18:09:54,204 INFO program: Running... grub2-install --no-floppy /dev/vdb 18:09:59,294 INFO program: Installation finished. No error reported. 18:09:59,297 DEBUG program: Return code: 0 18:10:02,644 INFO program: Running... grub2-set-default Fedora Linux, with Linux 0-rescue-3ea693951c66e80bfe6f2a098ec24fe7 18:10:02,857 DEBUG program: Return code: 0 18:10:02,858 INFO program: Running... grub2-mkconfig -o /boot/grub2/grub.cfg 18:10:06,931 INFO program: Generating grub.cfg ... 18:10:06,932 INFO program: Found linux image: /boot/vmlinuz-3.9.2-301.fc19.x86_64 18:10:06,933 INFO program: Found initrd image: /boot/initramfs-3.9.2-301.fc19.x86_64.img 18:10:06,933 INFO program: Found linux image: /boot/vmlinuz-0-rescue-3ea693951c66e80bfe6f2a098ec24fe7 18:10:06,934 INFO program: Found initrd image: /boot/initramfs-0-rescue-3ea693951c66e80bfe6f2a098ec24fe7.img 18:10:06,934 INFO program: done 18:10:06,935 DEBUG program: Return code: 0
Created attachment 753681 [details] program.log From program.log: 18:09:51,084 INFO program: Running... grub2-install --no-floppy /dev/vda 18:09:54,202 INFO program: Installation finished. No error reported. 18:09:54,204 DEBUG program: Return code: 0 18:09:54,204 INFO program: Running... grub2-install --no-floppy /dev/vdb 18:09:59,294 INFO program: Installation finished. No error reported. 18:09:59,297 DEBUG program: Return code: 0 18:10:02,644 INFO program: Running... grub2-set-default Fedora Linux, with Linux 0-rescue-3ea693951c66e80bfe6f2a098ec24fe7 18:10:02,857 DEBUG program: Return code: 0 18:10:02,858 INFO program: Running... grub2-mkconfig -o /boot/grub2/grub.cfg 18:10:06,931 INFO program: Generating grub.cfg ... 18:10:06,932 INFO program: Found linux image: /boot/vmlinuz-3.9.2-301.fc19.x86_64 18:10:06,933 INFO program: Found initrd image: /boot/initramfs-3.9.2-301.fc19.x86_64.img 18:10:06,933 INFO program: Found linux image: /boot/vmlinuz-0-rescue-3ea693951c66e80bfe6f2a098ec24fe7 18:10:06,934 INFO program: Found initrd image: /boot/initramfs-0-rescue-3ea693951c66e80bfe6f2a098ec24fe7.img 18:10:06,934 INFO program: done 18:10:06,935 DEBUG program: Return code: 0
ALPHA CRITERIA: Disk selection: * Other disks not touched: Disks not selected as installation targets must not be affected by the installation process in any way. This mentions 'disks' 'not partitions', and the issue is at partition level, not disk, because the disk was selected. With the exception that i selected vda for the bootloader and not vdb. BETA CRITERIA: Custom partitioning: When using the custom partitioning flow, the installer must be able to: * Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions * Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions * Remove a planned storage volume from the planned layout * Assign sizes to newly-created storage volumes and containers * Encrypt newly-created storage volumes * Remove existing storage volumes * Assign mount points to existing storage volumes * Reject or disallow invalid disk and volume configurations without crashing. I could not find any criteria that forbids formatting a partition that was not selected for being formatted. Aka: selected Partition_A as biosboot and anaconda formats Partition_A and Partition_X as biosboot. FINAL CRITERIA: * The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above This also does not match, so no blocker at all, not even for final. :-(
The bootloader target is vda (this is was is selected in installation options), but vdb is also setup 'for free'. I am proposing it as a FFE.
Discussed at 2013-05-30 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-30/f19final-blocker-review-1.1.2013-05-30-16.02.log.txt . We actually decided to promote this to a blocker bug per final criterion "All known bugs that can cause corruption of user data must be fixed or documented at Common F19 bugs". It's a slight squeeze as its arguable whether the contents of a BIOS boot partition are 'user data', but it at least fits the intent, which is 'we shouldn't mess with your existing stuff when installing': this bug can clearly break existing OS installs, which is very bad.
If I'm reading things correctly what you did was install onto an existing RAID1 which spans vda and vdb. Your /boot is on the raid so grub does have permission to touch the disk -- it needs to be installed to both drives, otherwise it won't boot when one fails. I think it is the grub2-install that is overwriting your other biosboot (it wasn't anaconda, it only touched the one on vda1). If you don't want it to touch the other drive's bootloader/biosboot then you need to go to 'Full Disk Summary and Bootloader" in the storage spoke and turn off installing a bootloader and handle it yourself.
@Brian C. Lane I am reopening this, further analysis is needed. I do agree to most of comment #10, but it should not be closed at the moment and not by notabug. (at least yet). I tried to workaround the fact that the second biosboot partition will be ovewriten by 'protecting it'. I did that by changing the guid of the biosboot partition to another one (i used solaris boot [be02]). To my surprise grub2 tried to put itself on such partition and of course failed. See Bug 969684 Comment #22. 10:53:06,622 INFO program: Running... grub2-install --no-floppy /dev/vda 10:53:09,829 INFO program: Installation finished. No error reported. 10:53:09,836 DEBUG program: Return code: 0 10:53:09,837 INFO program: Running... grub2-install --no-floppy /dev/vdb 10:53:14,116 INFO program: /usr/sbin/grub2-bios-setup: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible. 10:53:14,123 INFO program: /usr/sbin/grub2-bios-setup: error: embedding is not possible, but this is required for RAID and LVM install. 10:53:14,125 DEBUG program: Return code: 1 Also another reason for being notabug is the fact (i did not noticed it at first) but i retried the action and F18 pointed out (and most likely correctly) that it will not install to a v1.2 metadata for /boot (no separate /boot thus / should also not bee v1.2). I did not further test this, but it might be right because the 'side-A' was created by anaconda while the 'side-B' was created manually and it was v1.2 metadata. F19b RC4 did not validate that. Please do not close the bug-reports like that. Give some time for the bug-reported to accept that it was not a bug, or time to give more arguments. Cheers.
This specific action is not a bug, that's why I closed it. If we are not checking the metadata type for pre-existing raid arrays when putting /boot on them then that is a separate bug against python-blivet. Changing the biosboot to something else is bound to confuse things. You need to not install a bootloader and handle that yourself. Please try to limit the scope of your bugs. I appreciate the detail, but lumping multiple things together and running off on tangents makes it very hard to keep track of what is actually going on.