Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm, arm64, riscv [odd alignment for SBC images]

On 2022-Jul-29, at 13:49, Glen Barber <gjb@FreeBSD.org> wrote:

> On Wed, Jul 20, 2022 at 10:08:20AM -0700, Mark Millard wrote:
>> Would it seem appropriate to use a week (this week?) to do all
>> the snapshot builds with the builders all set to have
>> kern.geom.part.mbr.enforce_chs=0 and see what breaks, if anything?
>> (Sort of a snapshot exp run.)
>> 
>> More than just the SBC images might be involved for
>> kern.geom.part.mbr.enforce_ch consequences, for all I know.
>> 
> 
> Hey, Mark.
> 
> New snapshots for 13 and 14 are up now.  Is it possible for you to check
> if the issues you had run into are indeed resolved, after setting
> kern.geom.part.mbr.enforce_chs=0 on the builders?
> 

Well, it is a mix, I think (unsure).

I started with:

# dd if=FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220729-db2eff1cff8-251976.img of=/dev/da0 conv=sync,fsync bs=1m status=progress
  5222957056 bytes (5223 MB, 4981 MiB) transferred 21.027s, 248 MB/s
5120+0 records in
5120+0 records out
5368709120 bytes transferred in 21.816899 secs (246080301 bytes/sec)

I plugged the USB3 SSD into an old 8 GiByte RPi4B and it booted.

. . .
Starting file system checks:
/dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ufs/rootfs: clean, 499417 free (1153 frags, 62283 blocks, 0.1% fragmentation)
Growing root partition to fill device
random: randomdev_wait_until_seeded unblock wait
random: randomdev_wait_until_seeded unblock wait
random: unblocking device.
GEOM_PART: ufs/rootfs was automatically resized.
  Use `gpart commit ufs/rootfs` to save changes or `gpart undo ufs/rootfs` to revert them.
da0s2 resized
super-block backups (for fsck_ffs -b #) at:
 11524224, 12804672, 14085120, 15365568, 16646016, 17926464, 19206912,
. . .

But, after logging in:

root@generic:~ # gpart show
=>       63  468862065  da0  MBR  (224G)
         63       1985       - free -  (993K)
       2048     102400    1  fat32lba  [active]  (50M)
     104448  468757680    2  freebsd  (224G)

root@generic:~ # gpart show -p
=>       63  468862065    da0  MBR  (224G)
         63       1985         - free -  (993K)
       2048     102400  da0s1  fat32lba  [active]  (50M)
     104448  468757680  da0s2  freebsd  (224G)

So 1985 and 2048 are there, as intended.

But no explicit da0s2 BSD or da0s2a freebsd-ufs shows up
in gpart show's output.

I wonder if this is because of a lack of a distinct
starting offset vs. the BSD. For example, the old 2016
and 2079 alignment had showed:

=>        0  468757737   da0s2  BSD  (224G)
          0         57          - free -  (29K)
         57  468757680  da0s2a  freebsd-ufs  (224G)

where the 57 was, appearently, for alignment. May be now
the distance from the da0s2 to da0s2a is zero and so
BSD and its contained da0s2a is not now shown?

I've yet to try the 14-CURRENT.

===
Mark Millard
marklmi at yahoo.com