I tested this by locking `aguestuser`'s account (tpo/tpa/team#40772),
and running ud-generate on alberti. The user was still present on
alberti in: `/var/cache/userdir-ldap/hosts/forward-alias`.

follow-up of my proposal for an alternative fix of team#40775
which does not require partitioning the LUN from outside the instance
itself

I was kind of scared of destroying everything by using fdisk. Turns
out there's a really easy hack with sfdisk.

This hack was found on this page:

https://karelzak.blogspot.com/2015/05/resize-by-sfdisk.html

This was used to resize vineale, see team#40778.

Every time I ran that, the file was already gone. I think it gets
cleared out on reboot. We may want to recreate it elsewhere, but i'm
not sure it's worth the trouble.

See tpo/core/tor#40615, thanks @jim!

We were refering to web-chi-03 which is nice because it gave us a hint
on how to fix this broken procedure, but it's too risky to have that
there, because we could recreate the VM or otherwise mess with its
configuration.

It's more likely that the primary will have the partitions setup correctly.

We were missing two crucial steps:

 1. the partitions had to be created *before* the device was passed to
    the VM, otherwise it gets completely confused and just creates one
    gigantic filesystem

 2. each partition needs to be adopted separately

Closes: team#40775.

changes merged in tpa-rfc-2 through !29

TPA-RFC-28: alphabetical triage

See merge request !29

The blockchain-less procedure didn't work: NBXplorer was stuck and
would have seemingly never synchronized. This procedure actually
worked in the end, by doing a full rsync.

See team#33750

see nextcloud#6