@Jorma_Tuomainen Re:
Yes that looks like the best way to do it in your circumstance. All Rockstor systemd services begin with “rockstor” and can be found in:
ls -la /etc/systemd/system/rockstor*
-rw-r--r-- 1 root root 217 Oct 15 18:48 /etc/systemd/system/rockstor-bootstrap.service
-rw-r--r-- 1 root root 204 Oct 15 18:48 /etc/systemd/system/rockstor-pre.service
-rw-r--r-- 1 root root 227 Oct 15 18:48 /etc/systemd/system/rockstor.service
So systemctl disable on all of those:
systemctl disable rockstor-pre rockstor rockstor-bootstrap
Removed /etc/systemd/system/multi-user.target.wants/rockstor-pre.service.
Removed /etc/systemd/system/multi-user.target.wants/rockstor.service.
Removed /etc/systemd/system/multi-user.target.wants/rockstor-bootstrap.service.
so they don’t auto start on boot and then if you start the last to run (top) one rockstor-bootstrap it should invoke the rockstor service which in turn then invokes rockstor-pre (itself depending on postgresql and runs initrock to begin with). We may have more robustness work to be done in these services so do keep an eye on them and any suggestions always welcome.
Post this disabling of all rockstor’s main services, and a reboot their after, you should have nothing mounted on /mnt2:
mount | grep "/mnt2"
There are other rockstor related systemd services such as the one established if one sets hdparm parameters but that’s not relevant here.
So execution order of the main ‘start up’ systemd units is as follows:
rockstor-pre
rockstor
rockstor-bootstrap
But their defined inter dependencies (via their respective After= and Requires= entries) means that the last will invoke and wait for each in turn to start before it attempts to start itself.
So with all disabled and a consequent reboot rockstor is completely inactive.
You can then do your bit here.
Then an invocation of the top service and you should be good. Assuming their is sufficient time / dependency on the appearance of the Rockstor expected LUKS mapped drives names.
post:
systemctl start rockstor-bootstrap
you should then have the rockstor managed mounts back in place:
mount | grep "/mnt2"
/dev/vda3 on /mnt2/ROOT type btrfs (rw,relatime,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot)
/dev/vda3 on /mnt2/home type btrfs (rw,relatime,space_cache,subvolid=260,subvol=/@/home)
The above is an example openSUSE variant with no data pools attached but you get the idea.
Hope that helps and I think you’ve hit on the ideal way, with your circumstance/requirements, to go about this. Do keep us posted and consider sharing your results as it may be that others find this approach useful.
I may have missed something here but I’m sure it will come up if need be. And do remember that Rockstor has very specific expectations on the configuration of LUKS but only enacts them via standard LUKS config files. So as long as use use the Web-UI to configure stuff you should be good, and can then view what it has done via the normal LUKS config it establishes.