Re: Exec format error from armv7 snapshot on RPi2
- Reply: bob prohaska : "Re: Exec format error from armv7 snapshot on RPi2"
- In reply to: bob prohaska : "Re: Exec format error from armv7 snapshot on RPi2"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 01 Jun 2025 23:30:26 UTC
On Jun 1, 2025, at 14:56, bob prohaska <fbsd@www.zefox.net> wrote: > 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-( 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? 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. > So far my luck with snapshots has been very good, but they > aren't guaranteed. Perhaps I should just wait for the next..... Again, I suggest mounting the media on a aarch64 system capable of armv7 user space execution and seeing how things look based on that kernel being involved. > 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.... https://download.freebsd.org/ftp/snapshots/arm/armv7/ISO-IMAGES/15.0/FreeBSD-15.0-CURRENT-arm-armv7-GENERICSD-20250522-30fd79b0c0a3-277396.img.xz vs. https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/15.0/FreeBSD-15.0-CURRENT-arm-armv7-GENERICSD-20250522-30fd79b0c0a3-277396.img.xz show the same size. Have you downloaded and diff'd them in your context? (I count checksum checking as an example of such activity.) === Mark Millard marklmi at yahoo.com