Mounting ntfs partitions on t510

[auronandace]

I have 2 ntfs partitions. Under linux they are recognised as sda1 and sda5. Haiku doesn't detect either. It does detect my ext2 partitions though.

I have checked drive setup and it does indeed see all my partitions but only identifies 2 ext2 partitions.

I have tried using the same image on my t60 and it detects my ntfs partition there.

hrev39924 gcc4hybrid

[diver]

Could you try hrev39698 or earlier as it used ntfs-3g-2009.4.4 and in hrev39699 it was updated to ntfs-3g-2010.10.2?

[auronandace]

Just tried hrev39695 and it detects one of the partitions (sda5). That is the one that matters really because i use it as a storage partition. sda1 is win7 but it doesn't appear in the mount list.

I opened drive setup and it lists all the partitions and identifies 2 ext2 partitions and the 1 ntfs partition (sda5). The other ntfs partition (sda1) isn't identified but under the parameters column its marked as active (like the bfs partition i'm running haiku off).

[diver]

So it's a recent regression then. Until this bug is fixed you can use /system/add-ons/kernel/file_systems/ntfs binary from hrev39695.

[diver]

Also try some recent Linux distro to see how current version of ntfs-3g performs there. Does it detect both of your partitions? If possible try both ntfs-3g-2009.4.4 and ntfs-3g-2010.10.2.

[auronandace]

I run Arch 64bit and it uses ntfs-3g-2010.10.2 and detects and mounts rw both partitions fine.

[diver]

Please attach syslog from hrev39924 or later.

[diver]

Output of fdisk -l from linux as well as screenshot of DriveSetup wouldn't hurt either.

[auronandace]

syslog text file

[auronandace]

screenshot of drivesetup

[auronandace]

output of fdisk -l from arch 64bit

[diver]

So does the ntfs binary from hrev39695 works on your hrev39924?

[auronandace]

Haven't tried it yet. I take it I can't just copy it to a fat partition to transfer it due to the attributes?

I don't mind waiting till the alpha 3 release as long as this bug gets resolved by then.

[diver]

In fact I believe you can just copy it to your fat partition, or zip it first as zip supports bfs attributes (which AFAIK never used in drivers anyway).

[auronandace]

I copied it directly, overwriting the ntfs binary in hrev39924. The ntfs partitions are still not found.

[diver]

Have you tried to reboot?

[auronandace]

Thank you. I have rebooted and it now detects both partitions.

Sorry for that. Should have realised it required a reboot.

[diver]

Both partitions? I thought it should detect only one of your partitions (sda5). I'm not sure but being able to rescan partitions on the fly could be another bug or a missing feature.

[auronandace]

I thought it odd too. hrev39695 detects 1 ntfs partition. hrev39924 detects none. But hrev39924 with the ntfs binary from hrev39695 detects both.

[auronandace]

I think i'm going mad. I just booted into hrev39695 and now it doesn't detect either of them. The ntfs binary is still there, so i know i didn't accidentally cut and paste instead of copy and paste.

Edit1: This is strange. I tried booting it again but in a different usb port and now it sees the sda5 ntfs partition (just like it originally did). Surely it shouldn't matter which usb port i use to boot it off?

[diver]

Strange and it gets odder and odder.

[diver]

I think all you can do at this point is to attach syslogs with different detected partitions, so that developers could look into it.

[auronandace]

I decided to try something and here are my results:

As regards hrev39695 i've rebooted into it serveral times and it seems to be random. Sometimes it picks up 1 ntfs partition (sda5), sometimes it picks up both (sda1+5) and sometimes it picks up neither.

I tried the same with hrev39924 and the same thing occurs.

My t510 has a core i5 cpu, nvidia nvs 1300 graphics card, 4Gig of RAM and a 500Gig WD harddrive.

[diver]

Did you test hrev39924 with replaced ntfs binary or default one? Would be interesting to know if it's not ntfs-3g problem in the end.

[auronandace]

It's with the replaced binary. I'll dd the image again and see what happens with the hrev39934 ntfs binary.

Edit1: The same thing happens. It detects 1 (sda1 or sda5), both or neither. The good news though is the ext2 partitions are always detected. So I reckon it's a problem with the ntfs-3g driver.

[diver]

Please attach clean syslogs with different detected partitions.

[auronandace]

syslog of hrev39924 detected both ntfs partitions

[auronandace]

syslog of hrev39924 detected neither ntfs partitions

[auronandace]

syslog of hrev39924 detected sda5 (but not sda1) ntfs partition

[auronandace]

While restarting to get these syslogs hrev39924 now only goes into kdl (kernel debugging land?).

Due to this I have been unable to get a syslog of only sda1 detected.

Is there any output from kdl that I can provide here that would be helpful?

[diver]

Yes, please see Kernel Debugging Land part of ReportingBugs.

[auronandace]

photo of kdl after issuing the bt command

[auronandace]

photo of kdl after issuing the ints command

[auronandace]

photo of kdl (taken just after it entered kdl)

[diver]

It seems that Trac is not able to show images with unusual extenstion.

[auronandace]

I had to convert them because the jpeg versions were too big. You can view them fine in ristretto on xfce (i'm currently on xubuntu).

[diver]

I'm not sure but it looks like your bfs partition corrupted somehow. You can try to fix it by running checkfs -c /boot.

[auronandace]

I'm not worried about getting it up and running again (i can always dd the image again). Do the kdl pictures or the syslogs shed any light on why ntfs-3g is acting up?

[diver]

Not really. But it would be still interesting how well checkfs can handle this situation.

[auronandace]

Where do I run the command from? kdl doesn't recognise the command.

[diver]

If corrupted partition is on USB you'll need another USB drive to boot from, mount the first one and issue checkfs -c /Haiku1.

[korli]

Does this still happen with current revisions?

I checked syslog-both you provided and the interesting part isn't in the file. It could be in the syslog-old file.

Could you also identify which partitions is NTFS formatted (0, 3_0, 3_1, 3_2, 3_3, 3_4)?

Thanks!

[auronandace]

both ntfs partitions detected

[auronandace]

Just retried with hrev40916 gcc4hybrid and the same still occurs. It seems to randomly detect them or not. All other partitions are always detected (ext2,3,4). One of the ntfs partitions is primary (sda1 win7) and the other is a logical partition (sda5 labelled Storage).

[auronandace]

Sorry for doublepost, it should be hrev40913.

[auronandace]

Replying to auronandace:

Edit 1 (16/04/11): Clarification as follows:

There are 2 ntfs partitions, 1 primary (sda1 win7) and 1 logical (sda5 storage). Haiku randomly detects either. Sometimes 1, sometimes the other, sometimes both or sometimes neither. I can't tell what's causing it or if there is a pattern; it seems entirely random.

[bonefish]

From syslog-sda5:

380	KERN: KDiskDeviceManager::_ScanPartition(/dev/disk/scsi/0/0/0/0)
[...]
421	KERN:   trying: file_systems/ntfs/v1
422	KERN:   returned: 0.8

The NTFS module recognizes the partition contents. But later:

3031	KERN: KDiskDeviceManager::_ScanPartition(/dev/disk/scsi/0/0/0/0)
[...]
3069	KERN:   trying: file_systems/ntfs/v1
3070	KERN:   returned: -1

and:

3386	KERN: KDiskDeviceManager::_ScanPartition(/dev/disk/scsi/0/0/0/0)
[...]
3427	KERN:   trying: file_systems/ntfs/v1
3428	KERN:   returned: -1

The NTFS module reports that it doesn't recognize the partition contents. In syslog-both-r40916 there's also one of the scans where the partition contents is not recognized, though the last one is OK.

I haven't spotted anything in the syslogs pointing to a problem that would explain the behavior (like failing I/O). I suppose reviewing the NTFS identification code would be the way to go, adding more debug output, if nothing presents itself.

[auronandace]

Tested again with alpha 3 and it mounts both partitions fine all the time. It seems the bug is gone.

[diver]

This could be another gcc4 only issue. That would explain why you don't see this problem in alpha 3 which is gcc2 based. See also #8332.