fdisk head inconsistency

[Michael Conrad]

On 10/1/2019 6:58 PM, Mauro Condarelli wrote:
> 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.

I just tried two versions of busybox fdisk (1.19.0, and 1.30.1) vs. two 
versions of util-linux fdisk (2.19, 2.34) and all four tools agree about 
the drive geometry of any drive I've tested on. I think you'll just need 
to do more experiments and see if you can pin down the problem on your end.

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

Very inconvenient to do in a shell script, I agree :-) and in fact I'd 
advise against parsing fdisk with a shell at all.  The four tools I just 
tested each had a different output format! That's a pretty good 
indication it could change in the future and break your script and blow 
away someone's data.  Also that 'bootable' flag is pretty annoying 
because its presence/absence changes the number of fields on the line.  
There's an "sfdisk" which is better for scripting, but no busybox applet 
for it. Still, it is safer than scripting input for fdisk.

You don't need to give CHS geometry to fdisk, just sector numbers.  You 
can get sector numbers direct from the kernel using 
/sys/class/block/$DEV/start and /sys/class/block/$DEV/size.  (or on old 
kernels, /sys/block/$DEV/$PART_DEV/{start,size} ).  You could then 
construct a script for fdisk and pipe that in.  Of course, this depends 
on the kernel having read the partition table, which might not be the 
case if you're formatting something from scratch, but there's 
'partprobe' for that.  You also have to worry about what kind of 
partition table it is, because the kernel can parse GPT partitions and 
then if you try forcibly adding a new one with fdisk it might blow away 
the GPT table.  I just checked, and 'gdisk' isn't available from busybox 
yet... so there might not be a safe way to do this with pure busybox tools.

Hope that helps.

-Mike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20191002/e72309dd/attachment.html>