# New Install 10.2 "Partitioning Error"



## GeorgeG (Feb 12, 2016)

I am trying to install 10.2 on an old desktop. The installer seems to load fine but gives "Partitioning Error" no matter what option is selected. I've done some troubleshooting:

- I have two HDD on that system (ran Windows and eventually changed to Linux that way) and have tried both, including each with the other drive removed. No joy.
- Ubuntu 14.04.3 installs from disc fine, and then runs fine from the HDD. This was to verify that the HDD can be installed to and booted from.
- With FreeBSD LiveCD (DVD) running, ran both "`geom disk list`" and "`camcontrol devlist`" and each of those commands only lists the two optical drives installed. Neither command shows any HDD at all.

Since I know (by installing and running Ubuntu) that the SATA controller and (both) HDD are working, it seems like the FreeBSD installer is not seeing the controller. Is this a reasonable conclusion? Is there anything I can do about it? Or is it just a bad idea to try to get FreeBSD running on that particular hardware?

This is the 10.2 i386 DVD1 iso installer.
The desktop is a Dell Dimension E510 manufactured in 2006.

Any help would be appreciated.


----------



## tingo (Feb 12, 2016)

Any hints (as to why the hard drives or controller doesn't detect correctly) in `dmesg` output? Since the installer boots and starts, you can choose a shell or a live system instead.
If you can't get any clues from dmesg with a normal boot, try a verbose boot and see if you get any clues then.


----------



## protocelt (Feb 13, 2016)

Additionally, make sure your BIOS firmware is updated to the newest version released by Dell for that hardware.


----------



## GeorgeG (Feb 13, 2016)

Thanks, Tingo.

I had obtained some of the previous information by going to the live ISO boot and getting a shell. Not familiar with the dmesg(8) command, so I just ran it (`demsg | more`). It provided lots of data, these ones look to my eye like they do or might pertain to the hard drive controller:


```
hdac0: <Intel 82801G HDA controller> mem 0x efffc000 - 0xefffffff irq 16 at device 27.0 at device pci0

atapci0: <Intel ICH7 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf irq 16 at device 31.1 on atapci0

ata0: <ATA channel> at channel 0 on atapci0

atapci1: <Intel ICH7 SATA300 controller> port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfea0-0xfeaf irq 20 at device 31.2 on pci0

ata2: <ATA channel> at channel 0 on atapci1

ata3: <ATA channel> at channel 1 on atapci1
```

The above was transcribed to paper then typed in, so typographical errors are quite possible. Please ask about anything that I should verify.


----------



## GeorgeG (Feb 13, 2016)

protocelt said:


> Additionally, make sure your BIOS firmware is updated to the newest version released by Dell for that hardware.


Thank you - did that a while back. I think it's been a long time since they released anything for this system. They don't even have the service tag in their system anymore.


----------



## ab2k (Feb 13, 2016)

Hi, you have said you had 2 drives - did you had a some sort of raid enabled on those drives ? Sometimes drives are not available just because of it - software-raids done with chipset, windows logical volumes... etc.. 

UPDATE: Can you please post a full `dmesg` output (just from the reboot)


----------



## GeorgeG (Feb 13, 2016)

ab2k said:


> Hi, you have said you had 2 drives - did you had a some sort of raid enabled on those drives ? Sometimes drives are not available just because of it - software-raids done with chipset, windows logical volumes... etc..


No raid whatsoever at any time. Those are just two separate drives. Most recently I installed Ubuntu on one (as noted above), and (eventually) did a "dd" copy of that one to the other drive (running in a shell from another Live disk, either GParted or Clonezilla).



> UPDATE: Can you please post a full `dmesg` output (just from the reboot)


I would love to, but I'm not sure I can capture it. Will I be able to plug in a USB stick and have it be picked up? I'll give that a go and report back.

When you say "just from the reboot", could you clarify that some? I tried the FreeBSD Installer, when that didn't work I opted for the Live Boot (or however that option is worded), and logged in as "root". Is that what you mean by "from the reboot"?


----------



## protocelt (Feb 13, 2016)

GeorgeG, it looks like from the output you posted above the controller is running in legacy mode as opposed to ahci(4) mode. I do very vaguely remember there being some posts on the mailing list about the Intel ICH7 controller, or certain versions of, not supporting ahci(4) mode and also having problems under FreeBSD. I don't know if that is still an issue today as I don't own any hardware with that controller. 

Is there possibly an option in your BIOS to turn on ahci(4) mode?


----------



## GeorgeG (Feb 13, 2016)

protocelt said:


> GeorgeG, it looks like from the output you posted above the controller is running in legacy mode as opposed to ahci(4) mode. I do very vaguely remember there being some posts on the mailing list about the Intel ICH7 controller, or certain versions of, not supporting ahci(4) mode and also having problems under FreeBSD. I don't know if that is still an issue today as I don't own any hardware with that controller.
> 
> Is there possibly an option in your BIOS to turn on ahci(4) mode?


I just checked the BIOS, no such option nor anything that looks like it. Under the Drives section there is an option SATA Operation regarding RAID, where one setting is RAID Autodetect / ATA (= RAID if signed drives, otherwise ATA), the other is RAID On (SATA is configured for RAID on every boot). That is set to auto-detect. Just to reiterate, I am the original owner of the hardware and have never configured/used RAID on it.

Another setting, in the POST Behavior section, is Fast Boot, defined as "This field speeds up the boot process by bypassing some compatibility steps". Default is On, which means "Boot quickly". Off means "Do not skip any steps in the boot process". This does not sound really promising but I will change it and try the install again. 

Thanks for the mention about the ICH7 controller, I'll try some searches on that and see if it is thought to be troublesome.


----------



## GeorgeG (Feb 13, 2016)

ab2k said:


> UPDATE: Can you please post a full `dmesg` output (just from the reboot)


And here it is:


```
Copyright (c) 1992-2015 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 19:31:38 UTC 2015
    root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz (3192.07-MHz 686-class CPU)
  Origin="GenuineIntel"  Id=0xf43  Family=0xf  Model=0x4  Stepping=3
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x649d<SSE3,DTES64,MON,DS_CPL,EST,CNXT-ID,CX16,xTPR>
  AMD Features=0x20100000<NX,LM>
  TSC: P-state invariant
real memory  = 3221225472 (3072 MB)
avail memory = 3139751936 (2994 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: <DELL   DM051  >
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads
cpu0 (BSP): APIC ID:  0
cpu1 (AP/HT): APIC ID:  1
ioapic0: Changing APIC ID to 8
ioapic0 <Version 2.0> irqs 0-23 on motherboard
lapic0: Forcing LINT1 to edge trigger
kbd1 at kbdmux0
random: <Software, Yarrow> initialized
acpi0: <DELL DM051  > on motherboard
acpi0: Power Button (fixed)
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
atrtc0: <AT realtime clock> port 0x70-0x7f irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
attimer0: <AT timer> port 0x40-0x5f irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 450
Event timer "HPET1" frequency 14318180 Hz quality 440
Event timer "HPET2" frequency 14318180 Hz quality 440
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0xdc00-0xdcff mem 0xec000000-0xedffffff,0xefde0000-0xefdeffff irq 16 at device 0.0 on pci1
vgapci0: Boot video device
vgapci1: <VGA-compatible display> mem 0xefdf0000-0xefdfffff at device 0.1 on pci1
hdac0: <Intel 82801G HDA Controller> mem 0xefffc000-0xefffffff irq 16 at device 27.0 on pci0
pcib2: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
pci2: <ACPI PCI bus> on pcib2
uhci0: <Intel 82801G (ICH7) USB controller USB-A> port 0xff80-0xff9f irq 21 at device 29.0 on pci0
uhci0: LegSup = 0x3000
usbus0 on uhci0
uhci1: <Intel 82801G (ICH7) USB controller USB-B> port 0xff60-0xff7f irq 22 at device 29.1 on pci0
usbus1 on uhci1
uhci2: <Intel 82801G (ICH7) USB controller USB-C> port 0xff40-0xff5f irq 18 at device 29.2 on pci0
usbus2 on uhci2
uhci3: <Intel 82801G (ICH7) USB controller USB-D> port 0xff20-0xff3f irq 23 at device 29.3 on pci0
usbus3 on uhci3
ehci0: <Intel 82801GB/R (ICH7) USB 2.0 controller> mem 0xffa80800-0xffa80bff irq 21 at device 29.7 on pci0
usbus4: EHCI version 1.0
usbus4 on ehci0
pcib3: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci3: <ACPI PCI bus> on pcib3
pci3: <multimedia, video> at device 3.0 (no driver attached)
fxp0: <Intel 82801GB (ICH7) 10/100 Ethernet> port 0xccc0-0xccff mem 0xefbfd000-0xefbfdfff irq 20 at device 8.0 on pci3
miibus0: <MII bus> on fxp0
inphy0: <i82562ET 10/100 media interface> PHY 1 on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
fxp0: Ethernet address: 00:13:72:b0:40:49
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel ICH7 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf irq 16 at device 31.1 on pci0
ata0: <ATA channel> at channel 0 on atapci0
atapci1: <Intel ICH7 SATA300 controller> port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfea0-0xfeaf irq 20 at device 31.2 on pci0
ata2: <ATA channel> at channel 0 on atapci1
ata3: <ATA channel> at channel 1 on atapci1
pmtimer0 on isa0
orm0: <ISA Option ROMs> at iomem 0xc0000-0xccfff,0xcd000-0xcefff,0xcf000-0xcffff pnpid ORM0000 on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
ppc0: parallel port not found.
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 102a0000102a
device_attach: est0 attach returned 6
est1: <Enhanced SpeedStep Frequency Control> on cpu1
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 102a0000102a
device_attach: est1 attach returned 6
Timecounters tick every 1.000 msec
hdacc0: <Sigmatel STAC9221 HDA CODEC> at cad 0 on hdac0
hdaa0: <Sigmatel STAC9221 Audio Function Group> at nid 1 on hdacc0
pcm0: <Sigmatel STAC9221 (Analog 7.1+HP/2.0)> at nid 13,15,12,11,10 and 14,21 on hdaa0
random: unblocking device.
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 12Mbps Full Speed USB v1.0
usbus2: 12Mbps Full Speed USB v1.0
usbus3: 12Mbps Full Speed USB v1.0
usbus4: 480Mbps High Speed USB v2.0
ugen0.1: <Intel> at usbus0
ugen4.1: <Intel> at usbus4
uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus4
ugen3.1: <Intel> at usbus3
uhub1: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus3
ugen2.1: <Intel> at usbus2
uhub2: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus2
ugen1.1: <Intel> at usbus1
uhub3: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
uhub4: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
cd0 at ata0 bus 0 scbus0 target 0 lun 0
cd0: <TSSTcorp DVD-ROM TS-H352C DE02> Removable CD-ROM SCSI device
cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed
cd1 at ata0 bus 0 scbus0 target 1 lun 0
cd1: <PHILIPS DVD+-RW DVD8801 4D28> Removable CD-ROM SCSI device
cd1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
cd1: cd present [1244320 x 2048 byte records]
uhub2: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
uhub4: 2 ports with 2 removable, self powered
uhub3: 2 ports with 2 removable, self powered
lapic1: Forcing LINT1 to edge trigger
SMP: AP CPU #1 Launched!
Timecounter "TSC-low" frequency 1596036348 Hz quality 1000
Root mount waiting for: usbus4
Root mount waiting for: usbus4
uhub0: 8 ports with 8 removable, self powered
Root mount waiting for: usbus4
Trying to mount root from cd9660:/dev/iso9660/10_2_RELEASE_I386_DVD [ro]...
ugen2.2: <Logitech> at usbus2
ugen1.2: <Dell> at usbus1
ukbd1: <EP1 Interrupt> on usbus1
kbd2 at ukbd1
ums0: <Logitech USB-PS2 Optical Mouse, class 0/0, rev 2.00/20.00, addr 2> on usbus2
ums0: 4 buttons and [XYZ] coordinates ID=0
pid 864 (autopart), uid 0: exited on signal 11
ugen4.2: <SanDisk> at usbus4
umass0: <SanDisk SanDisk Cruzer, class 0/0, rev 2.00/2.00, addr 2> on usbus4
umass0:  SCSI over Bulk-Only; quirks = 0x4100
umass0:3:0:-1: Attached to scbus3
da0 at umass-sim0 bus 0 scbus3 target 0 lun 0
da0: <SanDisk SanDisk Cruzer 8.02> Removable Direct Access SCSI device
da0: Serial Number 07743311A7502DC5
da0: 40.000MB/s transfers
da0: 3863MB (7913471 512 byte sectors: 255H 63S/T 492C)
da0: quirks=0x2<NO_6_BYTE>
ugen4.2: <SanDisk> at usbus4 (disconnected)
umass0: at uhub0, port 8, addr 2 (disconnected)
da0 at umass-sim0 bus 0 scbus3 target 0 lun 0
da0: <SanDisk SanDisk Cruzer 8.02> s/n 07743311A7502DC5 detached
(da0:umass-sim0:0:0:0): Periph destroyed
ugen4.2: <SanDisk> at usbus4
umass0: <SanDisk SanDisk Cruzer, class 0/0, rev 2.00/2.00, addr 2> on usbus4
umass0:  SCSI over Bulk-Only; quirks = 0x4100
umass0:3:0:-1: Attached to scbus3
da0 at umass-sim0 bus 0 scbus3 target 0 lun 0
da0: <SanDisk SanDisk Cruzer 8.02> Removable Direct Access SCSI device
da0: Serial Number 07743311A7502DC5
da0: 40.000MB/s transfers
da0: 3863MB (7913471 512 byte sectors: 255H 63S/T 492C)
da0: quirks=0x2<NO_6_BYTE>
```


----------



## GeorgeG (Feb 13, 2016)

GeorgeG said:


> Another setting, in the POST Behavior section, is Fast Boot, defined as "This field speeds up the boot process by bypassing some compatibility steps". Default is On, which means "Boot quickly". Off means "Do not skip any steps in the boot process". This does not sound really promising but I will change it and try the install again.


I did try changing the Fast Boot setting in the BIOS, but it did not help at all. What it did do was make the POST portion of booting at least 5 or 6 times longer. Changed it back.


----------



## GeorgeG (Feb 13, 2016)

protocelt said:


> I do very vaguely remember there being some posts on the mailing list about the Intel ICH7 controller, or certain versions of, not supporting ahci(4) mode and also having problems under FreeBSD. I don't know if that is still an issue today as I don't own any hardware with that controller.
> 
> Is there possibly an option in your BIOS to turn on ahci(4) mode?


This is the most direct thing I found about the ICH7:
https://lists.freebsd.org/pipermail/freebsd-bugs/2012-November/050605.html
It basically says what I am experiencing (hard drives not seen).

The odd thing is that according to this:
https://www.freebsd.org/releases/10.2R/hardware.html#disk
FreeBSD thinks the Intel ICH7 is an audio device.


----------



## kpa (Feb 13, 2016)

GeorgeG said:


> The odd thing is that according to this:
> https://www.freebsd.org/releases/10.2R/hardware.html#disk
> FreeBSD thinks the Intel ICH7 is an audio device.



That's because some versions of the ICH7 chipset do include an audio controller.


----------



## GeorgeG (Feb 13, 2016)

kpa said:


> That's because some versions of the ICH7 chipset do include an audio controller.


OK, thanks.


----------



## GeorgeG (Feb 13, 2016)

kpa said:


> That's because some versions of the ICH7 chipset do include an audio controller.


With this in mind, I disabled the on-board audio (in case it was interfering with the SATA inside the drivers) and tried again, no difference.


----------



## GeorgeG (Feb 13, 2016)

I'm trying to sneak up on it. I burned (on Windows) a USB stick with the installation IMG file and started working from that. Nicely faster. Still can't see the hard drives, but I ran the installer (from the 4GB USB stick) to a 16GB USB stick. I did have to insert the target stick after the installer stick began to boot (otherwise no boot), but the installation went well and reported success. My thought is, if it is only the default driver from the installer medium with the issue, I might be able to see the drives when I boot from the stick with the installation run onto it. Or, if not, then maybe update the driver on that stick after booting it.

But (those of you reading might anticipate this) the system won't boot from the stick that I installed FreeBSD to.

If I substitute a spinning USB drive in place of the stick, will I be able to boot from that after installing to it?

Or, if I boot from some other Live CD just to get to a shell, will a dd copy from the USB stick with FreeBSD installed to an internal HDD have any chance of creating a bootable disk?

Am I just spinning my wheels uselessly?


----------



## wblock@ (Feb 14, 2016)

Isn't the ICH7 the one that Intel pretends they never made?

From a block standpoint, a USB hard drive is no different from a USB flash drive.  Binary copying the installer disk is not going to help much.  The format will have to be modified, and the files modified to keep it from running the installer.

The critical thing here is why the SATA drives are not seen.  I would disconnect all but one, then try the installer on that.
If that did not work, I would boot the installer, then manually set up GPT partitions and let the installer install to them.
If that did not work, I would boot the installer, then manually set up MBR/BSDlabel partitions on the assumption that Dell BIOS authors of that time were just as bad at it as Lenovo and HP.


----------



## GeorgeG (Feb 14, 2016)

Grateful for the suggestions! I might not have been clear on what I've tried so far. Here is status on the items you mentioned:


wblock@ said:


> Isn't the ICH7 the one that Intel pretends they never made?


I have no idea, but when you design and make zillions of products there are bound to be some that come out, shall we say, "sub-optimal"! 


> From a block standpoint, a USB hard drive is no different from a USB flash drive.  Binary copying the installer disk is not going to help much.  The format will have to be modified, and the files modified to keep it from running the installer.


It was not the installer USB stick that I asked about dd copying. It was a separate USB stick that I did a (reportedly) successful installation to.

I did get to try the dd copy of the 'successfully' installed USB stick to a HDD (using the shell from some other live ISO, not the BSD installer), and the copy went fine. But the HDD thus created will not boot the system. Looking at another thread I gathered that the boot process for FreeBSD is a bit different than some other OS, which is why they made a IMG file installer for USB sticks instead of copying the ISO to a stick. 


> The critical thing here is why the SATA drives are not seen.  I would disconnect all but one, then try the installer on that.


Tried that before even posting here - with one drive connected, with two drives connected... It seems like the FreeBSD installer is not seeing (or making available) the SATA controller.


> If that did not work, I would boot the installer, then manually set up GPT partitions and let the installer install to them.


The FreeBSD installer does not see the SATA controller, so it does not see the physical hard drives. I could set up partitions manually using some other live ISO, but the FreeBSD installer doesn't see the controller and doesn't see the drives, so it won't see the partitions.


> If that did not work, I would boot the installer, then manually set up MBR/BSDlabel partitions on the assumption that Dell BIOS authors of that time were just as bad at it as Lenovo and HP.


Same as prior answer - the FreeBSD installer does not see the controller so does not see the drives so cannot make any partitions.

In the last couple of days I have installed Ubuntu 14.04.3 to one of the HDD and Debian 8.3.0 to the other, and each boots fine. Obviously those installers did see the controller fine, so they must be using a different driver. Behind my thought about "sneaking up on it" (meaning getting FreeBSD installed) is the hope that running version of FreeBSD would not use the same driver as the FreeBSD installer. Or that I could update the driver once the installation was complete. 

I still want to try installing to a spinning USB connected drive (where maybe I can then update a driver). Does that have a better chance of working, or will the fact that it is USB connected when the installation process runs doom it to being formatted the same way that the USB stick was formatted when I installed to that?


----------



## tingo (Feb 14, 2016)

At this point, I would try the previous release of FreeBSD, just to see if that one would detect the hard drives or not.


----------



## GeorgeG (Feb 14, 2016)

tingo said:


> At this point, I would try the previous release of FreeBSD, just to see if that one would detect the hard drives or not.


I'm worried that this bug (https://lists.freebsd.org/pipermail/freebsd-bugs/2012-November/050605.html) was already extant in prior version(s). I'll try anyway when I can corral another HD to use.

If that works, will I then be able to upgrade in place to the present version?


----------



## wblock@ (Feb 14, 2016)

GeorgeG said:


> Looking at another thread I gathered that the boot process for FreeBSD is a bit different than some other OS, which is why they made a IMG file installer for USB sticks instead of copying the ISO to a stick.


No, rather it has been Linux which has combined the very different CD and hard drive/flash booting into a single thing.

As far as the controller, if FreeBSD did not see it, the system would still show the boot.  FreeBSD would halt after loading the kernel.  Since it doesn't make it even that far, my money would be on a stupid BIOS that misidentifies GPT partitions.

However, I'm still not clear on whether the disks are shown at all by the installer partitioning screen.


----------



## GeorgeG (Feb 14, 2016)

wblock@ said:


> No, rather it has been Linux which has combined the very different CD and hard drive/flash booting into a single thing.
> 
> As far as the controller, if FreeBSD did not see it, the system would still show the boot.  FreeBSD would halt after loading the kernel.  Since it doesn't make it even that far, my money would be on a stupid BIOS that misidentifies GPT partitions.
> 
> *However, I'm still not clear on whether the disks are shown at all by the installer partitioning screen.*


No, the SATA disks are not shown at all. The CD/DVD drives are seen. Plug in a USB stick and it is seen. No SATA drives are seen, no matter whether 1 or 2 are plugged in. I pasted a dmesg above which, I think, shows that the system (FreeBSD live boot from the installer disk) does not see the SATA controller. In fact, I wrote that dmesg to a USB stick that I plugged in and mounted just so I could capture the full dmesg output to paste here.

Later when I get a chance (can't just now) I will attach both HDD (one with bootable Ubuntu and one with bootable Debian) and boot from a Gparted CD, then look at the partition types on each of those drives. If I find GPT partitions on the Ubuntu and/or Debian disks, we'll know the BIOS is not a problem as far as that goes. 

As far as my effort of doing a dd copy of the USB stick to an HDD, that effort might not have been definitive at all. When the FreeBSD installer (from a different stick) partitioned and otherwise made that stick, a straight copy to an HDD might not have left the HDD bootable. 

I'll report back when I can.


----------



## wblock@ (Feb 15, 2016)

Using dd(1) to copy a USB memory stick image to a hard drive will probably work.  Of course, it will boot to the installer, and it uses BSDlabel-only partitioning, and there is no extra space in the filesystem.

The ata0 device shown is probably an IDE controller.  My system shows ada0 at ahcich0 bus 0 scbus0 target 0 lun 0.  I know AHCI is not required, but am not sure what is shown for a non-AHCI controller.  It's worth checking the BIOS for odd settings for the disk controller.  If AHCI is available, it should be on.


----------



## GeorgeG (Feb 15, 2016)

I have checked and both the Debian and Ubuntu drives have "msdos" type partition tables.

I plan to use a blank HDD to test making a GPT type partition table to be sure the hardware can see it.

However: Both HDD could and cannot be seen by the FreeBSD installer even with msdos partition tables, and could not be seen when they had no partition tables at all (I tried that too!). But the Ubuntu and Debian installers were able to see both HDD and install to them.

The BIOS could not know ahead of time that the FreeBSD installer wanted to later set up a GPT partition table, and therefore make the controller & drives unseen by FreeBSD installer. If it was the BIOS not being able to see GPT partition tables then the FreeBSD installer would have seen the drives when they had msdos partition tables and when they had no partition tables. But the FreeBSD installer never sees the SATA drives, so the impediment must be at the installer level, perhaps relating to being able to see the controller.

- I will verify that the BIOS sees a drive when that drive has a GPT type partition table.
- I will also try Tingo's recommendation of installing an older version (and then upgrading) when I have time to do that.
- I will also try FreeBSD installation to a spinning drive via USB and then copy that drive to internal SATA HDD.

Meanwhile if anyone has other suggestions on how I might be able to get FreeBSD running on that box they would be appreciated!


----------



## GeorgeG (Feb 15, 2016)

wblock@ said:


> Using dd(1) to copy a USB memory stick image to a hard drive will probably work.  Of course, it will boot to the installer, and it uses BSDlabel-only partitioning, and there is no extra space in the filesystem.


But it was not the installer USB memory stick that I copied, so why would it boot to the installer?



> The ata0 device shown is probably an IDE controller.  My system shows ada0 at ahcich0 bus 0 scbus0 target 0 lun 0.  I know AHCI is not required, but am not sure what is shown for a non-AHCI controller.  It's worth checking the BIOS for odd settings for the disk controller.  If AHCI is available, it should be on.


I'll check that again right now. Thanks.


----------



## GeorgeG (Feb 15, 2016)

wblock@:

I just checked the BIOS settings again and there is nothing odd. The only setting really even available there (the drive/controller area) is what I described in an earlier post:

"Under the Drives section there is an option SATA Operation regarding RAID, where one setting is RAID Autodetect / ATA (= RAID if signed drives, otherwise ATA), the other is RAID On (SATA is configured for RAID on every boot). That is set to auto-detect."

And as I noted there, this system has never had RAID of any kind configured on it.


----------



## Juha Nurmela (Feb 15, 2016)

Have you tried `camcontrol rescan all` or `camcontrol reset all` ?

Juha


----------



## GeorgeG (Feb 15, 2016)

Juha Nurmela said:


> Have you tried `camcontrol rescan all` or `camcontrol reset all` ?
> 
> Juha


No, I will add them to my list! Thank you.


----------



## Juha Nurmela (Feb 15, 2016)

Funny... There's a Dell on my junkpile, a desktop from 2006. OptiPlex GX520. All devices, including a SATA harddisk, CD/DVD, ... were found with some FreeBSD (10.0 I think) without problems.

Not that that helps at all, but...
Juha


----------



## GeorgeG (Feb 15, 2016)

Juha Nurmela said:


> Have you tried `camcontrol rescan all` or `camcontrol reset all` ?
> 
> Juha


First, I took another old HDD, booted a live Gparted CD and put a new GPT partition table on the HDD. Worked fine. Rebooted to the same Gparted live CD, saw the HDD with the GPT partition fine. So, it's not the BIOS.

Next, booted from the FreeBSD installer USB stick. It does not see the HDD. 
Went into the FreeBSD installer live boot (still on the installer USB stick), it does not see the HDD.
Tried camcontrol rescan all, it reported success on Bus 0 through Bus 4, but it still doesn't see the HDD.
Tried camcontrol reset all, it reported success on Bus 0 through Bus 3, and error 0x3a on Bus 4. Still can't see the HDD. Unless there is evidence to the contrary, I am assuming the error 0x3a on Bus 4 is no big deal. Maybe a consequence of running from the USB when trying to "reset" things??

I'll report back when I have more.


----------



## GeorgeG (Feb 15, 2016)

Juha Nurmela said:


> Funny... There's a Dell on my junkpile, a desktop from 2006. OptiPlex GX520. All devices, including a SATA harddisk, CD/DVD, ... were found with some FreeBSD (10.0 I think) without problems.
> 
> Not that that helps at all, but...
> Juha


Different model, so the issue I am seeing (and was reported in 2012) might just be a quirk of some particular hardware combination. 

BTW, when my wife complains that I am keeping "junk", I tell her no, those are "parts".


----------



## Juha Nurmela (Feb 15, 2016)

```
pci0:
 atapci0: UDMA100
  ata0:
   cd0:TSSTcorp DVD
   cd1: PHILIPS DVD
 atapci1: SATA300
  ata2:
  ata3:
```

Any or no partitioning should not prevent the device to identify itself. There's a disturbing gap (no ata1).

Juha


----------



## GeorgeG (Feb 15, 2016)

Juha Nurmela said:


> ```
> pci0:
> atapci0: UDMA100
> ata0:
> ...


I agree.

I just tried to install from a FreeBSD 10.0 installer CD, no joy. Based on the trouble ticket I found earlier (linked in two previous posts) this goes back to at least 2012, so I won't try going back to any older releases.

I have one more item on my list (install to spinning drive via USB then copy/clone/etc to internal HDD), and another to explore that I've thought of.

And I do have Debian and Ubuntu throwing fast balls in the bull pen...


----------



## wblock@ (Feb 15, 2016)

GeorgeG said:


> The BIOS could not know ahead of time that the FreeBSD installer wanted to later set up a GPT partition table, and therefore make the controller & drives unseen by FreeBSD installer. If it was the BIOS not being able to see GPT partition tables then the FreeBSD installer would have seen the drives when they had msdos partition tables and when they had no partition tables. But the FreeBSD installer never sees the SATA drives, so the impediment must be at the installer level, perhaps relating to being able to see the controller.


Well, this is tricky.  GPT includes a simulated MBR called the "protective" MBR.  So partitioning tools that do not understand GPT see that and assume it is MBR.

Systems with poorly-written BIOS implementations sometimes refuse to boot or even recognize disks with GPT partitioning.  Usually this is due to some stupid thing they have done using custom partition types.  IBM did things like that on the Thinkpads, and Lenovo has continued it.  It is likely that the drives would be visible after booting from another device, but not impossible that the BIOS would hide them.  Hiding the controller is unlikely, though.



GeorgeG said:


> But it was not the installer USB memory stick that I copied, so why would it boot to the installer?


Sorry, I read that as copying the installer image to the system drive, which was probably due to another thread where that was discussed.


----------



## wblock@ (Feb 15, 2016)

The RAID "autodetect" makes me suspicious.  If there is RAID metadata on a drive, it will be used for RAID regardless.  That would be motherboard RAID, documented in the Handbook here: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom-graid.html.

That metadata can remain on the disks without being obvious.  Some people have found it on factory disks, possibly from testing.

I don't know if the installer in 10.2 loads the graid(8) kernel module.  If not, that would explain some things.

Erasing that metadata on the machine in question might not be possible.  The RAID system hides it at the beginning or end of the disk.  Using graid(8) to erase it might be possible.  Otherwise, put the disk in a different machine and erase at least the first and last megabyte with dd(1).


----------



## GeorgeG (Feb 15, 2016)

wblock@ said:


> Well, this is tricky.  GPT includes a simulated MBR called the "protective" MBR.  So partitioning tools that do not understand GPT see that and assume it is MBR.
> 
> Systems with poorly-written BIOS implementations sometimes refuse to boot or even recognize disks with GPT partitioning.  Usually this is due to some stupid thing they have done using custom partition types.  IBM did things like that on the Thinkpads, and Lenovo has continued it.  It is likely that the drives would be visible after booting from another device, but not impossible that the BIOS would hide them.  Hiding the controller is unlikely, though.


I understand and it is something I will stay alert for. Have verified (see a couple of posts below) that the system can boot from a GPT partition.


----------



## GeorgeG (Feb 15, 2016)

wblock@ said:


> The RAID "autodetect" makes me suspicious.  If there is RAID metadata on a drive, it will be used for RAID regardless.  That would be motherboard RAID, documented in the Handbook here: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom-graid.html.
> 
> That metadata can remain on the disks without being obvious.  Some people have found it on factory disks, possibly from testing.
> 
> ...


I've tried several disks and they would all have to have hidden raid metadata left over by chance, including ones that I used for years on this system without RAID. Would deleting the partition table entirely get rid of such metadata? Asking because I did that too already. I can take additional steps to rule out this possibility if I know what they are (to wipe out recalcitrant metadata).

Anyway, see next post for an update...


----------



## wblock@ (Feb 15, 2016)

GeorgeG said:


> Would deleting the partition table entirely get rid of such metadata?


No.  When the RAID system is active, the metadata is not visible, and the drives appear to be correspondingly smaller.


----------



## GeorgeG (Feb 15, 2016)

An update. I tried the remaining item on my list. I took an internal SATA HDD, in this case an old 80GB given to me and plugged it into a USB dock. I disconnected all internal HDD. I then booted from the installer USB stick, and plugged in the USB dock just after the system recognized the installer stick and began booting from it.

I successfully ran the installation to the SATA HDD in the USB dock (accepting the default of GPT partition type), then shut down the system. I removed the SATA HDD from the dock, and installed internally to the SATA controller. I booted the system

The system did recognize and boot from the FreeBSD disk with the GPT partition. It went part way through the startup process, but then failed when it tried to re-mount root.

```
panic: mountroot: unable to (re-)mount root.
cpuid = 0
KDB: stackbacktrace:
#0 0xc0b720f2 at kdb_backtrace+0x52
#1 0xc0b332cb at vpanic+0x11b
#2 0xc0b331ab at panic+0x1b
#3 0xc0bd8d9b at vfs_mountroot+0x1ffb
#4 0xc0ad44de at start_init+0x5e
#5 0xc0af93c3 at fork_exit+0xa3
#6 0xc103fde4 at fork_trampoline+0x8
```
And then it wants to reboot, but allows you to stop it by pressing a key (which I did to copy down the message).

I don't know how to interpret the details, but it is clear that the system boots fine from the GPT partition, and only when the startup procedure gets to the point of remounting root - which I interpret to mean loading its own driver - does it fail.

I have access to this disk by using the USB dock (and any live boot CD), so is there another driver that I can obtain and substitute for the one that is not working?


----------



## GeorgeG (Feb 15, 2016)

wblock@ said:


> No.  When the RAID system is active, the metadata is not visible, and the drives appear to be correspondingly smaller.


Took me a while to type my last post...

Well, there is never any report (during boot, post, or anywhere) of RAID being active. That is not to say that somehow motherboard RAID support is not involved in the problem (by tripping up the FreeBSD driver or something), but there is no RAID being triggered by these disks.


----------



## Juha Nurmela (Feb 15, 2016)

Skimming  through that mailing list thread, If I understood it correctly, there was/is a real problem in driver, ata-intel.c, and alas, no promising changes in CURRENT. "Too exotic to fix". But unless that hardware matches yours exactly, ignore this "help".

Juha


----------



## GeorgeG (Feb 15, 2016)

"Too exotic to fix" - how lucky! 

Thank you, I would not have found that. So maybe it will be Debian for now on that box.


----------



## Juha Nurmela (Feb 15, 2016)

My words, not a quote from anywhere.


----------



## GeorgeG (Feb 15, 2016)

Juha Nurmela said:


> My words, not a quote from anywhere.


OK. It paints the picture pretty well. There are probably more possible combinations of hardware and software than there are 32-bit addresses, so they can't cover them all.


----------



## GeorgeG (Feb 22, 2016)

A last update, unless something else comes up or there are questions I can answer.

• I have Debian running on the box in question that spawned this thread.
• I have another box, also a Dell but a different model about a year older and some other differences, that was given to me by friends when they got a new PC. I have installed FreeBSD on that box without difficulty!

I came to try FreeBSD mostly on recommendations, including Randal Schwartz on his FLOSS Weekly podcast. In addition to the technical merits of FreeBSD, he often mentioned the great community surrounding FreeBSD.

He was absolutely right! Thank you for your generous support while I worked through this issue.


----------



## ab2k (Feb 24, 2016)

Hi,

1. you may try (if you have not done it ofc) to disable all raid things at boot loader - for that you have to boot a system and when a loader will show up just hit key "3" that corresponds to "Escape to loader Prompt" (suppose you are running FreeBSD 10.2 - on other version it may be an other key) and give it 2 commands:


```
set kern.geom.raid.enable=0
boot
```
and check for availability of your drive in installer or in shell `dmesg` command. If it will work - just add line below to /boot/loader.conf after you install the system or it will not boot.


```
kern.geom.raid.enable=0
```
2. if nothing have changed at step 1 and if the both Dell's having the same sized HDD (i mean size in inch) - can you try to change them between machines? and check for availability again...


----------



## GeorgeG (Feb 25, 2016)

What I did try was this: installed to a HDD in a USB dock. Installation successful. Took HDD out of USB dock and put on internal SATA. PC booted FreeBSD. However, during the boot process, at the point where root is dismounted and remounted, it was unable to re-mount root and crashed (panic). So, that confirmed that the PC was able to see the drive, boot from the drive, and proceed from there, but when FreeBSD loaded its driver for that controller, it could not see it. (This test was covered in an earlier post.)

I think tested the same thing that your suggestion #2 would test.


----------



## GeorgeG (Feb 25, 2016)

I just got an opportunity to try #1, and sadly it did not work. It yielded the same result, where the initial booting was successful but crashed when it tried to re-mount root.

Thanks again.


----------



## wblock@ (Feb 25, 2016)

There is no need to quote an entire message, especially when it is the one immediately preceding your response.  If you want to respond to a particular point, edit the quote down to just that point.


----------



## Jim Folts (Jun 25, 2016)

Thanks to all who posted here.  I ran into exactly the same problem and found this thread looking for an answer.  The answer seems to be that I have exactly the same machine as the original poster, so I too have decided to make it a Debian machine and find another piece of hardware to run FreeBSD.


----------

