Bug 967660
Summary: | anaconda erases additional biosboot partitions outside of what was setup for 'reformat' (destroys spare biosboot partitions one might have on other disks) | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Reartes Guillermo <rtguille> | ||||||||||||||
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||||||||||||
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||
Severity: | high | Docs Contact: | |||||||||||||||
Priority: | unspecified | ||||||||||||||||
Version: | 19 | CC: | anaconda-maint-list, awilliam, dshea, g.kaviyarasu, jonathan, jones.peter.busi, mkolman, robatino, sbueno, vanmeeuwen+fedora | ||||||||||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||||||||||
Target Release: | --- | ||||||||||||||||
Hardware: | x86_64 | ||||||||||||||||
OS: | Linux | ||||||||||||||||
Whiteboard: | AcceptedBlocker | ||||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||
Clone Of: | Environment: | ||||||||||||||||
Last Closed: | 2013-06-04 16:33:39 UTC | Type: | Bug | ||||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||||
Documentation: | --- | CRM: | |||||||||||||||
Verified Versions: | Category: | --- | |||||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||
Embargoed: | |||||||||||||||||
Bug Depends On: | |||||||||||||||||
Bug Blocks: | 834090 | ||||||||||||||||
Attachments: |
|
Description
Reartes Guillermo
2013-05-27 21:26:16 UTC
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. |