New Install 10.2 "Partitioning Error"

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.
 
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
 
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.
 
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". :D
 
Code:
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
 
Code:
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
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...
 
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.

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.
 
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).
 
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.
 
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).
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...
 
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.
Code:
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?
 
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.
 
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
 
"Too exotic to fix" - how lucky! :D

Thank you, I would not have found that. So maybe it will be Debian for now on that box. :)
 
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. :)
 
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:

Code:
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.

Code:
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...
 
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.
 
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.
 
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.
 
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.
 
Back
Top