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

Serial binary needs to be more robust #88

Open
CoD-Segfault opened this issue Jan 16, 2025 · 3 comments
Open

Serial binary needs to be more robust #88

CoD-Segfault opened this issue Jan 16, 2025 · 3 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@CoD-Segfault
Copy link

I'm running Linux Mint 22 and have encountered an error during the installation. Everything seems to have installed ok, it's just that it seems to panic during a reboot.

~/Downloads/release$ RUST_BACKTRACE=full ./install-linux.sh 
Using adb at /usr/bin/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. 2820.4 MB/s (918472 bytes in 0.000s)
uid=0(root) gid=0(root)
we have root!
./config.toml.example: 1 file pushed, 0 skipped. 10.1 MB/s (389 bytes in 0.000s)
./rayhunter-daemon: 1 file pushed, 0 skipped. 1.6 MB/s (11541004 bytes in 7.024s)
./scripts/rayhunter_daemon: 1 file pushed, 0 skipped. 11.6 MB/s (580 bytes in 0.000s)
./scripts/misc-daemon: 1 file pushed, 0 skipped. 39.4 MB/s (2302 bytes in 0.000s)
waiting for reboot...thread 'main' panicked at serial/src/main.rs:79:10:
Failed to read response: Timeout
stack backtrace:
   0:     0x60c0bc903dda - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h5b6bd5631a6d1f6b
   1:     0x60c0bc91eff3 - core::fmt::write::h7550c97b06c86515
   2:     0x60c0bc901a63 - std::io::Write::write_fmt::h7b09c64fe0be9c84
   3:     0x60c0bc903c22 - std::sys::backtrace::BacktraceLock::print::h2395ccd2c84ba3aa
   4:     0x60c0bc904bcc - std::panicking::default_hook::{{closure}}::he19d4c7230e07961
   5:     0x60c0bc904a12 - std::panicking::default_hook::hf614597d3c67bbdb
   6:     0x60c0bc9051a7 - std::panicking::rust_panic_with_hook::h8942133a8b252070
   7:     0x60c0bc90503a - std::panicking::begin_panic_handler::{{closure}}::hb5f5963570096b29
   8:     0x60c0bc9042b9 - std::sys::backtrace::__rust_end_short_backtrace::h6208cedc1922feda
   9:     0x60c0bc904ccc - rust_begin_unwind
  10:     0x60c0bc8d67e0 - core::panicking::panic_fmt::h0c3082644d1bf418
  11:     0x60c0bc8d6b56 - core::result::unwrap_failed::hd20b4aa073bda1e2
  12:     0x60c0bc8d81e6 - serial::main::h301e0f32046d805a
  13:     0x60c0bc8d8b03 - std::sys::backtrace::__rust_begin_short_backtrace::h787e527834a42f8d
  14:     0x60c0bc8d8af9 - std::rt::lang_start::{{closure}}::h9f55858da7778375
  15:     0x60c0bc8ff65e - std::rt::lang_start_internal::h1c66660c99c8424c
  16:     0x60c0bc8d8ae5 - main
  17:     0x75da1c82a1ca - __libc_start_call_main
                               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  18:     0x75da1c82a28b - __libc_start_main_impl
                               at ./csu/../csu/libc-start.c:360:3
  19:     0x60c0bc8d6e95 - _start
  20:                0x0 - <unknown>
@wgreenberg
Copy link
Collaborator

thanks for the report! the good news is, it looks like the installer successfully got the files installed on the device and mv/chown'd them, so your device should effectively be provisioned. if you reboot your device, does a green line eventually show at the top of the screen?

@CoD-Segfault
Copy link
Author

Yes, it does appear to be running correctly. I see the green bar on screen and the web interface does load.

@cooperq cooperq added enhancement New feature or request help wanted Extra attention is needed labels Jan 30, 2025
@cooperq cooperq changed the title Error on install - panic at serial/src/main.rs Serial binary needs to be more robust Jan 30, 2025
@cooperq
Copy link
Collaborator

cooperq commented Jan 30, 2025

The essential problem here is that the serial binary is pretty brittle and prone to timing out or having other issues like #89 where it couldn't parse UTF8 output. In this case it seems like the serial command is sending a reboot message and the reboot happens before the ack was sent. Serial could fail more gracefully in this case. A good issue for someone else to take on would be to improve serials error handling and responses to be more user friendly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants