SCALE 22.02.0.1 - import pools on boot hangs

That is correct. I deleted the datasets on stank/local_backups. The boot process now takes a reasonable amount of time (about 90 seconds). I now have an issue where the apps subsystem won't start up properly on boot (see my comments from 25 March).

can you please confirm if you delete the backed up dataset of ix-applications/docker, does the importing pool works fine and not time out after 15min?

Here is my setup for pools, snapshots, and replications:

I have three pools:

• apps: (2x SSD in Mirror) - this is the system pool, the Apps pool and the VM pool (all in different datasets)

• tank: (4x HDD in RAIDZ1) - this is where all of my "permanent" data lives (media, documents, etc.)

• stank: (4x HDD in RAIDZ1) - this is my "scratch" pool for temporary files, backups, time machine for my Macs, etc.

I have set up snapshot/replication tasks as follows:

• apps/vm/Homeseer_xxxxx: local replication to stank/local_backups/vm_Homeseer (Windows VM)

• apps/ix-applications: local replication to stank/local_backups/apps_ix-applications (the standard dataset created by SCALE for apps)

• apps/app_data: local replication to stank/local_backups/apps_app-data (dataset I created for all my hostpath storage for apps)

As for the ix-applications replication specifically, see the below screenshot.

can you please share where you are replicating your ix-applications dataset if you are replicating it(by where i mean which pool, if you can share the details about that replication task - that would be best)? It seems we have seen this bug before already and this might be a duplicate..

By using the following incantation, I am able to get my apps to start. This does not survive a reboot though, so I still need some help figuring this out.

zfs set mountpoint=legacy apps/ix-applications/k3s/kubelet
mount -t zfs apps/ix-applications/k3s/kubelet /var/lib/kubelet
zfs set mountpoint=legacy $(zfs list -o name | grep ix-applications | grep pvc)
midclt call service.stop kubernetes
midclt call service.start kubernetes

This was put together from various sources including (restarting k8s), (remounting PVCs), (figuring mountpoint=legacy could apply to /var/lib/kubelet since that's the error I was getting in middleware.log)