Bug 1019541 - unknown install shows up as entire disks instead of mount points of selected disks
Summary: unknown install shows up as entire disks instead of mount points of selected ...
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 20
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Brian Lane
QA Contact: Fedora Extras Quality Assurance
Whiteboard: RejectedBlocker AcceptedFreezeException
Depends On:
Blocks: F20BetaFreezeException 1020569
TreeView+ depends on / blocked
Reported: 2013-10-16 03:19 UTC by Tim Flink
Modified: 2013-11-24 04:00 UTC (History)
13 users (show)

Fixed In Version: pykickstart-1.99.46-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1020569 (view as bug list)
Last Closed: 2013-11-24 04:00:55 UTC
Type: Bug

Attachments (Terms of Use)
screenshot of custom partitioning screen (46.26 KB, image/png)
2013-10-16 03:20 UTC, Tim Flink
no flags Details
screenshot of selected disks dialog (12.57 KB, image/png)
2013-10-16 03:20 UTC, Tim Flink
no flags Details
anaconda.log (34.94 KB, text/plain)
2013-10-16 03:21 UTC, Tim Flink
no flags Details
program.log (56.10 KB, text/plain)
2013-10-16 03:22 UTC, Tim Flink
no flags Details
storage.log (601.97 KB, text/plain)
2013-10-16 03:23 UTC, Tim Flink
no flags Details
screenshot Manual Partitioning (165.96 KB, image/jpeg)
2013-10-21 06:12 UTC, Chris Murphy
no flags Details

Description Tim Flink 2013-10-16 03:19:24 UTC
I started an install with F20 TC4 x86_64 netinstall (anaconda-20.25-1) burned to a usb disk with litd on a system with several disks.

I selected 2 of 4 disks not including the usb stick (sda, sdc) for installation, selected encryption and went into custom partitioning.

When the custom partitioning screen shows up, instead of seeing the mount points on sda and sdc, I see all of the disks in my system despite the bottom of the screen saying "2 storage devices selected" (customPartitioningDisks.png).

Another odd thing is that when I look at the selected disks dialog, it's empty (selectedDisks.png)

Comment 1 Tim Flink 2013-10-16 03:20:11 UTC
Created attachment 812722 [details]
screenshot of custom partitioning screen

Comment 2 Tim Flink 2013-10-16 03:20:58 UTC
Created attachment 812723 [details]
screenshot of selected disks dialog

Comment 3 Tim Flink 2013-10-16 03:21:40 UTC
Created attachment 812724 [details]

Comment 4 Tim Flink 2013-10-16 03:22:26 UTC
Created attachment 812725 [details]

Comment 5 Tim Flink 2013-10-16 03:23:21 UTC
Created attachment 812726 [details]

Comment 6 Fedora Blocker Bugs Application 2013-10-16 03:29:02 UTC
Proposed as a Blocker for 20-beta by Fedora user tflink using the blocker tracking app because:

 Violates the following F20 beta release criterion: "When using the custom partitioning flow, the installer must be able to ... Assign mount points to existing storage volumes"

Comment 7 Tim Flink 2013-10-16 04:10:12 UTC
I tried custom partitioning on my other machine with multiple disks (2x 36G, 1x 1TB, no encryption and a mix of LVM, standard partitions) and everything shows up fine, so it's something about the difference between those systems 

I also tried removing my raid card on the problematic system but ended up with the same results.

Comment 8 David Lehman 2013-10-16 15:07:34 UTC
There are a few things going wrong here:

 1. parted is rejecting the disklabels on sda, sdb, and sdc
 2. something is failing to import __init__ (see anaconda.log@20:14:20,371)
 3. part of commit 1bcfb368 changed things so that now we treat the absence
    of a suitable stage1 bootloader device as a fatal error even if the
    user is headed into the custom spoke

Comment 9 Tim Flink 2013-10-16 15:41:44 UTC
(In reply to David Lehman from comment #8)
> There are a few things going wrong here:
>  1. parted is rejecting the disklabels on sda, sdb, and sdc

I've had problems with corrupt backup gpt tables on this box before and it turns out that it's happened again - all 3 disks had corrupt backup GPT tables.

I rebuilt the backup tables from the primary tables, restarted anaconda and everything appears to be showing up correctly now. I was able to create a layout using the existing partitions and have started the actual installation.

I suspect that this no longer qualifies as a beta blocker unless I'm misunderstanding 2) or 3) from c#8

Comment 10 Adam Williamson 2013-10-16 16:55:00 UTC
Discussed at 2013-10-16 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-16/f20beta-blocker-review-4.2013-10-16-16.02.log.txt . This is a complex issue. Our current understanding is this:

1. Due to "3)" in comment #8, if your disk selection at time of entering custom partitioning does not include a valid bootloader stage1 target device - the most common case of which would be doing a native UEFI install to a system with no existing EFI system partition - your disk selection from the 'disk selection screen' would be ignored, and all disks on the system would be displayed

2. *When issue 1 is in effect*, devices with an invalid partition table are shown in the device tree on the left-hand side of custom partitioning as shown in the screenshot

Assuming this understanding is correct, the bug is rejected as a Beta blocker but accepted as a freeze exception issue. Hitting scenario 2 is quite difficult and it is still not immediately damaging, though there is a risk a user might inadvertently wipe a device in this very specific scenario. Scenario 1 is less damaging - in most cases, the devices that are displayed despite not being selected will still be displayed correctly, and nothing about them will be changed by default (it would still take explicit user action to destroy any of their contents).

Comment 11 Jan Sedlák 2013-10-17 12:37:29 UTC
I have installed F20 on two disks using msdos partition table (BIOS). I put root, swap and boot on first disk and home on second disk. Then I booted F20 Beta TC4 netinst using UEFI and both disks showed up correctly. It showed correct partition names and sizes

Comment 12 Brian Lane 2013-10-17 18:21:53 UTC
I can reproduce this on UEFI. wipe the 2 disks in the machine, go to custom, they show up as 'unknown'. On BIOS everything seems to be working fine.

Comment 13 Chris Murphy 2013-10-18 15:47:02 UTC
Since tflink reports this has happened on this box before it makes me think of a RAID implementation that's not GPT aware, and drops its metadata partially overlapping the GPT secondary header/table causing the corruption. It's actually a somewhat common problem.

So I just tried willfully corrupting the secondary GPT, and parted reports:
Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used. Yet anaconda sees this disk as completely blank and partition free. I'll file a separate bug on this.

Comment 14 Chris Murphy 2013-10-18 16:48:06 UTC
I filed bug 1020974, but except for it being qemu/kvm and thus not UEFI, tflink thinks it's a duplicate.

In the case of an intact protective MBR, and either GPT primary or secondary header/table being valid, the partition scheme is as a whole is valid. The disk cannot be considered blank, otherwise it's a significant invitation to data loss.

Comment 15 Tim Flink 2013-10-18 16:57:41 UTC
somehow, the status change before c#14 was undone by the comment. putting status and fixed-in back where they should be

Comment 16 Chris Murphy 2013-10-21 06:12:30 UTC
Created attachment 814409 [details]
screenshot Manual Partitioning

Screenshot: Manual Partitioning shows partitions for a previously not selected USB stick (the install media).

EFI Mac. Both the selected HDD, and the not selected USB stick have EFI System partitions, and both have (two) valid GPTs with no corruption.

Comment 17 Fedora Update System 2013-10-22 00:32:16 UTC
anaconda-20.25.2-1.fc20 has been submitted as an update for Fedora 20.

Comment 18 Chris Murphy 2013-10-22 01:53:27 UTC
anaconda-20.25.2-1.fc20 fixes the problem described in comment 16.

Comment 19 Fedora Update System 2013-10-22 18:52:45 UTC
Package anaconda-20.25.2-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.2-1.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 20 Adam Williamson 2013-11-06 18:10:16 UTC
20.25.4-1 went stable as part of FEDORA-2013-20033, and the fix was verified, so this can be closed.

Comment 21 Fedora Update System 2013-11-16 02:13:23 UTC
anaconda-20.25.8-1.fc20 has been submitted as an update for Fedora 20.

Comment 22 Fedora Update System 2013-11-17 07:04:38 UTC
Package anaconda-20.25.8-1.fc20, pykickstart-1.99.46-1.fc20, python-blivet-0.23.5-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.8-1.fc20 pykickstart-1.99.46-1.fc20 python-blivet-0.23.5-1.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 23 Fedora Update System 2013-11-24 04:00:55 UTC
pykickstart-1.99.46-1.fc20, python-blivet-0.23.5-1.fc20, anaconda-20.25.9-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

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