Bug 967660 - anaconda erases additional biosboot partitions outside of what was setup for 'reformat' (destroys spare biosboot partitions one might have on other disks)
anaconda erases additional biosboot partitions outside of what was setup for ...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
19
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
AcceptedBlocker
: Reopened
Depends On:
Blocks: F19Blocker/F19FinalBlocker
  Show dependency treegraph
 
Reported: 2013-05-27 17:26 EDT by Reartes Guillermo
Modified: 2013-06-05 09:20 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-04 12:33:39 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
custom partitioning screen (95.36 KB, image/png)
2013-05-27 17:26 EDT, Reartes Guillermo
no flags Details
summaty of changes (94.19 KB, image/png)
2013-05-27 17:27 EDT, Reartes Guillermo
no flags Details
anaconda.log (30.96 KB, text/plain)
2013-05-27 17:28 EDT, Reartes Guillermo
no flags Details
storage.log (429.00 KB, text/plain)
2013-05-27 17:28 EDT, Reartes Guillermo
no flags Details
On the KVM guest where i reproduced the issue. (124.79 KB, text/plain)
2013-05-27 17:29 EDT, Reartes Guillermo
no flags Details
program.log (124.79 KB, text/plain)
2013-05-27 17:32 EDT, Reartes Guillermo
no flags Details

  None (edit)
Description Reartes Guillermo 2013-05-27 17:26:16 EDT
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.
Comment 1 Reartes Guillermo 2013-05-27 17:27:09 EDT
Created attachment 753677 [details]
summaty of changes

I setup a guest and reproduced the issue.
Comment 2 Reartes Guillermo 2013-05-27 17:28:02 EDT
Created attachment 753678 [details]
anaconda.log

On the KVM guest where i reproduced the issue.
Comment 3 Reartes Guillermo 2013-05-27 17:28:41 EDT
Created attachment 753679 [details]
storage.log

On the KVM guest where i reproduced the issue.
Comment 4 Reartes Guillermo 2013-05-27 17:29:03 EDT
Created attachment 753680 [details]
On the KVM guest where i reproduced the issue.
Comment 5 Reartes Guillermo 2013-05-27 17:29:46 EDT
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
Comment 6 Reartes Guillermo 2013-05-27 17:32:02 EDT
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
Comment 7 Reartes Guillermo 2013-05-27 18:10:00 EDT
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. :-(
Comment 8 Reartes Guillermo 2013-05-28 21:37:49 EDT
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.
Comment 9 Adam Williamson 2013-05-30 14:25:12 EDT
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.
Comment 10 Brian Lane 2013-06-03 20:50:43 EDT
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.
Comment 11 Reartes Guillermo 2013-06-04 10:16:11 EDT
@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.
Comment 12 Brian Lane 2013-06-04 12:33:39 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.