Bug#379628: Recommend to tag #380226 etch-ignore; #379835 downgraded to important
On 10/12/06, Frans Pop wrote: There are currently three RC bugs open related to the resizing of NTFS 3.1 partitions as created by Windows Vista. - #379628: ntfsresize - upstream bug, but disputed; I can reproduce it reliably though; needs confirmation by someone else [...] I have today uploaded a version of partman-partitioning that includes a check for NTFS 3.1 partitions and refuses to resize in that case; earlier NTFS partitions (NT, XP, 2000) should still be resizable. XP use NTFS 3.1 too. You've just blocked resizing of most users' NTFS partitions. IMO #379628 should not be ignored for Etch and it would be nice if someone else would try to either reproduce the bug or prove me wrong. There is plenty of information in the BR for that. Without a working ntfsresize, resizing NTFS 3.1 partitions is a no-op anyway. I've done some web searching and I have a wild guess about pcmcia.sys. After resizing, please boot into Vista's install disk and into the recovery console. From there, rename system32\drivers\pcmcia.sys (e.g. to pcmcia.bak) and reboot. Does Vista now boots? What about Safe mode? Another solution I found on the net was for Win2003 and was replacing ntldr and ntdetect.com with the ones on the install disk. The best projection on a newly installed Vista would be to replace the files with files from Win2003 or XP. Does this solve the case? If any of the above two workarounds help, then this is clearly an MS bug and should be fixed in Vista. Only if Vista final does not fix it, we can add a workaround to ntfsresize by checking the MD5 of the relevant files. Thanks Cheers, FJP -- Yuval Fledel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition
On 7/24/06, Frans Pop [EMAIL PROTECTED] wrote: Thanks for your quick reaction Yuval. On Monday 24 July 2006 19:42, Yuval Fledel wrote: The two are completely similar, except that the first is successful and the second leads to corruption. I noticed that the original partition was not the same in both cases. example: Vista: /dev/sda1 * 11217 97755217 HPFS/NTFS 2000: /dev/sda1 * 1255020482843+ 7 HPFS/NTFS No that is not correct (Vista will not even install into less than 16 MB :-) Sorry, I copied the wrong line for Vista. /dev/sda1 * 12550204810247 HPFS/NTFS 20482843+ is different than 20481024. I know for sure that when I repartitioned my disk, and entered the same number, only that it showed with no +, Windows no longer agreed to boot. Returning the partition table to what it was saved the day. It also feels strange because I did not change the starting sector and the end sector was well bigger than the new size of the NTFS partition. When you work with a cluster unit, fdisk sometimes move the starting sector. This is because a cluster may contain several sectors, and the original starting sector may not be cluster-aligned. When the first sector moves, the tools and the kernel driver can no longer mount the partition. Ah, I see 1.13.1 has just hit unstable. I will test with that and let you know. Thanks, that would be helpful. -- Yuval Fledel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
