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.

  • Do you think that they can clone from a compressed dd image for example with a custom made script which starts and does it's thing automatically?
    – sudodus
    Commented Jun 29, 2017 at 12:07
  • @sudodus Yeah, that's pretty much what I was thinking. I was imagining that something to do this already existed but an answer that has a script that does it all itself is acceptable.
    – Oli
    Commented Jun 29, 2017 at 12:38
  • I don't know such a fully automatic system, but it should work to create it with a script that is automatically started in a persistent live drive.
    – sudodus
    Commented Jun 29, 2017 at 12:42
  • A fully automatic system must be able to identify the target drive. Have you got an idea how to do that? Will there only be two drives, the live drive and the target drive, or can there be other drives too?
    – sudodus
    Commented Jun 29, 2017 at 12:56
  • Yeah there's only one drive in the system by default.
    – Oli
    Commented Jun 29, 2017 at 12:57

2 Answers 2



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:


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


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

if [ "$user" != "root" ]
 echo "run $0 with sudo or as root"
if [ "$1" == "" ] || ! test -s "$1"
 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\""


livedrive=$(lsblk -lo name,type,mountpoint | \
grep -m1 -e /$ -e /cdrom$ -e /lib/live/mount/medium -e /lib/live/mount/persistence)
#echo "$livedrive"
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 ]
 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 ]
  echo "--------------------------------------------------------
- Please remove every other possible target drive!
- Or are you running in the wrong computer?"
 echo "--------------------------------------------------------"

echo "target=$target"

umount "$target"?*


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

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

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


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,


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.


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.


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


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.

  • Are these hacker friendly Rubber Ducky devices secure enough to be appropriate for this task?
    – karel
    Commented Jun 29, 2017 at 12:02
  • @karel , I know they seem dodgy, but for conducting a whole lot of repetitive operations on many similar systems - especially systems which are not reliably networked, I really don't think there is a better solution. Also on the right hand, they are good aids for any competent sys-admin.
    – endrias
    Commented Jun 29, 2017 at 12:08
  • I suppose if the Rubber Ducky source code was available, it might be possible to copy it onto a device of one's own choosing instead of using a yellow USB device that looks like a duck.
    – karel
    Commented Jun 29, 2017 at 12:08
  • you don't need the any source code. The Hak5 website will show you all you'll need to know. and the Keystroke scripting language - ducky script - is so simple and easy, you can learn it, quite literally, in less than a minute.
    – endrias
    Commented Jun 29, 2017 at 12:11
  • I'm also interested in USB device security generally, for example this answer: superuser.com/questions/1206321/…
    – karel
    Commented Jun 29, 2017 at 12:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .