- Thread Starter
- #26
the "files" under /dev are no real files, you cannot copy those from another installation.
it's not another installation,its the same,only a little bit older. So,the nodes under /dev are the same.
the "files" under /dev are no real files, you cannot copy those from another installation.
nevertheless those nodes simply are no files. you cannot copy them by any means.it's not another installation,its the same,only a little bit older. So,the nodes under /dev are the same.
that definitely looks like a problem
the devd subsystem I think is responsible for this, hot plug things like USB also creates nodes.the /dev nodes are created by the kernel during boot.
zfs set canmount=on zroot/usr
i don't know why it is like that and can't remember how i installed it but a clean install has indeed usr and var with canmount=offNot sure what's going on, but I believe that zroot/usr and zroot/var should be canmount=off.
The real usr directory is in the root filesystem (something like zroot/ROOT/whatever). That's what you should mount and modify. zroot/usr is a "placeholder" filesystem that should never be mounted and it exists solely for being able to create filesystem like zroot/usr/ports, zroot/user/src, etc.If you need to change the content of the usr directory while you are accessing the zpool from outside,you can do it,but when the modifications have been done,it should be set up again to off.
I resolved all my ZFS issues by using UFS instead
Well, in my case it does make sense because I only have one SSD, no partition redundancy or any other configuration that could make sense to use ZFS.
Sure ZFS also works but I had some bad experience with it and lost all my data twice because of something I don't know what I did or happened... and yes... it happened twice and because there was no redundancy maybe... yep that was it.
Yeah I was dumb enough to make the same mistake twice.
Someday I will give it another try but for now UFS seems quite stable to me.
So my point here in this post is does it really make sense to use ZFS in your configuration too?
Think about that.
I have played with the canmount property and I've set everything to on ?
This seems to be the real problem :
… I believe thatzroot/usr
andzroot/var
should becanmount=off
.
Not always, yes. Especially if you create your pool structure yourself.Not always, please see the manual page for bectl(8) (NB above, the current breakage of the online view for RELEASE).
# zfs list -r -o name,canmount,mounted,mountpoint rpool/ROOT
NAME CANMOUNT MOUNTED MOUNTPOINT
rpool/ROOT noauto no /rpool/ROOT
rpool/ROOT/2023-04-13 noauto yes /rpool/ROOT/2023-04-13
rpool/ROOT/2023-04-13/usr off no /rpool/ROOT/2023-04-13/usr
rpool/ROOT/2023-04-13/usr/compat noauto yes /rpool/ROOT/2023-04-13/usr/compat
rpool/ROOT/2023-04-13/usr/compat/linux noauto yes /rpool/ROOT/2023-04-13/usr/compat/linux
rpool/ROOT/2023-04-13/usr/lib off no /rpool/ROOT/2023-04-13/usr/lib
rpool/ROOT/2023-04-13/usr/lib/debug noauto yes /rpool/ROOT/2023-04-13/usr/lib/debug
rpool/ROOT/2023-04-13/usr/local noauto yes /rpool/ROOT/2023-04-13/usr/local
rpool/ROOT/2023-04-13/usr/local/etc noauto yes /rpool/ROOT/2023-04-13/usr/local/etc
Too much technical for me. …
… I have a habit of having /usr/local be a part of a BE, but also be a separate filesystem. …
It could be either. The script that's responsible for mounting subordinate filesystems ( rc.d/zfsbe) handles both cases.The mountpoint in your example puzzles me:
/rpool/ROOT/2023-04-13/usr/local
Should it not be /usr/local?