Bug 855976 - In F18 Alpha, 'automatic' partitioning wipes entire disk without warning, should also allow 'install to free space'
Summary: In F18 Alpha, 'automatic' partitioning wipes entire disk without warning, sho...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 18
Hardware: All
OS: All
unspecified
high
Target Milestone: ---
Assignee: Chris Lumens
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker https://fedoraproject...
: 855996 861530 (view as bug list)
Depends On:
Blocks: F18Beta, F18BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2012-09-10 20:07 UTC by Adam Williamson
Modified: 2013-01-10 06:54 UTC (History)
18 users (show)

Fixed In Version: anaconda-18.12-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-10-05 19:36:07 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Adam Williamson 2012-09-10 20:07:08 UTC
As discussed in #anaconda today, as the proposed design hasn't been entirely implemented yet, newUI's current handling of partitioning is simply this:

* user picks a disk(s)
* anaconda says 'disk is big enough to continue!', and offers an option to go into custom partitioning (misleadingly named 'review') or not
* if user doesn't go into custom partitioning, anaconda simply blows away the entire selected disk(s) and re-formats it/them from scratch

you either blow away at least one entire disk, or use custom partitioning. The more fine-grained autopart options don't presently exist at all (though AIUI, this isn't exactly the intended final design).

However, anaconda doesn't make this clear in any way. The dialog saying the disk is big enough doesn't say anything about deleting existing data on it. There is no capability at present in newUI to truly 'review' anaconda's determined partition layout - if you pick the 'review' option you're actually just required to do your own partitioning from scratch. So there's no way the user can actually know what layout anaconda has selected, or that it will destroy existing data.

At minimum, the 'we're all ok to continue!' dialog should warn the user clearly that all existing data on the selected disk(s) will be destroyed.

Proposing as Alpha blocker, although we don't exactly have a criterion for this at present - we're still discussing revising the partitioning criteria.

Comment 1 Jesse Keating 2012-09-10 22:07:10 UTC
*** Bug 855996 has been marked as a duplicate of this bug. ***

Comment 2 Reartes Guillermo 2012-09-11 02:35:32 UTC
The option 'use free space' does exists in text mode and it works.
I think it should be added back to graphical mode.

Comment 3 Jesse Keating 2012-09-11 17:10:55 UTC
Of note, you can click the box to review/modify, and at that point you have the option to selectively remove existing partitions before clicking the button to automatically create a new partition set.  This is equiv to the "use free space" option.

Text mode exposes these options because we do not have the capability to do partition customization.

Comment 4 Kamil Páral 2012-09-11 19:07:23 UTC
It's sad we haven't thought about this earlier. I start to be so deep in the testing mindset that I forget to have some distance and look at it with general user eyes.

I certainly agree that it's very unfortunate to destroy all user data without a proper warning. There are certainly some users out there who will want to try out Fedora 18 Alpha and won't assume the installation is destructive. We might wipe all their data.

It should be easy to fix. We can put a warning dialog in the auto-partitioning screen saying that the whole disk will be erased. Also it would be nice to put a warning label into the manual-partitioning screen saying that this code is in early development and we don't recommend it to use it on machines with valuable data (yet).

+1 Alpha blocker

Comment 5 Jesse Keating 2012-09-11 19:16:32 UTC
It's an alpha.  We already warn people that it might eat their data.  You have to accept your fate.

Blocking an alpha release because some user might be caught unaware that their data could be eaten, by ALPHA SOFTWARE is ridiculous.

No idea if my vote counts, but -1 blocker.

Comment 6 Kamil Páral 2012-09-11 19:46:17 UTC
Yesterday a colleague of mine asked me whether it's possible now to install F18 Alpha (on a machine for development purposes). I was about to answer 'yes', but then he mentioned he had another 11 operating systems there. And I had to urge 'no'. He's lucky he mentioned that. "Alpha" doesn't always mean "destroy all data" for everybody. He used to install previous Alpha Fedoras.

One more thing. "Might eat your data" is generic. "Will erase the whole disk" is very concrete. If you don't know the NewUI workflow, you might not know that if you hit Continue, your disk is doomed. You have selected the target disk, that's true, but you might expect that on another screen you'll see detailed list of what's going to happen and only after that you'll confirm that. Or you might expect ubuntu-style slider allowing you to dual-boot with your current system. Don't forget, if you don't know NewUI, you have no idea what's on the next screen. That's why anaconda should be very clear about this. "Might be buggy" warning doesn't count.

(When talking about that, if would be great if the "Continue" button was renamed to "Begin installation". That would prevent some inconvenient surprises).

Comment 7 Reartes Guillermo 2012-09-11 20:23:52 UTC
> Blocking an alpha release because some user might be caught
> unaware that their data could be eaten, by ALPHA SOFTWARE is ridiculous.

Yes it is. However if people start to wipe their disks accidentally
after release, due to a confusing UI that by default leads to a 
complete hard disk wipe. 

I mean, by default f18 (as it is now) will erase whatever is in your
disk unless you told it to not to do it (by 'alternate' partitioning)

Don't get me wrong, i consider anaconda new UI to be much better 
than previous versions, with the exception of partitioning.

> If you don't know the NewUI workflow

It will be novel to a lot of people, that itself should not be an 
impediment nor a risk. 

The UI should have 'safe' defaults.

*We know dual boot exists.

*We know some people do use dual or even multi-boot.

*We know some of these people will be better by making backups prior to installing f18.

*We can detect if there is another os on the given (to anaconda) disk.

*And We will wipe it by default and replace it by Fedora.

Some people will do it wrong, no mater how easy the UI might be.

Comment 8 Adam Williamson 2012-09-11 20:49:45 UTC
jesse: like Kamil, I see a significant difference between a generic 'this might have bugs that cause data loss' warning and a notification of specific, intended destructive behaviour. The dialog that pops up at the start of install is a general warning that bad bugs might exist. The behaviour under discussion here isn't a bad bug, but intended anaconda behaviour. Any time an app is going to intentionally destroy existing data, it should say that's what it's going to do.

The question of Alpha blockeriness is arguable, but since this is an easy fix and clearly warning about the fact that you're about to eat someone's disk is the Right Thing To Do, it would be nice if we could just do it, regardless of whether we decide it's a blocker or not. It seems at least a blindingly obvious NTH candidate, to me.

Comment 9 Jesse Keating 2012-09-11 21:20:56 UTC
You can mark it NTH if you want, but don't expect any code.  You'd also have to get the translators to agree to breaking string freeze to introduce new strings (having string freeze prior to alpha, or even prior to beta seems pretty wrong to me).

Comment 10 Jaroslav Reznik 2012-09-12 11:06:28 UTC
(In reply to comment #9)
> You can mark it NTH if you want, but don't expect any code.  You'd also have
> to get the translators to agree to breaking string freeze to introduce new
> strings (having string freeze prior to alpha, or even prior to beta seems
> pretty wrong to me).

I expect Anaconda will need exception to grant string freeze, as it's still under heavy development and this would not be the only string change I bet.

Comment 11 Adam Williamson 2012-09-12 17:35:00 UTC
Discussed at 2012-09-12 blocker review meeting. This was a more controversial vote than usual. Those in favour cited the strong expectation in software in general that destructive actions should be explicitly warned about, those against argued that for an Alpha release the expectation must be that data loss can occur and we shouldn't delay an Alpha release for an issue like this. The bug does not clearly hit any existing release criteria, or currently proposed ones.

On the criteria and the balance of votes, the bug is rejected as an Alpha blocker and accepted as NTH. For the record, since we don't usually have such split votes, the votes were:

For blocker status: martix, adamw, kparal, tflink, robatino (5)
Against blocker status: jlk, dlehman, nirik, nanonyme, Viking-Ice, spoore, msivak, jwb (8)

We agreed to propose this as a Beta blocker. Anaconda team expect the behaviour to change for Beta anyway, but the presence of this bug on the Beta blocker list will act as a reminder to ensure that occurs.

Comment 12 Chris Lumens 2012-10-01 14:17:37 UTC
*** Bug 861530 has been marked as a duplicate of this bug. ***

Comment 13 Adam Williamson 2012-10-01 23:42:54 UTC
For the record, at the QA meeting today we agreed on the following Beta criterion (among others):

"The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched"

So that's what we're expecting to have working for Beta: it must be possible to do autopart-into-empty-space without entering the custom partitioning interface.

Comment 14 Adam Williamson 2012-10-03 16:47:38 UTC
Discussed at 2012-10-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-03/f18-beta-blocker-review-2.2012-10-03-16.00.log.txt . Accepted as a blocker per criterion "The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched".

Note that by 'automatic partitioning' that criterion is referring to 'automatic partitioning without entering custom partitioning mode'; now we have two forms of 'automatic partitioning' we should probably come up with language to distinguish them. We further note that anaconda team is using this bug to cover adding a 'free space' option to the outside-custom automatic partitioning code, and it's accepted as a blocker on that basis. Updating the summary to reflect that.

Comment 15 Jóhann B. Guðmundsson 2012-10-03 16:58:29 UTC
I'll better hope that when I hand end users usb keys or dvds and they install Fedora that the installer wipes their current hard drive dual booters can custom partition noobs cannot

Comment 16 Reartes Guillermo 2012-10-03 17:02:28 UTC
@Adam Williamson

> now we have two forms of 'automatic partitioning' we 
> should probably come up with language to distinguish them.

Automatic partitioning should mean (as you said in previous comment):

> Note that by 'automatic partitioning' that criterion is referring to 'automatic > partitioning without entering custom partitioning mode'

Can you elaborate on what you call the 'other automatic partitioning'?

Comment 17 cornel panceac 2012-10-03 17:14:26 UTC
Thank you form marking this as a blocker. It's bad enough that it was not a blocker for alpha.

Comment 18 Jim Bray 2012-10-03 20:09:10 UTC
I must have done over a hundred linux installs/upgrades, starting back with SLS when the kernel was at patch level 0.99-15 or so. I've never had a disk wiped without warning until Fedora Alpha 18. I had Windows 7 and FC17 installed. The comments above to the effect that one should expect an alpha to wipe one's disk without warning only strengthen my determination that neither I nor anyone who takes my advice will ever try any variant of Red Hat again.

Comment 19 Jóhann B. Guðmundsson 2012-10-03 21:13:41 UTC
I dont mind users getting warning but I do mind noobs having to go to the custom partitioning if they want to wipe their existing windows,Linux or any other OS ( or general use the entire disk ) that was previously installed on the hard drive or have the installer trying to use any existing free space instead

Comment 20 Fedora Update System 2012-10-04 00:57:09 UTC
anaconda-18.12-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.12-1.fc18

Comment 21 Fedora Update System 2012-10-04 17:50:55 UTC
Package anaconda-18.12-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.12-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-15378/anaconda-18.12-1.fc18
then log in and leave karma (feedback).

Comment 22 Jens Petersen 2012-10-05 06:00:41 UTC
Now it seems to have gone too far the way?
With 18.12 I have to remove an existing partitions by hand
before using the installer to be able to install
onto a HD with an existing install.  Removing the partition
table from inside anaconda didn't work for me.

Comment 23 Adam Williamson 2012-10-05 07:28:47 UTC
If you're talking about having problems within custom partitioning if you try to remove existing partitions and then automatically create new ones, I believe that's known and should be addressed in 18.13, which should show up tomorrow.

Comment 24 Adam Williamson 2012-10-05 07:32:22 UTC
Jim Bray: Fedora is not a variant of Red Hat. It's a separate project that is sponsored by Red Hat. It does not have anything like the same goals or requirements as any Red Hat project. If you consider the Fedora Alpha requirements to be so loose that you lose confidence in the Fedora project that's your prerogative, but it implies nothing at all about the processes associated with any Red Hat product. Those are quite different.

reartes: "Can you elaborate on what you call the 'other automatic partitioning'?" - within the 'custom partitioning' interface in F18 (newui), there is a button that lets you automatically create a set of Fedora partitions within the empty space on any disk, the idea being that you can use the custom partitioning interface to selectively delete or resize existing partitions to create space for a Fedora installation, but then allow the installer to take care of the details of creating the Fedora partitions rather than doing it manually. That's the 'other' autopart. (Actually I believe they both ultimately fire the same code, but from a UI standpoint they're rather different.)

Comment 25 cornel panceac 2012-10-05 07:48:32 UTC
(In reply to comment #24)
> Jim Bray: Fedora is not a variant of Red Hat. It's a separate project that
> is sponsored by Red Hat. It does not have anything like the same goals or
> requirements as any Red Hat project. If you consider the Fedora Alpha
> requirements to be so loose that you lose confidence in the Fedora project
> that's your prerogative, but it implies nothing at all about the processes
> associated with any Red Hat product. Those are quite different.
> 

I'd say it was just a way to express the pain from encountering the worst OS installer in more than 15 years of Linux usage. Or maybe it's just me assuming i'm not alone.

Comment 26 Adam Williamson 2012-10-05 08:51:11 UTC
I'd rather not try to read into it anything it doesn't say.

But come on, folks. An Alpha is an *Alpha*. Alphas are not code complete. Alphas are not stable. Alphas eat kittens.

This bug was explained in detail, with a heading in BOLD RED CAPITAL LETTERS, in the release announcement, the release notes, *and* the known bugs (errata) page for the Alpha.

If you're going to install Alphas onto disks that contain data you care about without reading any of the above documentation...I don't want to say you're asking for bad things to happen, but _really_. Come on.

Comment 27 Jim Bray 2012-10-05 09:10:53 UTC
I ran Debian/unstable for the better part of 15 years, never had it deliberately wipe my disk. 
I generally ran hand-built kernels using the latest source, often -RC versions. Ditto.
The idea that people would produce an ISO image of any kind that judging by this bug history was known to eat disks without warning or a chance to cancel, and then lack the decency to fall on their swords is just embarrassing to witness.

I'm now running Mint and can't conceive of running anything where <anyone>@redhat.com is making QA and release decisions.

Wiping disks is a capital offense. It's just that simple. Hardware can go bad, a driver or fs can be buggy, but an inataller? No, quite inexcusable.

Comment 28 Jim Bray 2012-10-05 09:21:31 UTC
S/inataller/installer
On review, I note that two people @redhat.com argued and voted for blocker status. 
Bravo. Would that sanity had prevailed.

Comment 29 Adam Williamson 2012-10-05 17:03:43 UTC
"I ran Debian/unstable for the better part of 15 years, never had it deliberately wipe my disk."

Fedora has very different goals from Debian, and an installed system is different from an installer. To an installer, wiping a disk is a pretty normal operation, to an installed operating system it is not. The circumstances are not at all the same, and I reject the comparison.

"I generally ran hand-built kernels using the latest source, often -RC versions. Ditto."

And again, ditto: a kernel is not an operating system installer. There is no normal circumstance in which a kernel is going to intentionally wipe a disk. Now if we're talking experimental kernel features, well, the upstream kernel introduces new filesystems quite often, and people using these early have _certainly_ lost data and disks. Take a look at the history of btrfs data loss bugs: that's using the btrfs support in the mainstream kernel source. That seems a reasonable comparison.

"Wiping disks is a capital offense. It's just that simple. Hardware can go bad, a driver or fs can be buggy, but an inataller? No, quite inexcusable."

Like I said, I think you have that exactly the wrong way around. Wiping disks is what an installer does. An operating system installer is a loaded gun. When I'm testing test composes I have my production disks unplugged and sitting outside the computer. I was one of the people who argued for this bug to be a blocker, because this ain't my first rodeo and I knew there'd be at least _one_ person who would use an Alpha version of a completely rewritten installer on production data without reading any of the documentation or taking the 'don't use this on a production system' warning that you clicked through at the start of install seriously, but that doesn't mean I think that person would be doing the right thing, and I don't. To use an Alpha release of a piece of code one of whose primary functions is to destroy data, on data you care about, without reading any of the documentation is not the right thing to do, and I can entirely see the point of those in the project who argued against taking this bug as a blocker, and won.

Comment 30 cornel panceac 2012-10-05 18:02:16 UTC
(In reply to comment #29)
> "I ran Debian/unstable for the better part of 15 years, never had it
> deliberately wipe my disk."
> 
> Fedora has very different goals from Debian, and an installed system is
> different from an installer. To an installer, wiping a disk is a pretty
> normal operation, to an installed operating system it is not. The
> circumstances are not at all the same, and I reject the comparison.
> 

But of course, it's not about an installer wiping a disk, it's about an installer that even if it was known to wipe disks without warning, was still released to the public. Yes, even as an alpha.

> "I generally ran hand-built kernels using the latest source, often -RC
> versions. Ditto."
> 
> And again, ditto: a kernel is not an operating system installer. There is no
> normal circumstance in which a kernel is going to intentionally wipe a disk.
> Now if we're talking experimental kernel features, well, the upstream kernel
> introduces new filesystems quite often, and people using these early have
> _certainly_ lost data and disks. Take a look at the history of btrfs data
> loss bugs: that's using the btrfs support in the mainstream kernel source.
> That seems a reasonable comparison.
> 
> "Wiping disks is a capital offense. It's just that simple. Hardware can go
> bad, a driver or fs can be buggy, but an inataller? No, quite inexcusable."
> 
> Like I said, I think you have that exactly the wrong way around. Wiping
> disks is what an installer does. An operating system installer is a loaded
> gun. When I'm testing test composes I have my production disks unplugged and
> sitting outside the computer. I was one of the people who argued for this
> bug to be a blocker, because this ain't my first rodeo and I knew there'd be
> at least _one_ person who would use an Alpha version of a completely
> rewritten installer on production data without reading any of the
> documentation or taking the 'don't use this on a production system' warning
> that you clicked through at the start of install seriously, but that doesn't
> mean I think that person would be doing the right thing, and I don't. To use
> an Alpha release of a piece of code one of whose primary functions is to
> destroy data, on data you care about, without reading any of the
> documentation is not the right thing to do, and I can entirely see the point
> of those in the project who argued against taking this bug as a blocker, and
> won.

I've noticed that sometimes we read the letter but ignore the spirit. 

At the point i have installed the freshly declared GOLD Alpha, there was no documentation released. And no, i do not consider that the decision to go forward was a good one, and not only because i've lost "only" 50 GB of data. As i've said before, to declare GOLD an OS that it is known to destroy data without warning is wrong, in my opinion, and is harmful for Fedora. As usual, this is not an attack against a person or a company. It's just an attempt to make things better.

Comment 31 Adam Williamson 2012-10-05 19:26:33 UTC
"At the point i have installed the freshly declared GOLD Alpha"

The gold notification is not a release announcement. The very second sentence reads "F18 Alpha will be released Tuesday, September 18, 2012": in other words, it's not released yet. It is only sent to internal Fedora project lists, the readers of whom should _really_ know what is going on. At that point you can only download the build labelled 'RC3' (or whatever) from the 'stage' server which is never used as a release server outside the project. There is a very clear distinction between the 'declared gold' mail and the release announcement, which actually says the build is released, is distributed broadly, and accompanies the staging of the release to the public mirrors. There's a week's delay between those two, part of the reason for which is to allow us to write up all the documentation that is inevitably needed to accompany an actual release.

Comment 32 Adam Williamson 2012-10-05 19:27:28 UTC
we did not declare an OS gold. we released an Alpha. an *Alpha*. An Alpha is not an OS. It is a very early prototype of an OS for testing purposes only. It should be treated as such. There's already been some discussion to the effect that the term 'gold' shouldn't be used for Alphas, and I think we're going to change that going forward, but really, it's still pretty clear.

Comment 33 Adam Williamson 2012-10-05 19:36:07 UTC
18.12 has gone stable and certainly changed this behaviour, it won't let you wipe a disk without very clear indication that's what you're doing. There are various bugs in the functionality which are being handled separately, but the design clearly addresses this concern. Closing.

Comment 34 cornel panceac 2012-10-08 08:18:25 UTC
Thank you very much, Adam.


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