Bug 855646 - custom partition setup: missing volume/device identification
custom partition setup: missing volume/device identification
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
18
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
AcceptedNTH RejectedBlocker
:
: 866754 872840 882511 (view as bug list)
Depends On:
Blocks: F18Beta-accepted/F18BetaFreezeExcept
  Show dependency treegraph
 
Reported: 2012-09-09 10:43 EDT by Xavier Hourcade
Modified: 2012-12-03 21:56 EST (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-23 02:27:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Xavier Hourcade 2012-09-09 10:43:30 EDT
Description of problem:

  In custom partition layout screen, little helps to identify existing physical or logical disks/partitions.

  Even the USB stick (holding the Live system being run..) appears as "EFI System Partition" : there is no EFI on this system and I recognize its capacity, that's how I could identify it...

  Same issue for any existing volume on the local hard drive.
  Displaying /dev for each volume would be very helpful.

Version-Release number of selected component (if applicable):

  F18 KDE Live alpha TC5

How reproducible:

  Always

Steps to Reproduce:

  1. Boot, launch Anaconda from Desktop, select language and accept fate
  2. Go to custom partitioning
  
Actual results:

  Volumes are hardly identifiable, only type and size appears.

Expected results:

  Volumes are easily identifiable, /dev path is displayed for each
Comment 1 Chris Lumens 2012-09-09 15:49:53 EDT
The device node path doesn't really mean anything anymore, as the kernel/udev/etc. are free to rename devices between boots as much as they want.  Since those names are completely dynamic, we are deemphasizing them in anaconda.  They're simply not stable, so relying on them as the primary means of identification is foolish.

This does not meet any alpha criteria.  Custom partitioning is only required for beta.
Comment 2 Xavier Hourcade 2012-09-09 17:39:24 EDT
(In reply to comment #1)
> Since those names are completely dynamic, we are deemphasizing them
> in anaconda.  They're simply not stable, so relying on them as the primary
> means of identification is foolish.

Thanks for the explanation :s 

> This does not meet any alpha criteria.  Custom partitioning is only required
> for beta.

May I precise what I am testing here :
- I am *not* trying to make a new custom layout
- I am trying to select *existing* Linux partitions as mount points
  (hence hoping to identify them clearly, with existing LVM/LUKS on the drive)

I assume this bug is eligible, as per criteria 12 for alpha releases ?
Comment 3 Adam Williamson 2012-09-10 00:47:05 EDT
That criterion (for reference, it reads "The installer must be able to complete an installation using the entire disk, existing free space, or existing Linux partitions methods, with or without encryption or LVM enabled") isn't easily applicable to newUI (F18); it's written in a way which is heavily tied to the old UI (those methods are all the ones that were presented to the user as possible automatic partitioning methods, by oldUI). Since newUI doesn't offer such options to the user, the criterion isn't much use in relation to newUI. We're debating a revision to it on the list at present.

This bug does serve as a useful reminder that newUI doesn't have such a neat divide between autopart and custom partitioning as oldUI, which made it pretty easy to set the criteria in the past. newUI only gives *one* 'automatic' option, which is pretty restricted. If we only require that automatic option to work for Alpha, and don't require any kind of other partitioning functionality at all, we're setting the bar quite a lot lower than we did previously...

We should probably kick this around in the next blocker review meeting (or QA meeting tomorrow).
Comment 4 Adam Williamson 2012-09-10 12:38:02 EDT
Discussed at 2012-09-10 QA meeting, acting as a blocker review meeting. We agreed that this issue might qualify as a blocker under current criteria, but the criterion is outdated and specifically tied to the old UI. It is currently undergoing revision. We will revisit this bug once the criterion has been revised.
Comment 5 Xavier Hourcade 2012-09-12 13:01:52 EDT
Does comment #1 mean that identifying volumes by labels/LVM names/UUID, is not planned in Anaconda even for final F18 releases ? Or is it planned from F18 beta onwards ?

As it stands now (alpha RC2):
- existing volumes are shown with types and sizes only
- no labels, VG/LV names, or UUIDs are shown
- two items, "LUKS" and "Unknown", appear and match the size of my LVM/LUKS here
- LUKS contents not listed even unlocked prior to Anaconda launch (bug 855644)
- USB stick appears as "EFI System Partition"
Comment 6 Adam Williamson 2012-09-12 13:48:08 EDT
Discussed at 2012-09-12 blocker review meeting. We agreed this doesn't meet the existing criterion, which covers only creation of a new partition layout, not re-use of existing partitions (the reference to 'use existing Linux partitions' is to an autopart method which *destroys* existing Linux partitions and creates new ones in their space). It does not meet any of the proposed revisions to the partitioning criteria, all of which are looser than the present criteria. Therefore, it is rejected as a blocker.
Comment 7 Joergen Thomsen 2012-09-21 17:22:54 EDT
Now that the alpha has been released, will the developers, please, forget about the bureaucracy and address the core of the problem: loss of control over the physical disk layout, which may be important in some cases ?
Comment 8 Chris Lumens 2012-10-16 11:03:30 EDT
*** Bug 866754 has been marked as a duplicate of this bug. ***
Comment 9 Adam Williamson 2012-10-16 17:25:54 EDT
There's a screenshot attached to the most recent dupe:

https://bugzilla.redhat.com/attachment.cgi?id=627935

which neatly illustrates the problem. Good luck figuring out what any of those are. There's also the special case that a Fedora USB stick is detected as an EFI system partition, which obviously isn't right, that should be fixed up somehow.

I'm not really sure what the best way to 'fix' this is, but looking at the above screengrab, the current design clearly isn't sufficient.
Comment 10 Adam Williamson 2012-10-16 17:26:40 EDT
CCing Mo for design insights.
Comment 11 Xavier Hourcade 2012-10-22 13:49:18 EDT
Just tried Anaconda from Fedora-18-Beta-TC6-x86_64-Live-KDE.iso, it has been quite improved and here is what I observed :

- Some volumes are now identifiable by their labels (if set)
- Some volumes are now grouped by discovered existing installations,
  and (eventually) identifiable by their respective mount points (fstab ?)
- LVM names or UUIDs are not shown (as previously)

*First* time we enter custom partitioning, and after unlocking the crypt here (which name might not be displayed either, IIRC), volumes do appear organized under per-existing-installation trees/sections (eg. "Fedora 17", "Fedora 16", "Unknown"), and are identifiable by their previous mount points from discovered fstab (? eg. /boot / swap /vol/local/whatever" etc.). If selecting one of these volumes, labels are also viewable in Anaconda right pane.

*Second* time we enter custom partitioning (that is, if pressing Back/Finish Partitioning and entering it again), this entire "existing installations tree" is no longer shown (labels only), i.e. all volumes appear in a long list without identifiers as previously (those volumes with labels set are still viewable in the right pane) which must be a bug. In my case, I can still distinguish eg. Fedora root partitions (by their classic label) but neither boot volumes, nor any other.

Any time, after defining mount points and "Apply'ing Changes" related volumes appear under the "Fedora 18" proposed layout section at the top, hence only identifiable by their labels (if set).

Also, all discovered swap volumes are automatically added to the proposed layout.

Labels and/or old mount points from discovered fstab, might not be sufficient to recognize each volume accurately :
- some labels might not have ever been set
- existing volumes might not have been defined in any fstab
- swap are not distinguishable

NB. On this system I only have 4 partitions including 1 x LVM and 1 x LUKS+LVM (no RAID nor any other more complex layouts)
Comment 12 Adam Williamson 2012-10-22 21:00:28 EDT
We already came up with a plan to improve this further. The /dev name of all 'Unknown' partitions will be shown (sda1, sdb3, etc), and the partitions in 'Unknown' will be ordered by physical disk + partition order. We figure that should be enough for most use cases to be able to identify their partitions. http://dlehman.fedorapeople.org/device-ids.1.png is a rough mockup of how it'll look.
Comment 13 Xavier Hourcade 2012-10-22 21:47:59 EDT
Thanks for sharing, looks helpful.
Will LVM volumes be shown and ordered as "vgname: lvname", then ?
Comment 14 Adam Williamson 2012-10-31 13:30:07 EDT
Discussed at 2012-10-31 NTH review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-31/f18beta-blocker-review-6.2012-10-31-16.00.log.txt . Accepted as NTH as this is a clearly significant and useful improvement to testability of custom partitioning, cannot be fixed with an update.
Comment 15 David Lehman 2012-11-05 10:01:38 EST
*** Bug 872840 has been marked as a duplicate of this bug. ***
Comment 16 Adam Williamson 2012-11-08 02:45:23 EST
David, what's the status of this? I kinda figured it was a quick fix that would go in soon after we discussed it, but it's not in 18.27. did it just kinda drop off the radar with all the other emergencies?
Comment 17 Fedora Update System 2012-11-20 17:02:47 EST
anaconda-18.29.2-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2012-18468/anaconda-18.29.2-1.fc18
Comment 18 Fedora Update System 2012-11-21 15:51:15 EST
Package anaconda-18.29.2-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-18.29.2-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-18468/anaconda-18.29.2-1.fc18
then log in and leave karma (feedback).
Comment 19 Adam Williamson 2012-11-22 20:49:31 EST
Confirming this is in 18.29.2 (RC1), nice!
Comment 20 Fedora Update System 2012-11-23 02:27:41 EST
anaconda-18.29.2-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 Chris Lumens 2012-12-03 21:56:36 EST
*** Bug 882511 has been marked as a duplicate of this bug. ***

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