Fist of all a bit of context, I'm using Project Trident and it has this cool feature:
All user home directories are encrypted out of box. The individual user directories are only “unlocked” and decrypted when that user logs in to the system. Logging out or rebooting the system automatically locks home directories.
So when you enable 66 boot-user@ user it doesn't start at next boot
doas 66-intree -zg users-session                                                                                                                                                  5.7s

Name         : users-session
Initialized  : yes
Enabled      : yes
Starts after : root
Current      : no
Allowed      : root
Symlinks     : svc->source db->source
Contents     : /
               |-(down,Enabled,oneshot) setenv@ gspe
               |-(1540,Enabled,longrun) svscan@ gspe-log
               |-(0,Enabled,longrun) svscan@ gspe
               |-(down,Enabled,module) scandir@ gspe
               |-(down,Enabled,oneshot) mount-run@ gspe
               |-(down,Enabled,module) boot-user@ gspe
               |-(1542,Enabled,longrun) dbus-log
               |-(1550,Enabled,longrun) dbus
               |-(1541,Enabled,longrun) sddm-log
               `-(1563,Enabled,longrun) sddm
If we look at logs: 
cat /run/66/log/0/current
....
2020-12-12 09:28:14.627148268  all-Runtime: info: starts...
2020-12-12 09:28:14.654640073  execl-toc: fatal: unable to create dir: /usr/home/gspe/.local/66/conf/svscan@ gspe: Permission denied
2020-12-12 09:28:14.670061297  66-start: fatal: unable to start services selection
2020-12-12 09:28:14.670122291  66-all: fatal: unable to start services of tree: users-session
2020-12-12 09:28:14.670977755  all-Runtime: fatal: crashed! -- Your machine is operational but some runtime service failed to start correctly. Please see the complete boot log at /run/66/log/0/current for further information.
we can see that it fail to create a dir inside user home.

After user login if we restart users-session tree 
doas 66-all -v 4 -t users-session up
...

doas 66-intree -zg users-session                                                                                                                                                    3942ms
Name         : users-session
Initialized  : yes
Enabled      : yes
Starts after : root
Current      : no
Allowed      : root
Symlinks     : svc->source db->source
Contents     : /
               |-(up,Enabled,oneshot) setenv@ gspe
               |-(1540,Enabled,longrun) svscan@ gspe-log
               |-(14483,Enabled,longrun) svscan@ gspe
               |-(up,Enabled,module) scandir@ gspe
               |-(up,Enabled,oneshot) mount-run@ gspe
               |-(up,Enabled,module) boot-user@ gspe
               |-(1542,Enabled,longrun) dbus-log
               |-(1550,Enabled,longrun) dbus
               |-(1541,Enabled,longrun) sddm-log
               `-(1563,Enabled,longrun) sddm
it start without any problems.

I don't know if there is a solution for this problem or not or if it's easy to implement, but will be a super cool feature to have users tree that works with encrypted user home.
Implementation of user tracking need to be evolve. I have no time for the moment to implement this feature, i'm currently finishing the 66-ns tool then i need to work on 66 heart code to follow the change of skarnet about skalibs and s6 which contain a lot of changes.
For now, just disable your user tree 
# 66-tree -D users-session
This will avoid to crash your boot sequence, but you need to start it manually (or by a script).

Please as far as your distribution do not concern Obarun post here: https://forum.obarun.org/viewforum.php?id=23
Thanks by advance
so unlocking /home must preceed starting the tree. So the tree shouldn't be enabled, it should just be there (66-tree -D boot-user). I suppose once logged in you can have a script that you can add to .zlogin (if you are using zsh) that does (% sudo 66-all boot-user up ... then 66-all user-trees..xyz up)

This is also zfs right?
I have such a Trident system in a vm but don't use user services at all, or dbus, or consolekit, or elogind. I have to wait for lockdown to be over so I can go to my lcs (local computer store :) and get a cheap refurbished disk to make a zfs system and use encrypted to see how it acts in real metal.

I haven't gotten a newer trident, I have an alpha and a beta, and the funny thing is that alpha works great beta fails to install, but I suspect once updated it is the same, unless there is a new separate trident repository I don't know of.
fungal_net wroteso unlocking /home must preceed starting the tree. So the tree shouldn't be enabled, it should just be there (66-tree -D boot-user). I suppose once logged in you can have a script that you can add to .zlogin (if you are using zsh) that does (% sudo 66-all boot-user up ... then 66-all user-trees..xyz up)
@ fungal_net, yeah the procedure should be this for the moment :-) I hope to get simpler one sooner or later...
fungal_net wrote This is also zfs right?
I have such a Trident system in a vm but don't use user services at all, or dbus, or consolekit, or elogind. I have to wait for lockdown to be over so I can go to my lcs (local computer store :) and get a cheap refurbished disk to make a zfs system and use encrypted to see how it acts in real metal.

I haven't gotten a newer trident, I have an alpha and a beta, and the funny thing is that alpha works great beta fails to install, but I suspect once updated it is the same, unless there is a new separate trident repository I don't know of.
Zfs is really nice, be able to have a snapshot before every update is great, you are free to test and roll back if your system break.
Having encrypted home is nice too, since isn't necessary to enter another password before login.
You are also using 2 users, are they on separate encrypted partitions? I was thinking locking one and unlocking the other is one hell of containerization :)
fungal_net wroteYou are also using 2 users, are they on separate encrypted partitions? I was thinking locking one and unlocking the other is one hell of containerization :)
Yes every user have it's own zfs dataset encrypted with login password, pam_zfs module decrypt user's dataset on login and encrypt on logout.
The only thing you have to care of is that you can't simply change user password you have to change encryption password as well, but there is a script to do that.

Technically haveing only user home dataset encrypted is more secure than having all system encrypted, this because in all system encryption schema you have well known files, like linux kernel, that can be used to guess encryption password. I'm not an expert but this is what I understand.

2 Users was just an experiment I did with obarun and normal void.

Powered by Obarun