Skip to content

Conversation

oliora
Copy link

@oliora oliora commented Feb 9, 2025

In our workflow we run rpi-sb-provisioner.sh manually and if anything went wrong it's inconvenient to gather logs from multiple places.

For die function it looks more logical to also output the die reason to stderr rather than to debug "channel".

@oliora oliora force-pushed the improve-logging branch 2 times, most recently from 684b74d to a68ea53 Compare February 13, 2025 13:48
@tdewey-rpi
Copy link
Collaborator

Thanks for the submission @oliora

Having considered the change and implications, I am not inclined to accept this PR as-is:

  1. I only have the bandwidth to support rpi-sb-provisioner in the flow as described (automated hands-off with complete control).
  2. The mechanism you're using, as it is not supported, is likely to be broken imminently by our upcoming 2.0 release, which will introduce multiple changes to the provisioning flow for easier debugging, faster flashing, and more features
  3. This change could also have been implemented by testing $DEBUG, and then redirecting the messages to that location - which would have been something I could forward-port without worrying about expanding the support cone.

@oliora
Copy link
Author

oliora commented Feb 19, 2025

@tdewey-rpi fair enough but still would be useful if all logging is duplicated to a single place unless it's something that is not trivial to implement. Even if rpi-sb-provisioner.sh is not supposed to be called directly its output may be observed via journalctl to troubleshoot.

Please also remember that it's not possible to provision RPi5 automatically since it does not have a jumper for OTG boot so provisioning needs to be assisted with rebooting the device in OTG mode when needed.

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 this pull request may close these issues.

2 participants