Created attachment 694620 [details] Screenshot 1: I wnet straight to MANUAL PARTITIONING. Description of problem: I am installing F18 on a test machine in our lab which has a disk with 15 partitions already used. One is for swap, one is extended, the other 13 partitions are different Linux installations (mostly RHEL and SLES). The goal is to choose one of the preexisting partitions and overwrite it with a fresh F18 installation. This has worked nicely with all distributions so far. Unfortunately anaconda in F18 doesn't offer the option to simply grab and overwrite an exisiting partition. Rather, partitions of exisiting distributions must be deleted and then recreated for F18. But that's not the point here. The point is: I selected /dev/sdb8 to be overwritten, but anaconda installed on /dev/sdb15, overwriting another distro which I hadn't planned to delete. I am going to attach a series of screen shots illustrating what I did, and what went wrong.
Created attachment 694621 [details] Screenshot 2: Selected /dev/sdb8 to be deleted (12th distro in list)
Created attachment 694623 [details] Screenshot 3: After deleting /dev/sdb8 The operation apparently succeeded. Weirdly, another distro, the 2nd in the tree, has been opened with /deb/sdb9 as root. The distro with /dev/sdb9 as root was number 13 in the tree before the deletion.
Created attachment 694624 [details] Screenshot 4: checking /dev/sdb8 Checking back in the entry I wanted to delete, the root file system is now gone. This looks correct.
Created attachment 694625 [details] Screenshot 5: Creating the new mount point for the new installation
Created attachment 694626 [details] Screenshot 6: anaconda offers me an LVM partition This is not what I want (although it would have been interesting to see the outcome)
Created attachment 694631 [details] Screenshot 7: standard partition sdb9? After changing the device type to "standard partition", anaconda says "name: sdb9"; surely not what I intended.
Created attachment 694634 [details] Screenshot 8: Changes to /dev/sdb15 after "apply" Being curious (none of the installations on this server are particularly valuable), I clicked on "Apply Changes", and anaconda changed the partion name from sdb9 to sdb15. Further clicks on "Apply" don't change anything any more.
Created attachment 694635 [details] Screenshot 9: /dev/sdb8 has reappeared Checking the tree, I find that the partition I meant to delete is back again, although 13th in the tree this time (everything seems to shifted down, possibly because sdb9 went up, see screenshot 3).
Created attachment 694636 [details] anaconda log files The log files of this installation.
Being curious what anaconda would actually do now, I started the installation, and it installed F18 without errors or warnings on /dev/sdb15. /dev/sdb8 remained untouched, and so did /dev/sdb9. I have reproduced this twice already on this system, it is deterministic behavior.
> The goal is to choose one of the preexisting partitions and overwrite it > with a fresh F18 installation. This has worked nicely with all distributions > so far. Unfortunately anaconda in F18 doesn't offer the option to simply > grab and overwrite an exisiting partition. Rather, partitions of exisiting > distributions must be deleted and then recreated for F18. But that's not the > point here. Sure it offers that option. Click on the first filesystem you want to use and it will open up on the right hand side. Then you either just assign it a mountpoint (in the case of something like /home), or you click reformat and then assign it a mountpoint (in the case of something like /). There's no need to go through all the extra steps of deleting things and then making new ones.
When a logical partition is deleted, all logical partitions following it are renumbered with the old partition number reduced by 1. Dave explains this behavior in Bug 902275, Comment 28. In this case: sdb8 is deleted. sdb9 becomes sdb8. ... sdb15 becomes sdb14. sdb15 is created. Note to developers: The fact that this has come up twice now indicates a major GUI design problem -- users have no coherent overview of what is happening with their partitions, so they cannot possibly understand this logical partition renumbering behavior. [snippet from attached storage.log] ... 16:22:51,608 INFO storage: devices to scan: ['sda', 'sdb', 'sdb1', 'sdb10', 'sdb11', 'sdb12', 'sdb13', 'sdb14', 'sdb15', 'sdb2', 'sdb3', 'sdb4', 'sdb5', 'sdb6', 'sdb7', 'sdb8', 'sdb9', 'sr0', 'loop0', 'loop1', 'loop2', 'loop3', 'loop4', 'loop5', 'loop6', 'loop7', 'dm-0'] ... 'name': 'sdb', ... type: msdos primaryPartitionCount: 4 lastPartitionNumber: 15 maxPrimaryPartitionCount: 4 ...
(In reply to comment #12) ... > Note to developers: The fact that this has come up twice now indicates a > major GUI design problem -- users have no coherent overview of what is > happening with their partitions, so they cannot possibly understand this > logical partition renumbering behavior. ... A solution would be to add two tabs that would let users switch between the installation view and a partition tree view ...
(In reply to comment #11) > Sure it offers that option. Click on the first filesystem you want to use > and it will open up on the right hand side. Then you either just assign it > a mountpoint (in the case of something like /home), or you click reformat > and then assign it a mountpoint (in the case of something like /). There's > no need to go through all the extra steps of deleting things and then making > new ones. All right. I didn't understand that when I looked at the dialog. I actually totally overlooked the "Reformat" button, several times (tried this installation at least 3-4 times before I reported this bug). I guess I must learn to look closer. In part, this is a psychological effect of the GUI - the fact the installed distribution is the primary object (and the partition secondary) made it non-obvious to me to "reformat" the partition at this point. IMO it would be more logical to offer an option to reassign this partition from the old distribution to the new one.
(In reply to comment #13) > A solution would be to add two tabs that would let users switch between the > installation view and a partition tree view ... I would strongly second that. From my point of view, at the moment of partitioning, I am mostly interested in the partitions, not the installations. It is of course valuable information to be able to see whether a given partition belongs to an existing installation; that's a great feature of the new UI. But I don't think it justifies "hiding" the partition tree in the way anaconda is currently doing it. Just my €0.02.
(In reply to comment #12) > When a logical partition is deleted, all logical partitions following it are > renumbered with the old partition number reduced by 1. Dave explains this > behavior in Bug 902275, Comment 28. > > In this case: > sdb8 is deleted. > sdb9 becomes sdb8. > ... > sdb15 becomes sdb14. > sdb15 is created. Are you talking about the actual device numbers or the numbering anaconda uses internally? Please note comment #10: The partition that eventually got overwritten by the new installation was indeed /dev/sdb15, not /dev/sdb8.
(In reply to comment #11) > Sure it offers that option. Click on the first filesystem you want to use > and it will open up on the right hand side. Then you either just assign it > a mountpoint (in the case of something like /home), or you click reformat > and then assign it a mountpoint (in the case of something like /). Confirmed - this works.
(In reply to comment #17) > Confirmed - this works. I can explain now why I overlooked the "Reformat" button - it is only visible after clicking on "customize" an didn't realize that deletion / overwriting was considered a form of customization.
Comment 11 is accurate and comment 12 offers a correct explanation of the partition numbering change. This is not a bug per se, but an assumption of wrongdoing based on poor communication from the installer ui and paranoia on the part of the user. We are seriously considering offering an alternative device-based view for users who are uncomfortable with the new view. It is not clear whether we will try to implement this for F19. One thing we are planning for F19 is the addition of device name to the mountpoint selector widgets in the tree on the left side of the screen.
(In reply to comment #16) > (In reply to comment #12) > > When a logical partition is deleted, all logical partitions following it are > > renumbered with the old partition number reduced by 1. Dave explains this > > behavior in Bug 902275, Comment 28. > > > > In this case: > > sdb8 is deleted. > > sdb9 becomes sdb8. > > ... > > sdb15 becomes sdb14. > > sdb15 is created. > > Are you talking about the actual device numbers or the numbering anaconda > uses internally? Please note comment #10: The partition that eventually got > overwritten by the new installation was indeed /dev/sdb15, not /dev/sdb8. IIUC, the installer displays the actual device numbers in the GUI. When a logical partition is deleted, some of those device numbers can change. Have you checked that the logical partition that was sdb15 before installation, and that is now sdb14, still contains the data it did before installation?
OK, understood. I think I never deleted a logical partition in this manner, although fdisk has always done it that way. The "poor communication" in my case was caused by the UI favouring "delete/create" (via the prominent "-" / "+" buttons) over "Reformat", which is hidden under the "customize" button. I am not sure if it is a good idea to encourage deletion of logical partitions in this way. The only reasonable use case for that which I can think of is to delete several adjacent logical partitions in order to create space for a new, larger one, or to split up a big logical partition into several ones. Both is stuff for real experts. Overwriting an existing partition is much more common IMO.
(In reply to comment #20) > Have you checked that the logical partition that was sdb15 before > installation, and that is now sdb14, still contains the data it did before > installation? It's ok. It behaved as you intended (although not necessarily as I expected it to behave, but that's mainly my fault). The result was a partition table with logical partitions not in disk order, that's what I didn't understand in the first place.