How to automount a second zpool ?

[ajm]

Alternatively, is the pool to hostname/hostid association kept on the host (not the pool), and is that in zpool.cache ?

There seem to be two paths in use for this file, /boot/zfs/zpool.cache and /etc/zfs/zpool.cache.

On my host, the former path contains data only on zroot, the second one contains data on both zroot and the second pool. Maybe the wrong path is being used at boot ? !t seems a bit odd there are 2 different files with the same name...

PS. I just booted the host up into FreeBSD 13.0, and its the same there, two different files with the same name, the one under /boot only has the root pool data in it, the one under /etc has both.

[ajm]

After doing a couple of checks under FreeBSD 13.0, I exported the second pool 'tank', and shut the host down.

I then rebooted back into the OPN 22.1 with the patch. The second pool was imported OK at boot time.

I then ran:

Code Select Expand


root@a-fw:~ # zdb -U /etc/zfs/zpool.cache
tank:
    version: 5000
    name: 'tank'
    state: 0
    txg: 206460
    pool_guid: 3111308251436133108
    errata: 0
    hostname: ''
<snip>


The 'hostname is null.

I then exported the pool, reimported it, then checked again:

Code Select Expand


root@a-fw:~ # zpool export tank
root@a-fw:~ # zpool import tank
root@a-fw:~ # zdb -U /etc/zfs/zpool.cache
tank:
    version: 5000
    name: 'tank'
    state: 0
    txg: 206553
    pool_guid: 3111308251436133108
    errata: 0
    hostid: 3119175440
    hostname: 'a-fw.<domain redacted>'
<snip>


The 'hostname' is the FQDN.

I suppose this makes sense as in the first case the hostname has not yet been set when the filesystems are being mounted.

[franco]

Thanks for testing. This level of sanity checking seems a bit excessive within ZFS, but it is what it is.

Looking at some older tickets like https://github.com/openzfs/zfs/issues/2794 it looks like it could be the host id instead of the host name that is causing this. The file is under /etc/hostid and now understanding you are booting into FreeBSD from the same machine could cause this bouncing?

One approach to test would be to unify both files.


Cheers,
Franco

[cookiemonster]

The implementations I've seen scan both locations for the cache file, I think it is normal.
More pertinent is the default I've always seen is the zpool create leaves the 'hostname' property empty. We can see that on the zroot pool on a OPN zfs installation.
@ajm are you sure it wasn't added when creating it or after? Is it worth a test from fresh install, maybe on a vm?
I'm going to see if I can set one up myself.

[cookiemonster]

Update for myself.
Created a VM with 22.1 iso. Installed with zfs on root.

Code Select Expand

root@OPNsense:~ # zdb -U /boot/zfs/zpool.cache
zroot:
    version: 5000
    name: 'zroot'
    state: 0
    txg: 4
    pool_guid: 5855889087766899018
    errata: 0
    hostid: 350323563
    hostname: 'OPNsense.localdomain'
    com.delphix:has_per_vdev_zaps
    vdev_children: 1
    vdev_tree:
        type: 'root'
        id: 0
        guid: 5855889087766899018
        create_txg: 4
        children[0]:
            type: 'disk'
            id: 0
            guid: 7374185842686849048
            path: '/dev/ada0p3'
            whole_disk: 1
            metaslab_array: 67
            metaslab_shift: 28
            ashift: 12
            asize: 3109552128
            is_log: 0
            create_txg: 4
            com.delphix:vdev_zap_leaf: 65
            com.delphix:vdev_zap_top: 66
    features_for_read:
        com.delphix:hole_birth
        com.delphix:embedded_data
I need to create a second pool and verify if it also populates the hostname and edit this post.
Update with findings after adding a second pool:

Code Select Expand

root@OPNsense:~ # truncate -s 64M poolA
root@OPNsense:~ # ls
.cshrc .lesshst .profile .vimrc
.history .login .shrc poolA
root@OPNsense:~ # zpool create -m /tank tank /root/poolA
root@OPNsense:~ # zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
tank     48M   456K  47.6M        -         -     5%     0%  1.00x    ONLINE  -
zroot  2.75G  1.02G  1.73G        -         -     1%    37%  1.00x    ONLINE  -

root@OPNsense:~ # ls /etc/zfs/
compatibility.d/ zpool.cache 

taroot@OPNsense:~ # zdb -U /boot/zfs/zpool.cache
zroot:
    version: 5000
    name: 'zroot'
    state: 0
    txg: 4
    pool_guid: 5855889087766899018
    errata: 0
    hostid: 350323563
    hostname: 'OPNsense.localdomain'
    com.delphix:has_per_vdev_zaps
    vdev_children: 1
    vdev_tree:
        type: 'root'
        id: 0
        guid: 5855889087766899018
        create_txg: 4
        children[0]:
            type: 'disk'
            id: 0
            guid: 7374185842686849048
            path: '/dev/ada0p3'
            whole_disk: 1
            metaslab_array: 67
            metaslab_shift: 28
            ashift: 12
            asize: 3109552128
            is_log: 0
            create_txg: 4
            com.delphix:vdev_zap_leaf: 65
            com.delphix:vdev_zap_top: 66
    features_for_read:
        com.delphix:hole_birth
        com.delphix:embedded_data
root@OPNsense:~ # zdb -U /etc/zfs/
compatibility.d/ zpool.cache
root@OPNsense:~ # zdb -U /etc/zfs/zpool.cache
tank:
    version: 5000
    name: 'tank'
    state: 0
    txg: 4
    pool_guid: 379491550502733551
    errata: 0
    hostid: 350323563
    hostname: 'OPNsense.localdomain'
    com.delphix:has_per_vdev_zaps
    vdev_children: 1
    vdev_tree:
        type: 'root'
        id: 0
        guid: 379491550502733551
        create_txg: 4
        children[0]:
            type: 'file'
            id: 0
            guid: 12194019493862066782
            path: '/root/poolA'
            metaslab_array: 67
            metaslab_shift: 24
            ashift: 12
            asize: 62390272
            is_log: 0
            create_txg: 4
            com.delphix:vdev_zap_leaf: 65
            com.delphix:vdev_zap_top: 66
    features_for_read:
        com.delphix:hole_birth
        com.delphix:embedded_data
zroot:
    version: 5000
    name: 'zroot'
    state: 0
    txg: 248
    pool_guid: 5855889087766899018
    errata: 0
    hostname: ''
    com.delphix:has_per_vdev_zaps
    vdev_children: 1
    vdev_tree:
        type: 'root'
        id: 0
        guid: 5855889087766899018
        create_txg: 4
        children[0]:
            type: 'disk'
            id: 0
            guid: 7374185842686849048
            path: '/dev/ada0p3'
            whole_disk: 1
            metaslab_array: 67
            metaslab_shift: 28
            ashift: 12
            asize: 3109552128
            is_log: 0
            create_txg: 4
            com.delphix:vdev_zap_leaf: 65
            com.delphix:vdev_zap_top: 66
    features_for_read:
        com.delphix:hole_birth
        com.delphix:embedded_data
root@OPNsense:~ #



[franco]

In my installs I don't have "hostid" property in either cache file.

If this truly is the protection against importing a foreign pool it makes sense that it needs to be imported manually once and exported cleanly to get the native hostid for the current host embedded?

Or does it "sticky" to the hostid if the host where the pool was created?


Cheers,
Franco

[cookiemonster]

That's what has me scratching my head franco.
Default zroot pool from install: My live OPN doesn't have a "hostid" and "hostname" is empty.What I'm trying to do is try to verify if the current code works and so far this is an edge case. I'd be worried if OPN had to modify code that should just work and maybe a method of installation like convert from vanilla freebsd creates some odd artifacts like the second cache file.
I'm going open minded but in the hope that a clean installation will just work as intended.

On a test VM I just spun up both attributes "hostid" and "hostname" are populated. I haven't created the second pool yet.

[franco]

It's not probematic per-se, but the issue I see is that since we use the bsdinstall to install ZFS and the hostid isn't there even though we set /etc/hostid on the first boot even on the installer I'm not sure how this happens... maybe a hostid tool is used and doesn't return anything for install media?

At least for subsequent pools the hostid is set?


Cheers,
Franco

[cookiemonster]

I'm stumped. I've rebooted the test VM  with the second pool and that second pool is not mounted. Seems to confirm the report.

I am not sure the hostid and hostnames values or lack of them are a problem but all my little test seem to show is that the second pool appears in only one of the cache files but I'd be very surprised if that wasn't normal behaviour.
Feels like we need an opinion from someone with a better understanding of zfs.
Anything else you think I could do to diagnose more, just let me know.

[franco]

Looking up https://serverfault.com/questions/954479/always-do-zpool-export-for-easier-and-or-more-reliable-recovery maybe this is solely due to missing manual export?

From what I can tell the installer on FreeBSD (and therefor for us regarding ZFS) exports its pool at the end of the installation. We do the same for our ZFS image support recently added to tools which we have tested without an issue.

From what I can find WRT FreeBSD rc scripting it never exports its pools so that would point to the same conclusion?

I'd think import -f manually should do the trick. If not export is worth an additional try but then it simply must work?


Cheers,
Franco

[cookiemonster]

Exactly. If vanilla FreeBSD rc does not export it as part of the shutdwon sequence, then a -f would be required.
But that led to the initial report that errored and suspected hostid or hostnname, no?
I think I need to pull in your patch to my test VM and try, right?

[franco]

Yes, that would help.


Cheers,
Franco

[cookiemonster]

I've done the patching, followed by reboot and unfortunately the second pool did not get mounted/imported.
No errors I can see in dmesg or /var/log/system/{date}.log
The same behaviour though,

Code Select Expand

zpool import with any option aka -Na or -f fail with "no pools to import" or similar (have had to connect and disconnect from VPNs thorughout the day).

What I'm unable due to time is to follow my gut. The zfs cache files are the same and I think the problem is with devices labels but can't confirm due to time. I think we should log as issue to investigate via github.

[ajm]

Thanks guys.
Sorry I've not been able to put more time into it, due to things 'IRL'.

[Fratzba]

I know this is an older thread, but unsettled.

I was having the exact same problem, after adding a second SSd to my system (protectli 6wd).

I had created/ recreated, imported, etc...  It was at the point where if I imported it manually after booting it worked, but after rebooting it was not mounted.

What I did that appears to have fixed the issue is (the name of my pool is ext)

## Import the pool
$ sudo zpool import ext

## Verify that it's there
$ df -kh /ext
Filesystem    Size    Used   Avail Capacity  Mounted on
ext           430G    104K    430G     0%    /ext

And then manually exported it
$ sudo zpool  export ext

And then rebooted.  It's been automatically mounting ever since.

My best guess is that since the pool wasn't mounted by the boot process, that when the system reboots it doesn't cleanly shut it down.

YMMV, but hey, if it works...

Fratz