5

I have a load of 14.04 kiosk systems, halfway across the country. These are horrible little integrated devices. I need to upgrade them all to 16.04 to support a new software stack. do-release-upgrade works half the time. The other half it destroys the install. In addition, the CPUs are really slow and network connections at some sites are also pretty shoddy. So even when it works, upgrading takes a long time.

So new plan.
I can make a fully-installed system image for each kiosk in Virtualbox, or LXC, or whatever.
I need a way to get these images unpacked onto the systems.

The main problem here is there are very few technical people available at the other end. And I don't want to fly 200 miles to do this myself. I need something that is almost completely automated and doesn't require a keyboard.

I'm imagining a scenario where:

  • I make a system image for each kiosk
  • I make a bootable USB drive for each kiosk and copy on the kiosk image.
  • I label each and post them.
  • At the other end, a staff member with physical access to the USB ports just plugs in the right drive and reboots.
  • The bootable element of this then writes and expands the disk image.

It's that "bootable element" that I'm looking for. I was expecting that something like this might already exist (for bulk reimaging installations) but it's possible I'm in new territory. Anything that gets my images installed without manual interference (past plugging it in) gets points.

As far as I know, options like Clonezilla require somebody with a keyboard to tell it what to do. I need something that doesn't require a keyboard, just gets on and does it.

Oli
  • 299,380

2 Answers2

3

Shellscript

I have enjoyed making a bash shellscript, that can do its thing automatically in installed as well as in persistent live Ubuntu based systems and also in a small '9w' system based on Debian Jessie. I hope it will be useful for you, as well as for other people in the future.

The script assumes that there should be two writable drives (mass storage devices), the live drive and the target drive. Do not use toram, it will spoil the identification of the live drive.

The shellscript calls dus-live, which is an executing part of mkusb. So it is replacing the interactive shellscript dus.

dus-live can manage the following kinds of source files,

  • file.iso
  • file.img
  • file.img.gz
  • file.img.xz

and the target system can have both MSDOS and GUID partition tables (when the target drive is bigger than the size of the original system in the image).

I used the name autoclone:

#!/bin/bash

# Date        Sign     Comment
# 2017-06-30  sudodus  Created
# 2017-07-01  sudodus  checking that there is 1 possible target drive

wait=30

read -t "$wait" -p "WARNING: After $wait seconds '$0' will CLONE AUTOMATICALLY;
from the file given as parameter to the first detected drive
(except the live drive), so it will be overwritten.
If this is not what you want or if you are not sure, PRESS {ctrl + C} NOW !
...
"

function power_off {
read -t "$wait" -p "WARNING: After $wait seconds '$0' will POWEROFF automatically;
If this is not what you want or if you are not sure, PRESS {ctrl + C} NOW !
...
"
sudo poweroff
}

user=$(whoami)
if [ "$user" != "root" ]
then
 echo "run $0 with sudo or as root"
 exit
fi
if [ "$1" == "" ] || ! test -s "$1"
then
 echo "Usage:   sudo $0 <with an iso file or image file as parameter>"
 echo "Example: sudo $0 \"file.iso\""
 echo "Example: sudo $0 \"file.img\""
 echo "Example: sudo $0 \"file.img.xz\""
 exit
fi

source="$1"

livedrive=$(lsblk -lo name,type,mountpoint | \
grep -m1 -e /$ -e /cdrom$ -e /lib/live/mount/medium -e /lib/live/mount/persistence)
#echo "$livedrive"
livedrive=${livedrive:0:3}
echo "livedrive=/dev/$livedrive"

number_of_targets=$(lsblk -ldo name,type|grep -v "$livedrive"|grep -v zram|grep disk|wc -l)
           target=$(lsblk -ldo name,type|grep -v "$livedrive"|grep -v zram|grep disk)

#echo "target=$target"
# echo "number_of_targets=$number_of_targets"
# sudo lsblk -o name,model,size,type,fstype,label,mountpoint | \
#  grep -v "$livedrive"|grep -v zram| grep -v loop|grep -v ' rom '
####

if [ $number_of_targets -ne 1 ]
then
 echo '--------------------------------------------------------'
 sudo lsblk -o name,model,size,type,fstype,label | \
  grep -v "$livedrive"|grep -v zram| grep -v loop|grep -v ' rom '
 echo "$number_of_targets possible target drives found, but
1 possible target drive should be found
for '$0' to work correctly."
 if [ $number_of_targets -gt 1 ]
 then
  echo "--------------------------------------------------------
- Please remove every other possible target drive!
- Or are you running in the wrong computer?"
 fi
 echo "--------------------------------------------------------"
 wait=60
 power_off
 exit
fi
target=/dev/${target:0:3}

echo "target=$target"

umount "$target"?*

paramfromfile=$(mktemp)

echo "$source
$target" > "$paramfromfile"

# do it with dus-live, which comes with mkusb version 12-

echo "calling 'dus-live' ..."
dus-live pff:"$paramfromfile"

power_off

Tested in persistent live systems

I tested that it works in two persistent live systems, which can be installed from compressed image files,

See more details about this method at this link,

Autostart

This script can be autostarted, when the following line is appended to autostart, in Lubuntu via the following command,

echo 'xterm -fa default -fs 12 -title autoclone -e sudo /home/lubuntu/autoclone dd_no-biggie-68MB.img.xz' >> ~/.config/lxsession/Lubuntu/autostart

Modify it to match with the actual 'dd' image /path/name and the actual location of the shellscript.

The corresponding command in 9w is

echo '@xterm -fa default -fs 12 -title autoclone -e sudo /root/autoclone /root/dd_no-biggie-68MB.img.xz' >> ./.config/lxsession/LXDE/autostart

Your own custom system

You may want to or have to create your own custom system (live, persistent live or installed in a USB drive or a memory card). You can probably replace dus-live with a simple dd command line, at least if the system you want to install uses the MSDOS partition table.

Disclaimer

This shellscript was made rather quickly, it works as tested by me, but there are many cases that are not tested, and unexpected things may happen. So please test it, where there is no drive with valuable data, that might be overwritten.

Screenshots

Three screenshots of Lubuntu

During the first 30 seconds you can use the hotkey combination ctrl + C to stop autocloning,

enter image description here

Console output: at this stage the system is syncing (flushing the buffers to the target drive),

enter image description here

During 30 seconds you can use the hotkey combination ctrl + C to avoid poweroff (if you wish to stay in the Lubuntu desktop session),

enter image description here

A corresponding screenshot of 9w

enter image description here

sudodus
  • 47,684
0

Have you considered using USB rubber duckies from Hak5 https://hakshop.com/collections/usb-rubber-ducky in twin-duck mode. I used them to install Ubuntu onto 7 machines. On each one, all I had to do was restart the systems with the rubber ducky plugged into the USB port, since my systems always give priority to booting from USB, this was easy. But you could use two rubber duckies and use one to adjust your BIOS preferences and boot from USB while using the other as a Live Boot flash drive and a Keyboard to navigate the setting splash screens produced by the unetbootin boot install menu. With a bit of patience and trial and error you can do it. And since no on site technicians are needed, you can mail the ready rubber duckies to people with physical proximity and access to the systems.

When in Twin-Duck mode, the rubber ducky acts as both a HID (in our case a Keyboard) and A USB mass storage device. So you only need to make a Bootable flash disk with unetbootin onto the USB Mass storage of the Rubber Ducky and use the HID (Keyboard) automation - keystroke injection - functionality to automate the navigation(keystrokes) needed while installing the OS. you can even do this on headless systems.

endrias
  • 637