Serial binary needs to be more robust

[CoD-Segfault]

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]

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]

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

[cooperq]

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.

[duckduckgrayduck]

I've experienced the same on Pop OS. Closed my ticket due to being a duplicate

[gaykitty]

I think I might take a crack at this. Improve the error messages, and don't panic. @cooperq any particular reason a timeout of 1 second is used? Should it be longer?

[cooperq]

no particular reason for that timeout. I think that one of our common issues here stems from the fact that the orbic reboots before it can respond to the command, so a timeout would be expected and shouldn't panic in that case, which is maybe addressed by #232 but I'm not sure.

[gaykitty]

Maybe we add a flag to serial where it will not error if it doesn't receive a response that we use for the shutdown command. fwiw I've never been able to recreate this issue, so it's not consistant.

[untitaker]

I think this might no longer be relevant, but not 100% sure.

[cooperq]

closing this since we no longer use the serial binary!