Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Panic on install on macOS #89

Closed
wgreenberg opened this issue Jan 16, 2025 · 3 comments · Fixed by #97
Closed

Panic on install on macOS #89

wgreenberg opened this issue Jan 16, 2025 · 3 comments · Fixed by #97

Comments

@wgreenberg
Copy link
Collaborator

Saw this at Shmoocon, someone's Apple Silicon macOS laptop wasn't able to run serial without panicking. iirc, the panic was about failing to decode UTF-8 characters in the response to the serial command.

@tigerbeard
Copy link

Just ran into this, too.
Macbook Air M3, Sonoma 14.6
Using the v0.2.4 release bundle.

Error at:

let responsestr = str::from_utf8(&response).expect("Failed to parse response");

Stack trace:

➜  releasebundle git:(main) ✗ RUST_BACKTRACE=full ./install-mac.sh
Using adb at ./platform-tools/adb
Force a switch into the debug mode to enable ADB
Device already in command mode. Doing nothing...
adb enabled, waiting for reboot... it's alive!
waiting for atfwd_daemon to startup... done!
./rootshell: 1 file pushed, 0 skipped. 3.6 MB/s (918472 bytes in 0.245s)
uid=0(root) gid=0(root)
we have root!
setting up rayhunter...
mkdir -p /data/rayhunter
thread 'main' panicked at serial/src/main.rs:81:49:
Failed to parse response: Utf8Error { valid_up_to: 116, error_len: Some(1) }
stack backtrace:
   0:        0x10460af38 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h7adefaad4a31afc0
   1:        0x10461e33c - core::fmt::write::h381c0b0ce6ab972a
   2:        0x104609180 - std::io::Write::write_fmt::h75af97148630d8d3
   3:        0x10460adec - std::sys::backtrace::BacktraceLock::print::h8baf33e22611de71
   4:        0x10460bca4 - std::panicking::default_hook::{{closure}}::h369c7295ef58c5b1
   5:        0x10460bae8 - std::panicking::default_hook::h50746358288a9d6a
   6:        0x10460c458 - std::panicking::rust_panic_with_hook::h7d795911432661cb
   7:        0x10460c10c - std::panicking::begin_panic_handler::{{closure}}::h36f15310ecbde379
   8:        0x10460b3fc - std::sys::backtrace::__rust_end_short_backtrace::heed121414170e0c7
   9:        0x10460bdc4 - _rust_begin_unwind
  10:        0x104624f74 - core::panicking::panic_fmt::h17b1b80ec02ffd19
  11:        0x104625240 - core::result::unwrap_failed::h6de8f20130c8e837
  12:        0x1045e264c - serial::main::ha654088b5c93223b
  13:        0x1045e0f6c - std::sys::backtrace::__rust_begin_short_backtrace::h6aa4da4dcb13e75f
  14:        0x1045e0f54 - std::rt::lang_start::{{closure}}::h3116ae15987bf856
  15:        0x104607348 - std::rt::lang_start_internal::h77891a2543177e4b
  16:        0x1045e31b0 - _main

Going to try installing from linux next, but if you want any help troubleshooting this further, lemme know.

@tigerbeard
Copy link

Rewrote the setup_rayhunter function to use the adb rootshell instead of the AT+SYSCMD serial commands and it appears to have worked.

setup_rayhunter_adb() {
    echo "setting up rayhunter..."
    _adb_shell "/bin/rootshell -c 'mkdir -p /data/rayhunter'"
    _adb_push config.toml.example /tmp/config.toml
    _adb_shell "/bin/rootshell -c 'mv /tmp/config.toml /data/rayhunter'"
    _adb_push rayhunter-daemon /tmp/rayhunter-daemon
    _adb_shell "/bin/rootshell -c 'mv /tmp/rayhunter-daemon /data/rayhunter'"
    _adb_push scripts/rayhunter_daemon /tmp/rayhunter_daemon
    _adb_shell "/bin/rootshell -c 'mv /tmp/rayhunter_daemon /etc/init.d/rayhunter_daemon'"
    _adb_push scripts/misc-daemon /tmp/misc-daemon
    _adb_shell "/bin/rootshell -c 'mv /tmp/misc-daemon /etc/init.d/misc-daemon'"
    _adb_shell "/bin/rootshell -c 'chmod 755 /etc/init.d/rayhunter_daemon'"
    _adb_shell "/bin/rootshell -c 'chmod 755 /etc/init.d/misc-daemon'"

    echo -n "waiting for reboot..."
    _adb_shell "/bin/rootshell -c 'shutdown -r -t 1 now'"

    # first wait for shutdown (it can take ~10s)
    until ! _adb_shell true 2> /dev/null
    do
        sleep 1
    done

    # now wait for boot to finish
    wait_for_adb_shell

    echo " done!"
}
setting up rayhunter...
./config.toml.example: 1 file pushed, 0 skipped. 3.4 MB/s (389 bytes in 0.000s)
mv: can't preserve ownership of '/data/rayhunter/config.toml': Operation not permitted
./rayhunter-daemon: 1 file pushed, 0 skipped. 1.4 MB/s (11541004 bytes in 8.013s)
mv: can't preserve ownership of '/data/rayhunter/rayhunter-daemon': Operation not permitted
./scripts/rayhunter_daemon: 1 file pushed, 0 skipped. 0.6 MB/s (580 bytes in 0.001s)
mv: can't preserve ownership of '/etc/init.d/rayhunter_daemon': Operation not permitted
./scripts/misc-daemon: 1 file pushed, 0 skipped. 6.5 MB/s (2302 bytes in 0.000s)
mv: can't preserve ownership of '/etc/init.d/misc-daemon': Operation not permitted
waiting for reboot... done!
checking for rayhunter server...success!
you can access rayhunter at http://localhost:8080

I can access the web interface, see the orca logo, etc., and it persists on reboots, soooooo.... I think that solved it, unless I'm missing a critical component of what the AT+SYSCMD command does differently.

@wgreenberg
Copy link
Collaborator Author

@tigerbeard that's extremely helpful, ty! some context on why we use the _at_syscmd command for the install process: some of the orbic devices seem to have a newer firmware version which prevents even a root user (i.e. our rootshell) from performing many of the install commands, but we found that executing those through the AT+CMD= serial prompt worked.

so unfortunately, i don't think your PR will be a universal fix for macOS users -- only those with the older firmware.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants