Richard Sent <rich...@freakingpenguin.com> writes: > > Running fdisk on the image produces (emulated build due to > cross-compilation failures): > > gibraltar :( guix$ fdisk -l $(guix system image > gnu/system/images/pinebook-pro.scm --system=aarch64-linux) > Disk > /gnu/store/832w3d7dh2vdfdm2qdv5025w8sfm8zrl-pinebook-pro-barebones-raw-image: > 1.62 GiB, 1741840384 bytes, 3402032 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disklabel type: dos > Disk identifier: 0x00000000 > > Device > Boot Start End Sectors Size Id Type > /gnu/store/832w3d7dh2vdfdm2qdv5025w8sfm8zrl-pinebook-pro-barebones-raw-image1 > * 18432 3402031 3383600 1.6G 83 Linux > > > I can't figure out where that 18432 offset is coming from. > ... > I may very well be missing something here, particularly with > interpreting the fdisk output.
Well, I did figure out one thing. fdisk is giving the offset in sector size, NOT bytes. With a sector size of 512 bytes, the offset in bytes is 18432*512, or 9437184 bytes. This is what we expect. Yay. I still suspect u-boot is overwriting part of the root FS in this particular image. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
