Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On Tue 08 Sep 2020 at 17:43:21 (-0400), rhkramer@gmail.com wrote:
> On Tuesday, September 08, 2020 04:39:05 PM David Christensen wrote:
> > Neither the string "2 MiB" nor the string "2 M" appear on page you have
> > cited.
>
> That is correct, that's is what I have not found on that page.
>
> > Please provide a URL that advocates "start the first partition at 2 MIB"
>
> Maybe I misinterpreted what David Wright said in an email responding to one of
> my questions back in June.
>
> <quote>
> Subject: Re: Advice on encrypted filesystem
> Date: Friday, June 26, 2020, 09:25:49 AM
> From: David Wright <deblis@lionunicorn.co.uk>
> To: debian-user@lists.debian.org
>
> ---< snip >---
>
> If encrypting an entire disk, scramble the disk first, then partition.
> If only encrypting a partition, partition the disk first.
> *Alignments should be at least 2M (4096 x 512B sectors).*
> Scramble any sensitive pre-existing contents:
> </quote>
>
> I took that to mean that the first partition should start at 2 MiB.
:) I'm flattered. OK, but those notes were introduced as *my*
method for encrypting (spinning rust) disks. My 2MB alignment
wouldn't apply to the first partition because I always start with
a BIOS boot partition aligned (not that it really matters much)
at the usual 1MB. With an ESP added too, I can boot the disk in
either type of machine, BIOS or EFI.
I see no point in not being generous with alignment as well as
with partition sizes. Also, I always include --align-payload 2048
when creating encrypted partitions, having been bitten by
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923561
(2048 is not an override, but just the default made explicit.)
Rationale: look back over just 2020 (if memory serves) for instances
posted here of undersized ESP, /boot, /, and lack of anywhere to
place Grub's core.img. Insufficient sizes get noticed; OTOH alignment
problems sometimes get reported when they're diagnosed or logged,
but are often ignored. Today's tools are very forgiving, and tend
to just do the Right Thing. In my case, things worked well until
I started adding encryption into the mix, and the logs reacted.
Cheers,
David.
Reply to: