# No bootpool FreeBSD-12.0-RELEASE install



## byrnejb (May 24, 2019)

I just installed 12.0 on a new host with new discs.  The install went fine but the system will not boot because:

gptfsboot: No ZFS pools found, can't boot

I have booted into single user mode from the install stick.  How do I mount bootpool so that the boot-loader finds it when I reboot?

camcontrol devlist shows the drives:


```
TEAC DV-20E-V 1.AB>            at scbus0 target 0 lun 0 (cd0,pass0)
<WDC WD80EFAX-68KNB0 81.00A81> at scbus1 target 0 lun 0 (pass1,ada0)
<WDC WD80EFAX-68KNB0 81.00A81> at scbus2 target 0 lun 0 (pass2,ada1)
<WDC WD80EFAX-68KNB0 81.00A81> at scbus3 target 0 lun 0 (pass3,ada2)
<WDC WD80EFAX-68KNB0 81.00A81> at scbus4 target 0 lun 0 (pass4,ada3)
<Kingston DataTraveler 2.0 PMAP> at scbus7 target 0 lun 0 (da0,pass5)
```

gpart shows all the drives partitioned.  zpool import shows nothing.

gpart shows that all drives have 3 partitions with the types: freebsd-boot, freebsd-swap, and freebsd-zfs for partitions 1,2, and 3 respectively


----------



## SirDice (May 28, 2019)

You're seeing a message from gptzfsboot(8) (which is read from the freebsd-boot partition) so something is booting. But it looks like something went amiss with ZFS. Even if it fails to boot you would still be able to import the pool. 

Does `zdb -l /dev/ada0p3` output anything interesting? Speaking of which, how did you configure ZFS to use the available disks? Striped, RAID, mirror?


----------



## byrnejb (May 28, 2019)

```
LABEL 0
------------
Failed to unpack label 0
.  .  .
```

Allan Jude suggested that:


> I am guessing your issue is that you do not have the 'GELI Boot' flag set on your encrypted partitions, so you are not being prompted to decrypt them in the loader.
> 
> Try: geli configure -g /dev/disk-partition-here



So I am going to try this, but first I need to determine which partition on which drives.  I lack the knowledge to be certain how this advice is applied in my specific case.  Intuitively I believe that this has to be done to the boot partition on each drive but this could equally be applied to the zfs partition.  So, I will try the boot approach first and if that does not work then I will try it on the zfs partitions.

I would like to know why this happened though.  There was nothing amiss reported throughout the guided zfs install.  The host just would not start.


----------



## SirDice (May 28, 2019)

If I recall correctly an encrypted ZFS install would have a small unencrypted ZFS pool to boot from. Looking at your installation (freebsd-boot, freebsd-swap and one freebsd-zfs partition) I doubt you have an encrypted setup. 

Which begs the question, what kind of ZFS install did you chose? Raid? Mirror? Stripped?


----------



## zirias@ (May 28, 2019)

SirDice said:


> If I recall correctly an encrypted ZFS install would have a small unencrypted ZFS pool to boot from.


That's no longer necessary since the boot code handles encryption -- you'll get a passphrase prompt before the bootloader.


----------



## SirDice (May 28, 2019)

Zirias said:


> That's no longer necessary since the boot code handles encryption


Isn't that the case with EFI boot? I mean where does it load loader(8) from?


----------



## zirias@ (May 28, 2019)

SirDice said:


> Isn't that the case with EFI boot? I mean where does it load loader(8) from?


I have two systems here booting from MBR (which, IIRC, contains `gptzfsboot`) from a fully encrypted disk, so this bootcode can decrypt GELI for loading `loader`. My machine with EFI boot indeed uses an unencrypted "bootpool", but that's only the case because I installed it before FreeBSD bootcode could use GELI, so I think nowadays, on an encrypted EFI system, the only partition that needs to be unencrypted is the efi partition itself.

Another guess I don't have the time to verify now: the "GELI Boot" flag talked about in this thread is necessary so the boot code (MBR or EFI) knows it has to decrypt in order to load `loader`.


----------



## byrnejb (May 28, 2019)

> Which begs the question, what kind of ZFS install did you chose? Raid? Mirror? Stripped?​



FreeBSD was installed as raidz2 on four 8Tb hdds using the guided ZFS install wizzard.   Root on ZFS was selected together with encryption and encrypted swap.  Perhaps zoot on zfs with encryption is not a good idea?  Although, raidz2 with root on encrypted zfs has worked for me in 10.2.


----------



## byrnejb (May 28, 2019)

`geli configure -g /dev/ada0p1 through /dev/ada3p3` all give the same result: '*class not found*'


----------



## byrnejb (May 28, 2019)

I occurs to me that I did not make it clear that I am booting the system from the install usb flash drive and dropping into the shell from there.  I cannot obtain a shell when I boot from the hdds.


----------



## byrnejb (May 29, 2019)

Further investigation led me to this thread https://forums.freebsd.org/threads/10-1-installation-with-mbr-fails-to-boot.49045/ which may apply in our case. I am attempting to recycle an old Supermicro server 6015-B. By fiddling with the BIOS I have changed the boot error from gptfsboot: 





> No ZFS pools found, can't boot


 to 





> Operating system not found


.

I reinstalled FreeBSD and chose the MBR option.  This likewise gives 





> Operating system not found


 when rebooting from the hdds.


----------



## byrnejb (May 30, 2019)

I believe that the problem is that the motherboard of the server in question (X7DBU) does not support UEFI and so it cannot boot from GPT disks larger than 1.4Tb or so.  However, the drives are SATA so there is no problem in accessing the larger disks, we just cannot boot from them.

The alternative that comes to mind is to install FreeBSD-12 on a USB flash drive ~80-256Gb, boot from that, and create the zpool from the four caged 8Tb drives.  The system has three internal USV 'heads' and two external USB ports.  From my experience with DELL servers I infer that the UBB boot drive is best installed inside the chassis.  

Is that a workable option?


----------



## SirDice (May 31, 2019)

byrnejb said:


> I believe that the problem is that the motherboard of the server in question (X7DBU) does not support UEFI and so it cannot boot from GPT disks larger than 1.4Tb or so.


As far as I know such a limitation never existed. Where did you get this from? There is a 2TB limitation but that's the maximum size of a MBR partition and this has nothing to do with booting.


----------



## byrnejb (May 31, 2019)

> As far as I know such a limitation never existed. Where did you get this from? There is a 2TB limitation but that's the maximum size of a MBR partition and this has nothing to do with booting.





> BIOS will be your stumbling point. MBR-style boot reads the first sector of the first hard drive. For a 3TB drive, that first sector is likely to be 4KB, and not 512b like it has been since the dawn of PC computing. If BIOS isn't set up to deal with that, it simply will not boot. An updated BIOS will be required to handle it, if such is even available.
> That said, if the BIOS can handle a 4KB sector size, or is actually counting on an EFI BIOS and still has 512b sectors (don't know if this critter even exists), it should boot.


https://serverfault.com/questions/259337/using-3tb-hdd-as-boot-drive-on-non-efi-bios

Is it possible to create or emulate a 512b MBR partition on a 4K sector drive?


----------



## byrnejb (May 31, 2019)

Apparently this problem is caused by some setting in the BISO.  I say some because the way that I corrected this was by resetting the BIOS to default before starting the next iteration of tests.  And the install worked thereafter.


----------

