Bug 875944

Proposing as F18 Final NTH. I would go even further and argue this could be a blocker, because this practically renders Windows unusable and it is quite hard to revert for a large group of potential Fedora users, but I guess I just care about innocent unsuspecting general users too much. Let's discuss.

When I think about it more, I think the Windows boot error was not caused by the small available free disk space, because ntfsfix fixed it, and the other two attempts went just fine. So it was most probably some glitch caused by ntfsresize, and that's something anaconda can hardly influence. Let's disregard this issue here and consider this bug report related to just the shrinking dialog problems.

Proposing as a blocker, Fedora 18 Final Release Criterion #9.

Summary: 2 for 2 broken, unbootable and unrepairable Windows installations. VM is VirtualBox (3GB memory VM, 750GB virtual disk).

1. One new virtual disk.
2. Install Windows 7 SP1, defaults.
3. Reboot Windows multiple times, it works.
4. Boot from Fedora-18-TC1-x86_64-Live-Desktop.iso, update to anaconda 18.37.2-1, launch installer.
5. Installation Destination > Installation Options | no options, accept default > Reclaim space.
6. Reclaim Disk Space (modal)> Click on the largest partition NTFS, click Shrink. I can't click on anything else, so I click Reclaim space. Then click on Begin Installation.
7. Installation successful, reboot.
8. Choose Fedora in GRUB - I get to firstboot. Reboot.
9. Choose Windows in GRUB ...

Actual results:
1. Blue screen with white text, for 1/2 second, then the VM reboots. It appears to have crashed.
2. On reboot to Windows, black and white screen "Windows Error Recovery", just like this image:
http://www.windowserrorhelps.com/wp-content/uploads/2012/02/11.png
3. I launch startup Repair, and it tries to repair, fails with this window:
http://www.pagestart.com/images/800_Startup_Repair_cannot_repair_this_computer_automatically-02.jpg

Expected results:
1. If I have no way to set the resize amount in the UI, the most free space Fedora should automatically take for itself from an existing Windows install is perhaps 25%. Probably more like 10%. 98% is simply wrong.

2. A functioning Windows, and Fedora.

See also:
Bug 885912 - Resize of NTFS partition results in partition smaller than the filesystem, broken Windows install

Could you run this on the NTFS partition from the Live CD?
# ntfsinfo -m /dev/sda1

We may have a duplicate bug, if the partition is smaller than the NTFS file system. (See Bug 885912, Comment 29 for example ntfsinfo output.)

There are a variety NTFS tools on the Live CD:
# rpm -ql ntfsprogs

[root@localhost liveuser]# ntfsinfo -m /dev/sda2
Failed to read last sector (26408192): Invalid argument
HINTS: Either the volume is a RAID/LDM but it wasn't setup yet,
   or it was not setup correctly (e.g. by not using mdadm --build ...),
   or a wrong device is tried to be mounted,
   or the partition table is corrupt (partition is smaller than NTFS),
   or the NTFS boot sector is corrupt (NTFS size is not valid).
Failed to mount '/dev/sda2': Invalid argument
The device '/dev/sda2' doesn't have a valid NTFS.
Maybe you selected the wrong device? Or the whole disk instead of a
partition (e.g. /dev/hda, not /dev/hda1)? Or the other way around?
Failed to open '/dev/sda2'.

Thanks, Chris. That looks like Bug 885912, but I will defer to the experts.

In Bug 885912, Comment 33, Robert recovered with:
# ntfsfix /dev/sda1

NB: The testing in Bug 885912 was with Windows XP.

I'm proposing this as a blocker bug on its merits as described by Kamil, not the problem covered in 885912.

Even disregarding that bug, the behaviour identified by Kamil - that non-custom shrinking just shrinks the partition to the minimum size anaconda considers possible, it doesn't allow you to specify the amount of shrinkage - makes this function pretty much unfit for purpose. In terms of the criterion:

"The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working"

It's not absolutely crystal clear, but the criterion clearly intends the result to be a viable Windows install and a viable Fedora install. A Windows partition which has been shrunk to the size of the data it contains plus 500MB (the padding amount used by anaconda to determine the maximum size, according to dlehman) is not a viable Windows installation, let's face it. Regular old Mysterious Windows Bloat will probably fill that in a week or two, never mind any actual practical use of the OS.

I think the non-custom shrink function as it stands is essentially a loaded gun pointed at the foot of the user. It is far more likely to cause people pain than it is to make them happy. It needs to have the option to specify the target size added back, or it needs to be taken out until F19.

+1 blocker.

I sometimes use Windows too and the behavior would
be unacceptable to me too, probably sour me to linux.

(In reply to comment #8)
> I think the non-custom shrink function as it stands is essentially a loaded
> gun pointed at the foot of the user. It is far more likely to cause people
> pain than it is to make them happy. It needs to have the option to specify
> the target size added back, or it needs to be taken out until F19.

I completely support this view. I appreciate making things 'just work', but there is no way you can guess what will be the final usage of the machine, and that surely affect the percentage of disk given to the two OS. 

A simple option to select how to split the disk is absolutely needed for this purpose

Let's take a contrary approach and install Fedora in the _minimum_ possible space, including swap. Since the Fedora installer already knows the minimum required space, including swap, this approach should be implementable. And it would offer Windows users the least disruptive way to try Fedora.

But seriously, Gianluca's suggestion[1] to offer users a simple split option is a good one. However, the split must account for swap space allocated for Fedora.

[1] Comment 10.

Discussed at 2012-12-17 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-17/f18final-blocker-review-5.2012-12-17-16.40.log.txt . Accepted as a blocker per the rationale cited in c#8 - we don't usually take shrink issues under that criterion, but that exception is more for 'a resize attempt failed for some technical reason' cases than 'the design of the resize function is fundamentally bad', as in this case.

Removing the shrink function from non-custom path would constitute a 'fix' for blocker purposes, though it would kinda suck - providing a size entry would be much nicer.

To be clear, since people seem to be confused: leaving things as they are is _not a viable option_ here. That is what the 'F18Blocker' status means: this bug is blocking release. It must be addressed.

As stated in comment #12, 'fixing' the function so the user is able to specify the size in some way is the *preferred* option. However, discussion in #anaconda today indicates that this may be difficult or impossible.

The other option is to take the function out of the 'guided' (non-custom) path entirely. This would suck, but it sucks less than leaving it in and letting people shoot themselves with it. Under this plan we would instruct people to use the custom partitioning path if they need to resize devices.

We must do one of those things (or something else clever that no-one's thought of yet). The blocker review 'team' is strongly agreed that we cannot leave things as they are, this is not a feature, it is a booby trap.

Comment 11 was meant to be facetious and is not so clever, but it seems like a viable alternative:

Install Fedora in a _minimum_ amount of space, so that the Windows partition is only minimally shrunk. IIUC, the UI wouldn't need to change at all.

My suggestion is to modify the padding that we apply to resized partitions to leave more space available, perhaps some significant (25%?  50%?  5 GB?  50 GB?) amount of the free space with the existing filesystem and therefore only free up the remainder for autopart use.  We can communicate this in the UI by printing the modified numbers instead of the actual numbers.

Taking the shrink button out and forcing Windows users to go through custom partitioning is a complete non-starter to me.  This significantly raises the bar for installation for Windows users wanting to install Fedora.  We're basically forcing them to go through the most complicated section of the installer, and we're bound to hit a lot more problems with them that way.  We are certainly bound to see decreased adoption numbers.

(In reply to comment #14)
> Install Fedora in a _minimum_ amount of space, so that the Windows partition
> is only minimally shrunk. IIUC, the UI wouldn't need to change at all.

I'm thinking take the smaller of 25GB or 15% free space from the host file system (the one to be shrunk). If 15% is the smaller, and is less than X GB, then the Installation Options modal dialog should not claim there's enough space for reclaim from existing file systems; ergo something must be deleted.

X GB is something like: install size + 2GB + total memory.

But yeah, presently in my test shrink is sucking 98% of the host fs's free space and that's just untenable to the point of sabotaging the original OS.

That would be better than the current situation. I don't think it's a great option though. bcl or dlehman (I forget which) put it best: shrinking is fundamentally not a binary operation. It is not 'shrink or don't shrink'. I don't think it's possible even to _approximate_ an ability to make a sensible choice for the user; certainly not with a simple one-shot buffering algorithm.

On the question of user adoption, well, an installer which is clearly doing something really silly - trying to guess for you how much you want your partitions shrunk, and probably doing a bad job of it - is arguably a poorer representation of the project than an installer which, temporarily, doesn't offer a shrink function outside of custom part. Let's be honest, F18 is already a 'first cut' at newUI, and I for one am going to be communicating that. We've done a good job at a first cut but there are lots of things that need refining, not just this. I think 'we realized there was a big problem with the function late in the F18 cycle so we took it out temporarily, it'll be back in F19' is a pretty reasonable story, and better than 'we realized there was a big problem with the function late in the F18 cycle, so we made a really half-assed attempt to paper over it and hoped it'd work out okay'.

The first time I ever installed Linux, I bought a second disk drive for that purpose, because I didn't want the installer touching my Windows system.

Voting to remove the shrink function altogether.

(In reply to comment #16)

> X GB is something like: install size + 2GB + total memory

+ some guess for padding for updates, cache files, downloads, etc.

(In reply to comment #15)
> My suggestion is to modify the padding that we apply to resized partitions to >leave more space available,

The use case for high preference to guided autopartitioning shrink, compared to manual partitioning shrink, should assume the user will continue to use the original OS primarily. That is the conservative position. In that case I think taking more than 50% of that fs's free space is a problem. 25% might be OK. 15% is safe.

>Taking the shrink button out and forcing Windows users to go through custom >partitioning is a complete non-starter to me. 

The non-starter is actually the present behavior. The corner it's boxing us into is a UI with no easy guided option for shrink; and a totally non-obvious UI with Windows appearing as "Unknown" in Manual Partitioning, which makes for a distinctly "now what do I do?" UX. Not a good combination.

Changing the padding is still the most sensible way out of the box. But it should defer conservatively to the current OS's file system.

(In reply to comment #18)
> The first time I ever installed Linux, I bought a second disk drive for that
> purpose, because I didn't want the installer touching my Windows system.
> 
> Voting to remove the shrink function altogether.

Unnecessary to remove for this use case. The user chooses the 2nd disk drive, and they will not even see the options for shrinking.

dracut-024-17.git20121220.fc18, anaconda-18.37.7-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2012-20838/dracut-024-17.git20121220.fc18,anaconda-18.37.7-1.fc18

Package dracut-024-17.git20121220.fc18, anaconda-18.37.8-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 dracut-024-17.git20121220.fc18 anaconda-18.37.8-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-20838/dracut-024-17.git20121220.fc18,anaconda-18.37.8-1.fc18
then log in and leave karma (feedback).

Fixed in that the shrink option has been removed.

Shrink is required for the QA:TestCase Windows Dual Boot so removing it is acceptable only as a short term solution.

"Shrink is required for the QA:TestCase Windows Dual Boot"

Hmm, you're right, but it shouldn't. Don't know why I didn't catch that when we wrote it. It should start with a Windows install and free space, as we explicitly don't guarantee shrink functionality.

With anaconda 18.37.8 there is no shrink functionality in guided partitioning dialog. Marking as VERIFIED.

dracut-024-17.git20121220.fc18, anaconda-18.37.8-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.