Bug#380226: Bug#379835: Recommend to tag #380226 etch-ignore; #379835 downgraded to important
Hi, (restricting to #380226) * Frans Pop ([EMAIL PROTECTED]) [061122 14:16]: On Saturday 11 November 2006 04:21, Steve Langasek wrote: But again, I don't understand how libparted has a bug separate from the linux-ntfs one. I'm not sure there's any reason this bug would be specific to NTFS partitions, though, is there? libparted causes the starting sector of the partition to change, thus making the physical partition invalid. This bug is indeed not even strictly related to Vista partitions, but other partitions seem to get created aligned on cylinder boundaries by default (or we'd have seen a lot more bug reports). Your rationale for ignoring 380226 also makes no sense to me; if this bug manifests in the installer, isn't that still a data loss bug that we need to fix before release? There are also two other packages in testing, gparted and mindi, which use libparted, so if there's a dataloss-causing bug in libparted I don't see that it's ignorable even if we did accept an argument that data loss in the installer is ok (which I don't). There are a few reasons why I thought we could tag the libparted issue etch-ignore: 1) it is not a regression from Sarge 2) there has been precious little attention to the issue from the maintainers of parted even though the BR was already 3 months old; I talked to Otavio today though and he promised to start on it Any news on this, Otavio? I don't want to tag it etch-ignore if that would mean the bug would just be ignored. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380226: Bug#379835: Recommend to tag #380226 etch-ignore; #379835 downgraded to important
Andreas Barth [EMAIL PROTECTED] writes: There are a few reasons why I thought we could tag the libparted issue etch-ignore: 1) it is not a regression from Sarge 2) there has been precious little attention to the issue from the maintainers of parted even though the BR was already 3 months old; I talked to Otavio today though and he promised to start on it Any news on this, Otavio? I don't want to tag it etch-ignore if that would mean the bug would just be ignored. Yes and no. I started to look at it but lacked the time to continue. I hope to get news about it on a week or so. Let's see. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380226: Bug#379835: Recommend to tag #380226 etch-ignore; #379835 downgraded to important
On Saturday 11 November 2006 04:21, Steve Langasek wrote: I'm having a hard time distilling the information in these bug reports into a summary of what each bug is actually about or what the current status is. I don't find that at all surprising as it cost me a lot of hours to get get the info collected, the issues identified and, in the case of ntfsprogs, upstream convinced [1]. Isn't it the case that there is a workaround in place now in the Debian packages that prevents resizing of NTFS filesystems if they're detected as belong to a recent version of Vista? s/a recent version of// Is this workaround implemented somewhere *other* than the linux-ntfs package? Yes, it is implemented in partman, not ntfs-resize. Partman now blocks resizing of any partition containing the Vista OS (or rather: the files that are used to boot Vista). It does not block resizing data partitions. The upstream maintainer of ntfsprogs only recently was convinced that the issue is real. He has said he wants to block resizing Vista partitions, but I don't know if that has been implemented yet. It is certainly not yet in Debian. There is some uncertainty if the ntfsresize issue only affects Vista OS partitions or if it also extends to (Vista) data partitions. Note that I have also seen two recent reports about issues with corruption of XP NTFS partitions (#394963), though that seems unrelated to resizing. [this quote moved up a bit] But again, I don't understand how libparted has a bug separate from the linux-ntfs one. [quote from message Saturday 11 November 2006 04:38] I'm not sure there's any reason this bug would be specific to NTFS partitions, though, is there? libparted causes the starting sector of the partition to change, thus making the physical partition invalid. This bug is indeed not even strictly related to Vista partitions, but other partitions seem to get created aligned on cylinder boundaries by default (or we'd have seen a lot more bug reports). ntfsresize somehow causes an corruption of internal consistency (probably some meta-data about the partition is saved somewhere and is not updated after the resize) that is expected by the Vista bootloader. Your rationale for ignoring 380226 also makes no sense to me; if this bug manifests in the installer, isn't that still a data loss bug that we need to fix before release? There are also two other packages in testing, gparted and mindi, which use libparted, so if there's a dataloss-causing bug in libparted I don't see that it's ignorable even if we did accept an argument that data loss in the installer is ok (which I don't). There are a few reasons why I thought we could tag the libparted issue etch-ignore: 1) it is not a regression from Sarge 2) there has been precious little attention to the issue from the maintainers of parted even though the BR was already 3 months old; I talked to Otavio today though and he promised to start on it 3) the chance that people will resize a partition not aligned on a cylinder boundary outside d-i seems pretty slim 4) it is not dataloss is the strict sense: you can recover by changing the staring sector back to its old value (the trick is how to find out what the old value was...) Resizing a partition that is not on a cylinder boundary is scary anyway: fdisk will also do the wrong thing unless you remember to change the units it uses from cylinders to sectors (using its 'u' command). I did check parted itself and that does the right thing as it asks for the starting sector (IIRC). I have no idea about gparted and mindi. If you feel the libparted bug should be fixed before the release, that is perfectly fine by me. However, it really is an upstream issue and there probably is a very good reason why that alignment check was originally added. I would not want to just apply Bas' patch and hope for the best. Can someone who understands what's going on with these bugs please fix up the bug titles so that they're an accurate summary, to help the rest of us figure out which bits of information in the bug log are relevant to the current bugs? IMHO the bug reports are pretty clear. They all have the same origin: /me having problems booting vista after resizing its NTFS partition, but have diverged at some point to deal with the separate issues. There is no actual bug in partman, but the two other bugs makes a workaround there necessary until the other two issues are fixed, hence the blocks. It could be argued that partman should also check if a partition in an msdos partition table is aligned on a cylinder boundary before allowing to resize, but I feel the risk of that happening for non-Vista partitions is small enough to ignore it (people should always backup their data before resizing anyway, right?). If someone would supply a patch for that I'd apply it though. The BR against ntfsprogs has grown huge, mostly because it took a lot of effort to convince the
Bug#380226: Bug#379835: Recommend to tag #380226 etch-ignore; #379835 downgraded to important
On Fri, Nov 10, 2006 at 07:21:00PM -0800, Steve Langasek wrote: On Thu, Oct 12, 2006 at 07:59:34AM +0200, 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 - #380226: libparted - clear issue, recently further traced during BSP in Utrecht; needs attention from Debian maintainer and upstream - #379835: partman - no bug in partman itself, but the result of the two listed above (blocked by both) 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. As partman is now safe I am downgrading #379835 to important. For #380226 I recommend tagging it 'etch-ignore'. The reason I think it's safe to do that is that it may only manifest itself in the installer. I'm unsure where else and how libparted is used though. I have tried resizing an NTFS 3.1 partition using parted, and that correctly left the starting partition unchanged, so parted is unaffected. 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'm having a hard time distilling the information in these bug reports into a summary of what each bug is actually about or what the current status is. Ok, I see that bug #380226 does have a reasonable title after reading the end of this bug log. I'm not sure there's any reason this bug would be specific to NTFS partitions, though, is there? Anyway, I stand by the statement that I don't think this would be appropriate to ignore for etch. Has anyone tried Bas's suggested workaround, to see if it does cause problems on older systems? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
