`qvm-pool --add` is persistent?

[qubenix]

Hello everyone. I'm just in the process of switching over to Qubes 4,
and I'm setting up a secondary, luks encrypted drive for vm storage. I'm
following the instructions here: https://qubes-os.org/doc/secondary-storage.

On r3.2 I used systemd to decrypt and mount my secondary drive, but now
I'm not sure how to proceed. If the `qvm-pool --add` is persistent, then
do I only need to decrypt the drive from systemd? If that's the case,
then should I specify a `Before=` in the unit?

Thanks for reading.

--
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

[qubenix]

qubenix:

> Hello everyone. I'm just in the process of switching over to Qubes 4,
> and I'm setting up a secondary, luks encrypted drive for vm storage. I'm
> following the instructions here: https://qubes-os.org/doc/secondary-storage.
>
> On r3.2 I used systemd to decrypt and mount my secondary drive, but now
> I'm not sure how to proceed. If the `qvm-pool --add` is persistent, then
> do I only need to decrypt the drive from systemd? If that's the case,
> then should I specify a `Before=` in the unit?
>
> Thanks for reading.
>

After some testing I realize that `qvm-pool` is not persistent. I solved
my problem with systemd again, calling a script which decrypts the
drive, executes `vgchange -ay` on my group, and then does the `qvm-pool
--add` command from the docs.

--
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

[awokd]

I'm using LUKS on both primary and secondary drives with the same password
and (apart from adding the secondary drive to /etc/crypttab) all I had to
do was covered in https://www.qubes-os.org/doc/secondary-storage/. Is your
configuration different?

[qubenix]

'awokd' via qubes-users:

I don't know why I was making this harder than it needs to be. I must
have been running `qvm-pool -r <mypool>` before shutdown (it was part of
my ExecStop because of my ignorance) on all my tests, because without
that the pool does persist.

Per suggestion, I simply added a line to /etc/crypttab with the options
"luks,keyscript=decrypt_keyctl,nofail" for my secondary drive. It now
successfully decrypts and I can see all my volumes with `lvs` or
`lsblk`. Thank you, awokd.

There is a new problem for me, though. Upon login, the vms which reside
on this secondary drive show "0" disk usage in Qube Manager, and will
not launch with the error: "<my_vg>/vm-vmname-private does not exist".

I have to manually restart the `qubesd` service to get everything to
work normally. So it appears there's some race condition maybe?

--
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

[awokd]

On Wed, July 25, 2018 4:53 pm, qubenix wrote:

>
> I don't know why I was making this harder than it needs to be. I must
> have been running `qvm-pool -r <mypool>` before shutdown (it was part of my
> ExecStop because of my ignorance) on all my tests, because without
> that the pool does persist.

:)

> Per suggestion, I simply added a line to /etc/crypttab with the options
> "luks,keyscript=decrypt_keyctl,nofail" for my secondary drive. It now
> successfully decrypts and I can see all my volumes with `lvs` or `lsblk`.
> Thank you, awokd.
>
>
> There is a new problem for me, though. Upon login, the vms which reside
> on this secondary drive show "0" disk usage in Qube Manager, and will not
> launch with the error: "<my_vg>/vm-vmname-private does not exist".
>
> I have to manually restart the `qubesd` service to get everything to
> work normally. So it appears there's some race condition maybe?

My crypttab line for the HDD is like:

<luksname> UUID=<UUID> none

Try that, and see if it helps? Double check to make sure you got rid of
all the custom systemd changes too.

[qubenix]

'awokd' via qubes-users:

I edited my crypttab like yours, but that was not the solution (even
though it's nice to have it simpler). I believe a failing systemd unit
`qube...@net.service` was causing a race condition, because after
disabling it everything is working as expected.

It was failing with "no vm 'net'" even though there has never been a vm
named 'net'.

I really appreciate your help, awokd!

--
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500