FreeBSD 9 installs but won't boot

I have installed FreeBSD hundreds of times and never had this happen.

I install v9 use guided/auto partitioning and every time I get the following (see attached screenshot). I have formatted the drive both high level and low level and same thing happens every time.
 

Attachments

  • IMG_0776.jpg
    IMG_0776.jpg
    92.8 KB · Views: 1,138
Details like the type of disk, the interface, the controller, and the partitions. What did you use to format it?

The message is that the backup GPT partition table at the end of the drive is bad. This can happen with some RAID configurations.
 
It's an older laptop. Compaq Evo 610c

IDE drive, no RAID. I used AUTO so whatever auto chooses to format it and partition it. I am not up to speed on this new GPT stuff, but I never had issues the old way on this same laptop. Windows and Linux have no issues running on this machine/drive.
 
I've had this happen on a couple of machines now. It seems to be an issue with FreeBSD 9.0 only, previous versions don't seem to have the problem on the same hardware. There are a bunch of threads on this forum and the PC-BSD forum addressing the issue. So far I don't think anyone has come up with a working solution.
 
Is there any way to use the old installer to install v9? Also how feasible would it be to isntall v8 and upgrade to v9 via freebsd-update?
 
Careful, there can be more than one cause for this problem. The second line of the error is
Code:
gptboot: error 1 lba 292495842

See this post about creating an MBR layout. It's not clear what the problem is with that sector. Could be that the drive reports an off-by-one size, or something the controller does. Either way, it would not hurt to make the /usr partition slightly smaller than space available. 1K would be enough, 1M is probably easier to figure out.
 
Just an update: Using the FreeBSD 9 again, I did a manual partition and this time made FreeBSD instead of GPT and made a slice under that as "/" (just to keep it easy) and this time the system boots without issue. Clearly there is a problem with the GPT code as it's not reliable on all drives/systems.
 
It could be the gptboot loader, but could also be the BIOS, or drive firmware, or the controller. GPT uses the very last sectors of the drive, which may not have been used before.
 
Whatever the reason, it doesn't matter. It should be smart enough to figure it out and work. You can't expect users to know (oh yeah the boot code doesn't like the last sector, let me back it off, blah blah)

By the handful of posts on this forum and PCBSD, it's happening enough to be a bug or broken and needs to be looked at.
 
The problem is usually that the boot loader is never even executed because the BIOS code locks up (or does something else that prevents boot) before handing off the boot to the boot loader when it finds something unexpected in the MBR or partition table. There's nothing to be done in those cases other than contacting the vendor and ask for a BIOS update to fix the issue.


FYI a GPT partitioned disk that is bootable on a standard PC is actually both GPT and MBR, the GPT part is hidden inside a protective MBR partition that covers the whole disk, that's what the /boot/pmbr is all about. This protective MBR is also a boot loader that passes the boot to the GPT partitioned part of the disk. This is all designed to make a bootable GPT appear as standard MBR partitioned disk to a BIOS that does not understand GPT partitioning. Assuming that the BIOS makes no assumptions on what's really on the disk this mechanism works perfectly because all the BIOS has to do is to load the boot loader and pass the control to it.

I have one such machine that refuses to boot from a GPT disk, thankfully it's only an issue when booting from USB. The same disk boots absolutely fine on my other machines.
 
You can try to justify it however you want. All I know is that windows works, linux works, and solaris works on this machine. FreeBSD v9 (auto) doesn't which means it's broken. You really expect a user to jump through hoops even just to boot the OS?
 
Windows (what version?) with GPT worked? Linux with GPT worked? Solaris with GPT also worked? That would be useful information, and could lead to locating a problem with FreeBSD's gptboot (if there is one). More likely those were all with MBR.
 
Windows xp and 7, Solaris 11 Express, Fedora, Ubuntu, OpenSuse, Debian, etc.

I don't know if they were using GPT as I (and your average user) picks a drive and expects the OS to be smart enough to do what it needs to do.
 
Confirmed

wblock@ said:
Windows (what version?) with GPT worked? Linux with GPT worked? Solaris with GPT also worked? That would be useful information, and could lead to locating a problem with FreeBSD's gptboot (if there is one). More likely those were all with MBR.

In my case both machines would run Windows XP (MBR) and Fedora (GPT) and Ubuntu (MBR), but locked up when I installed FreeBSD 9.0. I tried installing FreeBSD using both MBR and GPT, in both cases the machine locks up on the POST screen. It's definitely a FreeBSD issue.
 
If you're confident it's a FreeBSD problem, please enter a PR. Be as specific as possible.

Peedy: XP does not support GPT. As far as the installer being able to determine if an individual machine can handle GPT: short of coming up with a list of all the machines that can't handle GPT, I don't know how that could be determined. As kpa explained above, a GPT layout has a bootable MBR at the start.

NewGuy: Since your machine didn't boot either with GPT or MBR, this is not the same problem, and not a GPT problem. Could be any of a bunch of things: controller, BIOS, ACPI, many more.
 
I compared the GPT disks made by both Fedora 16 and FreeBSD 9 using VirtualBox. These outputs are from the Linux fdisk. There is not much difference but one thing stands out, the FreeBSD disk has number of heads set to 256 in the protective MBR (the embedded partition table) and the Fedora one has number of heads set to 255. As far as I know 256 is legal value (the values can be 0-255) but it's possible that some BIOSes consider that invalid for some obscure compatibility reasons. This may be something worth reporting to FreeBSD developers. I might write a bug report myself if I find the time.

The other difference is the lack of an active partition flag in the Fedora disk but I don't think that's crucial, one would expect that the FreeBSD disk would be more compatible because an active MBR partition is usually required for a disk to be bootable.

This first one is the Fedora 16 GPT disk:
Code:
Disk /dev/sda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders, total 16777216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1    16777215     8388607+  ee  GPT

And this is the FreeBSD 9 GPT disk:
Code:
Disk /dev/sdb: 17.2 GB, 17179869184 bytes
256 heads, 63 sectors/track, 2080 cylinders, total 33554432 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1    33554431    16777215+  ee  GPT
 
Where is it getting the disk size? That should be from a device inquiry, but if it was, the drive that was set up on FreeBSD would also show 255 heads on Linux. Is it using values from the partition table? (But what would it do if the partitions had different numbers of heads?)
 
I did a hex dump of the protective MBRs from both disks and it turns out that the real difference between the two is in the area where the head/sector/cylinder (normally called CHS values but that's the order they are stored in the partition table) values of the first sector of a partition are stored. The values clearly don't match on the FreeBSD disk, the LBA information claims start sector 1 and the other values claim start sector 2. These values should be ignored if the BIOS supports LBA addressing but who knows if they are required to match the LBA information by some BIOSes...

I actually saw the same difference in the output of FreeBSD fdisk(8) but I didn't trust it so looked at the hex dumps to be sure.

The FreeBSD disk has this information for the protective MBR partition:
Code:
head/sector/cylinder of the first sector: 0/2/0
head/sector/cylinder of the last sector: 255/63/1023
LBA of the first sector: 1
LBA sectors in the partition:  33554431


And the Fedora disk has this information:
Code:
head/sector/cylinder of the first sector: 0/1/0
head/sector/cylinder of the last sector: 254/63/1023
LBA of the first sector: 1
LBA sectors in the partition: 16777215

I have no idea why Linux fdisk claimed 256 heads on the FreeBSD disk, it's probably wrong...

I'm not sure if the geometry that is probed by the kernel is actually stored anywhere on the disk when a partition table is initialized or partitions are created/modified. The FreeBSD fdisk(8) manual page claims that the geometry is extracted from something called "in-core disklabel", anyone have an idea what that might refer to?


Edit: Considering that LBA addresses start from 0 the FreeBSD pbmr is actually correct, the sector numbers in the CHS numbers start from 1 so head 0, sector 2, cylinder 0 translates to LBA address 1. The Linux one is incorrect because the CHS numbers claim that the partition starts from LBA 0 but the LBA information claims start sector LBA 1.

All I can say is BIOS sucks..
 
Linux may do what it does for compatibility. It would be interesting to take a system that boots the Linux PMBR but not the FreeBSD PMBR, edit the FreeBSD partition table to match the Linux version, and see if the FreeBSD gtpboot code can handle it.
 
It gets even weirder when a real hard disk is used instead of VBox virtual hd, for some reason the beginning of the protective MBR partition is shifted to LBA 63. This is a 2.5" 500GB SATA disk in an USB enclosure. The good thing is that this disk actually boots on my firewall/router machine. All my previous attempts (I think the last time I tried was with 8-STABLE from few months ago) at creating a bootable GPT disk that is connected with USB resulted in lock up during POST.

Code:
******* Working on device /dev/da0 *******
parameters extracted from in-core disklabel are:
cylinders=60801 heads=255 sectors/track=63 (16065 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=60801 heads=255 sectors/track=63 (16065 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 238 (0xee),(EFI GPT)
    start 63, size 976768002 (476937 Meg), flag 80 (active)
	beg: cyl 0/ head 1/ sector 1;
	end: cyl 384/ head 254/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

Guess I have to start reading the gpart(8) source code to make sense of all this :p
 
Back
Top