Travis Glenn Hansen

https://github.com/democratic-csi/democratic-csi/commit/4dd57c13bd72a593e3d02afd11b3848c28ee61f1 Wait for the build to finish here: https://github.com/democratic-csi/democratic-csi/actions/runs/1816103561 then update your containers to the current `next` image In the driver config block simply set the `csi` block as below...

Are you suggesting volumes quit working for the iscsi/nfs drivers? Or it’s a regression of just the zfs-local driver? I would expect the datasets to not appear (see discussion above...

I know it seems confusing but it's really not. By default zfs will mount dataset in a directory hierarchy that matches the zfs hierarchy, but this can be disabled (`mountpoint=legacy`)....

kubelet path seems to be the issue.. https://github.com/k3s-io/k3s/issues/840 https://github.com/democratic-csi/charts/blob/master/stable/democratic-csi/values.yaml#L208 EDIT: scratch that, it appears they changed the default...maybe it's different in SCALE though?

That is expected as the driver will not retroactively update all the shares currently (most of those settings are only used at creation time and are not altered post-creation even...

That’s fair. We can leave this ticket open but I won’t be able to work on it for a bit unfortunately. If somebody else gets ambitious this would be done...

That sounds really bad. It should be checking if the disk already has a fs on it an only run that if it doesn’t.

What version of the driver are you running?

OK, I can't reproduce locally (thankfully!, this would be a very nasty bug). So the logic behind that check is: Get the output from the following `lsblk` command (obviously replace...

My guess is you are not mounting the host `/dev` into the container `/dev` or similar (I would assume the device is actually there otherwise the `mkfs` would fail as...