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

[Known issue] Cannot reboot to productive from ifm3d CLI #416

Open
lola-masson opened this issue Aug 9, 2023 · 5 comments
Open

[Known issue] Cannot reboot to productive from ifm3d CLI #416

lola-masson opened this issue Aug 9, 2023 · 5 comments
Labels
bug no-stale Issue will not be marked as stale

Comments

@lola-masson
Copy link
Member

Describe the bug
When the O3R platform is in recovery mode, it is not possible to reboot it from the command line interface using ifm3d reboot.

To Reproduce
Steps to reproduce the behavior.

  1. Reboot the O3R to recovery mode: ifm3d reboot --recovery
  2. Try to reboot to productive: ifm3d reboot
  3. An error is raised:
$ ifm3d reboot
2023-08-09 15:28:56 ERROR [../modules/device/src/libifm3d_device/xmlrpc_wrapper.hpp:98] http://192.168.0.69:80/api/rpc/v1/com.ifm.efector/ -> getParameter: Unable to transport XML to server and get XML response back.  libcurl failed to execute the HTTP POST transaction, explaining:  Failed to connect to 192.168.0.69 port 80: Connection refused
2023-08-09 15:28:56 WARN [../modules/device/src/libifm3d_device/device.cpp:176] Could not probe device type: Lib: XMLRPC Timeout - can you `ping' the sensor?
ifm3d error: -100001
Lib: XMLRPC Timeout - can you `ping' the sensor?

Expected behavior
The system should reboot into productive

Configuration/Environment:

  • OS: Ubuntu 20.04
  • ifm3d version: 1.3.3
  • using ROS: no
  • O3R firmware version >= 1.x.x

Comments:
If a firmware update is performed while the system is in recovery mode, the reboot to productive will happen properly.

@lola-masson lola-masson added the bug label Aug 9, 2023
@graugans
Copy link
Member

Hej @lola-masson,

thanks for pointing this out. May I ask a question why one would boot into recovery at all? I suspect that this may is an accidential action or at least a missunderstanding of what recovery does mean.

I currently see no reason to have ifm3d reboot --recovery at all. It was needed in the past when we had no swupdate command.

Given the fact that one has a the intention to manually install the SWU image over the Web-UI there is the restart button which reboots in productive mode.

My proposal for this is the removal of the --recovery flag for the reboot command. So there is no need to add a rather complex logic in the command line client to distiguish between the recovery system and the productive system.

In the meantime one can use this command to reboot into productive mode:

export no_proxy=172.25.125.65
curl -X POST http://172.25.125.65:8080/restart --data {}

Please use the IP address which is approriate for you.

@BigBoot
Copy link
Contributor

BigBoot commented Aug 10, 2023

There is also ifm3d swupdater --reboot to get out of the recovery.

I still think it would be a good idea to have ifm3d reboot to handle both cases.
All of the logic is already implemented in the SWUpdater module so complexity should be fairly small and I think having a single "reboot" command that handles all cases is quite nice especially because I feel a user could easily get "stuck" if he ended up in recovery mode for whatever reason.

@graugans
Copy link
Member

Thanks for pointing out ifm3d swupdater --reboot. Nevertheless I have the impression there is also a lack of documentation though what the recovery system is all about.... It is a more a software update system than a recovery systenm. It may help to recover from a failed software update but does not perform a device recovery/self healing. It does boot into the update mode where we do use SWUpdate

@lola-masson
Copy link
Member Author

Thank you guys for highlighting the workarounds. It will come in quite handy in case one mistakenly end up in recovery mode.

@github-actions
Copy link

This issue is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale label Sep 11, 2023
@BigBoot BigBoot added no-stale Issue will not be marked as stale and removed stale labels Sep 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug no-stale Issue will not be marked as stale
Projects
None yet
Development

No branches or pull requests

3 participants