On Monday 21 August 2006 21:10, you wrote: > Yes. If it's repeatable then we could exclude that you have a hardware > problem with random data corruptions (disk, cable, memory, etc). > Similar happened before.
Looks like I made a mistake somehow while _creating_ the md5sum file. It turns out the files are actually unchanged. I'm not sure what I've done wrong, but the following leads me to conclude this was a false lead: - after restoring the vmware image _before resize_, the files that were "changed" failed a full md5sums check too and their md5sums were actually the same as those I got _after_ resizing; - rebooting this restored vmware image into Vista led to a succesful boot; - I restored again and created a new md5sum file; comparing that with the original file only showed differences for the 4 files, as expected; - resizing to both 9G and 12G results in exactly the same issue I've been seeing since the beginning when rebooting into Vista; (thanks for pointing out that no relocation takes place for 12G; I'm slowly starting to understand what is actually happening); - checking the md5sums against the newly created check file results in _no_ differences. So we're back to the previous state: ntfsresize seems to work fine; the partition can be mounted fine in linux (though flagged dirty), but it completely reproducible fails to reboot in exactly the same way on both: - em64t real hardware after resizing from 64-bits linux; - within vmware running 32-bits linux (run on a different box from the previous tests). On Monday 21 August 2006 22:03, you wrote: > I think you have a hardware problem. No, I think that is too easy given the above. Please allow for the fact that testing this involves some serious juggling and a small mistake is easily made. I think (not hindered by any real knowledge) there are several options. - The version of Vista that I happen to have has a bug which is not present in other (earlier/later, I don't know...) versions. - Microsoft has subtly changed the way in which ntfs metadata is expected to be for a "dirty" filesystem. Where do changes for these actions end up? > Schedule chkdsk for NTFS consistency check at Windows boot time ... > Resetting $LogFile ... (this might take a while) > Updating $BadClust file ... > Updating $Bitmap file ... > Updating Boot record ... - Microsoft has put something sneaky in the boot procedure. - Microsoft does something sneaky in the sectors between 63 and 2048 it does not use while creating the NTFS partition. I checked MBR and partition table, but these are unchanged after the resize. This is the last I can do for now. From now on I'm going into holiday mode. The next thing to do is probably for other people to actively try to reproduce what I am seeing, actually installing and resizing Vista (preferably Beta2). Cheers, FJP
pgpxtpDV8WwPU.pgp
Description: PGP signature
