Can't load kernel after fresh install

T

tovo

Hi there,

I'm trying to install FreeBSD 9.1 from the memstick image. I have a Dell R720 with a PERC H710 RAID controller. The disk space is recognized (25[ ]TB) during the installation but the problem occurs on the first boot. I have the following error:
Code: 
gptboot: invalid backup GPT header
gptboot: No /boot/loader on 0:ad(0p2)
gptboot: No /boot/kernel/kernel on 0:ad(0p2)
I don't know if there is a relation but the disk was named mfid0 during the installation.

Any help is welcome. Thanks in advance.
 
Greetings,

While I haven't managed RAID for a while, and things may have changed, and I don't know the details of your hardware. I can say, that as memory serves, I needed to put the boot, and loader on a separate slice (partition) -- / (root). That way boot(8) could find, then load the necessary drivers, and configuration(s) to find, and manage the RAID, and everything on it. It might also be worth a look at loader(8), loader.conf(5), and the Handbook -- especially the sections 2. Installing FreeBSD 9.X and Later, 19. Storage, and 20. GEOM: Modular Disk Transformation Framework.

HTH

--cheis
 
tovo said:
I'm trying to install FreeBSD 9.1 from the memstick image. I have a Dell R720 with a PERC H710 RAID controller. The disk space is recognized (25 TB) during the installation but the problem occurs on the first boot. I have the following error:
Code: 
gptboot: invalid backup GPT header
gptboot: No /boot/loader on 0:ad(0p2)
gptboot: No /boot/kernel/kernel on 0:ad(0p2)
I don't know if there is a relation but the disk was named mfid0 during the installation.
Click to expand...

Not enough information: what kind of RAID is used? How are the disks arranged? What mode is the RAID controller using? The output of gpart show would be helpful.

gptboot: invalid backup GPT header means the backup GPT table at the end of the disk has been overwritten. That can happen with metadata from GEOM utilities like gmirror(8), but that would depend on how the disks are set up.
 
Thanks for the replies, here is more information:
  • RAID used is RAID5 (but, FreeBSD just sees one disk, here mfid0), all the disks are in one RAID volume.
  • The result of gpart show:
    Code: 
             34  54690578365  mfid0 GPT   (25T)
         34          128      1 freebsd-boot   (64k)
        162  53687091072      2 freebsd-ufs   (25T)
53687091072      8388608      3 freebsd-swap  (4.0G)
53695479842    995098557        - free -   (474G)
As I said, it's a fresh install and the issue occurs on the first reboot. I hope this information is enough but I'm always ready to tell more if necessary.

Thanks.
 
Hi again,

I was trying to solve it by myself but I can't. Well, FreeBSD is not supposed to see that there's a RAID system there (am I right?). If so, I wonder, what gmirror is doing here? At this time, I feel that I have a strong lack on the basis on how FreeBSD works. By the way, I did the guided partitioning during the installation and, isn't it supposed to work by default?

Thanks again.
 
gmirror(8) was mentioned just as an example of metadata conflicts. I have not used the mfi(4) RAID cards, but would have expected it to work as a single disk. The mailing lists probably have more users with those cards. Not sure which to recommend, but start with freebsd-questions.
 
wblock@ said:
I have not used the mfi(4) RAID cards, but would have expected it to work as a single disk. The mailing lists probably have more users with those cards. Not sure which to recommend, but start with freebsd-questions.
Click to expand...
The mfi(4) driver is quite well-behaved (better than mps(4) / mpt(4), in my opinion).

In the standard RAID modes on that card, the controller is /dev/mfi0 and the drive is mfid0. That assumes that there's one controller and one RAID volume, of course. I believe that you get a bunch of /dev/mfid# devices if you export the disks as JBOD. The controller keeps its metadata out of the area that it exposes to the host operating system. And if that data was being overwritten (for example, by an install trying to write past the end of the drive and getting away with it), the controller would complain about a "foreign configuration" on the next boot and ask you if you wanted to import it or not. Note that it is possible to write on areas the controller thinks it "owns" if you set hw.mfi.allow_cam_disk_passthrough, but I think it's safe to say the original poster didn't do that.

Since the original poster reports the error:
Code: 
gptboot: No /boot/loader on 0:ad(0p2)
I suspect a software configuration error rather than a driver / operating system problem. The mfi(4) driver doesn't know anything about ad(4) or ada(4) devices.

On a "classic" UFS installation of FreeBSD, I'd suspect either a wrong parameter passed to boot0cfg(8) or something extraneous in /boot/loader.conf. I don't know enough about gpart(8) to say what the equivalents are.
 
First check if the /etc/fstab on the installation uses the mfid or ad names. Secondly look into the boot order settings in BIOS, it's possible that the first device in boot order is not bootable and the 2nd bootable disk is used for booting.
 
fstab is fine:
Code: 
# Device          Mountpoint            FStype          Options     Dump  Pass#
/dev/mfid0p2      /                     ufs             rw          1     1
/dev/mfid0p2      none                  swap            sw          0     0
And the BIOS has been told to boot on this device (mfid0), that's probably why I have the boot prompt
Code: 
Boot:
because it's on the mfid0's MBR.
 
Since it's not getting even to loading /boot/loader, the /boot/loader.conf file is not read at all. Reading the boot(8) manual page there's mention of /boot.config file that could be used to change the path for loading loader(8). Maybe this could do the trick in /boot.config

Code: 
0:da(0,p2)/boot/loader

I changed ad to da because it means an SCSI type disk and the RAID card is surely equivalent to having an SCSI controller or similar and not an ATA controller. The manual page says that the allowed values are ad, da and fd.
 
kpa said:
I changed ad to da because it means an SCSI type disk and the RAID card is surely equivalent to having an SCSI controller or similar and not an ATA controller. The manual page says that the allowed values are ad, da and fd.
Click to expand...
That's a bug, possibly in the manpage. ada disks have been around for a long time, and mfid more recently.

I'm booting FreeBSD 8.4 on UFS2 from mfid0s1a without any magic in /boot/loader.conf or any /boot.config at all.
 
Terry_Kennedy said:
I'm booting FreeBSD 8.4 on UFS2 from mfid0s1a without any magic in /boot/loader.conf or any /boot.config at all.
Click to expand...

Really! I'm going to try to re-install 8.4. I'll tell you if it works or not. If it works, this means that we've a bug with sysinstall on 9.1.
 
Back again, I can't install the 8.4 version: after choosing the media installation, I have the following message:

Code: 
Unable to find device node for /dev/mfid0s1b in /dev!
The creation of filesystems will be aborted

I tried to do this trick set hw.pci.mcfg=1 but, it doesn't work at all.
 
Hi there,

I succeeded in installing the system and booting with it. Actually, I dropped the big RAID (26 TB) and built a new one with just 250 GB of space. But now, I'm facing a new problem with my network controllers. I have BroadCom BCM5720C ones and according to here, no luck for the moment.

Thanks again for helping me guys!
 
tovo said:
I succeeded in installing the system and booting with it. Actually, I dropped the big RAID (26 TB) and built a new one with just 250 GB of space. But now, I'm facing a new problem with my network controllers. I have BroadCom BCM5720C ones and according to here, no luck for the moment.
Click to expand...
Your best chance of attracting a developer is on the appropriate freebsd-listname@lists.freebsd.org mailing list. Second best is asking here, which may generate a reply of "go ask on the mailing list", depending on whether or not the developer in question is known to read these forums. Relying on external lists / forums may generate some user-to-user interaction, but is very unlikely you'll find the appropriate FreeBSD developer reading that particular external site.

Having said all that... @yongari@ committed fixes for the Dell x20 / Broadcom adapters to 8-STABLE 8 months ago as r243547 and to 9-STABLE as r243546.

The relevant part of the commit text is:

"With this change, bge(4) should work on any 5717/5718/5719/5720 controllers. Special thanks to Mike Hibler at Emulab who setup remote debugging on Dell R820. Without his help I couldn't be able to address several issues happened on Dell Rx20 systems. And many thanks to Broadcom for continuing to support FreeBSD!"
 
Last edited by a moderator:
Hi,

I've read the topics about Broadcom and FreeBSD here. @yongari@ didn't commit his fixes to 9.1 and I don't feel enough confident to recompile my kernel. I keep an eye on the situation but, right now, I need something to work. So, temporarly, I'm going to switch to a Linux distro because my colleagues are waiting for me.
 
Last edited by a moderator:
tovo said:
yongari@ didin't commit his fixes to 9.1 and I don't feel enough confident to recompile my kernel. I keep an eye on the situation but, right now, I need something to work. So, temporarly, I'm going to switch to a linux distro because my colleagues are waiting for me.
Click to expand...
There may be some confusion about the way FreeBSD releases work. Once a particular version is released, the only changes that get made are security fixes. For other bug fixes or enhancements, you need to track the relevant -STABLE branch. You can look here to see the commit history for 9.1. As you can see, 9.1 was branched 11 months ago, which is over 3 months before the bge fix made it into the source tree.

In addition, for some time before the official release there are various "freezes", after which only fixes deemed critical are made. This is so the developers don't have to chase a moving target while trying to get a release out the door.
 
You must log in or register to reply here.
Back
Top