Bug 885912 - Resize of NTFS partition results in partition smaller than the filesystem, broken Windows install
Resize of NTFS partition results in partition smaller than the filesystem, br...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
18
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
AcceptedBlocker
: Reopened
: 875484 (view as bug list)
Depends On:
Blocks: bonding/Bug/interface/multiple F18Blocker/F18FinalBlocker
  Show dependency treegraph
 
Reported: 2012-12-10 20:36 EST by Robert Lightfoot
Modified: 2012-12-23 17:57 EST (History)
13 users (show)

See Also:
Fixed In Version: anaconda-18.37.4-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-20 16:16:53 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Compressed File with contents of /var/log/anaconda from non-working attempt (128.20 KB, application/x-gzip)
2012-12-11 08:46 EST, Robert Lightfoot
no flags Details
Compressed File of logs from Working attempt - /var/log/anaconda (128.28 KB, application/x-gzip)
2012-12-11 08:56 EST, Robert Lightfoot
no flags Details
Grub2 Windows Section from Working System (668 bytes, application/octet-stream)
2012-12-13 00:59 EST, Robert Lightfoot
no flags Details
anaconda program.log (421.93 KB, text/plain)
2012-12-13 16:50 EST, Chris Murphy
no flags Details
anaconda storage.log (173.47 KB, text/plain)
2012-12-13 16:51 EST, Chris Murphy
no flags Details
storage.log w/ targeted logging (178.81 KB, text/plain)
2012-12-14 15:44 EST, Chris Murphy
no flags Details
storage.log with updates applied (i do not performed the installation) (85.18 KB, text/plain)
2012-12-14 15:49 EST, Reartes Guillermo
no flags Details
F18-TC2-I386-ClumensUpdateImg-Anaconda-ifcfg.log (505 bytes, application/octet-stream)
2012-12-15 03:55 EST, Robert Lightfoot
no flags Details
F18-TC2-I386-ClumensUpdateImg-Anaconda.log (9.85 KB, application/octet-stream)
2012-12-15 03:56 EST, Robert Lightfoot
no flags Details
F18-TC2-I386-ClumensUpdateImg-Anaconda.packaging.log (519.75 KB, application/octet-stream)
2012-12-15 03:57 EST, Robert Lightfoot
no flags Details
F18-TC2-I386-ClumensUpdateImg-Anaconda.storage.log (97.54 KB, text/plain)
2012-12-15 03:58 EST, Robert Lightfoot
no flags Details
F18-TC2-I386-ClumensUpdateImg-Syslog (60.95 KB, application/octet-stream)
2012-12-15 03:59 EST, Robert Lightfoot
no flags Details
F18-TC2-x8664-ClumensUpdateImg-Anaconda-ifcfg.log (505 bytes, application/octet-stream)
2012-12-15 04:09 EST, Robert Lightfoot
no flags Details
F18-TC2-x8664-ClumensUpdateImg-Anaconda.log (10.04 KB, application/octet-stream)
2012-12-15 04:10 EST, Robert Lightfoot
no flags Details
F18-TC2-x8664-ClumensUpdateImg-Anaconda.packaging.log (523.50 KB, application/octet-stream)
2012-12-15 04:11 EST, Robert Lightfoot
no flags Details
F18-TC2-x8664-ClumensUpdateImg-Anaconda.storage.log (97.92 KB, application/octet-stream)
2012-12-15 04:12 EST, Robert Lightfoot
no flags Details
F18-TC2-x8664-ClumensUpdateImg-Anaconda.xlog (59.70 KB, application/octet-stream)
2012-12-15 04:13 EST, Robert Lightfoot
no flags Details
F18-TC2-x8664-ClumensUpdateImg-Syslog (68.46 KB, application/octet-stream)
2012-12-15 04:14 EST, Robert Lightfoot
no flags Details
F18-TC2-i386-ClumensUpdateImg-Anaconda.xlog (60.45 KB, application/octet-stream)
2012-12-15 04:16 EST, Robert Lightfoot
no flags Details
storage.log (174.16 KB, text/plain)
2012-12-18 15:16 EST, Chris Murphy
no flags Details
storage.log (173.69 KB, text/plain)
2012-12-18 15:40 EST, Chris Murphy
no flags Details
storage.log (AFTER INSTALL) F18 TC2 with updates image (107.36 KB, text/plain)
2012-12-18 16:48 EST, Reartes Guillermo
no flags Details
storage.log (AFTER INSTALL) F18 smoke9 (138.88 KB, text/plain)
2012-12-20 20:46 EST, Reartes Guillermo
no flags Details

  None (edit)
Description Robert Lightfoot 2012-12-10 20:36:30 EST
Description of problem:
QA:Testcase dualboot with windows - F18-TC1 Auto Partition Does not create Working Dual Boot System while Manual Partition does create a working system.

Version-Release number of selected component (if applicable):
F18-Final-TC1

How reproducible:
QA:Testcase dualboot with windows

Steps to Reproduce:
1. Install Windows XP to Fresh VM
2. Launch F18 Installer
3. Choose Shrink NTFS Partition and Automatic Partitioning
  
Actual results:
A system with only Fedora in Grub menu is offered

Expected results:
Dual Boot Grub options 

Additional info:
Comment 1 Robert Lightfoot 2012-12-10 20:42:44 EST
I would vote this if F18-NTH but not a Final Blocker as a technical following of the QA Test Case produces a working result.  It may be confusing for the neophyte end user however when auto partitioning appears to be working not to encounter this problem.
Comment 2 Steve Tyler 2012-12-11 00:30:48 EST
Thanks for your report. This sounds like an clear F18 blocker under this release criterion[1]:

9. 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

You can propose this bug as an F18 blocker by adding the F18Blocker bug alias[2] to the Blocks field for this bug.

BTW, the developers are going to want to see the log files.
They should be in /var/log/anaconda/.

[1] Fedora 18 Final Release Criteria
https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria

[2] http://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers
Comment 3 Robert Lightfoot 2012-12-11 00:59:10 EST
I am working to recreate as I type this.  When I tested with manual partitioning and x86_64 I got results similiar to i386 with auto partitioning.  Chasing a theory that libvirtd caused the issue and not f18.  I'll post more as I get data.  Biggest problem is lack of drive space and each test vm takes 30GB.
Comment 4 Steve Tyler 2012-12-11 01:08:51 EST
Thanks for your update. This sounds like a related bug:
Bug 875944 - shrinking Windows partition creates an unusable dual-boot setup
Comment 5 Robert Lightfoot 2012-12-11 02:47:30 EST
I am finishing testing a dual boot with automatic partitioning and now have a working theory that if the shrink function steps on the minimum space needed by XP that it does not respond to os-probe and thus fails.  If I use a 30GB disk and reduce windows to 18GB and have 12GB for Fedora then dual isntall fails.  If I use a 40GB disk and reduce windows to 28GB and have 12GB for Fedora then Dual Install Works.  I'll be posting anaconda log files later this morning or afternoon.

That other bug could be related.  -- I'll leave that to the real experts aka developers.
Comment 6 Robert Lightfoot 2012-12-11 08:46:57 EST
Created attachment 661462 [details]
Compressed File with contents of /var/log/anaconda from non-working attempt

From the non workign Dual Boot Instance
Comment 7 Robert Lightfoot 2012-12-11 08:56:42 EST
Created attachment 661477 [details]
Compressed File of logs from Working attempt - /var/log/anaconda

System is identical between working and non-working except one is i386 other is x8664 and one was auto-part other was manual part.
Comment 8 Robert Lightfoot 2012-12-11 08:59:14 EST
Update - I am keeping the i386 non-working model and x86_64 working model idle and untouched in case folks need more information from them.  I did have a working i386 but had to delete it for space to test x8664.  Bottom line Auto partition creates a system without a Windows Grub entry and Manual Partiton works as expected for Dual Boot Shrink install on XP.
Comment 9 Paul Franklin (RHlists) 2012-12-11 09:50:33 EST
+1 Final blocker.

(I remember getting libvirtd errors on my i386 installs
but I never tried to reproduce it or track it down.)
Comment 10 Adam Williamson 2012-12-12 13:27:52 EST
Discussed at 2012-12-12 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-12/f18final-blocker-review-4.2012-12-12-17.01.log.txt .  We agreed we cannot determine the status of this bug until we're sure what the trigger is - is it the size of the Windows partition, automatic vs. manual partitioning, or something else. Bob, it would help if you could post the resulting partition tables of the broken and working cases (with parted or fdisk). I will try and find time to try and reproduce this and see if I can figure what's going on.
Comment 11 Robert Lightfoot 2012-12-12 15:19:03 EST
parted from non working system -- 
(parted) print all                                                        
Model: ATA QEMU HARDDISK (scsi)
Disk /dev/sda: 42.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  3555MB  3555MB  primary  ntfs         boot
 2      3555MB  4079MB  524MB   primary  ext4
 3      4079MB  42.9GB  38.9GB  primary               lvm


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/fedora-swap: 2114MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags: 

Number  Start  End     Size    File system     Flags
 1      0.00B  2114MB  2114MB  linux-swap(v1)


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/fedora-root: 36.8GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags: 

Number  Start  End     Size    File system  Flags
 1      0.00B  36.8GB  36.8GB  ext4


(parted)
Comment 12 Robert Lightfoot 2012-12-12 15:20:39 EST
fdisk -l output from defective system -- 
[root@localhost ~]# fdisk -l

Disk /dev/sda: 42.9 GB, 42949672960 bytes, 83886080 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x25c325c3

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63     6942719     3471328+   7  HPFS/NTFS/exFAT
/dev/sda2         6942720     7966719      512000   83  Linux
/dev/sda3         7966720    83886079    37959680   8e  Linux LVM

Disk /dev/mapper/fedora-swap: 2113 MB, 2113929216 bytes, 4128768 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/fedora-root: 36.8 GB, 36754685952 bytes, 71786496 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

[root@localhost ~]#
Comment 13 Robert Lightfoot 2012-12-12 15:36:12 EST
parted output from working system ---
[root@localhost ~]# parted -l
Model: ATA QEMU HARDDISK (scsi)
Disk /dev/sda: 42.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  29.4GB  29.4GB  primary  ntfs         boot
 2      29.4GB  29.9GB  524MB   primary  ext4
 3      29.9GB  42.9GB  13.1GB  primary               lvm


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/fedora-swap: 2114MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags: 

Number  Start  End     Size    File system     Flags
 1      0.00B  2114MB  2114MB  linux-swap(v1)


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/fedora-root: 10.9GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags: 

Number  Start  End     Size    File system  Flags
 1      0.00B  10.9GB  10.9GB  ext4


[root@localhost ~]#
Comment 14 Robert Lightfoot 2012-12-12 15:37:25 EST
fdisk from working system -- 
[root@localhost ~]# fdisk -l

Disk /dev/sda: 42.9 GB, 42949672960 bytes, 83886080 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x14691469

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63    57343999    28671968+   7  HPFS/NTFS/exFAT
/dev/sda2        57344000    58367999      512000   83  Linux
/dev/sda3        58368000    83886079    12759040   8e  Linux LVM

Disk /dev/mapper/fedora-swap: 2113 MB, 2113929216 bytes, 4128768 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/fedora-root: 10.9 GB, 10947133440 bytes, 21381120 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

[root@localhost ~]#
Comment 15 Steve Tyler 2012-12-12 15:39:05 EST
(In reply to comment #11)
...
> Number  Start   End     Size    Type     File system  Flags
>  1      32.3kB  3555MB  3555MB  primary  ntfs         boot
>  2      3555MB  4079MB  524MB   primary  ext4
>  3      4079MB  42.9GB  38.9GB  primary               lvm
...

For the record, Windows XP requires:
"At least 1.5 gigabytes (GB) of available space on the hard disk"

System requirements for Windows XP operating systems
http://support.microsoft.com/kb/314865
Comment 16 Robert Lightfoot 2012-12-12 15:56:07 EST
My Computer from the working system shows 27.3 GB of space and 24.7 GB of free space.  

A dir from C:\ shows 26,596,126,720 bytes free .

This would see to suggest that auto-partition did not take into account the 1.5 GB Free requirement Steve Tyler mentions above.
Comment 17 Adam Williamson 2012-12-12 18:12:05 EST
Published Windows space requirements are basically useless. the 1.5GB is a theoretical minimum amount of disk space needed for a fresh install (which, more to the point, Microsoft more or less pulled out of their asses). 

In general, though, the fact that an existing, dirty Windows partition got squished down to 3.5GB in size rings all kinds of alarm bells for me. That's pretty small. Can you hack up a correct bootloader entry and try booting that copy of Windows and see if it actually works? Can you run the grub os-detect script on the broken system manually and see if you can get any useful output from it to indicate why it fails?
Comment 18 Steve Tyler 2012-12-12 18:20:20 EST
According to Comment 0, Robert is doing fresh Windows XP installs. Windows XP has some recovery tools, so it might be possible to get it booted that way. The overzealous NTFS squishing appears to be reported here:

Bug 875944 - shrinking Windows partition creates an unusable dual-boot setup
Comment 19 Robert Lightfoot 2012-12-13 00:59:31 EST
Created attachment 662763 [details]
Grub2 Windows Section from Working System

I "borrowed" this grub.cfg section 30 from the working system and ported it blindly to the broken one since the windows isntalls were identical as far as I can tell on the surface.  It squawked about and item 1C90E7... not existing but went on and tried to boot ending in a BSOD message about an unmountable_boot_volume.  It suggested a restart in safe mode which resulted in the same BSOD after loading mup.sys.  I am about to RTFM on os-prober and play around on the fedora side of the broken dual boot.  Adam if you have a specific set of os-prober commands you can recommend it will probably save us all some time.  I am thinking I might need to change that 1C90E7.... device string to whatever os-prober sees as the the broken windows device number.  Any recommended reading on Grub2 windows boot syntax would also be appreciated guaidance here for me.
Comment 20 Adam Williamson 2012-12-13 01:37:56 EST
it kinda does sound like somehow the windows install has been squished too far - if Windows actually tries to boot, you got the grub config right, you can't fix a Windows BSOD by fiddling with grub config. for os-prober just look at the script grub2 uses - /etc/grub.d/30_os-prober
Comment 21 Robert Lightfoot 2012-12-13 01:52:50 EST
Adam the line OSPROBED="`os-prober | tr ' ' '^' | paste -s -d ' '`"
leads me to believe the command I want is something like 
os-prober | tr ' ' '^' | paste -s -d ' '
but this returns nothing but a blank line, which kind of lines up with the 30 section being empty on the broken system.  Am I missing something here?
Comment 22 Robert Lightfoot 2012-12-13 02:09:47 EST
mounted a CD holding the Windows XP Install Cd and entered rescue mode.  chkdsk returns the nice message "the volume appears to contain one or more unrecoverable errors".  I was considering a bootcfg, fixboot or fixmbr command might yield something, but I'll wait to see what others think as the fixboot and fixmbr are probably irreversable except to reisntall and repeat the whole test case.
Comment 23 Steve Tyler 2012-12-13 02:13:32 EST
For reference, here is the Windows XP partitioning for an install to a 40 GiB VM disk image[1]. Note that there is a 13.7 MB free space at the end. Based on past experience, the Windows XP installer reserves some free space at the end. That free space has been consumed by sda3 according to the fdisk reports in Comment 12 and Comment 14.

[root@localhost xfr]# parted /dev/sda print free
Model: ATA QEMU HARDDISK (scsi)
Disk /dev/sda: 42.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  42.9GB  42.9GB  primary  ntfs         boot
        42.9GB  42.9GB  13.7MB           Free Space

[root@localhost xfr]# fdisk -l /dev/sda

Disk /dev/sda: 42.9 GB, 42949672960 bytes, 83886080 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x3ceb3ceb

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63    83859299    41929618+   7  HPFS/NTFS/exFAT
[root@localhost xfr]# 

[1] Created with:
$ qemu-img create winxp-test-1.img 40G
$ qemu-kvm -m 2048 -hda winxp-test-1.img -cdrom ~/xfr/fedora/winxp/winxp-1.iso -usb -vga qxl -boot menu=on -usbdevice mouse -rtc base=localtime
Comment 24 Steve Tyler 2012-12-13 02:24:12 EST
What does the Windows XP recovery console report for the working system?
Comment 25 Steve Tyler 2012-12-13 02:31:04 EST
Can you mount either NTFS file system from the Live CD?
Comment 26 Steve Tyler 2012-12-13 02:46:02 EST
Linux has a variety of NTFS tools, and they are available on the Live CD:
# rpm -ql ntfsprogs
# ntfsinfo -m /dev/sda1
Comment 27 Adam Williamson 2012-12-13 02:52:51 EST
boblfoot: it all kinda lines up with the theory that the resize was too aggressive, really, but you might be able to get more details from os-prober by running it through sh -x.
Comment 28 Robert Lightfoot 2012-12-13 03:03:34 EST
output of sh -x os-prober Blah Blah
http://fpaste.org/a743/
[root@localhost ~]# sh -x os-prober | tr ' ' '^' | paste -s -d ' '
+ set -e
+ . /usr/share/os-prober/common.sh
++ cleanup_tmpdir=false
++ cleanup_ro_partitions=
++ progname=
++ type mapdevfs
+ newns
+ '[' '' ']'
+ exec /usr/libexec/newns os-prober

[root@localhost ~]#
Comment 29 Robert Lightfoot 2012-12-13 03:05:45 EST
Steve Tyler - ntfsinfo -m /dev/sda1 returns
[root@localhost ~]# ntfsinfo -m /dev/sda1
Failed to read last sector (6943344): 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/sda1': Invalid argument
The device '/dev/sda1' 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/sda1'.
[root@localhost ~]#
Comment 30 Steve Tyler 2012-12-13 03:08:09 EST
(In reply to comment #29)
> Steve Tyler - ntfsinfo -m /dev/sda1 returns
> [root@localhost ~]# ntfsinfo -m /dev/sda1
> Failed to read last sector (6943344): Invalid argument
...
>    or the partition table is corrupt (partition is smaller than NTFS),
...

Awesome! After resizing, the partition gets shrunk ... that could have gone wrong instead of the ntfsresize.
Comment 31 Robert Lightfoot 2012-12-13 03:11:10 EST
also the output from ntfsfix -n shows promise in the end.

[root@localhost ~]# ntfsfix -n /dev/sda1
Mounting volume... Failed to read last sector (6943344): 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
Attempting to correct errors... Failed to read last sector (6943344): 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
Failed to startup volume: Invalid argument
Failed to read last sector (6943344): 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).
Trying the alternate boot sector
The alternate bootsector is usable
Set sector count to 6942656 instead of 6943344
The startup data can be fixed, but no change was requested
Volume is corrupt. You should run chkdsk.
No change made
[root@localhost ~]#
Comment 32 Adam Williamson 2012-12-13 03:15:20 EST
steve: well yeah the partition has to be resized, otherwise the shrink doesn't actually free up any space.
Comment 33 Robert Lightfoot 2012-12-13 03:26:19 EST
Running ntfsfix for real and then sh -x os-prober yields some other better data.


Trying the alternate boot sector
The alternate bootsector is usable
Set sector count to 6942656 instead of 6943344
Rewriting the bootsector
The boot sector has been rewritten

Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($LogFile)... OK
NTFS volume version is 3.1.
NTFS partition /dev/sda1 was processed successfully.
[root@localhost ~]# sh -x os-prober | tr ' ' '^' | paste -s -d ' '
+ set -e
+ . /usr/share/os-prober/common.sh
++ cleanup_tmpdir=false
++ cleanup_ro_partitions=
++ progname=
++ type mapdevfs
+ newns
+ '[' '' ']'
+ exec /usr/libexec/newns os-prober
/dev/sda1:Microsoft^Windows^XP^Home^Edition:Windows:chain
[root@localhost ~]# grub2-mkconfig -o /boot/grub2/grub.cfg 
Generating grub.cfg ...
Found theme: /boot/grub2/themes/system/theme.txt
Found linux image: /boot/vmlinuz-3.6.9-4.fc18.i686.PAE
Found initrd image: /boot/initramfs-3.6.9-4.fc18.i686.PAE.img
Found Microsoft Windows XP Home Edition on /dev/sda1
done
Comment 34 Robert Lightfoot 2012-12-13 03:28:29 EST
And that windows boots and My Computer shows C: Drive as 3.3GB big with 768 mb of free space.  This won't run well for long now will it.  Definitely agressive shrink.
Comment 35 Steve Tyler 2012-12-13 03:45:05 EST
That's excellent. The NTFS file system is being corrupted at the end, but it may not be the fault of the ntfsresize command:

After minimizing the NTFS file system using the ntfsresize command on the F18 TC1 Live CD, Windows XP reboots, runs chkdsk, and reboots to the Windows desktop. The ntfsresize command alone does not explain the problem with the installer resize operation.

Procedure from the F18 TC1 Live CD:
# ntfsresize -m /dev/sda1 # get minimum size XXXX in MB
# ntfsresize -s XXXXM /dev/sda1

NB: This was done entirely from the Live CD. The installer was not run at all.
Comment 36 Steve Tyler 2012-12-13 03:57:07 EST
(In reply to comment #34)
> And that windows boots and My Computer shows C: Drive as 3.3GB big with 768
> mb of free space.  This won't run well for long now will it.  Definitely
> agressive shrink.

Windows XP is reporting Low Disk Space after the ntfsresize to the minimum. The warning says that:

"System Restore has suspended tracking changes ..."

Resizing to the minimum is definitely not something that should be done automatically without the user being notified first.
Comment 37 Adam Williamson 2012-12-13 04:55:16 EST
no kind of resize gets done 'automatically', you have to specifically request it through custom part or the reclaim space dialog.
Comment 38 Steve Tyler 2012-12-13 05:04:14 EST
(In reply to comment #33)
> Running ntfsfix ...
...
> Set sector count to 6942656 instead of 6943344
...

Let's do the math ... :-)


1. anaconda.program.log for non-working case (Comment 6):
...
03:25:41,942 INFO program: Running... ntfsresize -ff -s 3555M /dev/sda1
...
03:25:42,063 INFO program: New volume size    : 3554992640 bytes (3555 MB)
...

The new file system has 3554992640/512 = 6943345 sectors.


2. Partitioning for non-working case (Comment 12):

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63     6942719     3471328+   7  HPFS/NTFS/exFAT
/dev/sda2         6942720     7966719      512000   83  Linux
/dev/sda3         7966720    83886079    37959680   8e  Linux LVM

The sda1 partition sector count is 6942719-63+1 = 6942657 sectors.


3. Conclusion: The partition is smaller than the file system.


NB: I'm not sure why ntfsfix is reporting one sector less in each case.

Thanks, Bob and Adam, for helping get this figured out.
Comment 39 Robert Lightfoot 2012-12-13 08:56:43 EST
Not a problem steve.  As I told Adam in #fedora-qa.  I came to use Fedora and then Centos after starting with a double boot xp/fedora system.  That is why this test case is always on my radar.  I know of setting up double had not been easy back in Fedora8 I'd still be a doze only user.
Comment 40 Chris Murphy 2012-12-13 16:47:59 EST
Looks like anaconda is having parted set the partition size in the MBR contrary to the ntfsresize command.

storage.log
15:39:23,303 DEBUG storage: fixing size of existing 12866MB partition sda2 (3) with existing ntfs filesystem at 12866.00

program.log
15:38:31,998 INFO program: ntfsresize v2012.1.15 (libntfs-3g)
15:38:31,999 INFO program: Minsize (in MB): 12967
…
15:39:32,957 INFO program: Running… ntfsresize -ff -s 13491M /dev/sda2
Comment 41 Chris Murphy 2012-12-13 16:50:08 EST
Created attachment 663208 [details]
anaconda program.log

Windows 7 default installation (2 partition) to 750GB virtual disk, followed by default installation of Fedora 18 with anaconda 18.37.2-1 using autopart.
Comment 42 Chris Murphy 2012-12-13 16:51:09 EST
Created attachment 663209 [details]
anaconda storage.log

Windows 7 default installation (2 partition) to 750GB virtual disk, followed by default installation of Fedora 18 with anaconda 18.37.2-1 using autopart.
Comment 43 Vratislav Podzimek 2012-12-14 06:25:10 EST
*** Bug 875484 has been marked as a duplicate of this bug. ***
Comment 44 Paul Franklin (RHlists) 2012-12-14 13:25:24 EST
Adam, in Comment 10 you said "We agreed we cannot determine
the status of this bug until we're sure what the trigger is ..."
and I am curious as to whether the additional posts have met
your requirement, answered your question?  Thanks.
Comment 45 Steve Tyler 2012-12-14 13:49:46 EST
(In reply to comment #43)
> *** Bug 875484 has been marked as a duplicate of this bug. ***

Reartes did a superb job of analyzing this bug.

In Bug 875484, Comment 17 he concludes that:
...
* TEST#3: FOUND, After TEST#5, it is clear that the problem is in the partiton table generated by anaconda.
...
BUG: The END_SECTOR for the resized NTFS partiton is WRONG.
Comment 46 Chris Lumens 2012-12-14 15:19:00 EST
Does anyone have a setup available for testing?  If so, please let me know what version of anaconda you're using so I can supply an updates.img with some more targeted logging.
Comment 47 Reartes Guillermo 2012-12-14 15:21:34 EST
I have the w7 guest for testing, since i made a backup of the disk.

I have F18-TC2, smoke5, smoke6 or F18-TC1.
Comment 48 Chris Murphy 2012-12-14 15:24:36 EST
Fedora-18-TC2-x86_64-Live-Desktop.iso has anaconda 18.37.2-1. That's what I'd be using.
Comment 49 Chris Lumens 2012-12-14 15:34:46 EST
If you can use updates=http://clumens.fedorapeople.org/885912.img against the TC2 image containing anaconda-18.37.2-1 and attach /tmp/storage.log to this bug report, it would be very helpful.  Thanks.  You'll need to at least schedule the resizing, though you may not need to actually move to the second hub.
Comment 50 Chris Murphy 2012-12-14 15:44:00 EST
Created attachment 663804 [details]
storage.log w/ targeted logging

updates=http://clumens.fedorapeople.org/885912.img applied
Comment 51 Reartes Guillermo 2012-12-14 15:49:36 EST
Created attachment 663805 [details]
storage.log with updates applied (i do not performed the installation)
Comment 52 Robert Lightfoot 2012-12-14 16:05:36 EST
(In reply to comment #46)
> Does anyone have a setup available for testing?  If so, please let me know
> what version of anaconda you're using so I can supply an updates.img with
> some more targeted logging.

I have a pair of windows xpsp2 vm and the full DVD of TC2 in both i386 and x86_64 and will be available for testing over the weekend sometime after 2300 Friday.  Please provide desired test protocols if you can.
Comment 53 Chris Murphy 2012-12-14 16:17:06 EST
(In reply to comment #50)
FWIW logs in comment 41, 42 are from the same VM snapshot state as the log in comment 50.

15:41:14,744 INFO program: New volume size    : 13490995712 bytes (13491 MB)

Which is 26349601 sectors. Plus sda2 start LBA 206848 should be an end LBA 26556449. However:

15:41:23,873 INFO storage: !!! _computeResize: aligned end sector to 26556415

Which is what fdisk reports and is 34 sectors too short.
Comment 54 Adam Williamson 2012-12-14 16:32:35 EST
Paul: we haven't had another blocker review meeting since then. If we had, there would be a note of the decision on the bug. All blocker status discussions are documented in the bug.
Comment 55 Robert Lightfoot 2012-12-15 01:04:11 EST
F18 - TC2 - i386 - DVD .iso with clumens updates img notes

1.  adding just updates=http://clumens.fedorapeople.org/885912.img results in a cannot download error and a drop into DRACUT.  Have to add ksdevice=eth0 as well to get updated to download.

2.  Fresh Install of xpsp2 to 40gb vm.  Used automatic partitioning and shrink of ntfs partition resulting in system with no windows boot entry.  Suspect this system is identical to the TC1 system.

3.  Logs to follow :
Comment 56 Robert Lightfoot 2012-12-15 03:55:16 EST
Created attachment 663921 [details]
F18-TC2-I386-ClumensUpdateImg-Anaconda-ifcfg.log

F18-TC2-I386-ClumensUpdateImg-Anaconda-ifcfg.log
Comment 57 Robert Lightfoot 2012-12-15 03:56:20 EST
Created attachment 663922 [details]
F18-TC2-I386-ClumensUpdateImg-Anaconda.log

F18-TC2-I386-ClumensUpdateImg-Anaconda.log
Comment 58 Robert Lightfoot 2012-12-15 03:57:37 EST
Created attachment 663923 [details]
F18-TC2-I386-ClumensUpdateImg-Anaconda.packaging.log

F18-TC2-I386-ClumensUpdateImg-Anaconda.packaging.log
Comment 59 Robert Lightfoot 2012-12-15 03:58:31 EST
Created attachment 663924 [details]
F18-TC2-I386-ClumensUpdateImg-Anaconda.storage.log

F18-TC2-I386-ClumensUpdateImg-Anaconda.storage.log
Comment 60 Robert Lightfoot 2012-12-15 03:59:54 EST
Created attachment 663925 [details]
F18-TC2-I386-ClumensUpdateImg-Syslog

F18-TC2-I386-ClumensUpdateImg-Syslog
Comment 61 Robert Lightfoot 2012-12-15 04:01:03 EST
Log Files ks-script-1PE9nO.log  ks-script-ehMK75.log  ks-script-HANaik.log were 0 bytes in size and not uploaded for F18-TC2-i386
Comment 62 Robert Lightfoot 2012-12-15 04:09:45 EST
Created attachment 663926 [details]
F18-TC2-x8664-ClumensUpdateImg-Anaconda-ifcfg.log
Comment 63 Robert Lightfoot 2012-12-15 04:10:37 EST
Created attachment 663927 [details]
F18-TC2-x8664-ClumensUpdateImg-Anaconda.log
Comment 64 Robert Lightfoot 2012-12-15 04:11:38 EST
Created attachment 663928 [details]
F18-TC2-x8664-ClumensUpdateImg-Anaconda.packaging.log
Comment 65 Robert Lightfoot 2012-12-15 04:12:36 EST
Created attachment 663929 [details]
F18-TC2-x8664-ClumensUpdateImg-Anaconda.storage.log
Comment 66 Robert Lightfoot 2012-12-15 04:13:39 EST
Created attachment 663930 [details]
F18-TC2-x8664-ClumensUpdateImg-Anaconda.xlog
Comment 67 Robert Lightfoot 2012-12-15 04:14:34 EST
Created attachment 663931 [details]
F18-TC2-x8664-ClumensUpdateImg-Syslog
Comment 68 Robert Lightfoot 2012-12-15 04:16:30 EST
Created attachment 663932 [details]
F18-TC2-i386-ClumensUpdateImg-Anaconda.xlog
Comment 69 Robert Lightfoot 2012-12-15 04:19:01 EST
files ks-script-V2Bz_G.log  ks-script-varPAJ.log  ks-script-_YCcAo.log  were 0 bytes and not upliaded F18-TC2-ClumensUpdate.img
Comment 70 Chris Lumens 2012-12-16 09:45:58 EST
All I needed was storage.log, which I've not got several of.  I think we're good on data for this bug report now.
Comment 71 Adam Williamson 2012-12-17 13:53:26 EST
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 criterion "All known bugs that can cause corruption of user data must be fixed or documented at Common F18 bugs" - this bug can badly damage an existing Windows partition.
Comment 72 Chris Lumens 2012-12-18 14:51:15 EST
Could anyone who's got this still set up try testing again with updates=http://clumens.fedorapeople.org/885912.img and see if it works?  We've got a fairly cheesy fix that I'm hoping will work without introducing any new problems.
Comment 73 Chris Murphy 2012-12-18 15:16:46 EST
Created attachment 665739 [details]
storage.log

Reply to comment 72.

Inadvertently applied update to anaconda-18.37.3-1, instead of 18.37.2-1. But it does work, the Windows install isn't nerfed; the auto chkdsk on reboot to Windows completes with no errors, subsequently reboots to Windows successfully.
Comment 74 Chris Murphy 2012-12-18 15:40:31 EST
Created attachment 665747 [details]
storage.log

Reply to comment 72. This one applied against anaconda 18.37.2-1. Same results.
Comment 75 Reartes Guillermo 2012-12-18 16:48:27 EST
Created attachment 665772 [details]
storage.log (AFTER INSTALL) F18 TC2 with updates image

I tried with the same w7 guest.
 
W7 did boot, did the chkdsk stuff,then reboot, and then it booted normally.

(In addition, the boot-loader was installed properly)
Comment 76 Fedora Update System 2012-12-18 20:34:16 EST
anaconda-18.37.4-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.37.4-1.fc18
Comment 77 Chris Murphy 2012-12-19 00:29:46 EST
anaconda-18.37.4-1.fc18 appears to fix this bug.
Comment 78 Fedora Update System 2012-12-19 17:40:56 EST
Package anaconda-18.37.4-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.37.4-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-20677/anaconda-18.37.4-1.fc18
then log in and leave karma (feedback).
Comment 79 Fedora Update System 2012-12-20 00:35:22 EST
anaconda-18.37.4-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 80 Kamil Páral 2012-12-20 07:57:46 EST
We need to verify this is really fixed. Reartes, could you please try again with the smoke9 images?
http://dl.fedoraproject.org/pub/alt/qa/20121219_f18-smoke9/

Thanks!
Comment 81 Adam Williamson 2012-12-20 16:16:53 EST
Kamil: see comment #77.
Comment 82 Reartes Guillermo 2012-12-20 20:46:54 EST
Created attachment 667033 [details]
storage.log (AFTER INSTALL) F18 smoke9

I tried twice, and both times w7 guest was able to perform both the chkdsk and then boot normally. 

The second time i tested without installing a boot loader and it also worked. (attached storage.log).
Comment 83 Kamil Páral 2012-12-21 04:58:32 EST
(In reply to comment #81)
> Kamil: see comment #77.

I missed that one.

(In reply to comment #82)
> Created attachment 667033 [details]
> storage.log (AFTER INSTALL) F18 smoke9
> 
> I tried twice, and both times w7 guest was able to perform both the chkdsk
> and then boot normally. 
> 
> The second time i tested without installing a boot loader and it also
> worked. (attached storage.log).

Thank you very much for verification.
Comment 84 Robert Lightfoot 2012-12-23 17:57:04 EST
This problem maybe solved - I cannot prove it with my XPSP3-NTFS VM however and smoke12 encountered another dual boot problem 889896.

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