Hello. Sorry for opening a ticket, but after searching for days and trying at least 50 different configs, I've still not got it working, and I'm wondering whether it might be an actual bug.
Situation
I have an internal drive that is encrypted by VeraCrypt with standard system partition encryption. It's working absolutely fine so far. But I don't want to enter my password on every boot; rather I'd like to have an external drive that contains the bootloader and starts my encrypted system, just like the VeraCrypt bootloader that is present on the system disk would and is able to do.
What I've tried
I took the rescue image that was created during encryption and placed it on a USB drive. It can boot the minimal rescue shell fine, but completely ignores the DcsProp file and offers no option whatsoever to boot the existing system, presenting me only with options to decrypt it or reset to the original boot loader. Through a few dozen forum posts, I've found out that overriding \EFI\Boot\bootx64.efi with \EFI\VeraCrypt\DcsBoot.efi will actually start the boot loader instead of the rescue disk, and it seems to respect the DcsProp file placed on the USB drive. I was expecting the rescue disk to be able to boot the encrypted system as an option without replacing it manually with the boot loader, but nope. (Am I missing something here?)
Anyways, now that the boot loader is properly starting from USB... I still can't get it to work. I've tried various different variations of the DcsProp file, which I've included at the end of this issue. Depending on the configuration, I've gotten various responses from the bootloader:
"Can't find start partition" is the most common, and it happens after authentication success. The bootloader will authorize, print the correct drive offset and length (just like when I normally boot), and then stop with this error, while displaying a totally wrong UUID that is one-third ones, one-third zeroes and rest seems to be random.
"CRC invalid" happens when I leave out postexec. What does that do anyway?
"Not found" without further message happened a few times, I forgot which configs.
The possible bug
Please mind that albeit being a professional programmer, I've never really worked with C, so I might misunderstand parts of the code. But I think there might be a bug with the code that is figuring out the UUID of the partition to be booted from: https://github.com/veracrypt/VeraCrypt-DCS/blob/master/DcsBoot/DcsBoot.c#L193
The linked code seems to completely ignore any other drives that are present in the system. It will only try to find the partition UUID amongst the partitions of the bootloader file root's device, making it impossible to boot from a different drive than the one the bootloader is placed on.
I've dug a little deeper and found that EfiFindPartByGUID() (from https://github.com/veracrypt/VeraCrypt-DCS/blob/0342ec53dea13d16115fdb44ddc74724d82519c3/Library/CommonLib/EfiBio.c ) should probably be called before the above mentioned line, to find the correct device that the partition is placed on.
If that's not a bug, I don't really know where else to look. I think it's weird that the rescue disk offers no option to actually auto login according to the DcsProp file that is placed on the same partition, and it missing should be considered a bug as well. IMHO a rescue disk should always be able to boot the system, not only restore it. And technically it is, it's just missing the option in the menu, it seems.
Edit: looking further into the code I've talked about, I don't think anymore that this exact line is buggy. Later on in the code it seems to try to figure out whether the partition is on a different device and then search accordingly. But what has to be a bug is the fact that the UUID that I specify, is displayed incorrectly and randomly on each boot. It seems to me like this might be a pointer issue somewhere when reading the target UUID from DcsProp, or copying that afterwards.
Please help me get this fixed, as it's driving me crazy. I'd love to help with writing a bit of documentation about this part as soon as I've got it working.
Appendix A: My DcsProp file
The following is the config I've placed on the USB in \EFI\VeraCrypt\DcsProp (already existed with defaults). All private data is replaced by ***. I've tried both EFI partition and OS partition UUIDs in all combinations. The multiple ActionSuccess values are all variations I've tried.
Hello. Sorry for opening a ticket, but after searching for days and trying at least 50 different configs, I've still not got it working, and I'm wondering whether it might be an actual bug.
Situation I have an internal drive that is encrypted by VeraCrypt with standard system partition encryption. It's working absolutely fine so far. But I don't want to enter my password on every boot; rather I'd like to have an external drive that contains the bootloader and starts my encrypted system, just like the VeraCrypt bootloader that is present on the system disk would and is able to do.
What I've tried I took the rescue image that was created during encryption and placed it on a USB drive. It can boot the minimal rescue shell fine, but completely ignores the
DcsPropfile and offers no option whatsoever to boot the existing system, presenting me only with options to decrypt it or reset to the original boot loader. Through a few dozen forum posts, I've found out that overriding\EFI\Boot\bootx64.efiwith\EFI\VeraCrypt\DcsBoot.efiwill actually start the boot loader instead of the rescue disk, and it seems to respect theDcsPropfile placed on the USB drive. I was expecting the rescue disk to be able to boot the encrypted system as an option without replacing it manually with the boot loader, but nope. (Am I missing something here?)Anyways, now that the boot loader is properly starting from USB... I still can't get it to work. I've tried various different variations of the
DcsPropfile, which I've included at the end of this issue. Depending on the configuration, I've gotten various responses from the bootloader:postexec. What does that do anyway?The possible bug Please mind that albeit being a professional programmer, I've never really worked with C, so I might misunderstand parts of the code. But I think there might be a bug with the code that is figuring out the UUID of the partition to be booted from: https://github.com/veracrypt/VeraCrypt-DCS/blob/master/DcsBoot/DcsBoot.c#L193 The linked code seems to completely ignore any other drives that are present in the system. It will only try to find the partition UUID amongst the partitions of the bootloader file root's device, making it impossible to boot from a different drive than the one the bootloader is placed on. I've dug a little deeper and found that
EfiFindPartByGUID()(from https://github.com/veracrypt/VeraCrypt-DCS/blob/0342ec53dea13d16115fdb44ddc74724d82519c3/Library/CommonLib/EfiBio.c ) should probably be called before the above mentioned line, to find the correct device that the partition is placed on.If that's not a bug, I don't really know where else to look. I think it's weird that the rescue disk offers no option to actually auto login according to the
DcsPropfile that is placed on the same partition, and it missing should be considered a bug as well. IMHO a rescue disk should always be able to boot the system, not only restore it. And technically it is, it's just missing the option in the menu, it seems.Edit: looking further into the code I've talked about, I don't think anymore that this exact line is buggy. Later on in the code it seems to try to figure out whether the partition is on a different device and then search accordingly. But what has to be a bug is the fact that the UUID that I specify, is displayed incorrectly and randomly on each boot. It seems to me like this might be a pointer issue somewhere when reading the target UUID from
DcsProp, or copying that afterwards.Please help me get this fixed, as it's driving me crazy. I'd love to help with writing a bit of documentation about this part as soon as I've got it working.
Appendix A: My DcsProp file The following is the config I've placed on the USB in
\EFI\VeraCrypt\DcsProp(already existed with defaults). All private data is replaced by***. I've tried both EFI partition and OS partition UUIDs in all combinations. The multipleActionSuccessvalues are all variations I've tried.