Skip to content

๐Ÿ› ๏ธ Installation

This page logs the physical build of the Raspberry Pi server, step by step, with photos from each stage. It's updated as the build progresses โ€” today covers cooling fan installation, SSD prep, and starting the OS flash. ๐Ÿง‘โ€๐Ÿ”ง

๐Ÿ† Sponsored by

Build supported by Brunel Cybersecurity Society ๐ŸŽ“ and the CyberTutor Platform ๐Ÿ’ป๐Ÿ”.

๐Ÿ“… Day 1 Progress

โœ… Completed today

  • Opened the Raspberry Pi case and prepped the cooling fan kit
  • Mounted the heatsink + fan and wired it to the GPIO pins
  • Seated the SSD into the ORICO USB enclosure
  • Connected the SSD enclosure to the Pi over USB
  • Started flashing the OS onto the microSD card using Raspberry Pi Imager

๐Ÿ”— Resources used today:


1๏ธโƒฃ Unbox and open the case

The Pi 4 case was opened up and the GeeekPi Extreme Cooling Fan Kit was unboxed alongside it, ready for the fan to be installed before the board goes back into the case.

Raspberry Pi 4 board sitting in the open case next to the unopened Extreme Cooling Fan Kit box

2๏ธโƒฃ Mount the heatsink and fan

Following the kit's own instruction card (pictured below the board), the process was:

  1. Paste the heatsink onto the main chip (and thermal tape onto the smaller chips)
  2. Sit the fan on top of the heatsink
  3. Secure the fan bracket down over it

Fan and heatsink mounted onto the Pi board inside the case, with the manufacturer's 3-step instruction card shown below it

๐Ÿ”Œ Wiring detail

The fan's 2-pin JST connector (red = 5V, black = GND) plugs into the GPIO header. The important bit: the red and black wires need to sit next to each other, right after the first pin on the header โ€” not spread apart, and not on the very first pin itself. Getting this off-by-one is a common mistake that either fries the fan or leaves it dead, so it's worth double-checking against a GPIO pinout diagram before powering on.

Close-up of the red and black fan wires connected to the GPIO header, sitting next to each other just after the first pin

3๏ธโƒฃ Prep the SSD storage

With the Pi itself buttoned up, next was the storage side: the Samsung 860 EVO 500GB SSD and the ORICO 2.5" USB enclosure it lives in.

Samsung SSD, ORICO enclosure, and the fan-equipped Pi case laid out side by side before assembly

The SSD slides into the enclosure's tray and locks in with the connector at the end โ€” no tools or screws needed for this particular enclosure.

Samsung SSD seated into the open ORICO enclosure tray, ready to be closed up

4๏ธโƒฃ Connect the SSD to the Pi

Enclosure closed up, then connected to one of the Pi's USB ports via the USB-C to USB-A cable. This is what will carry all the Nextcloud data once the software stack is running.

Closed SSD enclosure connected via USB cable to the Raspberry Pi's USB port

5๏ธโƒฃ Start flashing the OS

Over on the laptop, Raspberry Pi Imager (v2.0.6) was opened to write the OS onto the Philips 16GB microSD card. First step in the wizard: selecting the device โ€” Raspberry Pi 4 โ€” before choosing the OS image and target storage.

Raspberry Pi Imager open on a laptop with the Philips 16GB microSD card in front of the keyboard, on the "Select your Raspberry Pi device" step

โœ… Update

Day 2 picked up right where this left off โ€” see below.


๐Ÿ“… Day 2 Progress

โœ… Completed today

  • SSH'd into the Pi for the first time from the laptop
  • Set a memory/kernel config option needed before cloning
  • Installed the rpi-clone tool
  • Cloned the OS from the microSD card over to the SSD โ€” no more relying on the SD card
  • Set the Pi to boot from the SSD/USB instead of the SD card via raspi-config
  • Completed OS migration and boot configuration, ready for application deployment

๐Ÿ”— Resources used today:

  • ๐Ÿงฌ rpi-clone by Jeff Geerling โ€” the tool used to clone the OS from the SD card to the SSD, referenced for Steps 3โ€“4 below

1๏ธโƒฃ First SSH login to the Pi

With the OS flashed and the Pi booted, the first connection was made from the laptop over SSH:

ssh pi@picloud.local

The very first connection to a new host prompts for a host key check โ€” this is SSH confirming it's really talking to the Pi and not something impersonating it. Typing yes accepts the fingerprint and adds the Pi to the laptop's list of known hosts, then it drops into the Pi's shell after the password prompt.

Terminal showing the first SSH connection to pi@picloud.local, accepting the host key fingerprint and logging into Debian on the Pi

๐Ÿ”’ IP addresses redacted

The Pi's IPv6 address briefly appears in the SSH host-key prompt in these screenshots โ€” it's been blacked out here since it's identifying info tied to the home network, same as the IPv4 address redacted further down this page.

2๏ธโƒฃ Set the memory/kernel config

Before cloning, one config line was appended to the Pi's boot config to make sure the correct 64-bit kernel is referenced:

echo "kernel=kernel8.img" | sudo tee -a /boot/firmware/config.txt

Then rpi-clone โ€” the tool that will handle copying the OS over to the SSD โ€” was installed straight from its GitHub repo:

curl https://raw.githubusercontent.com/geerlingguy/rpi-clone/master/install | sudo bash

Terminal showing the kernel config line being appended and rpi-clone being downloaded and installed into /usr/local/sbin

3๏ธโƒฃ Identify the SSD before cloning

lsblk lists all attached storage so the correct target disk can be confirmed before doing anything destructive โ€” the SSD shows up as sda (465.8G), separate from the SD card mmcblk0 (14.6G, currently holding /boot/firmware and /):

Terminal showing lsblk output listing sda (the SSD) and mmcblk0 (the SD card), with the sudo rpi-clone sda command typed and ready

โš ๏ธ Double-check the target disk

rpi-clone overwrites everything on the destination disk. Confirming with lsblk first that sda is really the SSD (and not, say, an accidentally-plugged-in USB stick) is a step worth never skipping.

4๏ธโƒฃ Clone the OS from SD card to SSD

sudo rpi-clone sda

rpi-clone shows a summary of both disks, warns that the destination will be completely overwritten, and asks for a final confirmation before doing anything:

rpi-clone showing the source (mmcblk0, 15.6GB) and destination (sda, 500.1GB) disks, the overwrite warning, and the yes confirmation to begin cloning

It then formats the SSD's partitions, syncs every file across, and fixes up the partition UUIDs so the SSD can boot independently. This run took about 4 minutes 38 seconds:

rpi-clone finishing the sync, updating PARTUUID references, and reporting "Done with clone to /dev/sda" with elapsed time 4:38

5๏ธโƒฃ Set the Pi to boot from the SSD

With the clone done, sudo raspi-config was opened to change the boot order โ€” otherwise the Pi would keep booting from the SD card out of habit, even with a perfectly good clone sitting on the SSD.

Advanced Options:

raspi-config main menu with Advanced Options highlighted

โ†’ Boot Options โ†’ B2 NVMe/USB Boot:

raspi-config Boot Options screen with B2 NVMe/USB Boot selected, so the Pi tries booting from the SSD before falling back to the SD card

This tells the Pi's firmware to look for a bootable OS on USB/SSD first, falling back to the SD card only if nothing's there. After this, the SD card can eventually be removed altogether.

โญ๏ธ Next stage moved

The Nextcloud setup and first-run application deployment steps are now documented in Nextcloud Deployment.

โญ๏ธ Next up

Still to come: setting a static IP/DHCP reservation so the address doesn't change, HTTPS via a reverse proxy, adding MariaDB and Redis in front of Nextcloud's default setup (see Requirements), and eventually remote access from outside the home network โ€” covered in Nextcloud Deployment and Network & Remote Access.

๐Ÿงพ Build Log

Date Milestone
Day 1 Case opened, cooling fan mounted and wired, SSD seated in enclosure and connected to Pi, OS flash started
Day 2 First SSH login, cloned OS from SD card to SSD with rpi-clone, set boot order to SSD, completed base system preparation for Nextcloud deployment

More to come

This page will keep growing day by day as the build continues โ€” static IP, MariaDB/Redis, HTTPS, and remote access are next.