Re: HOWTO: USB boot on 8 GB RPi4 with no SD card

[Paul Mather <bsd-lists%gromit.dlib.vt.edu@localhost>]

On Jul 29, 2020, at 8:00 PM, Ted Spradley <tsprad%talent-free-studios.com@localhost> wrote:

> Following up to my follow-uo to myself:
> 
> On Wed, 29 Jul 2020 18:35:25 -0500
> Ted Spradley <tsprad%talent-free-studios.com@localhost> wrote:
> 
>> Following up to myself
>> 
>> On Tue, 28 Jul 2020 20:33:27 -0500
>> Ted Spradley <tsprad%talent-free-studios.com@localhost> wrote:
> 
>> "mount_ffs: /dev/dk1 on /mnt: incorrect super block"
>> 
>> I can mount the EFI (msdos) partition dk0 no problem. I should be able
>> to do this, shouldn't I?
> 
> I went ahead and copied the files to the EFI partition and tried it on the RPi4 and it worked! Is it because the filesystem gets expanded on the first boot that I couldn't mount it on another machine?


I don't know.  It's odd, because when I mount arm64.img (downloaded from the NetBSD daily builds) using vndconfig I get the same error ("incorrect super block") when trying to mount the FFS file system.  I don't get an error when mounting the msdos EFI partition from arm64.img.

I say it's odd because when I fsck the FFS file system it says it is clean.  When I forcibly fsck it, no errors are reported.

I can only assume that the /etc/rc.d/resize_root service (which basically invokes the resize_ffs command) fixes the mount problem as a side-effect of resizing the file system.

When I looked at the FFS root file system in arm64.img its block and fragment size looked larger to me than I expected:

=====
arq ~# dumpfs /dev/wedges/netbsd-root
file system: /dev/wedges/netbsd-root
format  FFSv1
endian  little-endian
magic   11954           time    Wed Jul 29 04:14:31 2020
superblock location     8192    id      [ 5f212fe7 5da47568 ]
cylgrp  dynamic inodes  4.4BSD  sblock  FFSv2   fslevel 4
nbfree  1225    ndir    2267    nifree  111550  nffree  5
ncg     1       size    145792  blocks  143487
bsize   65536   shift   16      mask    0xffff0000
fsize   8192    shift   13      mask    0xffffe000
frag    8       shift   3       fsbtodb 4
bpg     18224   fpg     145792  ipg     145920
minfree 5%      optim   time    maxcontig 1     maxbpg  16384
symlinklen 60   contigsumsize 0
maxfilesize 0x04001000400bffff
nindir  16384   inopb   512
avgfilesize 16384       avgfpdir 64
sblkno  8       cblkno  16      iblkno  24      dblkno  2304
sbsize  8192    cgsize  40960
csaddr  2304    cssize  8192
cgrotor 0       fmod    0       ronly   0       clean   0x01
wapbl version 0x0       location 0      flags 0x0
wapbl loc0 0    loc1 0  loc2 0  loc3 0
usrquota 0      grpquota 0
flags   none
[[...]]
=====

The FFS block size of 64K and fragment size of 8K are double the maximum you'd get by default (32K and 4K respectively) based upon the total file system size according to the newfs man page.

(Note: I mounted the arm64.img disk image using vndconfig and didn't explicitly specify a block size and geometry.  It could be that might cause problems in my case.)

Cheers,

Paul.