Re: Exec format error from armv7 snapshot on RPi2

On Sun, Jun 01, 2025 at 04:30:26PM -0700, Mark Millard wrote:
> On Jun 1, 2025, at 14:56, bob prohaska <[email protected]> wrote:
> 
> > On Sat, May 31, 2025 at 07:10:02PM -0700, Mark Millard wrote:
> >> On May 31, 2025, at 13:43, bob prohaska <[email protected]> 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-(
> 
> Actually the original complaint is about file , not about
> /usr/bin/resizewin .
> 
> That means having an independent context's file command
> used for the likes of:
> 
> # file /mnt/usr/bin/file
> 
> is basically required for what I was trying to have checked.
> 
> So: What of the mounting the armv7 boot/world media on an
> aarch64 system capable of armv7 user space execution and
> testing from that context?
> 
> > Running tcsh is different:
> > root@:/ # file /usr/bin/resizewin
> > /usr/bin/file: 1: Syntax error: word unexpected (expecting ")")
> 
> 
> That suggests tcsh classified file as a text file.
> 
> > 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.
> 
> Wow.
> 
> > 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.
> 
> The "repeatedly" indicates that somewhat later errors are again
> found and the cycle repeats?
>

No, just one request to "re-run fsck", after that all was well. 

> It would seem that getting any errors indicates problems that
> should not have been present, even if there was not a
> "repeatedly" context showing up.
> 
> > Am I right in thinking this
> > largely exonerates the download and microSD integrity?
> 
> As I understand your wording, no.

It looks now as if the microSD card was corrupted, likely
by the usb-microsd adapter. A subsequent image file write
using the RaspBerry Pi Imager reported a write failure.
A different card produced the same error, but a different
adapter reported no error and the image, of 14.3-RC1, boots
and runs correctly. 

Thanks for writing, and apologies for all the noise!

bob prohaska