[Parted-maintainers] Bug#380226: Bug#379835: Recommend to tag
#380226 "etch-ignore"; #379835 downgraded to important
Frans Pop
elendil at planet.nl
Wed Nov 22 22:16:09 GMT 2006
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 upstream maintainer that there really was an
issue.
I am keeping track of all three BRs, so feel free to ask me for additional
info if you need it.
Cheers,
FJP
[1] I must say though that without the help from the ntfsprogs upstream I
would never have gotten the issues identified at all.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/parted-maintainers/attachments/20061122/001b2f05/attachment.pgp
More information about the Parted-maintainers
mailing list