Bug 733808 - Installer shrink function fails when asked to shrink an NTFS Partition
Summary: Installer shrink function fails when asked to shrink an NTFS Partition
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: ntfsprogs
Version: 16
Hardware: i386
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Tom "spot" Callaway
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedNTH
Depends On:
Blocks: F16Beta-accepted, F16BetaFreezeExcept
TreeView+ depends on / blocked
 
Reported: 2011-08-26 23:38 UTC by Robert Lightfoot
Modified: 2013-02-14 02:24 UTC (History)
7 users (show)

Fixed In Version: anaconda-16.17-1.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-14 02:24:33 UTC


Attachments (Terms of Use)
Installer Error message (35.44 KB, image/png)
2011-08-30 01:11 UTC, Robert Lightfoot
no flags Details
anaconda log (6.75 KB, text/plain)
2011-08-30 01:12 UTC, Robert Lightfoot
no flags Details
ifcfg log (510 bytes, text/plain)
2011-08-30 01:13 UTC, Robert Lightfoot
no flags Details
program log (25.62 KB, text/plain)
2011-08-30 01:13 UTC, Robert Lightfoot
no flags Details
storage log (102.61 KB, text/plain)
2011-08-30 01:14 UTC, Robert Lightfoot
no flags Details
xorg log (27.17 KB, text/plain)
2011-08-30 01:14 UTC, Robert Lightfoot
no flags Details
anaconda log 9-1-11 using dlehman patch (7.40 KB, application/octet-stream)
2011-09-02 00:24 UTC, Robert Lightfoot
no flags Details
ifcfg log 9-1-11 using dlehman patch (508 bytes, application/octet-stream)
2011-09-02 00:25 UTC, Robert Lightfoot
no flags Details
program log 9-1-11 using dlehman patch (39.38 KB, patch)
2011-09-02 00:25 UTC, Robert Lightfoot
no flags Details | Diff
storage log 9-1-11 using dlehman patch (107.01 KB, application/octet-stream)
2011-09-02 00:26 UTC, Robert Lightfoot
no flags Details
xorg log 9-1-11 using dlehman patch (27.32 KB, application/octet-stream)
2011-09-02 00:27 UTC, Robert Lightfoot
no flags Details
ntfsresize log output (1.18 MB, application/octet-stream)
2011-09-03 00:57 UTC, Robert Lightfoot
no flags Details
anaconda.log from Beta.RC2 failed install (7.58 KB, application/octet-stream)
2011-09-26 01:54 UTC, Robert Lightfoot
no flags Details
ifcfg log from Beta.RC2 failed install (574 bytes, application/octet-stream)
2011-09-26 01:55 UTC, Robert Lightfoot
no flags Details
program log from Beta.RC2 failed install (44.68 KB, application/octet-stream)
2011-09-26 01:56 UTC, Robert Lightfoot
no flags Details
storage log from failed Beta.RC2 install (106.64 KB, application/octet-stream)
2011-09-26 01:57 UTC, Robert Lightfoot
no flags Details
X.log from Beta.RC2 failed Install (79.33 KB, application/octet-stream)
2011-09-26 01:59 UTC, Robert Lightfoot
no flags Details
sector 63 from dd command of winxp system after installer started but before error failure (512 bytes, application/octet-stream)
2011-09-26 02:00 UTC, Robert Lightfoot
no flags Details
sector 63 from dd command of winxp system after installer error failure (512 bytes, application/octet-stream)
2011-09-26 02:03 UTC, Robert Lightfoot
no flags Details
sector 2048 from dd command of winxp system after installer started but before error failure (512 bytes, application/octet-stream)
2011-09-26 02:04 UTC, Robert Lightfoot
no flags Details
sector 2048 from dd command of winxp system after installer error failure (512 bytes, application/octet-stream)
2011-09-26 02:06 UTC, Robert Lightfoot
no flags Details
fdisk -l from initial windows system (709 bytes, application/octet-stream)
2011-09-26 19:47 UTC, Robert Lightfoot
no flags Details
fdisk -l after resizing before changing partiton table (709 bytes, application/octet-stream)
2011-09-26 19:48 UTC, Robert Lightfoot
no flags Details
parted -l before resizing partition table (470 bytes, application/octet-stream)
2011-09-26 19:48 UTC, Robert Lightfoot
no flags Details
parted -l after changing partition table size (470 bytes, application/octet-stream)
2011-09-26 19:49 UTC, Robert Lightfoot
no flags Details
The initial sector 63 dd export (512 bytes, application/octet-stream)
2011-09-26 19:49 UTC, Robert Lightfoot
no flags Details
the sector 63 dd export after ntfsresize (512 bytes, application/octet-stream)
2011-09-26 19:50 UTC, Robert Lightfoot
no flags Details
The sector 63 export after parted changed the partition table (512 bytes, application/octet-stream)
2011-09-26 19:51 UTC, Robert Lightfoot
no flags Details
sector 63 preisntall but post resize - windows still boots (512 bytes, text/plain)
2011-09-28 01:21 UTC, Robert Lightfoot
no flags Details
sector 63 post isntall of fedora - windows does mount but doesn't boot (512 bytes, text/plain)
2011-09-28 01:22 UTC, Robert Lightfoot
no flags Details
ntfsfix -n output (159 bytes, text/plain)
2011-09-28 01:23 UTC, Robert Lightfoot
no flags Details
parted -l from final system (836 bytes, text/plain)
2011-09-28 01:25 UTC, Robert Lightfoot
no flags Details
fdisk -l from final system (1.13 KB, text/plain)
2011-09-28 01:25 UTC, Robert Lightfoot
no flags Details

Description Robert Lightfoot 2011-08-26 23:38:08 UTC
Description of problem:
Use installer normally and receive an error message that Exit Code was 1 and system may now be unbootable.

Version-Release number of selected component (if applicable):
Fedora 16 alpha rc5

How reproducible:


Steps to Reproduce:
1. Select shrink option at install how screen
2.
3.
  
Actual results:
NTFS partiton shrink attempt results in an error message and error code 1

Expected results:
NTFS partiton should shrink.

Additional info:

THIS SHOULD WORK FOR FINAL RELEASE IF NOT BETA.

Comment 1 Brian Lane 2011-08-27 00:31:32 UTC
Please switch to tty2 (ctrl-alt-f2) and attach the logs from /tmp/*log to this bug as individual plain/text files.

Comment 2 Robert Lightfoot 2011-08-30 01:11:41 UTC
Created attachment 520493 [details]
Installer Error message

Comment 3 Robert Lightfoot 2011-08-30 01:12:40 UTC
Created attachment 520494 [details]
anaconda log

<CTRL><ALT><F2> gathered information

Comment 4 Robert Lightfoot 2011-08-30 01:13:20 UTC
Created attachment 520495 [details]
ifcfg log

<CTRL><ALT><F2> gathered information

Comment 5 Robert Lightfoot 2011-08-30 01:13:49 UTC
Created attachment 520496 [details]
program log

<CTRL><ALT><F2> gathered information

Comment 6 Robert Lightfoot 2011-08-30 01:14:20 UTC
Created attachment 520497 [details]
storage log

<CTRL><ALT><F2> gathered information

Comment 7 Robert Lightfoot 2011-08-30 01:14:48 UTC
Created attachment 520498 [details]
xorg log

<CTRL><ALT><F2> gathered information

Comment 8 Brian Lane 2011-08-30 16:10:00 UTC
Looks like ntfsresize doesn't like your disk. There are a bunch of errors like this in program.log

20:41:30,534 INFO program: Running... ntfsresize -m /dev/sda1
20:41:34,346 INFO program: ntfsresize v2011.4.12 (libntfs-3g)
20:41:34,351 INFO program: ntfs_mst_post_read_fixup: magic: 0x00000005  size: 1024  usa_ofs: 0  usa_count: 65535: Invalid argument
20:41:34,351 INFO program: Record 59142 has no FILE magic (0x5)

Comment 9 Robert Lightfoot 2011-08-30 20:09:10 UTC
Funny - It boots fine in XP.  Spent the day running all the windows system utilities on the disk and then tar'ing the .img file so I could restore easily.  Even on a "totally clean disk" from Windows perspective the installer halts and errors.  Going to try booting live dvd with HD attached and see if ntfsresize from cli can yield any more info.

Comment 10 David Lehman 2011-08-30 20:18:26 UTC
There is an anaconda bug here. I'll post a patch for it today for review. It's a trivial change.

Comment 11 David Lehman 2011-08-30 22:00:38 UTC
Due to the combination of an overly-cautious conditional and a not-so-recent change to make ntfs not mountable during install, anaconda was never checking the size of the existing ntfs filesystem. This led to mayhem when trying to schedule/execute resize operations.

Comment 12 Robert Lightfoot 2011-09-01 08:50:09 UTC
F16-Beta.TC1 still balks at shrinking an NTFS partiton.  So maybe it didn't get patched?

Comment 13 David Lehman 2011-09-01 14:08:58 UTC
POST means the patch is out for review. The patch has not been included in a build yet. The fix will most likely appear in anaconda-16.17-1.

Comment 14 Robert Lightfoot 2011-09-01 18:35:16 UTC
So as a proventester where can I find the patch and test instructions.  Or do I wait for anaconda 16.17-1?

Comment 15 Adam Williamson 2011-09-01 18:35:42 UTC
We explicitly don't consider resize bugs to be release blocking - 'resiz' does not appear in the criteria for a reason - but I'd see this as definitely NTH for Beta, proposing.

Comment 16 Adam Williamson 2011-09-01 18:36:12 UTC
bob: you'd have to rebuild anaconda for yourself and then build a boot.iso with the updated anaconda. that's possible, but it's a dose of heavy lifting. if you really want instructions, grab me on IRC.

Comment 17 David Lehman 2011-09-01 18:47:54 UTC
Just boot F16-Beta.TC1 with updates=http://dlehman.fedorapeople.org/updates-733808.img in the boot arguments. Let me know how it goes.

Comment 18 Robert Lightfoot 2011-09-02 00:24:55 UTC
Created attachment 521116 [details]
anaconda log  9-1-11 using dlehman patch

Comment 19 Robert Lightfoot 2011-09-02 00:25:20 UTC
Created attachment 521117 [details]
ifcfg log 9-1-11 using dlehman patch

Comment 20 Robert Lightfoot 2011-09-02 00:25:49 UTC
Created attachment 521118 [details]
program log 9-1-11 using dlehman patch

Comment 21 Robert Lightfoot 2011-09-02 00:26:35 UTC
Created attachment 521119 [details]
storage log 9-1-11 using dlehman patch

Comment 22 Robert Lightfoot 2011-09-02 00:27:06 UTC
Created attachment 521120 [details]
xorg log 9-1-11 using dlehman patch

Comment 23 Robert Lightfoot 2011-09-02 00:28:54 UTC
David - added the updates=http://dlehman.fedorapeople.org/updates-733808.img to the kernel line as a boot option and still received the same looking crash result.  Hopefully the logs will show you more.

Comment 24 David Lehman 2011-09-02 02:22:16 UTC
I think the immediate problem here is ntfsresize. It would be instructive if you could run 'ntfsresize -c /dev/sda1' from the shell on tty2 (during install) and see what the output looks like.

Comment 25 Jean-Pierre André 2011-09-02 15:04:06 UTC
> 20:41:30,534 INFO program: Running... ntfsresize -m /dev/sda1
> 20:41:34,346 INFO program: ntfsresize v2011.4.12 (libntfs-3g)
> 20:41:34,351 INFO program: ntfs_mst_post_read_fixup: magic: 0x00000005  size:
> 1024  usa_ofs: 0  usa_count: 65535: Invalid argument
> 20:41:34,351 INFO program: Record 59142 has no FILE magic (0x5)

This is a warning, not an error, it means the record is not initialized and has never been used. It should not prevent the resizing. Do a chkdsk on Windows to make sure.

Do you have other error messages ? Start ntfsresize with option -n for a read-only check.

Comment 26 Robert Lightfoot 2011-09-03 00:56:29 UTC
ran chkdsk -c and was told that system was not dirty.  Then ran chkdsk /p and it found one or more errors.  Ran chkdsk /r and it fixed the errors so that chkdsk /p returns no errors found.  The booted live.iso with hda attached and ran ntfsresize.  Output of the ntfsresize -nvs 16G /dev/sda1 is in ntfsresize.log attached.

Comment 27 Robert Lightfoot 2011-09-03 00:57:47 UTC
Created attachment 521305 [details]
ntfsresize log output

Comment 28 Robert Lightfoot 2011-09-03 01:06:06 UTC
Response with clean drive as judged by chkdsk was the same as before.

Comment 29 Jean-Pierre André 2011-09-03 10:20:02 UTC
> Response with clean drive as judged by chkdsk was the same as before.

Which response is this about ? Your test of ntfsresize went through, now do it for real....

Comment 30 Robert Lightfoot 2011-09-05 01:13:41 UTC
What it means is that the Windows chkdsk clean disk did not progress past the shrink operation in the installer and crashed the installer as it has in past trials.  I am working on shrinking and clearing free space using the live cd to see if ntfsresize and fdisk have any problem doing the work.

Comment 31 Fedora Update System 2011-09-08 17:29:04 UTC
anaconda-16.17-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/anaconda-16.17-1.fc16

Comment 32 Fedora Update System 2011-09-08 20:50:04 UTC
Package anaconda-16.17-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-16.17-1.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/anaconda-16.17-1.fc16
then log in and leave karma (feedback).

Comment 33 Robert Lightfoot 2011-09-09 09:28:34 UTC
Was able to boot F16-Beta.TC1 to the basic storage devices screen and then <ctrl><alt><f2> to tty and run ntfsresize -s 20480M /dev/sda1 and then found that while fdisk lists the starting sector as 63 when a new partition is created the starting sector is 2048.  Went to parted and the starting sector was 32.3kb aka 63 in fdisk and could be declared as 32.3kb in the newly created partition as well.  

Then progressed with isntaller choosing Use-free-Space option and install progressed more or less normally.  It is still ongoing as I type this 294 of 1224 packages installed for graphical desktop.

Would the fdisk change from a starting sector of 63 to 2048 cause issues?  I am thinking it might.

Comment 34 Robert Lightfoot 2011-09-09 09:29:42 UTC
Not to stupid or belabor the point, but how do I tell an F16-beta.TC1 DVD to use the anaconda-16.17-1.fc16 version of anaconda and not whats on the disk?

Comment 35 Robert Lightfoot 2011-09-09 12:29:34 UTC
OK I now have a bootable Fedora System with bug 735273 - ie windows won't boot.

Comment 36 Jean-Pierre André 2011-09-09 13:15:43 UTC
> Would the fdisk change from a starting sector of 63 to 2048 cause issues?

It obviously does. 63 is the usual starting sector (beginning of second cylinder) for Windows. ntfsresize assumes the beginning of the ntfs partition is not relocated (so far it cannot relocate its boot data on its own first sector). So the partition editor must keep the beginning of an existing ntfs partition unchanged.

Relocating the beginning of a resized partition reminds me of an old bug in parted which is documented as being solved : see https://bugzilla.gnome.org/show_bug.cgi?id=379482

There is a possibility you could repair the partition by deleting it and rebuilding to start at sector 63 provided the existing data were just ignored. If you dump the sectors 63 and 2048, I can tell whether some tool has possibly made an attempt to fully relocate the ntfs partition.

dd if=/dev/sda of=sector63 skip=63 bs=512 count=1
dd if=/dev/sda of=sector2048 skip=2048 bs=512 count=1

Comment 37 Adam Williamson 2011-09-09 18:35:12 UTC
Discussed at NTH review meeting of 2011-09-02. Agreed this is accepted as NTH as it's a visible installer issue which can't be fixed with an update.

Comment 38 Robert Lightfoot 2011-09-13 12:02:40 UTC
Note of additional information - the shrink function of FC15 also fails on an ntfs partition.

Comment 39 Adam Williamson 2011-09-23 01:29:50 UTC
what's the status of this bug with Beta RC1, please? thanks.

Comment 40 Jean-Pierre André 2011-09-23 07:23:38 UTC
> what's the status of this bug with Beta RC1, please? thanks.

No idea. But if you posted the contents of sectors 63 and 2048, I would have facts to support my theory that this is not an ntfsresize (ntfsprogs) bug. It looks to me like passing wrong information to the partition editor leading to partitions being recreated without taking existing data into account.

Comment 41 Robert Lightfoot 2011-09-26 01:52:04 UTC
Sorry for the delay Jean-Pierre in posting the sectors.  The sectors posted are from 16-Beta.RC2 and the before are as soon as the installer started up and the afters are after it crashed.

Comment 42 Robert Lightfoot 2011-09-26 01:54:51 UTC
Created attachment 524812 [details]
anaconda.log from Beta.RC2 failed install

Comment 43 Robert Lightfoot 2011-09-26 01:55:38 UTC
Created attachment 524813 [details]
ifcfg log from Beta.RC2 failed install

Comment 44 Robert Lightfoot 2011-09-26 01:56:32 UTC
Created attachment 524815 [details]
program log from Beta.RC2 failed install

Comment 45 Robert Lightfoot 2011-09-26 01:57:44 UTC
Created attachment 524817 [details]
storage log from failed Beta.RC2 install

Comment 46 Robert Lightfoot 2011-09-26 01:59:00 UTC
Created attachment 524818 [details]
X.log from Beta.RC2 failed Install

Comment 47 Robert Lightfoot 2011-09-26 02:00:09 UTC
Created attachment 524819 [details]
sector 63 from dd command of winxp system after installer started but before error failure

Comment 48 Robert Lightfoot 2011-09-26 02:03:32 UTC
Created attachment 524822 [details]
sector 63 from dd command of winxp system after installer error failure

Comment 49 Robert Lightfoot 2011-09-26 02:04:57 UTC
Created attachment 524823 [details]
sector 2048 from dd command of winxp system after installer started but before error failure

Comment 50 Robert Lightfoot 2011-09-26 02:06:38 UTC
Created attachment 524824 [details]
sector 2048 from dd command of winxp system after installer error failure

Comment 51 Jean-Pierre André 2011-09-26 08:21:45 UTC
The sector dumps show that there is no NTFS bootsector at sector 2048. There is one at sector 63 for a partition of 62894411 sectors (32GB). There has probably been no resizing at all. Where did you get mention of a partition starting at sector 2048 from ? What is the actual partitioning after the failure (using sector units) ? Also what is the error message when the installer fails ?

At the end of program.log, I see :
17:48:50,921 INFO program: Running... ntfsresize -m /dev/sda1
17:48:52,411 INFO program: ntfsresize v2011.4.12 (libntfs-3g)
[...]
17:48:52,434 INFO program: Minsize (in MB): 15649
[...]
17:49:07,283 INFO program: Running... ntfsresize -c /dev/sda1
17:49:07,336 INFO program: n

So ntfsresize could run at 17:48:52, but probably not at 17:49:07, and the "ntfsresize -c" is just checking whether the partition can be mounted, which is was two minutes earlier.

Storage.log shows what happened at 17:49:06 : the device was repartitioned :

17:49:06,841 DEBUG storage: action: [1] Resize Device (Shrink) partition sda1 (id 11)

It looks like this repartitioning prevented ntfsresize from doing its job, though I do not see the new partition limits in the log. Obviously the file system should be shrunk before the partition is shrunk.

Comment 52 Robert Lightfoot 2011-09-26 10:20:11 UTC
OK the 2048 comes from if you boot the installer and before pressing next on the "basic storage devices" option of the gui you switch to console <ctrl><alt><f2> and run ntfsresize -s 16384M /dev/sda1 ; which as I understand it resizes the ntfs file structure, but the fdisk partiton table still lists things as 32gb rather than the new 16GB.  Now if you launch fdisk it lists the partition 1 as starting as sector 63, but when you blow away partition 1 with fdisk and goto recreate your only option is a first sector of 2048.  I found to get a first sector of 63 on my new partition 1 I had to use parted.  Clear as mud I hope.  Anyways using parted and selecting sector 63 as the start I laid in a new partition of 16384M and then switched back to the gui and used the "use free space" option which worked for giving me a bootable fedora system, but windows was still hosed.

Comment 53 Robert Lightfoot 2011-09-26 10:57:41 UTC
Just tried the manual resize again with beta.RC2 as follows:
Step 1 - ntfsresize -cv /dev/sda1  ; passed ok
Step 2 - ntfsresize -i /dev/sda1 ; passed ok and recommended a 15000M SIZE
Step 3 - ntfsresize -n -s 16384M /dev/sda1 ; failed because needed exteneded address space suggested trying less free space.
Step 4 - ntfsresize -n -s 20480M /dev/sda1 ; passed without issue
Step 5 - ntfsresize -v -s 20480M /dev/sda1 running as I type this more to come

Comment 54 Robert Lightfoot 2011-09-26 11:17:58 UTC
OK - ntfsresize completes successfully, but fdisk wants to change the starting partition from 63 to 2048.  Use parted and got the partition start to remain at 63 but the end was moved from 32gb to 20.5gb.

Then exited fedora and rebooted to see if I had a working windows partition with free space and viola "unmountable boot volume" BSOD.

might be why this all fails.

Comment 55 Robert Lightfoot 2011-09-26 11:31:43 UTC
Might be of my own doing in specifying the wromg parameters to parted.  Checking into this welcome input.

Comment 56 Jean-Pierre André 2011-09-26 12:33:55 UTC
> and run ntfsresize -s 16384M /dev/sda1 ; which as I
> understand it resizes the ntfs file structure, but the
> fdisk partiton table still lists things as 32gb rather
> than the new 16GB.

This is correct. ntfsresize resizes the file system (the contents), not the partition (the container). You have to use a partition editor.

> Now if you launch fdisk it lists the partition 1 as starting
> as sector 63, but when you blow away partition 1 with
> fdisk and goto recreate your only option is a first sector
> of 2048.

If fdisk cannot start the partition at sector 63, it has been started with wrong arguments or it is buggy.

> I found to get a first sector of 63 on my new partition 1
> I had to use parted.  Clear as mud I hope.

What is unclear there ? Did you use fdisk at all in the process ? It could have changed the partition type or have overwritten the Windows booting data.

> Anyways using parted and selecting sector 63 as the start
> I laid in a new partition of 16384M and then switched back
> to the gui and used the "use free space" option which worked
> for giving me a bootable fedora system, but windows was
> still hosed.

Can you post the partition layout (sector unit) and the contents of sector 63
at this stage ? You were using MB as a unit in ntfsresize and parted, and the roundings they did might be different. Also please start ntfsfix for checking the compatibility of the file system and the partition and fix the discrepancy (please post the output from ntfsfix). Can you mount the partition and under Fedora ?

An important point would also be to know the partition editor used by anaconda. Using different tools may lead to a bootable Windows, but not solve the original problem.

Comment 57 Robert Lightfoot 2011-09-26 19:46:08 UTC
Ok repeat test to gather information requested.
Step 1 - Restore WindowsXP vm from tar.gz file
Step 2 - Launch Windows CD and run chkdsk /p and chkdsk /r on C: {/dev/sda1} and get clean bill of health
Step 3 - Boot Windows vm and confirm it starts up and shuts down as expected.
Step 4 - Boot F16-Beta.RC2 Installer as far as language select prompt and switch to tty2.
Step 5 - fdisk -l > initial_partition_table.dat captured and saved
Step 6 - dd if=/dev/sda of=/tmp/sector63initial.dat skip=63 bs=512 count=1  captured and saved
Step 7 - ntfsresize -cv /dev/sda1  ; passed ok
Step 8 - ntfsresize -iv /dev/sda1 ; passed ok and recommended a 16000M SIZE
Step 9 - ntfsresize -n -s 1683797168 /dev/sda1 ; failed because needed exteneded
address space suggested trying less free space.
Step 10 - ntfsresize -n -s 21474836480 /dev/sda1 ; passed without issue
Step 11 - ntfsresize -v -s 21474836480 /dev/sda1 run without error reported
Step 12 - fdisk -l > resized_partition_table.dat captured and saved
Step 13 - dd if=/dev/sda of=/tmp/sector63resized.dat skip=63 bs=512 count=1  captured and saved
Step 14 - run parted and remove partition 1
Step 15 - created partition 1 with parted start at sector=63 and end=41943103 and a size of 41943040. and set the flag boot as on.
Step 16 - dd if=/dev/sda of=/tmp/sector63postresize.dat skip=63 bs=512 count=1  captured and saved
NOTE : 21474836480 bytes divided by 512 bytes == 41943040 sectors
Step 17 - reboot to see if windows is viable. which it was.
Step 18 - reboot and install F16-Beta.RC2 using free space made from resize.
Install Proceeded normally

Comment 58 Robert Lightfoot 2011-09-26 19:47:20 UTC
Created attachment 524966 [details]
fdisk -l from initial windows system

Comment 59 Robert Lightfoot 2011-09-26 19:48:03 UTC
Created attachment 524967 [details]
fdisk -l after resizing before changing partiton table

Comment 60 Robert Lightfoot 2011-09-26 19:48:45 UTC
Created attachment 524969 [details]
parted -l before resizing partition table

Comment 61 Robert Lightfoot 2011-09-26 19:49:18 UTC
Created attachment 524970 [details]
parted -l after changing partition table size

Comment 62 Robert Lightfoot 2011-09-26 19:49:54 UTC
Created attachment 524971 [details]
The initial sector 63 dd export

Comment 63 Robert Lightfoot 2011-09-26 19:50:31 UTC
Created attachment 524972 [details]
the sector 63 dd export after ntfsresize

Comment 64 Robert Lightfoot 2011-09-26 19:51:09 UTC
Created attachment 524973 [details]
The sector 63 export after parted changed the partition table

Comment 65 Robert Lightfoot 2011-09-26 19:57:13 UTC
Jeanne-Pierre  sorry I didn't run ntfsfix on the "hosed" system.  Looks like if
I get the ntfsresize in bytes and the parted partitions in sectors to align
that you can get a working system.

This still leaves us the initial problem that if on a 30GB disk with 16GB
occupied by windows I try and shrink to a 14GB space for Fedora it fails
whether done by the anaconda installer or manually from tty2.  

it appears from the manual approach that ntfsresize cannnot give you more than
10gb of freespace for Fedora.  This is not a tried and true hard fact just my
experience in two cases now.

Comment 66 David Lehman 2011-09-26 21:06:18 UTC
(In reply to comment #51)
> The sector dumps show that there is no NTFS bootsector at sector 2048. There is
> one at sector 63 for a partition of 62894411 sectors (32GB). There has probably
> been no resizing at all. Where did you get mention of a partition starting at
> sector 2048 from ? What is the actual partitioning after the failure (using
> sector units) ? Also what is the error message when the installer fails ?
> 
> At the end of program.log, I see :
> 17:48:50,921 INFO program: Running... ntfsresize -m /dev/sda1
> 17:48:52,411 INFO program: ntfsresize v2011.4.12 (libntfs-3g)
> [...]
> 17:48:52,434 INFO program: Minsize (in MB): 15649
> [...]
> 17:49:07,283 INFO program: Running... ntfsresize -c /dev/sda1
> 17:49:07,336 INFO program: n
> 
> So ntfsresize could run at 17:48:52, but probably not at 17:49:07, and the
> "ntfsresize -c" is just checking whether the partition can be mounted, which is
> was two minutes earlier.
> 
> Storage.log shows what happened at 17:49:06 : the device was repartitioned :
> 
> 17:49:06,841 DEBUG storage: action: [1] Resize Device (Shrink) partition sda1
> (id 11)
> 
> It looks like this repartitioning prevented ntfsresize from doing its job,
> though I do not see the new partition limits in the log. Obviously the file
> system should be shrunk before the partition is shrunk.

You misunderstand the log message. The message you will see to indicate anaconda is actually performing the action will start with "executing action:". The ntfsresize -c is run immediately before trying to resize the filesystem and we do not try to perform the resize if the check fails.

Comment 67 Robert Lightfoot 2011-09-26 23:50:26 UTC
Based on David's comment and my experience using ntfsresize and parted manually I need to try things automatically with anaconda using a free space of less then 10gb and see if it succeeds.

Comment 68 Jean-Pierre André 2011-09-27 07:12:58 UTC
> if on a 30GB disk with 16GB occupied by windows I try
> and shrink to a 14GB space for Fedora it fails

Windows is not a live-CD, it needs some free disk space to run.

> I need to try things automatically with anaconda using a
> free space of less then 10gb and see if it succeeds.

You have proven that the repartitioning is possible with a set of parameters, now you have to do the same automatically. If you reach a Windows unbootable state, please post the *final* situation :

- the partition layout with sector units
- the first sector of the Windows partition (be it 63 or 2048)
- whether the Windows partition can be mounted on Linux (e.g. on a live-CD)
- the output of ntfsfix -n

Comment 69 Robert Lightfoot 2011-09-28 01:20:04 UTC
The Jeanne_Pierre *final* situation with unbootable windows
1.  Start with Bootable 30GB windows guest vm on Fedora FC14-x86_64 host. 

2. Resize ntfs partition to create free space
ntfsresize -v -s 21474836480 /dev/sda1 run without error reported
parted created a new primary bootable partiton 1 from 63 to 41943103 sectors
Captured a postresize dd export of sector 63 and post it after this comment

3. Reboot resized ntfs partition before isntalling Fedora and confirm it works.
NOTE: chkdsk does run as queued by ntfsresize

4. Install F16-Beta.RC2 into free space using default options.

5. Reboot into F16-Beta.RC2 and Capture a postinstall dd export of sector 63 and post it after this comment.

6. attempted to mount /dev/sda1 to /mnt/sysimage. response was "disk contains an unclean filesystem (0, 1). The file system wasn't safely closed on Windows. Fixing" and then it mounts and is browsable.

7. ntfsfix -n returns no errors but output is attached.

8.  reboot to windows then still fails

Comment 70 Robert Lightfoot 2011-09-28 01:21:11 UTC
Created attachment 525240 [details]
sector 63 preisntall but post resize - windows still boots

Comment 71 Robert Lightfoot 2011-09-28 01:22:05 UTC
Created attachment 525241 [details]
sector 63 post isntall of fedora - windows does mount but doesn't boot

Comment 72 Robert Lightfoot 2011-09-28 01:23:58 UTC
Created attachment 525242 [details]
ntfsfix -n output

Comment 73 Robert Lightfoot 2011-09-28 01:25:23 UTC
Created attachment 525243 [details]
parted -l from final system

Comment 74 Robert Lightfoot 2011-09-28 01:25:56 UTC
Created attachment 525244 [details]
fdisk -l from final system

Comment 75 Robert Lightfoot 2011-09-28 08:22:39 UTC
I know this was F16-Beta NTH but reading Final Criteria 5 would it also be a final bolocker?  "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above "

Since a shrinkable partition did not succeed to work?

Comment 76 Jean-Pierre André 2011-09-28 09:19:22 UTC
I am getting short of ideas. The final state looks correct to me : the partitioning is as expected, the ntfs boot sector is correct, ntfsfix identifies no error, and the partition is browsable on Linux. At step 3 in comment 69 you have resized and started chkdsk, so the resizing has been done and has led to a bootable Windows.

Note that the new NTFS boot sector shows a file system of 41943032 sectors starting a sector 63. There is no difference from the bootable situation you posted at comment 64. The size is consistent with what fdisk shows (41943040, one sector being reserved for the backup boot sector, and 7 sectors lost were when clustering to 8 sectors per cluster).

You could chkdsk after resizing (to me this means Windows was bootable at this stage), but Windows was not bootable later on. Why should the blame be put on ntfsresize ?

Which ntfsresize were you using in comment 57 and comment 69 (the one from FC16, the one from the released FC14, or the one from updated FC14 ?), I do not know of meaningful differences, but who knows ?

Comment 77 Jean-Pierre André 2011-09-28 17:16:58 UTC
I now see an unexpected message at step 6 of comment 69 : "disk contains
an unclean filesystem... etc.", which should not be seen after the partition check at end of step 3. So the partition has been mounted and marked dirty or badly unmounted during install or reboot (step 4 or 5). What is that ?

Comment 78 Robert Lightfoot 2011-09-28 20:56:32 UTC
The ntfsresize used would be the fc16-Beta.RC2 I suspect as the resize was done in tty2 of the vm after booting the fc16-Beta.RC2 kernel and initrd from /isolinux folder.

The partition was attempted to b mounted after finishing the install, rebooting into fc16-Beta.RC2 and opening a terminal.  

I suppose I could switch to tty2 before starting the install and see if /dev/sda1 mounts with or without the "dirty" message.  DOn't know what that would tell us but would be nice to know if the linux mount command sees a freshly chkdsked platter as dirty or clean.

Comment 79 Jean-Pierre André 2011-09-29 06:37:36 UTC
> would be nice to know if the linux mount command sees a
> freshly chkdsked platter as dirty or clean.

chkdsk marks the partition dirty, but if you run chkdsk from Windows and close Windows properly, the partition will be marked clean. If you run chkdsk without closing Windows, it will be marked dirty.

If you closed Windows at step 3, the comment 69 shows the partition was accessed (and damaged) during install. I cannot say much more until I know why.

Comment 80 Robert Lightfoot 2011-09-29 07:32:22 UTC
Jean-Pierre Step 3 was to boot windows, let it run chkdsk as part of starting up and then use the start button and shutdown and wait for windows to compelte the shutdown before booting the vm using the f16-beta.pxeboot.dvd.

Comment 81 Fedora Update System 2011-09-30 19:38:49 UTC
anaconda-16.17-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 82 Robert Lightfoot 2011-10-01 23:49:41 UTC
anaconda 16.20 from RC4 still has this bug.

Comment 83 Jean-Pierre André 2011-10-12 20:46:38 UTC
I really cannot understand why in comment 69 step 6 you get "disk contains
an unclean filesystem, etc." This message can only be issued on the first mounting on Linux after an unclean unmounting by Windows, and any mounting should fix the cause for the message being issued. Actually I only see two possibilities :

a) booting on Windows was tried before step 6
b) after chkdsk at step 3, Windows was not closed safely

There could be another one : the initial bootable image or the image left after the chkdsk contained a hibernated Windows.

Comment 84 Danny D'Amours 2012-01-17 14:57:50 UTC
I ran into this bug on an FC16 64 bit install on a Dell 6420 laptop.
Using the Custom Layout option allowed me to shrink the NTFS partition and install properly.

Comment 85 Fedora End Of Life 2013-01-17 00:30:17 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 86 Fedora End Of Life 2013-02-14 02:24:38 UTC
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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