I may be missing a point, but I create a regular, non-encrypted snapshot using Colin’s AMI maker, which then gets copied across regions into an encrypted one. From that one, I can successfully boot a larger, encrypted EBS instance.
The main reasons for using encrypted EBS are two: compliance with “best effort” in case the discarded data storage fell into someone’s hands, and an onion-like approach to security, getting an extra (though thin) layer at pretty much no cost. I cannot see a reason why not to use that feature provided it works in the background without any visible performance issues. Many thanks, Rafal -- Rafal Lukawiecki Pardon errors, mobile device. > On 2 Apr 2021, at 08:40, Colin Percival <[email protected]> wrote: > > Oh, I should have clarified -- the default size is 10 GB but the snapshot > itself is 4 GB; you can create a volume any size from 4 GB upwards. (That > size varies from release to release, btw.) > > Colin Percival > >> On 4/1/21 4:17 PM, Connor Sheridan wrote: >> Even trying to provision an encrypted volume at the default size results in >> the same behavior. I hesitate to assert that FreeBSD on encrypted EBS is >> broken, but it seems to be. >> >> -----Original Message----- >> From: Colin Percival <[email protected]> >> Sent: Thursday, April 1, 2021 6:46 PM >> To: Connor Sheridan <[email protected]>; [email protected] >> Subject: Re: FreeBSD 12.2-RELEASE x86_64 EC2 AMIs in us-east-2 not booting >> >> #2 certainly works. I think #1 would work, but honestly I don't use >> encrypted volumes; I've never been able to think up a plausible attack which >> they would protect against. >> >> If you try #1, please let me know how it goes, so I can relay that to the >> next person to ask. >> >> Colin Percial >> >>> On 4/1/21 3:30 PM, Connor Sheridan wrote: >>> That's precisely the situation, yes. 32GB EBS volume. So, would either of >>> the following work? >>> >>> 1. Provisioning an encrypted volume at the snapshot size, then extending >>> the size of the volume. >>> 2. Provisioning an unencrypted volume at the desired size. >>> >>> Obviously #1 would be preferable. >>> >>> -----Original Message----- >>> From: Colin Percival <[email protected]> >>> Sent: Thursday, April 1, 2021 6:29 PM >>> To: Connor Sheridan <[email protected]>; [email protected] >>> Subject: Re: FreeBSD 12.2-RELEASE x86_64 EC2 AMIs in us-east-2 not >>> booting >>> >>> On 4/1/21 2:57 PM, Connor Sheridan wrote: >>>> I've attempted to provision x86_64 instances in AWS region us-east-2 from >>>> both the Marketplace AMIs and the specific AMI ID provided by the >>>> 12.2-RELEASE announcement, and they just get stuck in an endless boot >>>> loop. Appears to load the kernel, then reboot instantly. Are there any >>>> known gotchas about provisioning this release or anything I can do to get >>>> these running? >>> >>> There seems to be an issue related to encrypted disks -- possibly >>> specifically related to creating an EBS encrypted volume which is larger >>> than the backing snapshot. >>> >>> Are you using an encrypted disk? >>> >>> -- >>> Colin Percival >>> Security Officer Emeritus, FreeBSD | The power to serve Founder, >>> Tarsnap | www.tarsnap.com | Online backups for the truly paranoid >>> >> >> -- >> Colin Percival >> Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | >> www.tarsnap.com | Online backups for the truly paranoid >> _______________________________________________ >> [email protected] mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-cloud >> To unsubscribe, send any mail to "[email protected]" >> > > -- > Colin Percival > Security Officer Emeritus, FreeBSD | The power to serve > Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid > _______________________________________________ > [email protected] mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-cloud > To unsubscribe, send any mail to "[email protected]" _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-cloud To unsubscribe, send any mail to "[email protected]"
