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.
Please switch to tty2 (ctrl-alt-f2) and attach the logs from /tmp/*log to this bug as individual plain/text files.
Created attachment 520493 [details] Installer Error message
Created attachment 520494 [details] anaconda log <CTRL><ALT><F2> gathered information
Created attachment 520495 [details] ifcfg log <CTRL><ALT><F2> gathered information
Created attachment 520496 [details] program log <CTRL><ALT><F2> gathered information
Created attachment 520497 [details] storage log <CTRL><ALT><F2> gathered information
Created attachment 520498 [details] xorg log <CTRL><ALT><F2> gathered information
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)
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.
There is an anaconda bug here. I'll post a patch for it today for review. It's a trivial change.
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.
F16-Beta.TC1 still balks at shrinking an NTFS partiton. So maybe it didn't get patched?
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.
So as a proventester where can I find the patch and test instructions. Or do I wait for anaconda 16.17-1?
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.
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.
Just boot F16-Beta.TC1 with updates=http://dlehman.fedorapeople.org/updates-733808.img in the boot arguments. Let me know how it goes.
Created attachment 521116 [details] anaconda log 9-1-11 using dlehman patch
Created attachment 521117 [details] ifcfg log 9-1-11 using dlehman patch
Created attachment 521118 [details] program log 9-1-11 using dlehman patch
Created attachment 521119 [details] storage log 9-1-11 using dlehman patch
Created attachment 521120 [details] xorg log 9-1-11 using dlehman patch
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.
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.
> 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.
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.
Created attachment 521305 [details] ntfsresize log output
Response with clean drive as judged by chkdsk was the same as before.
> 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....
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.
anaconda-16.17-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/anaconda-16.17-1.fc16
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).
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.
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?
OK I now have a bootable Fedora System with bug 735273 - ie windows won't boot.
> 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
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.
Note of additional information - the shrink function of FC15 also fails on an ntfs partition.
what's the status of this bug with Beta RC1, please? thanks.
> 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.
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.
Created attachment 524812 [details] anaconda.log from Beta.RC2 failed install
Created attachment 524813 [details] ifcfg log from Beta.RC2 failed install
Created attachment 524815 [details] program log from Beta.RC2 failed install
Created attachment 524817 [details] storage log from failed Beta.RC2 install
Created attachment 524818 [details] X.log from Beta.RC2 failed Install
Created attachment 524819 [details] sector 63 from dd command of winxp system after installer started but before error failure
Created attachment 524822 [details] sector 63 from dd command of winxp system after installer error failure
Created attachment 524823 [details] sector 2048 from dd command of winxp system after installer started but before error failure
Created attachment 524824 [details] sector 2048 from dd command of winxp system after installer error failure
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.
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.
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
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.
Might be of my own doing in specifying the wromg parameters to parted. Checking into this welcome input.
> 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.
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
Created attachment 524966 [details] fdisk -l from initial windows system
Created attachment 524967 [details] fdisk -l after resizing before changing partiton table
Created attachment 524969 [details] parted -l before resizing partition table
Created attachment 524970 [details] parted -l after changing partition table size
Created attachment 524971 [details] The initial sector 63 dd export
Created attachment 524972 [details] the sector 63 dd export after ntfsresize
Created attachment 524973 [details] The sector 63 export after parted changed the partition table
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.
(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.
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.
> 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
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
Created attachment 525240 [details] sector 63 preisntall but post resize - windows still boots
Created attachment 525241 [details] sector 63 post isntall of fedora - windows does mount but doesn't boot
Created attachment 525242 [details] ntfsfix -n output
Created attachment 525243 [details] parted -l from final system
Created attachment 525244 [details] fdisk -l from final system
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?
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 ?
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 ?
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.
> 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.
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.
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.
anaconda 16.20 from RC4 still has this bug.
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.
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.
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
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.