Skip to content

Conversation

@jvonau
Copy link
Contributor

@jvonau jvonau commented Jul 25, 2018

Initial import for install.txt to be hosted at github
rework ordering for better future use of iiab-factory

@tim-moody
Copy link
Contributor

is a monitor and keyboard required for this script

RUN "touch /boot/ssh" to enable incoming SSH after next reboot

is there any provision for exiting from an infinite loop of fail, reboot, rerun, like a maximum number of iterations?

@jvonau
Copy link
Contributor Author

jvonau commented Sep 4, 2018

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.

@jvonau
Copy link
Contributor Author

jvonau commented Sep 4, 2018

The script for the master branch works by using:
curl https://raw.githubusercontent.com/jvonau/iiab-factory/master/scripts/install-latest.txt | sudo bash
The install.txt file does not use the reboot and iiab-installer method it's intended to replace the current script that does not live under git control but needs the git branches named 'release-6.6' for iiab and iiab-admin-console to be created, or at least for iiab and the variable changed for iiab-admin console to be 'master'

@jvonau
Copy link
Contributor Author

jvonau commented Sep 4, 2018

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:
Sep 04 05:13:09 box.lan systemd[1]: Starting IIAB installer...
Sep 04 05:13:11 box.lan continue.sh[1249]: Removed /etc/systemd/system/multi-user.target.wants/iiab-installer.service.
Sep 04 05:13:11 box.lan systemd[1]: Started IIAB installer.

Now the service is disabled for subsequent reboots.

./iiab-install $REINSTALL
apt update
apt -y dist-upgrade
reboot
Copy link
Member

@holta holta Sep 4, 2018

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 :-(

@jvonau
Copy link
Contributor Author

jvonau commented Sep 4, 2018

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.

@holta
Copy link
Member

holta commented Dec 10, 2018

PR #55 implements this in a slightly different way.

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.

3 participants