Solved Cannot find ZFS bootpool, EFI panic

After customizing loader.conf, the EFI loader couldn't boot the system. Furthermore, I tried to do some rescuing with memstick installer, after that EFI doesn't see the boot(pool) pool.

There's got to be a way to recover from this.
 
So it stopped working after you changed something in loader.conf? What did you change?
 
Well, I only added. Stuff from my other installation, things like fuse_load, beastie_disable, etc.

But I also re-arranged stuff, because I wanted to cluster together module loads, module options and boot tuners.

Does the order matter?
 
Shouldn't be much of an issue, but then again I'm not well experienced with UEFI.

But when you said it doesn't boot, what exactly does or doesn't happen? I mean, do you get the boot menu at all? If so; what happens if you hit escape (to get the ok> prompt) and then issue the lsdev command? Does that show anything?

I'm not much of a fan of the memstick environment (because it provides few tools to work with) but if you boot using a rescue environment (my choice would be the disc1 ISO image) then what happens if you run # gpart show or # zpool import?

If those last 2 commands actually show reasonable output then this situation might be easily solvable by editing loader.conf again.
 
Shouldn't be much of an issue, but then again I'm not well experienced with UEFI.

But when you said it doesn't boot, what exactly does or doesn't happen? I mean, do you get the boot menu at all? If so; what happens if you hit escape (to get the ok> prompt) and then issue the lsdev command? Does that show anything?

First, it got stuck at loader.conf. After attempted rescue, it panics. In both cases, loader.efi is recognized.


I'm not much of a fan of the memstick environment (because it provides few tools to work with) but if you boot using a rescue environment (my choice would be the disc1 ISO image) then what happens if you run # gpart show or # zpool import?

If those last 2 commands actually show reasonable output then this situation might be easily solvable by editing loader.conf again.


gpart show shows reasonable output.

However, zpool import outputs no pools available to import.
zpool list shows HEALTH->UNAVAIL for both bootpool and zroot
 
None of the zpool commands work.
EFI says [I]no ZFS pools[/I].
zpool says pools "UNAVAIL".
EFI loader shows up, but panic.
zpool status says
status: [I]One or more devices could not be opened. There are insufficient replicas for the pools to continue functioning.[/I]
action: [I]Attach the missing device and online it using 'zpool online'[/I]



Code:
NAME                    STATE        READ WRITE CKSUM
bootpool                UNAVAIL           0     0       0
  12798312938724987234    UNAVAIL           0     0       0 was /dev/ada0p2


  • I am using a signel disk (striped, probably no RAID controllers)
  • This is a laptop. No device hot plugging except usb's
  • ... which is why "device missing" is impossible
System bricked.
 
I'm not much of a fan of the memstick environment (because it provides few tools to work with) but if you boot using a rescue environment (my choice would be the disc1 ISO image)



By the way, what is the difference between choosing a SHELL and Live CD, as far as rescue options go?
 
By the way, what is the difference between choosing a SHELL and Live CD, as far as rescue options go?
Not that much, it mostly boils down to having more tools and information (manual pages) at your disposal. So if you're doing a rescue operation you'll also have full network support at your disposal.
 
Thanks for the answers, appreciate it. Trying to learn ZFS. Any on-topic advice? I would like to try any approach, and get to the bottom of this problem, short of re-installing the system.

If I need a hammer, or a screwdriver, I have them at hand.

There is no OS like FreeBSD, and some of my first potential IT salary will definitely go to the FreeBSD foundation. No sucking up, for real. I donated one euro to the blender foundation, my other favorite donatable effort.
 
So it stopped working after you changed something in loader.conf? What did you change?

This seems to be the crux of the problem. I am well aware of the importance of loader.conf, so I take good care of not messing it up. But tuning it might have been the original problem.

The other thinking path is: do I need both BIOS encrpytion and geli encryption? Do they collide? How does ZFS behave if you start a live memstick without unlocking the hard disk? That could be one of the reasons.

Knowing that I haven't touched gpart, I believe zfs is fool-proof enough for these kinds of problem. And I'm also of the sort of people that think that real problems only start when you've already solved the easy ones.
 
Thanks for the answers, appreciate it. Trying to learn ZFS. Any on-topic advice? I would like to try any approach, and get to the bottom of this problem, short of re-installing the system.
Unfortunately no. My problem is that I have very little experience with UEFI and from what I do know that setup also provides the whole BIOS for a PC. Which makes it hard to determine a cause. I could imagine this caused by either a mismatched or not working drivers, or something more drastic such as a possible pool corruption.

But the error message stating that it somehow "lost" a slice makes me think in the direction of drivers.

However, that's also where my lack of experience on this subject comes into play.

(edit)

What I would suggest though is possibly consider moving away from ZFS in favor of UFS. ZFS is an awesome filesystem but at its best when used with multiple disks. Also noteworthy is that it's pretty resource intensive, partly due to what it is. So on a laptop with only a single disk I would definitely favor a setup with UFS over ZFS myself. At the very least it'll be less resource intensive and considering the environment I don't think you'll lose out on too much functionality.
 
The other thinking path is: do I need both BIOS encrpytion and geli encryption? Do they collide? How does ZFS behave if you start a live memstick without unlocking the hard disk?
Please explain what you have been doing about encryption. Your comments sound like the harddisk itself is encrypted (that exists, they're called SED or self-encrypting drives), and the harddisk needs to be unlocked. You'll need to tell us what is going on.

Here would be a good starting point: My system is a FooBar model 1234, it uses a Soandso BIOS. I have two hard-disks, the first one is a SSD that I boot from and that contains the root file system, the second one is a SeaTachi model AB-987. Each disk has only one partition. I installed them using XFS, YFS and ZFS. I have hardware encyrbbtion enabled on the second disk, and usually I type the key into the BIOS window when I boot. I'm not going to tell you my secret key, but it is definitely not "password". I'm running FreeBSD version 3.14.159. After I modified loader.conf, the BIOS still boots, but it doesn't ask me for my password, it instead asks "what is the airspeed of an unladen swallow". Independent of whether I enter "european" or "african", it starts FreeBSD (I see the beastie logo), and then it complains "insufficient number of moose (mouses?) found on disk, please call the rat-catcher of Hamelin". Here is a cell-phone picture of the exact error message: (imagine slightly indecent selfie of you, with the monitor in the background, wearing socks with unmatched color).

This is the kind of level of detail that might help the community debug your problem; I fear that we don't really understand yet what's going on. Your most recent comments about missing slices and encryption make me worry that there is more to the story than we know.
 
OK.
The machine is by [FONT=Arial]hp[/FONT] Notebook 250 G6.
The BIOS is InsydeH2O UEFI F.24
One integrated WD 500GB 5400 HD ( I am planning on having a home partition moved to a Buffalo USB2.0 external HD later on )

Partitioning is bsdinstall's autopartitioning as RootOnZFS, choosing

* striped configuration, using the whole disk,
* encryption on both the "disk" and "swap",
* swap is 6G, because RAM is 4G. (DDR4)
* booting scheme chosen was GPT ( UEFI )
* mirroring is off

BIOS security options:

* admin pass := set
* poweron pass := set
* TPM device := available
* TPM state := enabled
* clear TPM := no
* Intel SGX := software controlled
* DriveLock pass := set
* MBR and GPT saving to flash := enabled

HD has to be unlocked with a pass after a poweroff, i.e., bsdinstall won't find it if it's not unlocked.
There's the power-on password as well, it always comes up.

After that, normally, FreeBSD EFI boot text shows up (that one before the ASCII logo).
It is supposed to be the loader.efi() stage, I think.
It usually says that it found ZFS pools,
loads loader.conf(), then asks for the geli() password.

Then the beastie logo menu appears (I switch it off usually).

After editing loader.conf(), the EFI loader got stuck at loading loader.conf (the spinning thingie stops after like 2-3 "rotations".
No ZFS pools found. If there is a FreeBSD memstick inserted it will load that even if I tell it to boot from the hard drive.

That's all I could think of.

EDIT

The chipset should be Intel Skylake powerd by i3 6th gen 1x2x2 CPU architecture.

EDIT2

The partitioning scheme ended up like this, as reported by gpart:

ada0 1 EFI 200M - free 1M 2 freebsd-zfs 2G 3 freebsd-swap 6G 4 freebsd-zfs the rest of G's - free 4K (the bsdinstall option 4K per sector was selected)
 
Thank you for the detail! So you seem to have a poweron password, and a drivelock password. I think (but I'm not 100% sure) that this means that the disk itself is hardware-encrypted (a SED = self encrypting drive), and the BIOS drivelock password encrypts the disk.

Everything else looks sensible, everything is configured for UEFI and GPT, which all makes sense.

On top of that, you do have FreeBSD-level encryption. We could now argue whether it is sensible to have two layers of encryption, but this is not a good time to have that argument, first your machine needs to start working again.

Here is my only suggestion: I suspect the problem is one of the two encryption layers. Boot again from a memstick. Then use gpart to show the partition table on your disk. If that works, and gives reasonable answers, then the BIOS hardware encryption has been correctly unlocked. Next step: Find the partition that is supposed to be the ZFS volume in the gpart output, and run the command zdb -l on it (example: "zdb -l /dev/adaXpY", for suitable values of X and Y, probably ada0p2 judging from your old ). That should show that this partition contains a ZFS volume, and will tell you many details about it. If that completely fails, then perhaps the partition or disk is still encrypted. Here is for fun the start of the zdb output for one of my partitions, to give you a flavor (it goes on for >100 lines):
Code:
# zdb -l /dev/ada3p9
--------------------------------------------
LABEL 0
--------------------------------------------
    version: 5000
    name: 'macbackup'
    state: 0
    txg: 6035078
    pool_guid: 8337558203742914770
    hostid: 4194647577
    hostname: 'house.lr.los-gatos.ca.us'
    top_guid: 16009679047817592512
    guid: 16009679047817592512
    vdev_children: 1
    vdev_tree:
        type: 'disk'
        id: 0
        guid: 16009679047817592512
        path: '/dev/gpt/hd16_macbackup'
        ...
 
Thanks for the answer, but it was way beyond me. I didn't mentioned I played with some zpool commands. To anyone who is reading this, n o t a g o o d i d e a. I actually tried to make a diagram for myself for the way ZFS works, but it's totally alien to anything I know.

So ZFS pools hardware resources and makes it available to a file system (ZFS?), but it needs an unencrypted boot part... oops, no partitions here. It's another pool, right? But it is on a separate partition (slice), and then you also have the EFI slice, and the swap slice. The only thing that is included in fstab is the swap slice, so ZFS basically doesn't use fstab, but you can actually mix'n'match datasets and mountpoints. (?) And it all resides on a GPT disk, but that can actually be an array of disks. And the boot pool contains a ZFS file system, and the root pool contains a ZFS file system, onto which you can mount non-ZFS file system. That's what she said, anywaaay... Anyway, I'm locked in to Windows because I do professional music production in Ableton Live, so I put the Beastie into a little box they call Virtual, thanks to now being a proud owner of a VX-D hardware.
 
Back
Top