#7019 closed bug (fixed)
Mounting ntfs partitions on t510
Reported by: | auronandace | Owned by: | 3dEyes |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | File Systems/NTFS | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
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
Attachments (10)
Change History (49)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
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).
comment:3 by , 14 years ago
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.
comment:4 by , 14 years ago
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.
comment:5 by , 14 years ago
I run Arch 64bit and it uses ntfs-3g-2010.10.2 and detects and mounts rw both partitions fine.
comment:7 by , 14 years ago
Output of fdisk -l from linux as well as screenshot of DriveSetup wouldn't hurt either.
comment:9 by , 14 years ago
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.
comment:10 by , 14 years ago
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).
comment:11 by , 14 years ago
I copied it directly, overwriting the ntfs binary in hrev39924. The ntfs partitions are still not found.
comment:13 by , 14 years ago
Thank you. I have rebooted and it now detects both partitions.
Sorry for that. Should have realised it required a reboot.
comment:14 by , 14 years ago
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.
comment:15 by , 14 years ago
comment:16 by , 14 years ago
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.
comment:18 by , 14 years ago
I think all you can do at this point is to attach syslogs with different detected partitions, so that developers could look into it.
comment:19 by , 14 years ago
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.
comment:20 by , 14 years ago
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.
comment:21 by , 14 years ago
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.
by , 14 years ago
Attachment: | syslog-neither added |
---|
syslog of hrev39924 detected neither ntfs partitions
by , 14 years ago
Attachment: | syslog-sda5 added |
---|
syslog of hrev39924 detected sda5 (but not sda1) ntfs partition
comment:23 by , 14 years ago
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?
comment:26 by , 14 years ago
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).
comment:27 by , 14 years ago
I'm not sure but it looks like your bfs partition corrupted somehow. You can try to fix it by running checkfs -c /boot.
comment:28 by , 14 years ago
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?
comment:29 by , 14 years ago
Not really. But it would be still interesting how well checkfs can handle this situation.
comment:31 by , 14 years ago
If corrupted partition is on USB you'll need another USB drive to boot from, mount the first one and issue checkfs -c /Haiku1.
comment:32 by , 14 years ago
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!
comment:33 by , 14 years ago
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).
comment:35 by , 14 years ago
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.
comment:36 by , 14 years ago
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.
comment:37 by , 13 years ago
Tested again with alpha 3 and it mounts both partitions fine all the time. It seems the bug is gone.
comment:38 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:39 by , 13 years ago
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.
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?