Skip to content
Source
Sign inSign up

pingdotgg

t3codePublic Synced with GitHub
Popular #1 Fork 0

[Bug]: oracle cloud arm server install t3 cli failed #34328

Send to my agent
Closedborgle(GitHub profile, opens in a new tab) opened this issue 2 comments
borgle(GitHub profile, opens in a new tab)commented

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

I got this messages when i install t3 cli using shell.

[dev@inst5 ~]$ curl -fsSL https://t3.codes/install.sh | sh

  ██████████ ████████
      ███       ▄██▀       T3 Code
      ███       ████▄      CLI installer
      ███    ▄     ███
      ███    ███████▀

  Installing T3 Code 0.1.8

  ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 100%  133.0 / 133.0 MB
  Extracting T3 Code...sh: line 260: /home/dev/.t3/runtime/versions/.staging-Ugvh9g/t3: cannot execute binary file: Exec format error

t3 install: the downloaded executable does not run

Expected behavior

Installation successful.

Actual behavior

the downloaded executable does not run

Impact

Blocks work completely

Version or commit

0.1.8

Environment

No response

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

  1. borgle(GitHub profile, opens in a new tab) added labelsbug

  2. borgle(GitHub profile, opens in a new tab) added labelsneeds-triage

  3. juliusmarmingecommented

    This is the same problem as #12628, so I'm closing it in favour of that one. If it is different, say how and it will be reopened.

  4. juliusmarminge closed this

  5. borgle(GitHub profile, opens in a new tab)commented

    @juliusmarminge

    Bug Description

    The pre-built t3-0.1.9-linux-arm64 binary fails immediately upon execution on native aarch64 Linux machines with: cannot execute binary file: Exec format error

    Root Cause (Corrupted ELF PT_NOTE Segment)

    Inspecting the binary with file and readelf -l reveals that the ELF header in the linux-arm64 release artifact is malformed during the packaging/bundling step (likely when injecting the JS bundle/resources into the executable):

    1. file output: t3: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, with debug_info, not stripped, too many notes (256)

    2. readelf -l t3 output (relevant segments):

      Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  ...
  LOAD           0x0000000008f80000 0x0000000010f60000 0x0000000010f60000
                 0x00000000011e0000 0x00000000011e0000  R      0x1000
  NOTE           0x0000000008f80000 0x0000000010f60000 0x0000000010f60000
                 0x00000000011d7b7c 0x00000000011d7b7c  R      0x4

    The PT_NOTE segment (FileSiz: 0x11d7b7c, ~18.7 MB) has been erroneously expanded to encompass the appended payload/bundle data instead of staying a valid ELF note section.

    When executing an arm64 binary, the Linux kernel's binfmt_elf loader (parse_elf_properties()) strictly parses all PT_NOTE segments to check for GNU_PROPERTY_TYPE_0 (BTI/PAC hardware features). Encountering an ~18.7 MB malformed PT_NOTE causes the kernel to reject the binary with -ENOEXEC (Exec format error).

    Environment

    • Artifact: t3-0.1.9-linux-arm64
    • Architecture: aarch64 (4KB page size, getconf PAGESIZE = 4096)
    • Kernel: 6.12.0-204.92.4.3.1.el10uek.aarch64

    Suggested Fix

    Please check the bundling/compilation step in the CI/CD pipeline for linux-arm64 (e.g., bun build --compile or post-build ELF patching) to ensure payload data is appended cleanly without corrupting or extending the PT_NOTE program header size, and verify execution on a real Linux aarch64 runner.

Sign in to join this conversation.