Re: How does system-disk-image work with embedded-style boot loaders?

[Richard Sent <richard@freakingpenguin.com>]

Richard Sent <richard@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.