# Accessing non-BSD slices



## eldiener (May 9, 2014)

I am using PC-BSD but the problem I have been encountering on my system appears to be one for the underlying FreeBSD system.

I have three hard disks, one of which is empty. I am booting PC-BSD into a primary slice on my third hard disk using a boot manager called BootIt Bare Metal in a multi-boot computer. I also boot into and use other OSs including Windows and a number of Linux distros. The PC-BSD system boots fine and comes up under the KDE system.

I need to be able to access two other slices on the same hard disk in which I boot PC-BSD. I know how to edit fstab but my problem is doing it so that PC-BSD recognizes the other two slices. I need to find out the name of these slices under PC-BSD so that I can enter it into fstab.

First here are my disks using `parted -l` in Fedora 20:


```
Model: ATA Hitachi HDS72302 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 32.3kB 240GB 240GB primary ntfs hidden
2 240GB 593GB 353GB primary ntfs hidden
3 593GB 704GB 111GB extended boot, lba
5 593GB 595GB 1078MB logical ext3
6 595GB 596GB 1053MB logical ext3
7 596GB 597GB 1077MB logical ext3 boot
8 597GB 598GB 1077MB logical ext3
9 598GB 599GB 1069MB logical ext3
10 599GB 600GB 1049MB logical ext3
11 600GB 601GB 1049MB logical ext3
4 1996GB 2000GB 4294MB primary fat16


Model: ATA ST2000DL003-9VT1 (scsi)
Disk /dev/sdb: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags


Model: ATA WDC WD20EARX-00P (scsi)
Disk /dev/sdc: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 2065kB 977GB 977GB extended lba
5 2097kB 53.7GB 53.7GB logical ext4
6 53.7GB 107GB 53.7GB logical ext3
7 107GB 161GB 53.7GB logical ext4
8 161GB 215GB 53.7GB logical ext3
9 215GB 269GB 53.7GB logical ext4
10 269GB 321GB 52.4GB logical ext3
11 321GB 373GB 52.4GB logical ext4
12 373GB 426GB 52.4GB logical ext3
13 426GB 485GB 59.6GB logical ext3
14 485GB 540GB 55.1GB logical
15 540GB 557GB 16.8GB logical linux-swap(v1)
16 557GB 610GB 52.5GB logical ext4
17 610GB 663GB 53.7GB logical ext4
18 663GB 716GB 52.4GB logical ext4
19 716GB 767GB 51.2GB logical ext4
20 767GB 819GB 52.4GB logical ext4
21 819GB 871GB 51.2GB logical ext4
2 1575GB 1680GB 105GB primary boot
3 1680GB 2000GB 320GB primary ntfs
```

Next here are the disks using `gpart show`:


```
=> 63 3907029105 ada0 MBR (1.8T)
63 469274652 1 ntfs (224G)
469274715 689750775 2 ntfs [active] (329G)
1159025490 3244 - free - (1.6M)
1159028734 216879106 3 ebr (103G)
1375907840 2522734592 - free - (1.2T)
3898642432 8386560 4 !223 (4.0G)
3907028992 176 - free - (88K)

=> 63 3907029105 diskid/DISK-MN1220F323ZT0D MBR (1.8T)
63 469274652 1 ntfs (224G)
469274715 689750775 2 ntfs [active] (329G)
1159025490 3244 - free - (1.6M)
1159028734 216879106 3 ebr (103G)
1375907840 2522734592 - free - (1.2T)
3898642432 8386560 4 !223 (4.0G)
3907028992 176 - free - (88K)

=> 0 216879106 ada0s3 EBR (103G)
0 2105346 1 linux-data (1.0G)
2105346 11990 - free - (5.9M)
2117336 2056320 33609 linux-data (1.0G)
4173656 2104515 66249 linux-data (1.0G)
6278171 2104515 99654 linux-data (1.0G)
8382686 2088450 133059 linux-data (1.0G)
10471136 2050338 166209 linux-data (1.0G)
12521474 2050877 198754 linux-data (1.0G)
14572351 202306755 - free - (96G)

=> 63 3907029105 ada1 MBR (1.8T)
63 3907029105 - free - (1.8T)

=> 0 216879106 diskid/DISK-MN1220F323ZT0Ds3 EBR (103G)
0 2105346 1 linux-data (1.0G)
2105346 11990 - free - (5.9M)
2117336 2056320 33609 linux-data (1.0G)
4173656 2104515 66249 linux-data (1.0G)
6278171 2104515 99654 linux-data (1.0G)
8382686 2088450 133059 linux-data (1.0G)
10471136 2050338 166209 linux-data (1.0G)
12521474 2050877 198754 linux-data (1.0G)
14572351 202306755 - free - (96G)

=> 63 2105281 ada0s5 MBR (1.0G)
63 2105281 - free - (1.0G)

=> 63 2056194 ada0s6 MBR (1.0G)
63 2056194 - free - (1.0G)

=> 63 2104389 ada0s7 MBR (1.0G)
63 2104389 - free - (1.0G)

=> 63 2104389 ada0s8 MBR (1.0G)
63 2104389 - free - (1.0G)

=> 63 2088324 ada0s9 MBR (1.0G)
63 2088324 - free - (1.0G)

=> 63 2047937 ada0s10 MBR (1.0G)
63 2047937 - free - (1.0G)

=> 63 2048766 ada0s11 MBR (1.0G)
63 2048766 - free - (1.0G)

=> 63 3907029105 diskid/DISK-5YD4L8KW MBR (1.8T)
63 3907029105 - free - (1.8T)

=> 63 3907029105 diskid/DISK-WD-WCAZAC376630 MBR (1.8T)
63 3970 - free - (1.9M)
4033 1907429439 1 ebr (910G)
1907433472 1169063936 - free - (557G)
3076497408 204800000 2 freebsd [active] (98G)
3281297408 625731760 3 ntfs (298G)

=> 63 2105281 diskid/DISK-MN1220F323ZT0Ds5 MBR (1.0G)
63 2105281 - free - (1.0G)

=> 63 2056194 diskid/DISK-MN1220F323ZT0Ds6 MBR (1.0G)
63 2056194 - free - (1.0G)

=> 63 2104389 diskid/DISK-MN1220F323ZT0Ds7 MBR (1.0G)
63 2104389 - free - (1.0G)

=> 63 2104389 diskid/DISK-MN1220F323ZT0Ds8 MBR (1.0G)
63 2104389 - free - (1.0G)

=> 63 2088324 diskid/DISK-MN1220F323ZT0Ds9 MBR (1.0G)
63 2088324 - free - (1.0G)

=> 63 2047937 diskid/DISK-MN1220F323ZT0Ds10 MBR (1.0G)
63 2047937 - free - (1.0G)

=> 63 2048766 diskid/DISK-MN1220F323ZT0Ds11 MBR (1.0G)
63 2048766 - free - (1.0G)

=> 63 2105281 ext2fs/SUSEBOOT MBR (1.0G)
63 2105281 - free - (1.0G)

=> 63 2056194 ext2fs/MANDRIVBOOT MBR (1.0G)
63 2056194 - free - (1.0G)

=> 63 2104389 ext2fs/FEDORABOOT MBR (1.0G)
63 2104389 - free - (1.0G)

=> 63 2104389 ext2fs/CENTOSBOOT MBR (1.0G)
63 2104389 - free - (1.0G)

=> 63 2088324 ext2fs/CENT63BOOT MBR (1.0G)
63 2088324 - free - (1.0G)

=> 63 2047937 ext2fs/UBUNTUBOOT MBR (1.0G)
63 2047937 - free - (1.0G)

=> 63 2048766 ext2fs/MINTBOOT MBR (1.0G)
63 2048766 - free - (1.0G)

=> 0 1907429439 diskid/DISK-WD-WCAZAC376630s1 EBR (910G)
0 104855615 1 linux-data (50G)
104855615 104855552 1664375 linux-data (50G)
209711167 125830 - free - (61M)
209836997 104862842 3330746 linux-data (50G)
314699839 104857600 4995236 linux-data (50G)
419557439 104855552 6659642 linux-data (50G)
524412991 102400000 8324016 linux-data (49G)
626812991 102416360 9949413 linux-data (49G)
729229351 102400024 11575070 linux-data (49G)
831629375 116344832 13200467 linux-data (55G)
947974207 1345 - free - (673K)
947975552 107667630 15047231 fat32 (51G)
1055643182 32770577 16756241 linux-swap (16G)
1088413759 2023 - free - (1.0M)
1088415782 102479897 17276441 linux-data (49G)
1190895679 104810496 18903107 linux-data (50G)
1295706175 102402048 20566765 linux-data (49G)
1398108223 99905536 22192195 linux-data (48G)
1498013759 102402048 23777997 linux-data (49G)
1600415807 99905536 25403426 linux-data (48G)
1700321343 207108096 - free - (99G)

=> 0 204800000 diskid/DISK-WD-WCAZAC376630s2 BSD (98G)
0 200683520 1 freebsd-zfs (96G)
200683520 4096000 2 freebsd-swap (2.0G)
204779520 20480 - free - (10M)

=> 63 107667504 diskid/DISK-WD-WCAZAC376630s14 MBR (51G)
63 107667504 - free - (51G)
```

It does not seem to me that the ada2 slices are being recognized whereas the ada0 slices are. Instead I just see above  diskid/DISK-WD-WCAZAC376630s1 EBR (910G) instead of the individual slices in that extended slice.

Is there something I must do at the FreeBSD level that will get it to recognize the individual slices in the extended slice on ada2? Or have I just encountered some limitation at the FreeBSD level that keeps the OS from being able to access the individual slices on my 3rd hard disk ? Note also that the ZFS filesystem in which I boot is on the 3rd hard disk and FreeBSD evidently has no problem accessing it and working with it.


----------



## wblock@ (May 9, 2014)

`gpart show` will show what it sees for disks.  It's not clear what you mean by "recognize".  You have a lot of "extended" DOS partitions, which will show as ada0s5 and up.


----------



## eldiener (May 9, 2014)

wblock@ said:
			
		

> `gpart show` will show what it sees for disks.  It's not clear what you mean by "recognize".  You have a lot of "extended" DOS partitions, which will show as ada0s5 and up.



I have an "extended" DOS partition on ada2 but I do not see the equivalent ada2s5 on up. That is the issue I am trying to understand.


----------



## wblock@ (May 9, 2014)

It may require building a custom kernel with the GEOM_PART_EBR option.  What does `gpart show` produce?


----------



## kpa (May 9, 2014)

These options are on by default in the GENERIC kernel on FreeBSD 10 and they should be on by default on earlier versions too:


```
options	GEOM_PART_EBR_COMPAT
options	GEOM_PART_EBR
```

There shouldn't be a need to compile a custom kernel to have support for EBR at least on basic FreeBSD. No idea what PC-BSD does though.


----------



## wblock@ (May 9, 2014)

They're in DEFAULTS, but not in GENERIC, at least with 10-STABLE.


----------



## kpa (May 9, 2014)

wblock@ said:
			
		

> They're in DEFAULTS, but not in GENERIC, at least with 10-stable.



I took those options from the GENERIC kernel I'm using with `sysctl kern.conftxt`, they are definitely on. The DEFAULTS file seems to be read in by config(8) before the kernel config file is read.


----------



## eldiener (May 9, 2014)

wblock@ said:
			
		

> It may require building a custom kernel with the GEOM_PART_EBR option.  What does `gpart show` produce?



I printed the output from `gpart show` in my OP.


----------



## eldiener (May 9, 2014)

I am using PC-BSD 10.0. 

It sounds like what is being said is that I need a custom kernel to support my hard drive configuration in ada2, or that I need some data file which the kernel reads when booting (or maybe building) to be tweaked in some way.

I am a very experienced computer programmer but I am pretty new to *BSD so if anyone can give me instructions for solving this problem it would be appreciated. I realize PC-BSD is not FreeBSD but I believe the PC-BSD 10.0 release uses FreeBSD 10.0 underneath.

I also believe that there is an upcoming PC-BSD 10.1 release based on FreeBSD 10.1 so that if my problem is solved in an upcoming release I can wait until that happens.


----------



## wblock@ (May 9, 2014)

No, you do not need a custom kernel.  You did post `gpart` output, but all the whitespace formatting was lost so it's very difficult to read.

Please show the output of `gpart show ada2`.  Post it in 
	
	



```
tags so the format is preserved.
```


----------



## eldiener (May 9, 2014)

wblock@ said:
			
		

> No, you do not need a custom kernel.  You did post `gpart` output, but all the whitespace formatting was lost so it's very difficult to read.
> 
> Please show the output of `gpart show ada2`.  Post it in
> 
> ...




```
gpart show ada2
gpart: No such geom: ada2.
```


----------



## kpa (May 9, 2014)

eldiener said:
			
		

> wblock@ said:
> 
> 
> 
> ...




Anything in the `dmesg` output about ada2? It's possible that the GEOM system detects an error and rejects the partition table on ada2 for some reason. If that's the case there should be an error message in the `dmesg` output.


----------



## wblock@ (May 10, 2014)

Something is preventing the GEOM system from recognizing ada2.  Maybe a "hybrid" GPT/MBR setup?  `# file -s /dev/ada2` might be able to tell what type of partitioning it's trying to use.


----------



## eldiener (May 10, 2014)

kpa said:
			
		

> eldiener said:
> 
> 
> 
> ...



From dmesg:


```
ada0 at ahcich0 bus 0 scbus2 target 0 lun 0
ada0: <Hitachi HDS723020BLA642 MN6OA5C0> ATA-8 SATA 3.x device
ada0: Serial Number MN1220F323ZT0D
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad8
ada1 at ahcich1 bus 0 scbus3 target 0 lun 0
ada1: <ST2000DL003-9VT166 CC32> ATA-8 SATA 3.x device
ada1: Serial Number 5YD4L8KW
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
ada1: quirks=0x1<4K>
ada1: Previously was known as ad10
ada2 at ahcich2 bus 0 scbus4 target 0 lun 0
ada2: <WDC WD20EARX-00PASB0 51.0AB51> ATA-8 SATA 3.x device
ada2: Serial Number WD-WCAZAC376630
ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada2: Command Queueing enabled
ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
ada2: quirks=0x1<4K>
ada2: Previously was known as ad12
```

That is all that is about ada0, ada1, or ada2 in the dmesg output.


----------



## eldiener (May 10, 2014)

wblock@ said:
			
		

> Something is preventing the GEOM system from recognizing ada2.  Maybe a "hybrid" GPT/MBR setup?  `# file -s /dev/ada2` might be able to tell what type of partitioning it's trying to use.




```
file -s /dev/ada2
/dev/ada2: x86 boot sector; partition 1: ID=0xf, starthead 64, startsector 4033, 1907429439 sectors; partition 2: ID=0xa5, active, starthead 27, startsector 3076497408, 204800000 sectors; partition 3: ID=0x7, starthead 80, startsector 3281297408, 625731760 sectors, code offset 0x33
```

All three are just MBR AFAIK. I do have GPT disks as external backup disks but the external backup drives in an IcyDock enclosure are turned off entirely when booting PC-BSD. Is there an equivalent to fdisk or gdisk in FreeBSD that will give me more information about /dev/ada2 ?


----------



## wblock@ (May 10, 2014)

fdisk(8) is the old program that only handles MBR.  But if the GEOM system does not detect an MBR, something is wrong.  Check the output of `dmesg -a` for error messages.  (-a shows additional messages that may not be in visible in the ordinary `dmesg`.)


----------



## eldiener (May 10, 2014)

wblock@ said:
			
		

> fdisk(8) is the old program that only handles MBR.  But if the GEOM system does not detect an MBR, something is wrong.  Check the output of `dmesg -a` for error messages.  (-a shows additional messages that may not be in visible in the ordinary `dmesg`.)



There were no further messages about ada(n) in the output from `dmesg -a`.


----------

