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
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
