Hide Forgot
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)
Created attachment 812722 [details] screenshot of custom partitioning screen
Created attachment 812723 [details] screenshot of selected disks dialog
Created attachment 812724 [details] anaconda.log
Created attachment 812725 [details] program.log
Created attachment 812726 [details] storage.log
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"
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.
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
(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
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).
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
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.
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.
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.
somehow, the status change before c#14 was undone by the comment. putting status and fixed-in back where they should be
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.
anaconda-20.25.2-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.25.2-1.fc20
anaconda-20.25.2-1.fc20 fixes the problem described in comment 16.
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: https://admin.fedoraproject.org/updates/FEDORA-2013-19692/anaconda-20.25.2-1.fc20 then log in and leave karma (feedback).
20.25.4-1 went stable as part of FEDORA-2013-20033, and the fix was verified, so this can be closed.
anaconda-20.25.8-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.25.8-1.fc20
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: https://admin.fedoraproject.org/updates/FEDORA-2013-21553/pykickstart-1.99.46-1.fc20,python-blivet-0.23.5-1.fc20,anaconda-20.25.8-1.fc20 then log in and leave karma (feedback).
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.