Bug 855646

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.

(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 ?

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).

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.

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"

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.

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 ?

*** Bug 866754 has been marked as a duplicate of this bug. ***

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.

CCing Mo for design insights.

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)

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.

Thanks for sharing, looks helpful.
Will LVM volumes be shown and ordered as "vgname: lvname", then ?

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.

*** Bug 872840 has been marked as a duplicate of this bug. ***

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?

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

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).

Confirming this is in 18.29.2 (RC1), nice!

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.

*** Bug 882511 has been marked as a duplicate of this bug. ***