I’d like to share some info about my playing with the 4kn drive.
I went through 51lieal’s instructions (using stock r4.1.1 iso). I got two main volumes, one is “varlibqubes” using file-reflink driver, the other is “vm” using lvm-thin driver.
When I was installing templates, I found that stock 512b templates didn’t boot on “vm”, but booted on “varlibqubes”. My self-built 4kn template booted on both two volumes.
However, since I upgraded dom0 to testing-latest, all my VMs refuse to boot, and the error messages are “libxenlight failed to create domain xxx”, just like those when I try to boot 512b templates on “vm”.
I can confirm this isn’t a kernel issue, because downgrading kernel version doesn’t help. I suspect this is somthing xen related.
Edit：
Even stock “LVM” installation ( because I cannot proceed with “LVM thin” option) without those modifications to luks on a 4kn drive will lead to the same result, that VMs refuse to boot when testing-repos are enabled.
@dom0 ~]$ systemd-analyze critical-chain
The time when unit became active or started is printed after the “@” character.
The time the unit took to start is printed after the “+” character.
I am just a user, when this issue is solved by the tech-people I’ll just reïnstall Qubes en restore from back-up.
Or stop using Qubes on this machine because another issue is I really need to install rpmfusion repos in dom0, what is not available in EOL Fedora 32.
Edit: sorry. I think as I go and seem to not be able to do a full post one shot and always edit multiple times. Sorry if you reply from email, hopefully this is sent to you in the 10 minutes edition permission time prior of sending the email you would reply to.
It seems the reason you were thwarted by gdisk is that it only guards the first sector alignment for you. And if you always make the LUKS partition last, then it will happily make the end ‘ragged’, not sizing the partition to multiples of the alignment value.
Easy fix for this is:
In gdisk eXpert menu, choose ‘L’ and enter ‘8’ if your drive has 512b sectors. This should also work if your drive has 4096b sectors. ‘8’ is 4096 / 512.
Go back to the main menu with ‘M’ and choose ‘N’ for a new partition. The default start should be OK. For the end, specify a relative canonical value like ‘+64g’ or ‘+64800m’. Using ‘g’ or ‘m’ will give you intrinsic multiples of 4096.
After that, cryptsetup with --sector-size 4096 should not complain about alignment.
A user reported that the old cryptsetup version used under Heads (2.3.3) was using argon2i when reencrypting, which was suboptimal for security. This is true. Qubes 4.1 has cryptsetup 2.3.5. argon2i is used there, I think. Anyway: even when reencrypting Q4.1 install with cryptsetup 2.6.1, this results into LUKS container still being argon2i. I guess that’s good: we don’t want to enforce something that breaks compatibility with initrd of OS.
So I spent my day trying to version bump Heads to use 2.6.1. Was successful.
Fixed scripts to not call cryptsetup-reencrypt but cryptsetup reencrypt, removed -B 64 which is not supported anymore and tried reencrypting with both --direct-io and without, to realise that speed of reencryption (with/without misalignment errors of original OS installation assumptions, block size etc) were still present on Qubes 4.2?
Related Qubes issue (encryption defaults for installer and upgrader).
Option --use-directio is only for LUKS1 according to cryptsetup reencrypt man page and here in this thread there are cases where it was used and speed was higher as well as where it wasn’t and speed was higher (different tuples), so I think there may just be a lot of variation for all sorts of reasons and --use-directio probably has nothing to do with it (at least if the man page is to be trusted).
Regarding sector size I’ve looked around a bit and this is not consistent, either; some report better performance with 512, others with 4k, yet others basically the same performance…the one thing that definitely helps here is to avoid a misaligned partition on 4k, but my impression is that 512 is very much recommended for Qubes anyway, as 4k is not well supported at the moment.
Maybe an issue should be opened on the cryptsetup gitlab or a question sent to their mailing list?
