Re: Exec format error from armv7 snapshot on RPi2

On Sat, May 31, 2025 at 07:10:02PM -0700, Mark Millard wrote:
> On May 31, 2025, at 13:43, bob prohaska <fbsd@www.zefox.net> wrote:
> 
> > Just downloaded 
> > FreeBSD-15.0-CURRENT-arm-armv7-GENERICSD-20250522-30fd79b0c0a3-277396.img,
> > wrote it to a microSD card and tried to boot an older (so armv7) Raspberry
> > Pi 2.
> > 
> > It boots hands off, but complains about "exec format error" on some but
> > not all commands. The first occurrence was during boot -s:
> > ...
> > ...
> > umass0 on uhub2
> > umass0: <JMicron SABRENT, class 0/0, rev 2.10/12.14, addr 6> on usbus0
> > umass0:  SCSI over Bulk-Only; quirks = 0x0
> > umass0:0:0: Attached to scbus0
> > 
> > -sh: /usr/bin/resizewin: Exec format error
> > root@:/ # da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> > da0: <SABRENT  1214> Fixed Direct Access SPC-4 SCSI device
> > da0: Serial Number 000000000000A
> > ...
> > ...
> > 
> > Many more appear during boot to multi-user. Nonetheless,
> > it puts a login prompt on the serial console. 
> > 
> > Attempt to log in look like:
> > 
> > login: root
> > pid 664 (login), jid 0, uid 0: exited on signal 11 (core dumped)
> > 
> > FreeBSD/arm (generic) (ttyu0)
> > 
> > login: 
> > 
> > Any insights appreciated. I understand armv7 is on its last legs,
> > but was hoping not yet.
> 
> If you can get to the point of doing such, what does:
> 
> # file /usr/bin/resizewin
> 
> report?
> 
Another Exec format error 8-(

Running tcsh is different:
root@:/ # file /usr/bin/resizewin
/usr/bin/file: 1: Syntax error: word unexpected (expecting ")")

Running uname -a is more different, if not informative:
root@:/ # uname -a
/usr/bin/uname: dsp_traceflagp_tracevpvnodep_tracecredp_textvpp_lockp_sigiolstslh_firstsio_usiu_procsiu_pgrppg_hashpg_memberspg_sessions_counts_leaders_ttyvps_ttydpcdev_privs_ttypt_mtxt_mtxobjt_listt_revokecntt_inqti_firstblockttyinq_blockti_startblockti_reprintblockti_lastblockti_beginti_linestartti_reprintti_endti_nblocksti_quotattyinqt_inlowt_outqto_firstblockttyoutq_blockto_lastblockto_beginto_endto_nblocksto_quotattyoutqt_outlowt_inwaitt_outwaitt_outserwaitt_bgwaitt_dcdwaitt_inpollsi_tdlistselfdselfdlistsi_notekl_listkn_linkkn_selnextkn_knlistkn_tqekn_kqkqueuekn_keventidentu_short__intptr_tkn_statuskn_sfflagskn_sdatakn_ptrfilep_procp_aioaiocblistp_lioaioliojobp_nexttimekn_fopf_isfdf_attachf_detachf_eventf_touchu_longfilteropskn_hookkn_hookidknotekl_lockkl_unlockkl_assert_lockedkl_assert_unlockedkl_lockargsi_mtxselinfot_outpollt_sigiot_termiost_winsizews_rowws_colws_xpixelws_ypixelt_columnt_writepost_compatflagst_termios_init_int_termios_lock_int_termios_init_outt_termios_lock_outt_devswtsw_flagstsw_opentsw_open_ttsw_closetsw_close_ttsw_outwakeuptsw_outwakeup_ttsw_inwakeuptsw_inwakeup_ttsw_ioctlcaddr_ttsw_ioctl_ttsw_cioctltsw_cioctl_ttsw_paramtsw_param_ttsw_mode..........
Eventually it ends with Argument list too long and returns a prompt.

Two suspects are a corrupt download or a faulty microSD card.
However, running fsck -fy repeatedly finds, fixes and does not
find again the errors it fixed. Am I right in thinking this
largely exonerates the download and microSD integrity?

So far my luck with snapshots has been very good, but they
aren't guaranteed. Perhaps I should just wait for the next.....

There do seem to be two paths to armv7 snapshots. One is
/snapshots/arm/armv7/ISO-IMAGES/15.0/
and the other is
/snapshots/ISO-IMAGES/15.0/
Could the files possibly be different? The directory contents
certainly look different.... 

Thanks for writing!

bob prohaska