On Sat, November 19, 2011 07:58, Jeremy Chadwick wrote:
On Fri, Nov 18, 2011 at 10:55:10PM -0200, Nenhum_de_Nos wrote:
hail,
I have two disks, and the one holding Windows appears just as ada1 or
ad8, despite fdisk shows
all
partitions fine.
I tried to kldload geom_gpt_something, but it says it was already
loaded. I couldn't mount using
mount_ntfs, so I would use fuse to have ability to write on it :)
is there a way to solve this ?
two disks. One just FreeBSD, the other just Windows.
Jeremy, thanks and let's to the answers.
First: to my knowledge, fdisk does not support GPT, so I'm not sure what
you mean when you say "it shows all partitions fine". You should
probably use gpart(8) instead, e.g. "gpart show" and/or "gpart list".
See the man page for usage. It will work with all types, and tell you
what scheme is used (MBR, GPT, etc.).
its all here :)
macgyver# fdisk ada1
******* Working on device /dev/ada1 *******
parameters extracted from in-core disklabel are:
cylinders=484521 heads=16 sectors/track=63 (1008 blks/cyl)
Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=484521 heads=16 sectors/track=63 (1008 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 7 (0x07),(NTFS, OS/2 HPFS, QNX-2 (16 bit) or Advanced UNIX)
start 2048, size 204800 (100 Meg), flag 80 (active)
beg: cyl 0/ head 107/ sector 16;
end: cyl 48/ head 134/ sector 14
The data for partition 2 is:
sysid 7 (0x07),(NTFS, OS/2 HPFS, QNX-2 (16 bit) or Advanced UNIX)
start 206848, size 103165952 (50374 Meg), flag 0
beg: cyl 48/ head 134/ sector 15;
end: cyl 1023/ head 223/ sector 19
The data for partition 3 is:
sysid 7 (0x07),(NTFS, OS/2 HPFS, QNX-2 (16 bit) or Advanced UNIX)
start 103372800, size 385019904 (187998 Meg), flag 0
beg: cyl 1023/ head 239/ sector 63;
end: cyl 1023/ head 239/ sector 63
The data for partition 4 is:
<UNUSED>
macgyver# gpart show ada1
=> 34 488397101 ada1 GPT (232G)
34 488397101 - free - (232G)
macgyver# gpart list ada1
Geom name: ada1
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 488397134
first: 34
entries: 128
scheme: GPT
Consumers:
1. Name: ada1
Mediasize: 250059350016 (232G)
Sectorsize: 512
Mode: r0w0e0
macgyver# dmesg | grep ada1
ada1 at ahcich2 bus 0 scbus2 target 0 lun 0
ada1: <ST3250820AS 3.AAE> ATA-7 SATA 1.x device
ada1: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C)
ada1: Previously was known as ad8
macgyver#
Next item: what do you mean it appears as "ada1 **or** ad8"? ada1
indicates you're using ahci.ko (not ataahci.ko) which supports AHCI via
CAM(4), while the latter indicates you're using ata(4) (even if AHCI is
in use; that would be ataahci.ko). Why/how would this change unless you
are messing with cables or enabling/disabling drivers?
As now I'm on FreeBSD in this machine, there is:
macgyver# ls /dev/ada1*
/dev/ada1
but the FreeBSD disk:
macgyver# ls /dev/ada0*
/dev/ada0 /dev/ada0s1 /dev/ada0s1a /dev/ada0s1b
/dev/ada0s2 /dev/ada0s2a
/dev/ada0s3 /dev/ada0s4 /dev/ada0s4a /dev/ada0s4b
and I still have old ad4 and ad8:
macgyver# ls /dev/ad4* /dev/ad8*
/dev/ad4 /dev/ad4s1 /dev/ad4s1a /dev/ad4s1b
/dev/ad4s2 /dev/ad4s2a
/dev/ad4s3 /dev/ad4s4 /dev/ad4s4a /dev/ad4s4b /dev/ad8
and my point here is there even though fdisk shows some windows
partitions, I can't even address
them as I just see ada1/ad8. no ada1s1 or anything alike.
Next item: I think you're referring to the geom_part_gpt.ko module,
but you don't need to do that. GEOM and related kernel bits will load
it automatically, which is why it told you it's already loaded. You can
use "kldstat" to verify. Otherwise it's statically-included in your
kernel.
I noticed that. I got to put it on loader.conf: for the record, no good
and won't be able to boot
the box (usb live solved). I thought I needed to load the module to see
the gpt.
Next item: this sounds like the crux of your issue. As I understand it,
NTFS support via kernel on FreeBSD is in an extremely bad state on
numerous levels. You can find complaints about lack-of or badly-done
UTF-8 filename/path support, lack of full write support, and the more
important/major Non-MPSAFE filesystem declaration here:
http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS
unfortunately I didn't got to this point as I never got to see the
partitions :( but I plan to use
ntfs from fuse.
It looks like atti...@freebsd.org has taken ownership of the NTFS driver
in the kernel at this point. You may want to ask him if there are any
patches you could try.
However, as I understand it, the fuse-based NTFS is more reliable and
has much higher compatibility. The trade-offs are added complexity
getting it all to work, and slower speed.
Final item: you sent this mail twice, once to sta...@freebsd.org, once
to
freebsd-stable@freebsd.org. The mail ID headers appear to indicate
they were separate/unique and the mail content themselves slightly
differs (extra newlines, etc.). No need for this; they are the same
list.
3909 11/18 22:55 Nenhum_de_Nos (0.8K) mount GPT from Windows
7 in FreeBSD 9
Message-ID:
<678178215ed5d725a42eb2b4ae25102c.squir...@eternamente.info>
3910 11/19 03:20 Nenhum_de_Nos (1.1K) mount GPT from Windows
7 in FreeBSD 9
Message-ID:
<1c312a399e23d546f05f5e8396763323.squir...@eternamente.info>
and this, sorry for the double post. I sent the message to
freebsd-stable@ and waited a couple of
hours. Nothing showed on the list. I thought was a problem with it, then
sent again:
sta...@freebsd.org 03:20 1.4 k mount GPT from Windows 7 in FreeBSD 9
freebsd-stable@freebsd.org Fri, 22:55 1.1 k mount GPT from Windows 7 in
FreeBSD 9
this is from squirrelmail. first message 22:55 from Friday in my time
zone, the second was 3:20
from Saturday. then I tried to subscribe again to the list (I thought I
was no more on it), and
got the message I was there ...
again, sorry but I just thought I was not there anymore. Was there any
issues with the list
yesterday ? usually it is not that slow (I think).
thanks,
matheus
