[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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 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.

Attachment: pgpf5I1yHlDjk.pgp
Description: PGP signature


Reply to: