Andy Weidenbaum

Removing `block_uuid.map` (altering `modules.d/90crypt/*.sh` to remove references to `block_uuid.map`, accordingly) doesn’t make a difference.

> So this seems to indicate that fixing the issue regarding block_uuid.map would not actually make this particular scenario work. Perhaps it is better to focus on the validity of...

> I would just have one line in /etc/crypttab with detach headers and make it work The root volume with detached headers already gets unlocked properly — that part works....

@wowpetr In my case, the headerless (root) LUKS volume is successfully unlocked on startup. It’s the boot volume, a normal LUKS volume, which isn’t unlocked on startup.

Restated, [atweiden/voidvault](https://github.com/atweiden/voidvault) stores the root LUKS volume detached header in a second, separately LUKS-encrypted “boot” volume. It is this boot volume which is not unlocked. The root volume with detached...

@wowpetr, It just dawned on me your idea may be to patch in support for `luksUUID` in `/etc/block_uuid.map`. This way, there would at least be *something* there rather than extraneous...

Reason for PR: ```vim " s:light_bg_2 becomes background colour for |hl-Todo| when colorscheme " is seoul256-light " " n.b. it cannot exceed 256, hence with |g:seoul256_light_background| " set to 256,...

> So the difference is only noticeable to the users who switch between light and dark modes, using 256 for the light background color, and 233 for the dark background....

I’ve incorporated some of the standout features of #80 minus the reorg in the develop branch at https://github.com/atweiden/zig.vim, in addition to a few recent pull requests. IIRC I haven’t done...

+1, a `--noconfirm` flag would be great.