So I wanted to take another look at what has happened with the Imager since then. The short answer: quite a lot. The long answer – with a special focus on us Linux users and the little pitfalls that most guides gloss over – is what this article is about.

What is the Raspberry Pi Imager?

The Raspberry Pi Imager is the official tool from the makers of the Raspberry Pi for writing operating system images to a microSD card, a USB stick or an SSD. Unlike a plain old dd, the Imager downloads the images directly, decompresses them on the fly, writes them and then verifies the result.

Besides Raspberry Pi OS, the selection also includes Ubuntu, media centre distributions, retro gaming systems, images for 3D printers and home automation as well as utility images, for example for updating the bootloader. The program is licensed under Apache 2.0, and the source code lives on GitHub. So you can check at any time what it is doing on your machine.

The real highlight, though, is the pre-configuration: hostname, user account, Wi-Fi, time zone, keyboard layout and SSH access can all be set before the first boot. The Pi then joins the network fully set up – ideal for headless operation, where you want to get by without a monitor and keyboard.

What’s new in Raspberry Pi Imager 2.0?

At the end of November 2025, the Foundation released Raspberry Pi Imager 2.0; by now version 2.0.11 is current (or 2.0.11.1 as a hotfix). A lot has changed under the hood since then, but above all the program looks completely different. The most important changes at a glance:

• Wizard instead of a single window: You now click your way step by step through device, operating system, storage device, customisation and writing.
• Customisation in plain sight: The formerly hidden dialog for the “advanced options” (Ctrl+Shift+X, anyone?) is now a regular step in the wizard.
• Location by capital city: Instead of country codes you pick a capital city, and the Imager derives the time zone, keyboard layout and Wi-Fi regulatory country from it.
• Interfaces at the click of a mouse: I2C, SPI, 1-Wire, the serial interface and USB gadget mode (the Pi presents itself as a network device on the USB port, so SSH works straight over the cable) can be enabled directly in the Imager, with no detour via raspi-config.
• Raspberry Pi Connect: You can sign in with your Connect account while writing, and the Pi then shows up in remote access right after the first boot. Since version 2.0.10 this also works with Connect for Organisations.
• Accessibility: The interface can be operated entirely by keyboard and is labelled for screen readers.
• Stricter verification: The Imager forces the operating system to actually confirm written blocks. This can make writing take a little longer, but the result is more reliable.

Something has been removed as well, though: custom image files can still be written, but can no longer be pre-configured with hostname, Wi-Fi and so on. The developers justify this by saying the feature was never officially supported. Only images that are flagged accordingly can still be customised.

So if you have been pre-configuring a self-built image with the Imager, you’ll need to find another way – or turn to the CLI mode, which I introduce further down. There is good news on SSH keys, however: support for multiple keys, which was dropped when 2.0 launched, has since returned.

Installing Raspberry Pi Imager on Linux

This is where things get interesting for us Linux users, because the distributions differ considerably. The official download page offers an AppImage for Linux. On GitHub there are additionally .deb packages for amd64, arm64 and armhf as well as a pure command-line version. What your distribution ships, however, is a different story.

Arch Linux: up to date straight from extra

As so often, Arch users have it easiest: the Imager is in the official extra repository and is up to date there (version 2.0.11.1 at the time of writing). No AUR helper is needed; a simple pacman call is enough, and the Imager is ready in your application menu:

$ sudo pacman -S rpi-imager

The Arch package ships a Polkit rule. If you launch the Imager normally from the application menu, it requests the necessary privileges itself via pkexec – so you just enter your password in the Polkit dialog. If you use an AUR helper such as Paru or Yay, you’ll also find rpi-imager-git in the AUR – normally you won’t need it.

Ubuntu: hands off Universe and Snap

On Ubuntu, by contrast, there is a trap that none of the usual guides say a word about. A sudo apt install rpi-imager does work, but even on Ubuntu 26.04 it still installs the ancient version 1.8.5 from universe. The snap in the Snap Store is stuck at version 1.9.6 as well.

So neither package gets the new wizard, Raspberry Pi Connect or the bug fixes of recent months. Ubuntu users are therefore better off with the AppImage, the Flatpak (both covered below) or the official .deb package from GitHub. Replace <version> in the command with the version number of the file you downloaded:

$ sudo apt install ./rpi-imager_<version>_amd64.deb

If you already have an old version installed via apt or Snap, remove it first so that you don’t end up with two Imagers side by side in your application menu. Otherwise you may accidentally launch the old version and wonder where the features have gone.

$ sudo apt remove rpi-imager
$ sudo snap remove rpi-imager

AppImage: the official route for all distributions

The AppImage works regardless of distribution – so on Fedora, openSUSE and the like too. Download it from the official download page, make it executable and run it; no installation is required. Here, too, replace the <version> placeholder with the version number from the file name:

$ chmod +x Raspberry_Pi_Imager-v<version>-desktop-x86_64.AppImage
$ ./Raspberry_Pi_Imager-v<version>-desktop-x86_64.AppImage

On first launch without root privileges, the Imager complains and offers you the Install Authorization button. If you click it, it places (after you enter your password) a Polkit rule under /etc/polkit-1/actions/ that applies to exactly this path of the AppImage. After that, it obtains the privileges by itself on every launch.

If you later move the AppImage to a different folder, you have to set up the authorisation again. If you’d rather work without a permanent rule, launch the AppImage with sudo. There is a stumbling block here that Michael Kofler points out in his article: sudo does not search the current directory, so you have to specify a path.

$ sudo ./Raspberry_Pi_Imager-v<version>-desktop-x86_64.AppImage

Without the ./ all you get is “command not found”. Curiously, the Imager itself suggests exactly this command without a path in its missing-privileges dialog. On Ubuntu 24.04 a second trap awaits: there the AppImage crashes right at startup because Qt is missing a library for X11. In the terminal it looks like this:

$ ./Raspberry_Pi_Imager-v2.0.11-desktop-x86_64.AppImage 
Platform: Linux 7.0.0-38-generic (x86_64)
qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin.
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "/tmp/.mount_RaspbedIOBeG/usr/plugins/platforms" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, wayland-brcm, wayland-egl, wayland, xcb.

Aborted (core dumped)

The fix is the libxcb-cursor0 package, which you install as usual through the package manager. After that, the Imager starts without complaint on Ubuntu 24.04 too. On Ubuntu 26.04 the problem no longer occurs. The libfuse2t64 package that used to be recommended so often, on the other hand, was no longer necessary in my test.

$ sudo apt install libxcb-cursor0

By the way: the 2.0.11.1 hotfix has so far only been released for Windows, macOS and as a .deb package; as an AppImage, 2.0.11 is the latest version. That’s no big deal, though, because the hotfix merely fixes a bug when signing in to Raspberry Pi Connect. If you don’t use Connect, you’re not missing anything.

Flatpak: convenient, but not verified by the vendor

On Flathub the Imager is available as org.raspberrypi.rpi-imager in the current version. The Flatpak gets full access to all devices and talks to UDisks2 to write to storage devices. A nice touch for the privacy-conscious: it is built without telemetry. Installation works as usual:

$ flatpak install flathub org.raspberrypi.rpi-imager

Note, however, that the app is not marked as verified on Flathub. Flathub does name Raspberry Pi Ltd as the developer, but that doesn’t tell you whether Raspberry Pi maintains the package itself. As a rule this isn’t a problem, but you should be aware of it.

Raspberry Pi OS

If you want to use the Imager directly on a Raspberry Pi, for example to prepare a second card or an SSD for another Pi, you install it on Raspberry Pi OS the classic way from the package sources. Here the package comes straight from the Foundation’s repositories, unlike on Ubuntu:

$ sudo apt update && sudo apt install rpi-imager

On the Raspberry Pi 4 and 5 you can get by without a second computer entirely: their bootloader can use network install to load a stripped-down version of the Imager from the internet, which you then use to write an SD card or SSD directly in the Pi. With version 2.0.11, this network installer was noticeably reworked and slimmed down.

Why does the Imager need root privileges at all?

On Windows and macOS you hardly notice it, but on Linux you do: the Imager writes directly to the block device, for example /dev/sdb or /dev/mmcblk0, and a normal user isn’t allowed to do that. Version 2 therefore takes care of obtaining the necessary privileges via pkexec itself.

The prerequisite is a matching Polkit rule. With the Arch package and the official .deb it is installed along with the program; with the AppImage you create it via Install Authorization. If you launch the Imager via sudo or pkexec, settings and the download cache still end up in your home directory and not in /root, because the Imager detects the calling user.

A little tip for the tidy-minded: the rules created by the AppImage are named com.raspberrypi.rpi-imager.appimage-<hash>.policy and live under /etc/polkit-1/actions/. If you delete the AppImage, you can remove the corresponding rule there by hand. This also works on distributions with a read-only /usr such as Fedora Silverblue, since the Imager deliberately writes to /etc.

How to write an image with Raspberry Pi Imager

Actually using the program is quickly explained thanks to the new wizard. You work your way from top to bottom through five steps and can go back a step at any time if you’ve misclicked. Writing only happens at the very end after an explicit confirmation prompt, so nothing happens to your SD card before that:

1. Choose device: First you tell the Imager which model the image is intended for, such as Raspberry Pi 5 or Raspberry Pi Zero 2 W. The list of operating systems is then filtered accordingly.
2. Choose operating system: Here you pick Raspberry Pi OS (with or without desktop, 32-bit or 64-bit) or one of the many other distributions. Via Use custom you select a locally stored image.
3. Choose storage device: Now it’s the turn of the SD card or USB stick. More on that in the next section.
4. Customise: Hostname, location, user and password, Wi-Fi, SSH (by password or public key), Raspberry Pi Connect and interfaces such as I2C and SPI. Depending on the operating system, the Imager writes these settings to the boot partition as firstrun.sh, as a cloud-init configuration or in another format.
5. Write: After a confirmation prompt, the Imager downloads the image, writes it and verifies it. Images that have been downloaded once end up in the cache, so writing the same image again is considerably faster.

If you want to set up several Pis in one go, you’ll appreciate the option to write another card at the end of the wizard. It lets you write the same image including customisations once more without having to click through all the steps again. Just remember to change the hostname.

My tip for headless operation: store your public SSH key right away instead of a password. Then you can connect to the Pi via ssh immediately after the first boot without ever having to type a password. If you access it from several machines, simply enter several keys.

If you set up a Pi afresh with the same hostname, SSH will complain about a changed host key at the next login. In this case there is no attack behind it; the freshly installed system has simply generated new keys. A single command fixes the problem quickly.

Careful: pick the right drive

Probably the most important point of all: the Imager overwrites the selected storage device completely and does not check whether it still contains data. Michael Kofler rightly criticises that the icons for SD cards and USB devices in the selection can be confusing and that the summary doesn’t show the concrete device name such as /dev/sde.

Sure, the Imager hides system drives by default, but an external backup disk on the USB port is just another removable drive as far as it is concerned. On Linux, however, you have a simple way of playing it safe: use lsblk before and after plugging in the SD card to see which device has been added.

$ lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINTS
NAME          SIZE MODEL                TRAN   MOUNTPOINTS
sda           4.5T WDC WD50NDZW-11BCSS1 usb    
└─sda1        4.5T                             /mnt/backup
sdb         117.2G Speed Line           usb    
├─sdb1        198K                             
├─sdb2        2.8M                             
└─sdb3        4.6G                             
zram0         3.8G                             [SWAP]
nvme0n1       3.6T CT4000P3PSSD8        nvme   
├─nvme0n1p1   512M                      nvme   /boot
└─nvme0n1p2   3.6T                      nvme   /var/log
                                               /var/cache/pacman/pkg
                                               /home
                                               /.snapshots
                                               /

In my example the situation is clear: sdb is the “Speed Line” USB stick with a good 117 GB and the remains of an old ISO image. sda, by contrast, is the external backup disk mounted at /mnt/backup. According to the TRAN column, both are attached via USB.

This is exactly where the danger lies, because to the Imager both drives are equally removable media. Size and model name tell you which device is the right one. To be on the safe side, it’s best to unplug all external hard disks before starting the Imager. A few seconds of caution certainly beat a flattened backup disk.

Incidentally, since version 2.0.11 the Imager locks the drive exclusively on Linux while it is writing to it. No other program can then access the card at the same time and wreck your freshly written image. Of course, that doesn’t protect you from picking the wrong drive – only a careful look helps there.

Raspberry Pi Imager in the terminal: CLI mode

What most guides don’t mention: the Imager can also be used entirely without a graphical interface. That’s handy for scripts, for working over SSH or when you want to prepare several cards. You activate CLI mode with --cli, followed by the image and the target device:

$ sudo rpi-imager --cli raspios.img.xz /dev/sdb

The image may be compressed (since 2.0.11 also as a multi-part .img.zst), and instead of a local file the Imager also accepts an HTTP or HTTPS address. rpi-imager --cli --help gives an overview of all options, and the Arch package also ships a man page. The most useful options in my view:

• --sha256 <hash> checks before writing whether the image matches the expected checksum.
• --disable-verify skips verification after writing (saves time, costs safety).
• --first-run-script <file> puts your own firstrun.sh onto the image.
• --cloudinit-userdata <file> and --cloudinit-networkconfig <file> write your own cloud-init configurations to the card as well.
• --disable-eject prevents the drive from being ejected after writing – handy if you still want to copy files to the boot partition afterwards.
• --quiet only prints errors, ideal for scripts.

The cloud-init options in particular are interesting: they give you more possibilities in the terminal than in the graphical interface, and that includes images which the Imager no longer customises in the wizard. For servers without a Qt interface, GitHub also offers a separate rpi-imager-cli package and a CLI AppImage, for which the --cli switch is not needed.

Custom image lists with –repo

One more treat for tinkerers, clubs and schools: with --repo you teach the Imager your own list of images. Instead of querying Raspberry Pi’s servers, it then reads a JSON file that is located either online or locally on your disk. The format is described in the repository under doc/json-schema.

$ rpi-imager --repo https://example.org/os_list.json

That way you can, for example, hand a club or a school class an Imager that only shows your own prepared images. Simply create a custom launcher in the application menu that calls the Imager with the appropriate parameter. The Imager takes care of the rest as usual.

Disabling telemetry

By default, on every write the Imager anonymously reports to Raspberry Pi which image you selected, along with the Imager version, your host operating system, the architecture and the language setting. According to the README, only counters are stored, and the aggregated data is publicly available at rpi-imager-stats.raspberrypi.com.

If you’d still rather not have that, switch off the statistics in the app options or launch the Imager once with the --disable-telemetry parameter, which saves the setting permanently. As mentioned above, telemetry isn’t compiled into the Flatpak in the first place. So there’s nothing you need to do there.

Common problems on Linux

The Imager reports that it isn’t running as root. With the AppImage, click Install Authorization or launch it with sudo ./…. With distribution packages, check whether the file com.raspberrypi.rpi-imager.policy exists under /usr/share/polkit-1/actions/. If it is missing, reinstall the package or launch the Imager with sudo as a test.

The AppImage won’t start. First check whether the executable bit is set (chmod +x). On Ubuntu 24.04, libxcb-cursor0 is also missing, without which the AppImage crashes right at startup. Launch the AppImage in a terminal as a test; then you’ll see the error message and know which piece of the puzzle is still missing.

Ubuntu shows the old interface. Then you’ve caught the version from apt or the Snap Store, both of which are still stuck at 1.x. Uninstall it and use the .deb from GitHub, the AppImage or the Flatpak instead. After that, the new wizard will greet you on Ubuntu too.

The SD card doesn’t show up. Use lsblk to check whether the card reader recognises the card at all. Some card readers only show a device after the card is reinserted, others simply don’t like certain cards. If the card doesn’t appear in lsblk either, the problem isn’t the Imager.

Writing takes forever. Verification reads the complete image back from the card once more after writing. With slow cards or USB 2 card readers this can take a while. A faster card helps more here than switching off the check. If verification fails, you should check your card for errors.

Faulty USB sticks or microSD cards. If the Imager shows the notice “Limited by storage device speed” while writing, the storage device is slowing the process down considerably. At just a few MB/s, a worn-out stick or a faulty card is often behind it. In that case, check the device for errors before you find yourself puzzling over an aborted verification.

Alternatives to Raspberry Pi Imager

Of course it doesn’t always have to be the Imager. If you’ve already downloaded an image, you can get there on Linux with built-in tools too – for instance with dd, with the Restore Disk Image function in GNOME Disks or the GTK4 tool Impression. You’ll then be missing the convenient pre-configuration, though, and will have to set up hostname, SSH and Wi-Fi by hand.

If, conversely, you want to back up an existing system and keep the image as small as possible, take a look at PiShrink. It shrinks an image you’ve read out down to the space actually used, and you can later write it back to a card with the Imager.

Better than dd, but not mandatory either

All in all, the upgrade to Raspberry Pi Imager 2.0 was a clear step forward in my view. The wizard guides even beginners safely through the setup, and for Linux users a good deal of fiddling has been eliminated, particularly when it comes to root privileges. Arch users simply install the program from extra and are done.

Ubuntu users, on the other hand, should definitely steer clear of the package sources and the Snap Store and go for the official package. And if you like working in the terminal, you should take a closer look at CLI mode with its cloud-init options. How do you prepare your SD cards? Do you use the Imager, or do you still swear by dd?

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

On GitHub, I recently stumbled across the PiShrink script, which does exactly that. The little program takes a Pi image, reduces the partition size to the necessary minimum and also adds a script to the archived system that automatically expands the partition to the maximum available space on the next boot on real hardware. This way, you can quickly shrink the image of a Raspbian system from several gigabytes to a few hundred megabytes – without much effort. You also save time when restoring, since the file system automatically expands to its full size again the first time the Raspberry Pi boots.

$ mkdir ~/bin
$ wget https://raw.githubusercontent.com/Drewsif/PiShrink/master/pishrink.sh -P ~/bin
$ chmod +x ~/bin/pishrink.sh

Since PiShrink is a simple Bash script, installing it isn’t particularly complicated: you just download the script and set the execute permission. Personally, I put scripts like this in the ~/bin directory in my home folder. The system should automatically add this folder to your user’s $PATH, so you can run the command from anywhere without specifying a path. If that’s not the case for you, there are plenty of guides online on extending the environment variable (the linked article refers to Ubuntu, but the procedure is very similar on other distributions).

PiShrink compresses Raspberry Pi images

You should now be able to call the PiShrink script directly in the terminal with a bold pishrink.sh. Without an image, the script merely shows its syntax. In the end, calling it comes down to specifying an image file and, optionally, a second file name if PiShrink should leave the original Raspberry Pi image untouched. If you only specify one file name, PiShrink edits that image directly.

The only switch, -s, matters if you want to shrink the image of a Pi system that isn’t based on Raspbian – for example the Kodi distributions LibreELEC or OpenELEC. More precisely, the switch tells PiShrink not to expand the system automatically on the next boot. To do this, PiShrink normally adds a command to the /etc/rc.local file, which Raspbian runs automatically at boot. However, this file doesn’t exist on LibreELEC (and some other distributions).

### Show PiShrink's help:
$ pishrink.sh
Usage: /home/toff/bin/pishrink.sh [-s] imagefile.img [newimagefile.img]
### Shrink an existing Pi image:
$ sudo pishrink.sh raspberry-pi.img
### Shrink the image and keep the original:
$ sudo pishrink.sh raspberry-pi.img raspberry-pi_pishrink.img
### Disable automatic expansion of the partition:
$ sudo pishrink.sh -s raspberry-pi.img raspberry-pi_small.img

So how does it all come together? As an example, I’m using a current installation of Raspbian Lite on a 16 GB SD card. You insert it into the card reader, determine the device ID with lsblk and then back up the image to the hard disk with dd. The image file then sits on the hard disk as raspberry-pi.img, around 16 GB in size – even though the image is actually mostly empty. Apart from the Raspbian system and a few configuration files, there’s no other data on the system.

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
[...]
sdd      8:48   1  14.9G  0 disk
├─sdd1   8:49   1    63M  0 part /run/media/[...]/boot
└─sdd2   8:50   1  14.8G  0 part /run/media/[...]/0aed834e-8c8f-412d-a276-a26
$ sudo dd if=/dev/sdd of=~/raspberry-pi.img
15894831104 bytes (16 GB, 15 GiB) copied, 210 s, 75.7 MB/s
31116288+0 records in
31116288+0 records out
15931539456 bytes (16 GB, 15 GiB) copied, 210.459 s, 75.7 MB/s
$ ls -alh ~/raspberry-pi.img
-rw-r--r-- 1 root root 15G Feb 24 21:48 raspberry-pi.img

Then you call PiShrink accordingly – since this is a Raspbian system, I leave out the -s option. PiShrink first copies the image (so make sure there’s enough free space), mounts the copy in a temporary directory under /tmp and then reduces the size of the image: from just under 16 GB originally to only about 1.6 GB. The effect you achieve naturally depends on how much real data was stored on the Raspberry Pi’s SD card.

$ sudo pishrink.sh raspberry-pi.img raspberry-pi_pishrink.img
Copying raspberry-pi.img to raspberry-pi_pishrink.img...
Creating new /etc/rc.local
e2fsck 1.43.4 (31-Jan-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/loop2: 35832/959616 files (0.2% non-contiguous), 321790/3872384 blocks
resize2fs 1.43.4 (31-Jan-2017)
resize2fs 1.43.4 (31-Jan-2017)
Resizing the filesystem on /dev/loop2 to 382429 (4k) blocks.
Begin pass 2 (max = 40814)
Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 119)
Scanning inode table          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 3178)
Updating inode references     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/loop2 is now 382429 (4k) blocks long.

Shrunk raspberry-pi_pishrink.img from 15G to 1.6G
$ ls -alh raspberry-pi*
-rw-r--r-- 1 root root  15G Feb 27 11:08 raspberry-pi.img
-rw-r--r-- 1 root root 1.6G Feb 27 11:30 raspberry-pi_pishrink.img

Restoring a shrunk Pi image

As a test, the Raspbian system originally installed on a 16 GB SD card is to move to a microSD card with only 8 GB. To do this, I write the image shrunk with PiShrink back to the new card with dd, insert it into the Raspberry Pi and boot the shrunk system. To make full use of the available storage space, the system automatically reboots once during the first boot. After that, you land in the familiar Raspbian system – a df -h shows that the system now uses the entire SD card.

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
[...]
sdd      8:48   1   7.4G  0 disk
├─sdd1   8:49   1    63M  0 part /run/media/[...]/boot
└─sdd2   8:50   1   7.3G  0 part /run/media/[...]/0aed834e-8c8f-412d-a276-a26
$ sudo dd if=raspberry-pi_pishrink.img of=/dev/sdd bs=1M; sync
1560+1 records in
1560+1 records out
1636684288 bytes (1.6 GB, 1.5 GiB) copied, 116.203 s, 14.1 MB/s

pi@raspberrypi:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.2G  990M  6.0G  14% /
devtmpfs        459M     0  459M   0% /dev
tmpfs           463M     0  463M   0% /dev/shm
tmpfs           463M  6.2M  457M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           463M     0  463M   0% /sys/fs/cgroup
/dev/mmcblk0p1   63M   21M   42M  33% /boot

If you back up a Raspberry Pi system that isn’t based on Raspbian and has no /etc/rc.local – such as the Kodi distributions LibreELEC or OpenELEC mentioned above – error messages appear when shrinking it with PiShrink. The reason: by default, PiShrink tries to add a command to this file that later expands the partition automatically. To avoid this, you have to use the -s option. That way, you can shrink the image successfully even without an rc.local.

### Error messages when shrinking a LibreELEC image:
$ sudo pishrink.sh libreelec.img
[...]
md5sum: /tmp/tmp.4ornQ3Va4y/etc/rc.local: No such file or directory
/home/[...]/bin/pishrink.sh: line 63: [: !=: unary operator expected
[...]
### LibreELEC, OpenELEC and co. are better shrunk like this:
$ sudo pishrink.sh -s libreelec.img
Skipping autoexpanding process...
e2fsck 1.43.4 (31-Jan-2017)
/dev/loop2: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/loop2: 861/1810432 files (1.0% non-contiguous), 252448/7235584 blocks
resize2fs 1.43.4 (31-Jan-2017)
resize2fs 1.43.4 (31-Jan-2017)
Resizing the filesystem on /dev/loop2 to 49976 (1k) blocks.
Begin pass 2 (max = 15759)
Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 884)
Scanning inode table          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 143)
Updating inode references     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/loop2 is now 49976 (1k) blocks long.

Shrunk libreelec.img from 7.5G to 563M

However, the restored system then doesn’t expand automatically, because LibreELEC (and, as far as I know, OpenELEC too) offers no option in its menus to manually expand the data partition to the full card size. The internal resizing routine only kicks in on a freshly copied first installation, as you can see in the script. To make full use of the partition anyway, the only option is to fix it up manually with a partitioning tool such as GParted. On Linux, GParted is readily available; Windows users can use the tool via a live CD or live USB stick.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

When establishing a connection via SSH, the SSH client usually stores the public SSH key of the remote system together with its hostname and IP address in the file ~/.ssh/known_hosts in the current user’s home directory on the client machine. Among other things, this is done to prevent man-in-the-middle attacks, in which an attacker pretends to be the target machine in order to phish your login credentials. However, this security measure also kicks in when there is no threat at all: for example, when you set up a Pi from scratch and try to log in via SSH again. In such a case, SSH reports WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED in big letters.

SSH after reinstalling the system

$ grep 192.168.111.100 ~/.ssh/known_hosts
raspberrypi,192.168.111.100 ecdsa-sha2-nistp256 AAAAE2...ABBBBqf

$ ssh pi@192.168.111.100
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:6rR+0/i3KnPLds3EuGkfWiudIgu8VMpe1xq+X3I3yNM.
Please contact your system administrator.
Add correct host key in /home/toff/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/toff/.ssh/known_hosts:10
ECDSA host key for 192.168.111.100 has changed and you have requested strict checking.
Host key verification failed.

You could now open the file ~/.ssh/known_hosts in a text editor and delete the offending line 10 from the list by hand, but there is a better way: with ssh-keygen -R IP-address, you remove the key from the file with a single command, so the next time you connect, you start from scratch – and have to confirm the key just like the very first time you connected to this machine. This also works if you use the hostname instead of the IP address to connect. To be on the safe side, the command copies the old state to ~/.ssh/known_hosts.old in the same directory.

$ ssh-keygen -R 192.168.111.100
# Host 192.168.111.100 found: line 10
/home/toff/.ssh/known_hosts updated.
Original contents retained as /home/toff/.ssh/known_hosts.old

$ ssh pi@192.168.111.100
The authenticity of host 'raspberrypi (192.168.111.100)' can't be established.
ECDSA key fingerprint is SHA256:6rR+0/i3KnPLds3EuGkfWiudIgu8VMpe1xq+X3I3yNM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.111.100' (ECDSA) to the list of known hosts.
pi@192.168.111.100's password:

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Apr 22 08:40:10 2016 from 192.168.178.57

Forcibly terminating an SSH connection

If you are logged in to a remote machine via SSH and shut it down with shutdown, halt or reboot, the system doesn’t kill the SSH connection abruptly. It stops the SSH server cleanly during shutdown, so you end up back in the terminal of the client machine and can keep working in the same terminal window. Now, I – and surely other Pi tinkerers too – like to unplug the Raspberry Pi and plug it back in to restart it quickly and painlessly. This is certainly not ideal for the integrity of the data on the memory card, but if I’m going to set up the system on it from scratch anyway, I don’t much care.

The downside is that SSH usually hangs in the terminal when you do this – after all, you just pulled the chair out from under it. You could now kill the SSH process or close the terminal window and open it again, but there is a clean solution for this situation, too: SSH knows a number of escape sequences that let you manage the current SSH session. You get an overview of the available commands if you type ~? on a new line in the terminal. To be on the safe side, simply press Enter once beforehand.

pi@raspberrypi:~ # ~?
Supported escape sequences:
 ~.   - terminate connection (and any multiplexed sessions)
 ~B   - send a BREAK to the remote system
 ~C   - open a command line
 ~R   - request rekey
 ~V/v - decrease/increase verbosity (LogLevel)
 ~^Z  - suspend ssh
 ~#   - list forwarded connections
 ~&   - background ssh (when waiting for connections to terminate)
 ~?   - this message
 ~~   - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)

The first sequence shown in the help is exactly the function we’re looking for: if you type ~. as text during an SSH session, you terminate the current SSH connection, no matter what. This doesn’t only work with a session that is still active and working (which you could close with exit at any time anyway), but also when, for example, you cut the power to the Pi and nothing happens in the terminal anymore. Here, too, it can help to press Enter once more before the actual command. Otherwise the escape sequence may come to nothing.

Pausing and resuming an SSH connection

The escape sequences can do other handy things, too. For example, you can suspend an SSH connection and resume it later without having to use a terminal multiplexer such as screen or tmux. If a process takes longer than expected, you can park the connection this way while the process on the remote machine keeps running. Unlike with the two terminal multiplexers mentioned, you don’t have to think ahead that the task might take longer and start them as a precaution. The corresponding sequence is the somewhat cryptic ~^Z, where the caret doesn’t stand for a character but for the Ctrl key. So you type ~ and then press Ctrl+Z. You then land back in the terminal of the machine on which you originally ran ssh. From there, you can pick up the connection again by typing fg and pressing Enter.

If you work on a “truly” remote system over the internet, the connection may well drop. On the one hand, this is because the server terminates the connection after a period of inactivity; on the other hand, your own network infrastructure (read: the router) may interfere. However, you can prevent the timeout with a keep-alive function. Depending on the situation, you can either configure the SSH server accordingly (which of course requires root privileges) or call SSH with the appropriate parameters right away. In that case, you don’t need any special privileges on either system.

Keep-alive on the server side

### Default keep-alive settings:
$ grep Alive /etc/ssh/sshd_config
#TCPKeepAlive yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
### Edit the SSH server configuration:
$ sudo nano /etc/ssh/sshd_config

### In the end, the relevant lines should look like this:
$ grep Alive /etc/ssh/sshd_config
TCPKeepAlive yes
ClientAliveInterval 60
ClientAliveCountMax 3

### Restart the SSH server once:
$ sudo systemctl restart sshd

Keep-alive on the client side

### Keep the SSH connection alive from the client side
$ ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=1 pi@raspberrypi

In the first case, the setting applies to all users who want to log in to the system via SSH. As a rule, you should therefore only make this change if all users actually need it. Most of the time, though, you only need keep-alive in exceptional cases, so it makes sense to set the option only when needed when calling ssh. For me, this is the case with a web service I can log in to via SSH, for example. If I start long-running backups there, my router terminates the connection before the backup process can report success. With the keep-alive settings mentioned above, however, that’s no longer a problem.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.