Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #226795 > unrolled thread

Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

Back to article view | Back to linux.debian.user

Contents

  Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ... rhkramer@gmail.com - 2020-09-08 19:00 +0200
    Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... Tixy <tixy@yxit.co.uk> - 2020-09-08 19:00 +0200
    Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ... rhkramer@gmail.com - 2020-09-08 19:00 +0200
      Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... David Christensen <dpchrist@holgerdanske.com> - 2020-09-08 22:40 +0200
        Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ... rhkramer@gmail.com - 2020-09-08 23:50 +0200
          Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... David Christensen <dpchrist@holgerdanske.com> - 2020-09-09 00:50 +0200
          Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... David Wright <deblis@lionunicorn.co.uk> - 2020-09-09 17:10 +0200
            Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... David Christensen <dpchrist@holgerdanske.com> - 2020-09-10 03:30 +0200
              Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... David <bouncingcats@gmail.com> - 2020-09-10 08:10 +0200
                Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... David Wright <deblis@lionunicorn.co.uk> - 2020-09-10 18:50 +0200
                  Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... David Christensen <dpchrist@holgerdanske.com> - 2020-09-11 00:40 +0200
                    Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... David <bouncingcats@gmail.com> - 2020-09-11 05:10 +0200
                      Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... David Christensen <dpchrist@holgerdanske.com> - 2020-09-11 06:20 +0200
                      Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... David Wright <deblis@lionunicorn.co.uk> - 2020-09-11 16:30 +0200
                Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... David Christensen <dpchrist@holgerdanske.com> - 2020-09-11 01:20 +0200
                  Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... David <bouncingcats@gmail.com> - 2020-09-11 05:50 +0200
                  Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... David Wright <deblis@lionunicorn.co.uk> - 2020-09-11 16:30 +0200
                    Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... David Christensen <dpchrist@holgerdanske.com> - 2020-09-11 22:10 +0200
          Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ... Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-09-09 17:20 +0200
            Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... David Wright <deblis@lionunicorn.co.uk> - 2020-09-09 18:30 +0200
              Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-09-09 19:10 +0200
    Re: Why start the first partition at 2 MIB, why not at any multiple  of 4096 bytes ... Michael Stone <mstone@debian.org> - 2020-09-08 23:10 +0200

Page 1 of 2  [1] 2  Next page →

#226795 — Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes 
that leaves room for whatever may need to be at the beginning of the disk 
(like maybe the MBR, or LILO, or ???)?

I've seen the advice to align partitions properly by starting them at a 
multiple of 4096 bytes, and I have (I think) a reasonable understanding of why 
(based on a sketch in the Wikipedia article on advanced partitioning).

But then I see the advice to start the first partition at 2 MiB -- why not at 
some lower multiple of 4096 while leaving room for anything that may need to 
be at the very beginning of the disk?  (I haven't found an explanation for 
that.)

[toc] | [next] | [standalone]

#226797 — Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

On Tue, 2020-09-08 at 12:53 -0400, rhkramer@gmail.com wrote:
> Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes 
> that leaves room for whatever may need to be at the beginning of the disk 
> (like maybe the MBR, or LILO, or ???)?

I believe it's for 'disks' based on solid state storage technology,
NAND flash can have a large erase block size.

-- 
Tixy 

[toc] | [prev] | [next] | [standalone]

#226798

Sorry, the Wikipedia article is Advanced Format:

http://en.wikipedia.org/wiki/Advanced_Format

On Tuesday, September 08, 2020 12:53:00 PM rhkramer@gmail.com wrote:
> Why start the first partition at 2 MIB, why not at any multiple of 4096
> bytes that leaves room for whatever may need to be at the beginning of the
> disk (like maybe the MBR, or LILO, or ???)?
> 
> I've seen the advice to align partitions properly by starting them at a
> multiple of 4096 bytes, and I have (I think) a reasonable understanding of
> why (based on a sketch in the Wikipedia article on advanced partitioning).
> 
> But then I see the advice to start the first partition at 2 MiB -- why not
> at some lower multiple of 4096 while leaving room for anything that may
> need to be at the very beginning of the disk?  (I haven't found an
> explanation for that.)

[toc] | [prev] | [next] | [standalone]

#226808 — Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

> On Tuesday, September 08, 2020 12:53:00 PM rhkramer@gmail.com wrote:
>> Why start the first partition at 2 MIB, why not at any multiple of 4096
>> bytes that leaves room for whatever may need to be at the beginning of the
>> disk (like maybe the MBR, or LILO, or ???)?
>>
>> I've seen the advice to align partitions properly by starting them at a
>> multiple of 4096 bytes, and I have (I think) a reasonable understanding of
>> why (based on a sketch in the Wikipedia article on advanced partitioning).
>>
>> But then I see the advice to start the first partition at 2 MiB -- why not
>> at some lower multiple of 4096 while leaving room for anything that may
>> need to be at the very beginning of the disk?  (I haven't found an
>> explanation for that.)

On 2020-09-08 09:56, rhkramer@gmail.com wrote:
 > Sorry, the Wikipedia article is Advanced Format:
 >
 > http://en.wikipedia.org/wiki/Advanced_Format

Please use inline posting style or bottom posting style.


Neither the string "2 MiB" nor the string "2 M" appear on page you have 
cited.


Please provide a URL that advocates "start the first partition at 2 MIB"


David

[toc] | [prev] | [next] | [standalone]

#226812

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.

[toc] | [prev] | [next] | [standalone]

#226815 — Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

On 2020-09-08 14:43, 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.

Perhaps David Wright can elaborate.


David

[toc] | [prev] | [next] | [standalone]

#226831 — 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.

[toc] | [prev] | [next] | [standalone]

#226839 — Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

On 2020-09-09 08:03, David Wright wrote:
> ... having been bitten by
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923561

I have a 300 GB drive that has been causing me some confusion.  Did I 
elicity the bug when I partitioned the disk as follows?

     2020-03-03 08:39:57 root@po ~
     # parted /dev/disk/by-id/ata-ST3300622AS_******** mkpart primary 
ext2 0% 100%
     Information: You may need to update /etc/fstab.


David

[toc] | [prev] | [next] | [standalone]

#226848 — Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

On Thu, 10 Sep 2020 at 11:26, David Christensen
<dpchrist@holgerdanske.com> wrote:
> On 2020-09-09 08:03, David Wright wrote:

> > ... having been bitten by
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923561

> I have a 300 GB drive that has been causing me some confusion.  Did I
> elicity the bug when I partitioned the disk as follows?

I have not read all relevant messages, but in case it helps you can
check your exact device partition boundaries by running:

parted /dev/disk/by-id/ata-ST3300622AS_******** 'unit compact print
free unit s print free unit b print free'

[toc] | [prev] | [next] | [standalone]

#226868 — Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

On Thu 10 Sep 2020 at 16:02:59 (+1000), David wrote:
> On Thu, 10 Sep 2020 at 11:26, David Christensen <dpchrist@holgerdanske.com> wrote:
> > On 2020-09-09 08:03, David Wright wrote:
> 
> > > ... having been bitten by
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923561
> 
> > I have a 300 GB drive that has been causing me some confusion.  Did I
> > elicity the bug when I partitioned the disk as follows?
> 
> I have not read all relevant messages, but in case it helps you can
> check your exact device partition boundaries by running:

My choice would be   fdisk -l   or   gdisk -l   for the partition
table, but I'm not sure what to ask for in terms of the encryption:
I don't know what options are available, nor how to interrogate for
them after the event. But IIRC the alignment problem was logged in
kern.log, so any output when the partition is unlocked and mounted
might be useful.

> parted /dev/disk/by-id/ata-ST3300622AS_******** 'unit compact print
> free unit s print free unit b print free'

I don't like parted particularly, and don't know what "free" does.
Can you elucidate?

$ man parted | grep -i free
$ info --output=/dev/stdout --subnodes parted | grep -i free
  Feel free to ask for help on this list -- just check that your
GNU Parted is free software, covered by the GNU General Public License
in the COPYING file.  If not, write to the Free Software Foundation,
     the Free Translation Project.
   * 'COPYING.DOC' - the GNU Free Documentation Licence, the term under
   * 'INSTALL' -- how to compile and install Parted, and most other free
* GNU Free Documentation License::  License for copying this manual
File: parted.info,  Node: GNU Free Documentation License,  Up: Copying This Manual
A.1 GNU Free Documentation License
     Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
     functional and useful document "free" in the sense of freedom: to
     assure everyone the effective freedom to copy and redistribute it,
     works of the document must themselves be free in the same sense.
     license designed for free software.
     free software, because free software needs free documentation: a
     free program should come with manuals providing the same freedoms
     grants a world-wide, royalty-free license, unlimited in duration,
     network protocols a complete Transparent copy of the Document, free
     The Free Software Foundation may publish new, revised versions of
     the GNU Free Documentation License from time to time.  Such new
     published (not as a draft) by the Free Software Foundation.  If the
     choose any version ever published (not as a draft) by the Free
       under the terms of the GNU Free Documentation License, Version 1.3
       or any later version published by the Free Software Foundation;
       Free Documentation License''.
recommend releasing these examples in parallel under your choice of free
their use in free software.
  This manual is distributed under the GNU Free Documentation License,
the Free Software Foundation; with no Invariant Sections, with no
* FDL, GNU Free Documentation License:   GNU Free Documentation License.
$ 

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#226877 — Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

On 2020-09-10 09:44, David Wright wrote:
> On Thu 10 Sep 2020 at 16:02:59 (+1000), David wrote:
>> On Thu, 10 Sep 2020 at 11:26, David Christensen <dpchrist@holgerdanske.com> wrote:

> ,,, I'm not sure what to ask for in terms of the encryption:

See cryptsetup(8) with the 'isLuks' action and/or the '-v' option.


For example, my daily driver:

2020-09-10 14:59:09 root@tinkywinky ~
# cat /etc/debian_version ; uname -a
9.13
Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) 
x86_64 GNU/Linux


The boot partition (sda1) does not contain a LUKS volume.  The root 
partition (sda3) does:

2020-09-10 15:25:51 root@tinkywinky ~
# cryptsetup isLuks -v /dev/sda1
Device /dev/sda1 is not a valid LUKS device.
Command failed with code 22: Invalid argument

2020-09-10 15:25:55 root@tinkywinky ~
# echo $?
1

2020-09-10 15:25:56 root@tinkywinky ~
# cryptsetup isLuks -v /dev/sda3
Command successful.

2020-09-10 15:25:58 root@tinkywinky ~
# echo $?

0


> I don't like parted particularly, and don't know what "free" does.
> Can you elucidate?
> 
> $ man parted | grep -i free
> $ info --output=/dev/stdout --subnodes parted | grep -i free

I also am unable to find canonical documentation via RTFM, info, and 
STFW.  GNU must have missed documenting it (?).


Briefly, if 'free' is provided after the 'print' option to parted(8), 
the displayed partition table shows unpartitioned free space.  It is 
aware of sectors consumed by the partition scheme.


For example, the system disk on my daily driver uses MBR:

2020-09-10 15:09:43 root@tinkywinky ~
# parted /dev/sda u s p
Model: ATA INTEL SSDSC2CW06 (scsi)
Disk /dev/sda: 117231408s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start      End         Size       Type     File system  Flags
  1      2048s      1953791s    1951744s   primary  ext4         boot
  2      1953792s   3907583s    1953792s   primary
  3      3907584s   27344895s   23437312s  primary
  4      27344896s  117229567s  89884672s  primary


2020-09-10 15:09:46 root@tinkywinky ~
# parted /dev/sda u s p free
Model: ATA INTEL SSDSC2CW06 (scsi)
Disk /dev/sda: 117231408s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start       End         Size       Type     File system  Flags
         63s         2047s       1985s               Free Space
  1      2048s       1953791s    1951744s   primary  ext4         boot
  2      1953792s    3907583s    1953792s   primary
  3      3907584s    27344895s   23437312s  primary
  4      27344896s   117229567s  89884672s  primary
         117229568s  117231407s  1840s               Free Space


The 300 GB external disk uses GPT:

2020-09-10 15:19:20 root@tinkywinky ~
# parted -s /dev/sdb u s p
Error: The backup GPT table is corrupt, but the primary appears OK, so 
that will be used.
Model: ATA ST3300622AS (scsi)
Disk /dev/sdb: 586072368s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start  End         Size        File system  Name      Flags
  1      2048s  586072063s  586070016s  ext2         4NF2P9SV


2020-09-10 15:23:14 root@tinkywinky ~
# parted -s /dev/sdb u s p free
Error: The backup GPT table is corrupt, but the primary appears OK, so 
that will be used.
Model: ATA ST3300622AS (scsi)
Disk /dev/sdb: 586072368s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start       End         Size        File system  Name      Flags
         34s         2047s       2014s       Free Space
  1      2048s       586072063s  586070016s  ext2         4NF2P9SV
         586072064s  586072334s  271s        Free Space


David

[toc] | [prev] | [next] | [standalone]

#226882 — Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

On Fri, 11 Sep 2020 at 08:30, David Christensen
<dpchrist@holgerdanske.com> wrote:
> On 2020-09-10 09:44, David Wright wrote:

> > I don't like parted particularly, and don't know what "free" does.
> > Can you elucidate?

> > $ man parted | grep -i free
> > $ info --output=/dev/stdout --subnodes parted | grep -i free

> I also am unable to find canonical documentation via RTFM, info, and
> STFW.  GNU must have missed documenting it (?).

# parted --help | grep -A 1 free
  print [devices|free|list,all|NUMBER]     display the partition table,
        available devices, free space, all found partitions, or a particular
        partition

[toc] | [prev] | [next] | [standalone]

#226884 — Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

On 2020-09-10 20:03, David wrote:
> On Fri, 11 Sep 2020 at 08:30, David Christensen...  wrote:
>> On 2020-09-10 09:44, David Wright wrote:
> 
>>> I don't like parted particularly, and don't know what "free" does.
>>> Can you elucidate?
> 
>>> $ man parted | grep -i free
>>> $ info --output=/dev/stdout --subnodes parted | grep -i free
> 
>> I also am unable to find canonical documentation via RTFM, info, and
>> STFW.  GNU must have missed documenting it (?).
> 
> # parted --help | grep -A 1 free
>    print [devices|free|list,all|NUMBER]     display the partition table,
>          available devices, free space, all found partitions, or a particular
>          partition

Thank you for finding that.  :-)


David

[toc] | [prev] | [next] | [standalone]

#226900 — Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

On Fri 11 Sep 2020 at 13:03:44 (+1000), David wrote:
> On Fri, 11 Sep 2020 at 08:30, David Christensen <dpchrist@holgerdanske.com> wrote:
> > On 2020-09-10 09:44, David Wright wrote:
> 
> > > I don't like parted particularly, and don't know what "free" does.
> > > Can you elucidate?
> 
> > > $ man parted | grep -i free
> > > $ info --output=/dev/stdout --subnodes parted | grep -i free
> 
> > I also am unable to find canonical documentation via RTFM, info, and
> > STFW.  GNU must have missed documenting it (?).
> 
> # parted --help | grep -A 1 free
>   print [devices|free|list,all|NUMBER]     display the partition table,
>         available devices, free space, all found partitions, or a particular
>         partition

It looks as if that just got left out of the man page
which, in other respects, has been condensed to yield
$ /sbin/parted --help

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#226878 — Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

On 2020-09-09 23:02, David wrote:
> On Thu, 10 Sep 2020 at 11:26, David Christensen
> <dpchrist@holgerdanske.com> wrote:
>> On 2020-09-09 08:03, David Wright wrote:
> 
>>> ... having been bitten by
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923561
> 
>> I have a 300 GB drive that has been causing me some confusion.  Did I
>> elicity the bug when I partitioned the disk as follows?
> 
> I have not read all relevant messages, but in case it helps you can
> check your exact device partition boundaries by running:
> 
> parted /dev/disk/by-id/ata-ST3300622AS_******** 'unit compact print
> free unit s print free unit b print free'

That parted(8) incantation has issues, as does the disk:

2020-09-10 14:00:52 root@tinkywinky ~
# parted /dev/disk/by-id/ata-ST3300622AS_******** 'unit compact print 
free unit s print free unit b print free'
Error: The backup GPT table is corrupt, but the primary appears OK, so 
that will be used.
parted: invalid token: unit
OK/Cancel? ok
Model: ATA ST3300622AS (scsi)
Disk /dev/sdb: 300GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name      Flags
         17.4kB  1049kB  1031kB  Free Space
  1      1049kB  300GB   300GB   ext2         ********
         300GB   300GB   139kB   Free Space


This is how I invoke parted(8):

2020-09-10 14:01:58 root@tinkywinky ~
# parted /dev/disk/by-id/ata-ST3300622AS_******** unit s print free
Error: The backup GPT table is corrupt, but the primary appears OK, so 
that will be used.
OK/Cancel? ok
Model: ATA ST3300622AS (scsi)
Disk /dev/sdb: 586072368s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start       End         Size        File system  Name      Flags
         34s         2047s       2014s       Free Space
  1      2048s       586072063s  586070016s  ext2         ********
         586072064s  586072334s  271s        Free Space



Looking at the above information, my first partition starts at sector 
2048 and ends at sector 586072063 (inclusive).  Both of these values 
represent 1 MiB alignment, so it appears that the partition has not been 
affected by bug 923561.


David

[toc] | [prev] | [next] | [standalone]

#226883 — Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

On Fri, 11 Sep 2020 at 09:15, David Christensen
<dpchrist@holgerdanske.com> wrote:
> On 2020-09-09 23:02, David wrote:

> > parted /dev/disk/by-id/ata-ST3300622AS_******** 'unit compact print
> > free unit s print free unit b print free'

> That parted(8) incantation has issues

It works for me, but then again my disks are neither broken nor GPT.

[toc] | [prev] | [next] | [standalone]

#226899 — Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

On Thu 10 Sep 2020 at 16:15:05 (-0700), David Christensen wrote:
> On 2020-09-09 23:02, David wrote:
> > On Thu, 10 Sep 2020 at 11:26, David Christensen <dpchrist@holgerdanske.com> wrote:
> > > On 2020-09-09 08:03, David Wright wrote:
> > 
> > > > ... having been bitten by
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923561
> > 
> > > I have a 300 GB drive that has been causing me some confusion.  Did I
> > > elicity the bug when I partitioned the disk as follows?
> > 
> > I have not read all relevant messages, but in case it helps you can
> > check your exact device partition boundaries by running:
> > 
> > parted /dev/disk/by-id/ata-ST3300622AS_******** 'unit compact print
> > free unit s print free unit b print free'
> 
> That parted(8) incantation has issues, as does the disk:

[…]

> This is how I invoke parted(8):
> 
> 2020-09-10 14:01:58 root@tinkywinky ~
> # parted /dev/disk/by-id/ata-ST3300622AS_******** unit s print free
> Error: The backup GPT table is corrupt, but the primary appears OK, so
> that will be used.
> OK/Cancel? ok
> Model: ATA ST3300622AS (scsi)
> Disk /dev/sdb: 586072368s
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> Disk Flags:
> 
> Number  Start       End         Size        File system  Name      Flags
>         34s         2047s       2014s       Free Space
>  1      2048s       586072063s  586070016s  ext2         ********
>         586072064s  586072334s  271s        Free Space

I don't know what might have got your disk into this state, but
I'm happy that you got it fixed. My own strategy would have been
to use gdisk (my preferred partitioning program) to rewrite the
backup table from the main table (command r for the recovery menu,
then d).

> Looking at the above information, my first partition starts at sector
> 2048 and ends at sector 586072063 (inclusive).  Both of these values
> represent 1 MiB alignment, so it appears that the partition has not
> been affected by bug 923561.

I don't think the bug affects ordinary 512/512 disks, but only
Advanced Format ones with larger block sizes, and then only if
"they" also supply an erroneous I/O value, eg:

Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes

It's possible that this only occurs with USB disks, too.
The partition can be 1MB aligned, but cryptsetup is fooled into
setting the wrong alignment, eg:

device-mapper: table: 254:1: adding target device sdb2 caused an alignment inconsistency:
physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=33553920

which was produced by this partition:

/dev/sdb2  1302349824 1953521663  651171840 310.5G  c W95 FAT32 (LBA)

>>> 1302349824/2048
635913.0
>>> 

So, as my notes show, for the simple life, I always create
partitions with 2MB alignment regardless of future use¹,
and always add  --align-payload 2048 to my cryptsetup
commands. This option is benign because it's the default
when the kernel doesn't supply a value. The man page says
to prefer --offset, but as I know nothing about what any
of these options actually do, I don't use --offset just
because there's no default value given for it. (I suspect
it may be the same as for --align-payload.)

¹ I don't worry about the initial BIOS boot partition.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#226911 — Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

On 2020-09-11 07:21, David Wright wrote:
> On Thu 10 Sep 2020 at 16:15:05 (-0700), David Christensen wrote:
>> On 2020-09-09 23:02, David wrote:
>>> On Thu, 10 Sep 2020 at 11:26, David Christensen <dpchrist@holgerdanske.com> wrote:
>>>> On 2020-09-09 08:03, David Wright wrote:
>>>>> ... having been bitten by
>>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923561

>> 2020-09-10 14:01:58 root@tinkywinky ~
>> # parted /dev/disk/by-id/ata-ST3300622AS_******** unit s print free
>> Error: The backup GPT table is corrupt, but the primary appears OK, so
>> that will be used.

> I don't know what might have got your disk into this state, but
> I'm happy that you got it fixed. My own strategy would have been
> to use gdisk (my preferred partitioning program) to rewrite the
> backup table from the main table (command r for the recovery menu,
> then d).

Thank you for the pointer.  I will look at gdisk(8) the next time I have 
a need that I cannot figure out.


> I don't think the bug affects ordinary 512/512 disks, but only
> Advanced Format ones with larger block sizes, and then only if
> "they" also supply an erroneous I/O value, eg:
> 
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
> 
> It's possible that this only occurs with USB disks, too.
> The partition can be 1MB aligned, but cryptsetup is fooled into
> setting the wrong alignment, eg:
> 
> device-mapper: table: 254:1: adding target device sdb2 caused an alignment inconsistency:
> physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=33553920
> 
> which was produced by this partition:
> 
> /dev/sdb2  1302349824 1953521663  651171840 310.5G  c W95 FAT32 (LBA)
> 
>>>> 1302349824/2048
> 635913.0
>>>>
> 
> So, as my notes show, for the simple life, I always create
> partitions with 2MB alignment regardless of future use¹,
> and always add  --align-payload 2048 to my cryptsetup
> commands. This option is benign because it's the default
> when the kernel doesn't supply a value. The man page says
> to prefer --offset, but as I know nothing about what any
> of these options actually do, I don't use --offset just
> because there's no default value given for it. (I suspect
> it may be the same as for --align-payload.)
> 
> ¹ I don't worry about the initial BIOS boot partition.

That sounds like some hard-won knowledge.  I hope they fix the bug 
before I stumble into it.


David

[toc] | [prev] | [next] | [standalone]

#226832

rhkramer@gmail.com writes:

> 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.

That doesn't follow -- 0 is 2 MiB-aligned (it's also aligned on whatever
other size boundary you care to name, of course).

[toc] | [prev] | [next] | [standalone]

#226833 — Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

On Wed 09 Sep 2020 at 08:53:20 (-0600), Joe Pfeiffer wrote:
> rhkramer@gmail.com writes:
> > 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.
> 
> That doesn't follow -- 0 is 2 MiB-aligned (it's also aligned on whatever
> other size boundary you care to name, of course).

Care to explain how you align the first partition with the start of the disk?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web