-
Notifications
You must be signed in to change notification settings - Fork 19
Host install.txt on Github #33
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
Conversation
|
is a monitor and keyboard required for this script
is there any provision for exiting from an infinite loop of fail, reboot, rerun, like a maximum number of iterations? |
|
A monitor not required if you pre-prep the image with '/boot/ssh' then you could kick off the curl install over ssh and after the reboot the install continues to run without ssh. The installer runs once upon boot and will continue to retry upon each boot until all the installs are run then disables itself when complete. |
|
The script for the master branch works by using: |
|
After the first reboot and iiab-installer is running the progress can be monitored with 'journalctl --no-pager -u iiab-installer' Once the install completes and reboots journalctl --no-pager -u iiab-installer' will show: Now the service is disabled for subsequent reboots. |
scripts/install-latest.txt
Outdated
| ./iiab-install $REINSTALL | ||
| apt update | ||
| apt -y dist-upgrade | ||
| reboot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't apt update; apt -y dist-upgrade; reboot need to happen prior to ./iiab-install, so the network stage[*] works reliably?
[*] equivalent to ./iiab-network (and potentially also other aspects of IIAB's install routine!)
The concern is that many implementers run "apt update; apt -y dist-upgrade" on a new OS (on their own, out of habit, whether we ask them to or not!) and yet do not reboot after that — leaving them with a partially installed kernel, that is not yet running — that then blocks their IIAB installation :-(
|
The network stage is reliable when the there is no kernel mismatch between what has been installed and what is running. Using the running kernel will ensure there is no mismatch for the network stage, Delaying the reboot till after when a kernel might be installed makes life easier support wise but that new kernel install process could occur at any point in the install. Having the reboot take place at this point is to catch those who have installed a new kernel but have not rebooted, as stage 9 is complete, network is configured but if there was a failure at 'systemd restart networking' the services were not restarted but otherwise ready and working correctly with a reboot. |
|
PR #55 implements this in a slightly different way. |
Initial import for install.txt to be hosted at github
rework ordering for better future use of iiab-factory