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.
*** Bug 855996 has been marked as a duplicate of this bug. ***
The option 'use free space' does exists in text mode and it works. I think it should be added back to graphical mode.
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.
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
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.
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).
> 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.
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.
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).
(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.
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.
*** Bug 861530 has been marked as a duplicate of this bug. ***
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.
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.
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
@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'?
Thank you form marking this as a blocker. It's bad enough that it was not a blocker for alpha.
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.
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
anaconda-18.12-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.12-1.fc18
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).
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.
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.
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.)
(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.
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.
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.
S/inataller/installer On review, I note that two people @redhat.com argued and voted for blocker status. Bravo. Would that sanity had prevailed.
"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.
(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.
"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.
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.
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.
Thank you very much, Adam.