fdisk head inconsistency

[Mauro Condarelli]

On 10/1/19 12:30 AM, Michael Conrad wrote:
>
> 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.
>
Truth is util-linux fdisk and BusyBox fdisk have very different "ideas"
about SD geometry.
The former consistently swears I have "Geometry: 245 heads, 62
sectors/track, 1021 cylinders",
while the latter insists on "Geometry: 4 heads, 16 sectors/track, 242560
cylinders".
Physically the *same* card.
Of course Debian Linux is accessing the card through a USB card reader
(hama a4504143, if it matters), while embedded Linux is accessing it
directly via MMC interface present on uController (MT7628)... which
could be a significant difference.
>
> 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.
>
I am fully aware of that, but it is beyond the point (see below).
>
> 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 ;-)
>
I can try, but it won't help me.
I need to do this in a script and to use BB fdisk I need to print
previous partition data and manually set start of next one to
prev_end+1. This is "inconvenient" to do in a shell script.
IMHO one of the two programs is severely broken and I would like to
understand which and how to fix it.
Right now my "solution" is to disable BB fdisk and to install util-linux
one, but that, of course, has a cost in a severely constrained embedded
system with 16M total Flash space.

Any advice welcome.
>
> -Mike
>
/mauro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20191002/5172f78c/attachment.html>