'Re: fdisk head inconsistency'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: busybox
Subject: Re: fdisk head inconsistency
From: Michael Conrad <mconrad () intellitree ! com>
Date: 2019-09-30 22:30:27
Message-ID: 8114b20c-8479-c8a4-f118-6eb63947a7a4 () intellitree ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

On 9/29/2019 8:57 AM, Mauro Condarelli wrote:
> Note: the SD card was originally formatted using Debian GNU/Linux fdisk
> on a desktop.
>
> I have several problems here, possibly all stemming from   a bogus
> detection of "disk geometry":
> - (n)ew partition always suggested sector 16 as starting point
> (obviously useless).
> - (p)rint shows bogus values in CHS of newly created Partitions.
> - (v)erify complains about "old" partition geometry.
(snip)
> Command (m for help): p
> Disk /dev/mmcblk0: 7580 MB, 7948206080 bytes, 15523840 sectors
> 242560 cylinders, 4 heads, 16 sectors/track
> Units: sectors of 1 * 512 = 512 bytes
>
> Device             Boot StartCHS       EndCHS               StartLBA         EndLBA
> Sectors   Size Id Type
> /dev/mmcblk0p1       0,33,3           17,96,10                   2048         264191
> 262144   128M   c Win95 FAT32 (LBA)
> /dev/mmcblk0p2       17,96,11       293,126,14           264192       4458495
> 4194304 2048M 83 Linux

Since you have only run "delete" commands prior to this print command, 
I'm assuming that the debian fdisk wrote out those partitions where the 
head number (i.e. 33) is exceeding the maximum (4).   (but maybe you 
could check?)   I would guess that maybe the USB stick came with the 
partition table listing 4 heads 16 sectors as a hint to partition tools 
that the media likes 32K boundaries (4*16*512=32768).   Maybe Debian 
fdisk ignored those and wrote out CHS offsets based on assumption that 
the partition table matches the default geometry that fdisk generates?   
Either way, I'm guessing the inconsistency is already written to disk, 
so you can fix it (or not) however you like.

In the grand scheme of things, no modern software cares about those CHS 
numbers anyway.   Each partition table entry contains redundant CHS 
start/end and LBA (plain old integer sector number) start/end, and every 
modern tool/OS uses the LBA number and ignores the CHS, because the CHS 
haven't been real measurements for 25 years or more.

https://en.wikipedia.org/wiki/Master_boot_record#Partition_table_entries

The only thing you should worry about is that the partition is aligned 
on a multiple of the erase-size of the USB media.   I'm not current on 
what those are, but 1MiB should be sufficient, which is why the default 
start sector for fdisk is 2048 (*512=1MiB)

I'd just go ahead and try it.... assuming you have all the data on there 
backed up, which you should any time you play with partition tables ;-)

-Mike

[Attachment #5 (text/html)]

<html><body>
On 9/29/2019 8:57 AM, Mauro Condarelli wrote:
<blockquote>Note: the SD card was originally formatted using Debian GNU/Linux \
fdisk on a desktop. I have several problems here, possibly all stemming from \
a bogus detection of &ldquo;disk geometry&rdquo;: <ul><li>(n)ew partition \
always suggested sector 16 as starting point</li></ul> (obviously \
useless). <ul><li>(p)rint shows bogus values in CHS of newly created \
Partitions.</li> <li>(v)erify complains about &ldquo;old&rdquo; partition \
geometry.</li></ul></blockquote> (snip)
<blockquote>Command (m for help): p Disk /dev/mmcblk0: 7580 MB, 7948206080 bytes, \
15523840 sectors 242560 cylinders, 4 heads, 16 sectors/track Units: sectors of 1 * \
512 = 512 bytes Device Boot StartCHS EndCHS \
StartLBA EndLBA Sectors Size Id Type /dev/mmcblk0p1 0,33,3 \
17,96,10 2048 264191 262144 128M c Win95 FAT32 (LBA) \
/dev/mmcblk0p2 17,96,11 293,126,14 264192 4458495 4194304 \
2048M 83 Linux</blockquote> Since you have only run &ldquo;delete&rdquo; \
commands prior to this print command, I'm assuming that the debian fdisk wrote out \
those partitions where the head number (i.e. 33) is exceeding the maximum (4). (but \
maybe you could check?) I would guess that maybe the USB stick came with the \
partition table listing 4 heads 16 sectors as a hint to partition tools that the \
media likes 32K boundaries (4*16*512=32768). Maybe Debian fdisk ignored those and \
wrote out CHS offsets based on assumption that the partition table matches the \
default geometry that fdisk generates? Either way, I'm guessing the inconsistency \
is already written to disk, so you can fix it (or not) however you like. In \
the grand scheme of things, no modern software cares about those CHS numbers anyway. \
Each partition table entry contains redundant CHS start/end and LBA (plain old \
integer sector number) start/end, and every modern tool/OS uses the LBA number and \
ignores the CHS, because the CHS haven't been real measurements for 25 years or \
more. <a href="https://en.wikipedia.org/wiki/Master_boot_record#Partition_table \
_entries">https://en.wikipedia.org/wiki/Master_boot_record#Partition_table_entries</a>
 The only thing you should worry about is that the partition is aligned on a \
multiple of the erase-size of the USB media. I'm not current on what those are, but \
1MiB should be sufficient, which is why the default start sector for fdisk is 2048 \
(*512=1MiB) I'd just go ahead and try it.... assuming you have all the data on \
there backed up, which you should any time you play with partition tables ;-) \
-Mike

<img src="https://u8477214.ct.sendgrid.net/wf/open?upn=dCCleNsAjkncO-2BKmpSXMox0Zzgog5 \
t6r-2BJ2aTvk-2FwJpvc3VkHYQ7JHALt-2BvugZ2sjFtCw2NeKKoiSCbQF1M0WOAG66Y1SIXV3VyzBs-2BycC- \
2FcKck4S8f4TVLfHU-2BQHak-2BhJhV39CPiimCeNbA-2BegjI216Hy98YHCCCCtjZmAKXLR3gxU-2FBjUe4Dmok79oTWAcHiWIYJQkITtaMUcGVGq2tlconLFBjG2ehGPO1zwA-2FoU-3D" \
alt="" width="1" height="1" border="0" style="height:1px !important;width:1px \
!important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 \
!important;margin-right:0 !important;margin-left:0 !important;padding-top:0 \
!important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 \
!important;"/> </body></html>

_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

[prev in list] [next in list] [prev in thread] [next in thread] 