"Editing" unknown partition to Crypt to see if crypt detected instantly destroys what was there, "Quit" does not revert

[ellie]

In the graphical desktop installer, "Editing" unknown partition to crypt to see if LVM or crypto is detected instantly destroys what was there, "Quit" does not revert: https://i.stack.imgur.com/p0SWz.png

This is a horrible thing to do because:
1.) why would you not detect LVM in the first place
2.) why is there no warning that you're just destroying data. Not that you don't even have a proper commit system (every partitioning tool I have seen except command line DOS stuff will let me try changes first, then APPLY them when I choose so AFTER A WARNING), but there is no warning at all
3.) you do even have a revert button, but clicking "Quit" apparently doesn't trigger that and my partitions are left broken

TL;DR: I tried to make it detect my LVM, quitted with "Quit" since apparently it can't, and now my LVM is gone forever.

1995 is calling and wants its horrible partitioning GUI back!! Also, thanks for wasting all my data.

[ellie (et1234567)]

Oh and while I assume there's no good way of undoing that, if there IS actually some doable way I overlooked I'd be thrilled to know.

[ellie (et1234567)]

Apparently, all dm crypt stuff gets written to disk instantly without the slightest warning. Resize or actually doing the install gives me a big warning popup before it goes to disk though - why this stupid inconsistency that has just cost me a lot of data?

It seems outdated that the installer doesn't use some sort of commit system at all (where no change gets EVER written to disk, and you can first try around and before a final confirm it shows you all steps in all detail). It seems it kinda tries to do that with the formatting and alerting me before it does that, but it doesn't for a lot of other big changes.

Compare Red Hat's anaconda or gparted for how to do this stuff properly - this current half-hearted attempt is just deceiving and user-hating. Do you want people to accidentally lose their data? This is how you make people accidentally lose their data.

[ellie (et1234567)]

I just checked the base text-based installer thing.

It has exactly the same behavior... except that it gives me a BIG WARNING before it writes the LVM to disk! This is how it should be! Why was that specific part omitted in the graphical one??

[Phillip Susi (psusi)]

What version of Ubutu is this? From your screen shot it looks like 10.04 or older, which is no longer supported. I tried reproducing this on 14.04 and it does not have the option to change to lvm, but does to crypt. After choosing crypt, then hitting the back button, it did not destroy the existing partition. 12.04 doesn't even have the crypt option.

[ellie (et1234567)]

Ubuntu 15.04, the screenshot is just googled to illustrate the page I was on (it's not reflecting my settings either) - and when hitting "Quit", it quite happily destroyed things. I can't tell if "Back" would have saved me.

It might have been the crypt option. What I certainly remember is selecting the unknown partition (which was the encrypted luks lvm of my previous install), clicking edit, choosing something which I hoped might be the right thing to open it up (something along the lines of an "encrypted container" choice or what it has? I don't think it wasn't explicitely named LVM or dm-crypt), and then I had dev mappers appear at the top. I discovered it would want to create something new instead of accessing my existing stuff, so I clicked "Quit" - but at that point, it has already written stuff to disk.

Again if you check the base installer, it does the same thing before allowing you to use the mappers after you specify dm-crypt for some partition - writing the LVM or dm-crypt to disk. I guess this was adapted at this point for similar behavior. However, the text installer doesn't do that *without any warning*, unlike ubiquity seems to do..

[Phillip Susi (psusi)]

I'm not able to reproduce this on 15.04 either ( which also only has the crypt option, not lvm ).

[ellie (et1234567)]

Did you try the crypt option? Do dev mappers instantly appear for you?

[ellie (et1234567)]

More detail: I could try again in a VM, but this should be the process to make it work:

1. Create LVM with LUKS (sadly I can't recall if LUKS was inside LVM or the other way round)
2. Open installer which recognizes the partition but doesn't realize what it is
3. Click partition, click edit, choose the encryption container thing for the partition

At this point, the installer suddenly becomes very busy, /dev/mapper things appear at the top and there's some short statements about reloading info from disk is on the screen.

If you quit at this point by clicking "Quit" (NOT "back"), your LVM/LUKS partition should be destroyed and unable to boot. Might still be recognized, but shouldn't load up anymore.

[Phillip Susi (psusi)]

I had an existing ext4 partition on the disk, clicked change in the installer and chose crypt. The listing changed to show the partition as crypt, but after going back or canceling and restarting, it reverted to ext4.

If you can describe exactly what you did to the disk by hand before starting the installer, I can try that.

[ellie (et1234567)]

Well basically I had an existing Fedora installation, which is now gone..

I would assume ext4 doesn't trigger it because the installer knows what it is. It might have failed to revert my luks/lvm/whateveritwas maybe because it didn't recognize it?

I would have to guess what Fedora set up in detail, so I can't tell you for sure.

Anyway, if you do actually write to disk but revert, I think that's utterly broken too. What if the pc is carelessly shutdown because the user assumes no changes were finalized yet? Give at least some sort of warning popup before you actually touch the disk like the debian text-based installer does before writing and activating the dm-crypt stuff - currently it's really out of the blue.

[ellie (et1234567)]

Did you do take a look at Red Hat's anaconda installer by the way? It never touches the disk ever and lets you plan the whole thing including crypto setup, creating/changing partitions etc, and then when submitting the whole thing, gives you a verbose listing of changes that will be done with a big "do it and ruin my disk" finalizing button.

Compared to ubiquity's current nontransparent sometimes-happens-immediately-sometimes-later with sometimes warning and sometimes no warning behavior, it seems light years ahead in technology. I was really caught by surprise that it immediately touched the disk without even the slightest warning, and then failed to revert it correctly.

[Phillip Susi (psusi)]

That is exactly how it works; it doesn't touch the disk until it you click proceed. It only shows you what it is *going* to do.

[Phillip Susi (psusi)]

Bingo! I tried zeroing out the first 64 sectors of the existing (ext4) partition before running the installer so it wouldn't recognize it, and it reports the partition as unrecognized. Changing its type to crypto still does not change the contents of the disk, and if I quit the installer and restore the first 64k, it works fine. HOWEVER, if I start with an existing crypto install, the installer also reports that it does not recognize the partition type ( possibly a separate bug ) and now if I change its type to crypto, it indeed does immediately commit the the changes to disk, destroying the previous luks container.

[ellie (et1234567)]

Btw why is the alternate installer faded out? I could neither make this graphical one recognize the LVM (see this bug report with the desastrous result when I tried), nor a plain LUKS partition. How do you expect people to install properly on existing partition schemes with this unfinished piece of software?

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Launchpad Janitor (janitor)]

[Expired for ubiquity (Ubuntu) because there has been no activity for 60 days.]