for the version from the v2023.9.0 tag in the repository). The installation bootstrap script performs the following steps:
1. The script loads some [parameters](#script-parameters) (set by environment variables and/or corresponding command-line arguments) which set the behavior of the script.
2. The script installs `git`, if it was not already installed (as is the case on the "Lite" image of the Raspberry Pi OS); if the `yes` parameter was not set and `git` was not already installed, the script will first ask the user to confirm that they wish to install `git` before the script continues. `git` is required to resolve version query parameters provided to the script, so that the script can determine how to download the requested version of the PlanktoScope OS's distro setup scripts.
3. The script clones a minimal ["mirror"](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---mirror) copy of the specified repository (set by the `repo` parameter) of distro setup scripts to a temporary directory (i.e. a directory created in `/tmp`). This "mirror" copy is used to:
-
- - Resolve the version query parameters (`version-query`, `query-type`, and - when `query-type` is `tag` - `tag-prefix`) into a specific commit hash for the repository.
-
- - Determine a [*(pseudo-)version*](https://git-scm.com/docs/git-describe#_examples) string for the resolved commit based on the last release tag (whose name is prefixed with the `tag-prefix` parameter) ancestral to that commit.
+
+ - Resolve the version query parameters (`version-query`, `query-type`, and - when `query-type` is `tag` - `tag-prefix`) into a specific commit hash for the repository.
+
+ - Determine a [_(pseudo-)version_](https://git-scm.com/docs/git-describe#_examples) string for the resolved commit based on the last release tag (whose name is prefixed with the `tag-prefix` parameter) ancestral to that commit.
4. The script clones a copy of the specified repository (set by the `repo` parameter) to a temporary directory and checks out the specific commit which was resolved by the previous step; if the `yes` parameter was not set, the script will first ask the user to confirm that they wish to download the resolved commit of the distro setup scripts before the script continues. Because the repository containing the distro setup scripts may have many large files (e.g. image files for documentation) which are unrelated to the distro setup scripts, this step only downloads files in the specific commit needed for the distro setup scripts.
@@ -108,7 +108,7 @@ This phase performs steps which might (in theory) be useful for other projects w
This phase performs steps specific to the PlanktoScope's hardware:
-- Setup of the PlanktoScope hardware controller: various Python tools (`pip`, `venv`, and `poetry`) are installed using APT, a hard-coded version of a hard-coded Git repository (namely [github.com/PlanktoScope/device-backend](https://github.com/PlanktoScope/device-backend)) is cloned, and various dependencies (both system libraries and Python packages) of the hardware controller are installed. The `planktoscope-org.device-backend.controller-adafruithat.service` and `planktoscope-org.device-backend.controller-planktoscopehat.service` systemd services are created, and the appropriate one is enabled depending on which HAT the PlanktoScope OS is being installed for. The appropriate hardware configuration file will also be copied into the location expected by the hardware controller. (Note: once the PlanktoScope hardware controller is containerized and managed in Forklift, this step will be eliminated.)
+- Setup of the PlanktoScope hardware controller: various Python tools (`pip`, `venv`, and `poetry`) are installed using APT, a hard-coded version of a hard-coded Git repository (namely [github.com/PlanktoScope/device-backend](https://github.com/PlanktoScope/device-backend)) is cloned, and various dependencies (both system libraries and Python packages) of the hardware controller are installed. The appropriate hardware configuration file will also be copied into the location expected by the hardware controller. (Note: once the PlanktoScope hardware controller is containerized and managed in Forklift, this step will be eliminated.)
- Setup of GPIO stepper initialization at boot: a systemd service is created to release the stepper motors at startup. (Note: this service currently doesn't work and will eventually be fixed, deleted, or replaced.)
diff --git a/documentation/docs/reference/software/subsystems/startup.md b/documentation/docs/reference/software/subsystems/startup.md
index 412b7eff2..71686060e 100644
--- a/documentation/docs/reference/software/subsystems/startup.md
+++ b/documentation/docs/reference/software/subsystems/startup.md
@@ -22,7 +22,7 @@ The PlanktoScope OS's setup scripts provide some system services which are not m
- `overlay-usr.service` runs after `overlay-sysroot.service` and before `overlay-fs.target`.
-- `overlay-etc.service` runs after `overlay-sysroot.service` and `systemd-machine-id-commit.service` , and before `systemd-sysctl.service` and `overlay-fs.target`.
+- `overlay-etc.service` runs after `overlay-sysroot.service` and `systemd-machine-id-commit.service` , and before `systemd-sysctl.service` and `overlay-fs.target`.
- `start-overlaid-units.service` runs after `overlay-fs.target` and `basic.target`.
@@ -54,7 +54,7 @@ For descriptions of the various targets (e.g. `sysinit.target`, `network-pre.tar
### User interface
-- `assemble-cockpit-config.service`, `assemble-cockpit-origins.service`, and `assemble-cockpit-origins-templated.service` update Cockpit's configuration file from drop-in config file fragments in `/etc/cockpit/cockpit.conf.d`, `/etc/cockpit/origins.d`, and `/etc/cockpit/origins-templates.d`, respectively. They run after `generate-machine-name.service` and `generate-hostname-templated.service` and before `cockpit.service`.
+- `assemble-cockpit-config.service`, `assemble-cockpit-origins.service`, and `assemble-cockpit-origins-templated.service` update Cockpit's configuration file from drop-in config file fragments in `/etc/cockpit/cockpit.conf.d`, `/etc/cockpit/origins.d`, and `/etc/cockpit/origins-templates.d`, respectively. They run after `generate-machine-name.service` and `generate-hostname-templated.service` and before `cockpit.service`.
- `ensure-ssh-host-keys.service` regenerates the SSH server's host keys if the keys are missing, and runs before `ssh.service`.
@@ -62,4 +62,4 @@ For descriptions of the various targets (e.g. `sysinit.target`, `network-pre.tar
### PlanktoScope-specific hardware abstraction
-- The PlanktoScope hardware controller (managed by `planktoscope-org.device-backend.controller-{adafruithat or planktoscopehat}.service`) starts after `forklift-apply.service` (which manages Mosquitto) and `nodered.service` have started, to ensure that the PlanktoScope hardware controller broadcasts the detected camera model name only after the PlanktoScope Node-RED dashboard is ready to receive that broadcast. (In the future the PlanktoScope hardware controller will instead be run as a Docker container and will be managed by `forklift`.)
+- The PlanktoScope hardware controller (managed by `planktoscope-org.device-backend.controller.service`) starts after `forklift-apply.service` (which manages Mosquitto) and `nodered.service` have started, to ensure that the PlanktoScope hardware controller broadcasts the detected camera model name only after the PlanktoScope Node-RED dashboard is ready to receive that broadcast. (In the future the PlanktoScope hardware controller will instead be run as a Docker container and will be managed by `forklift`.)
diff --git a/software/node-red-dashboard/adafruithat/flows.json b/software/node-red-dashboard/adafruithat/flows.json
index 8e03caceb..2271db36d 100644
--- a/software/node-red-dashboard/adafruithat/flows.json
+++ b/software/node-red-dashboard/adafruithat/flows.json
@@ -7313,7 +7313,7 @@
"order": 1,
"width": 0,
"height": 0,
- "format": "\n The PlanktoScope software application consists of three components: a Node-RED dashboard which provides the user interface you're using; a Hardware Controller\n which executes commands sent from the Node-RED dashboard for hardware control and image acquisition; and a Segmenter which processes an acquired dataset of\n images and isolates objects from those images. Each component has its own independent log of messages, managed separately from the logs for the other components.\n
\n\n All three components have live-updating logs which you can monitor. Additionally, the Hardware Controller and the Segmenter also save all of their log messages\n to files which you can browse and download. Those software components create a new log file each time they start, and the name of the log file includes the time\n in the PlanktoScope's clock when the software component started. However, if your PlanktoScope's clock is usually wrong, it makes the log files difficult to navigate.\n This will be fixed in a future version of the software.\n
\n\n If you need to share your logs with other people (e.g. on Slack or GitHub), you should open the \"Downloadable Logs\" links, and then you can select one file or multiple\n log files for downloading as a zip archive.\n
\n\n - \n Node-RED:\n
\n - Live-updating logs (log in as the \"pi\" user with the \"pi\" user's password)
\n - Certain errors generated in the dashboard: see the \"Dashboard errors\" panel on this page.
\n
\n \n - \n Hardware Controller:\n \n
\n - \n Segmenter:\n \n
\n - \n Operating System:\n \n
\n
",
+ "format": "\n The PlanktoScope software application consists of three components: a Node-RED dashboard which provides the user interface you're using; a Hardware Controller\n which executes commands sent from the Node-RED dashboard for hardware control and image acquisition; and a Segmenter which processes an acquired dataset of\n images and isolates objects from those images. Each component has its own independent log of messages, managed separately from the logs for the other components.\n
\n\n All three components have live-updating logs which you can monitor. Additionally, the Hardware Controller and the Segmenter also save all of their log messages\n to files which you can browse and download. Those software components create a new log file each time they start, and the name of the log file includes the time\n in the PlanktoScope's clock when the software component started. However, if your PlanktoScope's clock is usually wrong, it makes the log files difficult to navigate.\n This will be fixed in a future version of the software.\n
\n\n If you need to share your logs with other people (e.g. on Slack or GitHub), you should open the \"Downloadable Logs\" links, and then you can select one file or multiple\n log files for downloading as a zip archive.\n
\n\n - \n Node-RED:\n
\n - Live-updating logs (log in as the \"pi\" user with the \"pi\" user's password)
\n - Certain errors generated in the dashboard: see the \"Dashboard errors\" panel on this page.
\n
\n \n - \n Hardware Controller:\n \n
\n - \n Segmenter:\n \n
\n - \n Operating System:\n \n
\n
",
"storeOutMessages": true,
"fwdInMessages": true,
"resendOnRefresh": true,
diff --git a/software/node-red-dashboard/planktoscopehat/flows.json b/software/node-red-dashboard/planktoscopehat/flows.json
index d0671342e..5b6fe2817 100644
--- a/software/node-red-dashboard/planktoscopehat/flows.json
+++ b/software/node-red-dashboard/planktoscopehat/flows.json
@@ -7158,7 +7158,7 @@
"order": 1,
"width": "0",
"height": "0",
- "format": "\n The PlanktoScope software application consists of three components: a Node-RED dashboard which provides the user interface you're using; a Hardware Controller\n which executes commands sent from the Node-RED dashboard for hardware control and image acquisition; and a Segmenter which processes an acquired dataset of\n images and isolates objects from those images. Each component has its own independent log of messages, managed separately from the logs for the other components.\n
\n\n All three components have live-updating logs which you can monitor. Additionally, the Hardware Controller and the Segmenter also save all of their log messages\n to files which you can browse and download. Those software components create a new log file each time they start, and the name of the log file includes the time\n in the PlanktoScope's clock when the software component started. However, if your PlanktoScope's clock is usually wrong, it makes the log files difficult to navigate.\n This will be fixed in a future version of the software.\n
\n\n If you need to share your logs with other people (e.g. on Slack or GitHub), you should open the \"Downloadable Logs\" links, and then you can select one file or multiple\n log files for downloading as a zip archive.\n
\n\n - \n Node-RED:\n
\n - Live-updating logs (log in as the \"pi\" user with the \"pi\" user's password)
\n - Certain errors generated in the dashboard: see the \"Dashboard errors\" panel on this page.
\n
\n \n - \n Hardware Controller:\n \n
\n - \n Segmenter:\n \n
\n - \n Operating System:\n \n
\n
",
+ "format": "\n The PlanktoScope software application consists of three components: a Node-RED dashboard which provides the user interface you're using; a Hardware Controller\n which executes commands sent from the Node-RED dashboard for hardware control and image acquisition; and a Segmenter which processes an acquired dataset of\n images and isolates objects from those images. Each component has its own independent log of messages, managed separately from the logs for the other components.\n
\n\n All three components have live-updating logs which you can monitor. Additionally, the Hardware Controller and the Segmenter also save all of their log messages\n to files which you can browse and download. Those software components create a new log file each time they start, and the name of the log file includes the time\n in the PlanktoScope's clock when the software component started. However, if your PlanktoScope's clock is usually wrong, it makes the log files difficult to navigate.\n This will be fixed in a future version of the software.\n
\n\n If you need to share your logs with other people (e.g. on Slack or GitHub), you should open the \"Downloadable Logs\" links, and then you can select one file or multiple\n log files for downloading as a zip archive.\n
\n\n - \n Node-RED:\n
\n - Live-updating logs (log in as the \"pi\" user with the \"pi\" user's password)
\n - Certain errors generated in the dashboard: see the \"Dashboard errors\" panel on this page.
\n
\n \n - \n Hardware Controller:\n \n
\n - \n Segmenter:\n \n
\n - \n Operating System:\n \n
\n
",
"storeOutMessages": true,
"fwdInMessages": true,
"resendOnRefresh": true,