Previous post: From microSD to SSD Boot on Raspberry Pi 4

What this covers

With the Pi running cleanly from the Intenso SSD, the next goal; get a real Kubernetes cluster running and understand what's actually happening when a pod starts.

By the end of this post you'll have seen:

• K3s installed and running on ARM hardware

• The full pod scheduling pipeline live in your own cluster

• Resource requests and limits in practice

• QoS classes changing in real time based on what you define

Why K3s and not full Kubernetes

K3s is a lightweight Kubernetes distribution built specifically for edge devices, ARM hardware, and resource-constrained environments. It exposes the full Kubernetes API — every kubectl command you learn here works identically against a production EKS or GKE cluster — but it runs in a fraction of the memory.

Full Kubernetes on a Raspberry Pi 4 would consume most of the available RAM before you deployed a single workload. K3s runs comfortably alongside a full application stack on the same 4GB.

Source: https://docs.k3s.io/architecture

Step 1 — Enable cgroups

This is the step that catches almost everyone on Raspberry Pi OS. Kubernetes needs Linux cgroups (control groups) to enforce container resource limits — CPU throttling, memory limits, scheduling decisions. On Pi OS they're not fully enabled by default.

Edit /boot/firmware/cmdline.txt:

sudo nano /boot/firmware/cmdline.txt

Add these parameters at the end of the single line:

cgroup_memory=1 cgroup_enable=memory cgroup_enable=cpuset

The full line now looks like:

console=serial0,115200 console=tty1 root=PARTUUID=6692b3d6-02 rootfstype=ext4 fsck.repair=yes rootwait usb-storage.quirks=152d:0579:u cgroup_memory=1 cgroup_enable=memory cgroup_enable=cpuset

Verify with cat -A — one line, one $ at the end. Then reboot.

After reboot, verify cgroups are active:

cat /sys/fs/cgroup/cgroup.controllers

Output:

cpuset cpu io memory pids

memory in that list confirms the memory controller is active.. I am on cgroup v2 -which modern Raspberry Pi OS uses it by default. The legacy cgroup_memory=1 syntax is harmless but the actual enablement comes from cgroup v2's memory controller being present.

Source: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html

Source: https://docs.k3s.io/installation/requirements?os=pi#operating-systems

Step 2 — Install K3s

One command:

curl -sfL https://get.k3s.io | sh -

This downloads the K3s binary, installs it as a systemd service, generates a kubeconfig, and starts the cluster. Takes about 2 minutes on the Pi.

Verify the cluster started:

sudo systemctl status k3s | head -5

● k3s.service - Lightweight Kubernetes
     Loaded: loaded (/etc/systemd/system/k3s.service; enabled)
     Active: active (running)

Source of truth: https://docs.k3s.io/quick-start

Step 3 — The kubectl permissions problem (and how it was fixed)

This is where it got interesting.

K3s writes its kubeconfig to /etc/rancher/k3s/k3s.yaml with root-only permissions (600). Running kubectl get nodes without sudo fails:

yvette@newerkey-lab:~ $ kubectl get nodes
WARN[0000] Unable to read /etc/rancher/k3s/k3s.yaml, please start server
with --write-kubeconfig-mode or --write-kubeconfig-group to modify kube
config permissions
error: error loading config file "/etc/rancher/k3s/k3s.yaml": open
/etc/rancher/k3s/k3s.yaml: permission denied

The documented fix is to create /etc/rancher/k3s/config.yaml with:

write-kubeconfig-mode: "0644"

This tells K3s to write the kubeconfig with readable permissions on every start. I verified the file was correct — cat -A showed clean YAML, xxd showed no hidden characters — but K3s kept ignoring it.

After tdebugging for what felt like forever, I took a more explicit approach: a systemd service override.

sudo mkdir -p /etc/systemd/system/k3s.service.d
sudo nano /etc/systemd/system/k3s.service.d/override.conf

Content:

[Service]
ExecStart=
ExecStart=/usr/local/bin/k3s server --write-kubeconfig-mode=0644

The first blank ExecStart= clears the existing command before setting the new one — required systemd syntax for overrides.

sudo systemctl daemon-reload
sudo systemctl restart k3s

Verify the permissions changed:

ls -la /etc/rancher/k3s/k3s.yaml

-rw-r--r-- 1 root root 2941 Jun  5 16:45 /etc/rancher/k3s/k3s.yaml

-rw-r--r-- is 644. It means that the owner can read and write to the file, while everyone else (groups and others) can only read**.** Now kubectl works without sudo and survives every restart and upgrade.

yvette@newerkey-lab:~ $ kubectl get nodes
NAME           STATUS   ROLES           AGE     VERSION
newerkey-lab   Ready    control-plane   3d18h   v1.35.5+k3s1

Why I decided on the systemd override as my preferred long-term fix:

• Survives K3s upgrades (stored separately from the K3s binary)

• Survives restarts (applied every time the service starts)

• Explicit — you can see exactly what flag is being passed

• Standard Linux pattern

Source: https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html

Step 4 — What K3s installed automatically

yvette@newerkey-lab:~ $ kubectl get pods --all-namespaces
NAMESPACE     NAME                                      READY   STATUS      RESTARTS       AGE
kube-system   coredns-8db54c48d-q6wzr                   1/1     Running     4 (147m ago)   3d21h
kube-system   helm-install-traefik-crd-2xxbj            0/1     Completed   0              3d21h
kube-system   helm-install-traefik-wf99m                0/1     Completed   2              3d21h
kube-system   local-path-provisioner-5d9d9885bc-bnddm   1/1     Running     4 (147m ago)   3d21h
kube-system   metrics-server-786d997795-twsvr           1/1     Running     4 (147m ago)   3d21h
kube-system   svclb-traefik-0ad420ed-zcg6n              2/2     Running     8 (147m ago)   3d21h
kube-system   traefik-9bcdbbd9-drlcw                    1/1     Running     4 (147m ago)   3d21h

What each component does:

coredns — Cluster DNS. Every service gets a DNS name automatically. Pods resolve http://my-service to the right cluster IP without any manual configuration.

helm-install-traefik (Completed) — Finished Jobs that ran once to install Traefik via Helm and exited. Completed status is expected — they're not consuming resources.

local-path-provisioner — Creates Persistent volumes on the node's local disk. Needed from Day 3 when the private registry needs persistent storage.

metrics-server — Collects CPU and memory usage from all pods and nodes. Powers kubectl top and the Horizontal Pod Autoscaler.

svclb-traefik — K3s's built-in service load balancer. Routes external traffic into the cluster.

traefik — The ingress controller. Routes HTTP/HTTPS requests to the right service based on hostname and path rules. Day 4 builds on this directly.

Step 5 — The pod scheduling pipeline

Deploy the first pod:

kubectl run hello-nginx --image=nginx:alpine
kubectl get pods --watch

Once Running, describe it:

yvette@newerkey-lab:~ $ kubectl describe pod hello-nginx

The Events section at the bottom shows the full scheduling pipeline:

Normal  Scheduled  27m   default-scheduler  Successfully assigned default/hello-nginx to newerkey-lab
Normal  Pulling    27m   kubelet            Pulling image "nginx:alpine"
Normal  Pulled     27m   kubelet            Successfully pulled image "nginx:alpine" in 4.797s
Normal  Created    27m   kubelet            Container created
Normal  Started    27m   kubelet            Container started

Step by step:

1. kubectl run sends a pod spec to the API server

2. API server writes it to etcd (cluster state store)

3. The scheduler watches for unscheduled pods and assigns this one to newerkey-lab

4. The kubelet on that node sees the assignment, pulls the image from the registry

5. The container runtime (containerd) creates and starts the container

6. Once the container passes its readiness check, the pod moves to Running

Also note: QoS Class: BestEffort at the bottom of the describe output. No resource requests or limits were set, so Kubernetes assigned the lowest quality of service class. These pods are first to be evicted under memory pressure.

Source: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

Step 6 — The QoS class change

This is the thing that was insightful for me. I deleted the bare pod and redeployed it with resource requests and limits defined in a YAML manifest:

apiVersion: v1
kind: Pod
metadata:
  name: hello-nginx
  namespace: default
spec:
  containers:
  - name: hello-nginx
    image: nginx:alpine
    resources:
      requests:
        memory: "64Mi"
        cpu: "100m"
      limits:
        memory: "128Mi"
        cpu: "200m"

kubectl apply -f hello-nginx.yaml
kubectl describe pod hello-nginx

Two things changed in the describe output:

Requests and limits now appear:

Limits:
  cpu:     200m
  memory:  128Mi
Requests:
  cpu:        100m
  memory:     64Mi

QoS Class changed:

QoS Class: Burstable

Reading the documentation told me this would happen. Seeing it change in my own cluster output made it real.

The three QoS classes:

This matters for production platform work. A pod with no resource limits in a shared cluster is a neighbour problem — it can consume unbounded resources and starve other workloads. Setting limits is not optional on a platform that other teams depend on.

Source: https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/

Source : https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

Step 7 — Checking actual resource usage

yvette@newerkey-lab:~ $ kubectl top pod hello-nginx
NAME          CPU(cores)   MEMORY(bytes)
hello-nginx   0m           4Mi

yvette@newerkey-lab:~ $ kubectl top node
NAME           CPU(cores)   CPU(%)   MEMORY(bytes)   MEMORY(%)
newerkey-lab   129m         3%       1331Mi          35%

The pod is using 4Mi against a 128Mi limit — well within bounds. If it hit 128Mi, the Linux kernel OOM killer would terminate the container process and Kubernetes would restart it. Repeated OOMKills produce CrashLoopBackOff.

The node is using 1331Mi of 4GB — 35%. That leaves roughly 2.4GB free for the rest of the work in this series.

Source: https://kubernetes.io/docs/reference/kubectl/generated/kubectl\_top/

The four kubectl commands to know

These are the common commands I used:

# List resources
kubectl get pods
kubectl get pods --all-namespaces
kubectl get pods --watch

# Detailed info — use this first when something is wrong
kubectl describe pod hello-nginx

# Application logs
kubectl logs hello-nginx

# Shell into a running container
kubectl exec -it hello-nginx -- /bin/sh

kubectl describe is the most important debugging command. The Events section shows exactly what happened at each stage — whether the pod failed to schedule, whether the image pull failed, whether the container crashed on start.

Source: https://kubernetes.io/docs/reference/kubectl/quick-reference/

What's running now

newerkey-lab (Raspberry Pi 4, 4GB)
└── K3s v1.35.5+k3s1
    ├── kube-system: coredns, traefik, metrics-server, local-path-provisioner
    └── default: hello-nginx (nginx:alpine, Burstable QoS, 4Mi/128Mi memory)

Node utilisation: 129m CPU (3%), 1331Mi memory (35%)
kubectl: working without sudo, permanent via systemd override

What I learned today

Kubernetes concepts land differently hands-on but still a lot to take in so don't rush to understand all at once. QoS classes, pod scheduling pipeline, resource requests — I'd read about all of these. Watching the QoS class change from BestEffort to Burstable in my own describe output, against a pod I just deployed, made the concept stick in a way documentation alone doesn't.

Debugging is normal. The kubectl permissions issue took longer than the K3s install itself. The solution — a systemd service override — is more robust than the documented config.yaml approach. Sometimes the detour teaches you more than the happy path would have.

Image caching is visible. First deployment: Pulling image "nginx:alpine" in 4.797s. Second deployment: Container image "nginx:alpine" already present on machine. That's the image cache working — and the reason CronJob pods sometimes start slowly on nodes that haven't cached the image yet.

What's next

Private Docker Registry. Deploy a private container registry inside the K3s cluster with persistent storage, configure K3s to trust it, and push the first image from the laptop into the cluster.

References

• K3s quick start

• K3s architecture

• K3s installation requirements

• K3s cluster access

• K3s configuration file

• systemd service overrides

• Kubernetes pod lifecycle

• Kubernetes QoS classes

• Kubernetes resource management

• kubectl quick reference

• kubectl top

• cgroup v2 documentation

Why I'm doing this

I'm an IT Infrastructure Support engineer transitioning into platform engineering. So I decided to put together a permanent home lab that mirrors, in miniature, the kind of infrastructure I believe platform teams actually run. This totally from a beginner's perspective.

The plan over the next days:

• Foundation: Pi setup, K3s, private registry, networking, Terraform with a Makefile wrapper, CI/CD

• GitOps with Flux CD

• OpenTelemetry observability layer aligned with the OTCA certification syllabus

Every project I build from now on lives on this Pi. It's my permanent lab.

What I set out to do today

The first step seemed simple: get a Raspberry Pi 4 running Raspberry Pi OS Lite, booting from a USB SSD instead of a microSD card, with SSH key authentication configured for passwordless access from my laptop.

What actually happened was a four-hour debugging session that taught me more about USB controllers, kernel parameters, and partition UUIDs than I expected.

The hardware

• Raspberry Pi 4 Model B (4GB)

• Intenso External SSD 256GB Premium

• 32GB Samsung microSD (used only for initial setup, removed at the end)

• Geekworm aluminium passive case

• Wired keyboard, mouse, and a portable monitor for setup

• Ubuntu laptop for SSH and flashing

I want to call out one decision specifically. I went back and forth between getting the Argon ONE M.2 case with an internal SSD versus using my existing Geekworm case with a USB SSD. The Argon ONE is the "proper" permanent setup — internal M.2 drive, active cooling, cleaner form factor. But it would have cost €90+ more.

I chose the budget path: keep the Geekworm case, use a USB SSD for now, plan to migrate to the Argon ONE in 12-18 months. The learning value is identical regardless of which case the SSD is in. Don't let perfect be the enemy of started.

Phase 1: The Imager problem

I started by flashing Raspberry Pi OS Lite (64-bit) to the microSD using Raspberry Pi Imager on Ubuntu.

Source: Raspberry Pi Imager documentation

Imager's "OS customisation" feature is supposed to let you pre-configure hostname, SSH, username, and password before flashing — so the Pi boots ready to use without monitor and keyboard.

It didn't work for me. Twice.

I followed the documented flow: EDIT SETTINGS → fill in → SAVE → YES to apply → YES to overwrite. The flash completed, I put the card in the Pi, booted it — and the Pi prompted me for a new username and password as if no customisation had been applied at all.

I attempted a manual workaround: flash a clean image, then create ssh and userconf.txt files on the boot partition myself. That didn't work cleanly either.

In the end, the fastest path forward was to plug a keyboard and monitor into the Pi and just go through the first-boot wizard interactively. 30 seconds and I had a working system.

Lesson: When a tool that's supposed to save you time isn't working, sometimes the most productive thing is to abandon it. Don't burn an hour debugging a convenience feature.

Phase 2: Enabling SSH

After completing the first-boot wizard, I tried to SSH from my laptop and got:

ssh: connect to host 192.168.0.249 port 22: Connection refused

SSH wasn't enabled by default. Easy fix from the Pi console:

sudo systemctl enable ssh
sudo systemctl start ssh
sudo systemctl status ssh

Source: systemd documentation on enabling services

From this point on, I could disconnect the keyboard, mouse, and monitor and work entirely over SSH from my laptop. Much faster.

Phase 3: Setting up USB boot from SSD

This is where the real adventure began.

The Pi 4 can boot from USB devices, but two things have to be in place:

1. The bootloader firmware needs to be configured to look for USB before microSD

2. The USB device needs to be detected reliably during early boot

Step 1: Update the bootloader and set USB boot priority

sudo apt update && sudo apt full-upgrade -y
sudo rpi-eeprom-update -a
sudo raspi-config

In raspi-config: Advanced Options → Boot Order → B2 USB Boot.

Verifying:

sudo rpi-eeprom-config

Output included BOOT_ORDER=0xf14, which reads right-to-left:

• 4 = USB mass storage

• 1 = SD card

• f = retry forever

So the Pi will try USB first, then fall back to SD card, then loop. Exactly what a permanent SSD setup needs.

Source: Raspberry Pi bootloader configuration documentation

Phase 4: The JMicron problem

I plugged the Intenso SSD into a blue USB 3.0 port, ran lsblk, and saw the drive appear as /dev/sda with 238.5GB of capacity. So far so good.

Then I ran a speed test:

yvette@newerkey-lab:~ $ sudo apt install -y hdparm
yvette@newerkey-lab:~ $ sudo hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads: 4 MB in 32.19 seconds = 127.23 kB/sec

127 kilobytes per second. That's roughly a thousand times slower than a working USB 3.0 drive should be. At that rate, copying a 4GB OS image would take about nine hours.

I checked dmesg and found the issue. The Intenso SSD uses a JMicron USB-to-SATA controller:

yvette@newerkey-lab:~ $ sudo dmesg | grep -i sda
[546.122668] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd
[546.140093] usb 2-2: New USB device found, idVendor=152d, idProduct=0579
[546.140131] usb 2-2: Product: Portable SSD
[546.140142] usb 2-2: Manufacturer: Intenso
[546.685838] sd 0:0:0:0: [sda] 500118192 512-byte logical blocks: (256 GB/238 GiB)
[546.770965]  sda: sda1 sda2
[546.771605] sd 0:0:0:0: [sda] Attached SCSI disk

JMicron controllers have a long history of incompatibility with USB Attached SCSI (UAS) on Raspberry Pi 4. The fix is a kernel parameter that disables UAS for the specific drive ID:

usb-storage.quirks=152d:0579:u

Source: James A. Chambers' Raspberry Pi USB Boot Config Guide

The :u flag tells the kernel to ignore UAS and fall back to standard USB mass storage protocol — slower theoretical maximum, but actually functional with JMicron controllers.

The first cmdline.txt mistake

The quirks parameter goes into /boot/firmware/cmdline.txt, which is a single-line file containing all the kernel boot parameters.

I edited it with nano and added the quirks parameter. Saved, rebooted, and the Pi never came back online. SSH timed out with "No route to host".

Plugged a monitor in. Grey screen. No boot text, no kernel messages, just grey.

Pulled the microSD out, put it in my laptop, ran:

cat /media/yvette/bootfs/cmdline.txt

The line read:

usb-storage.quirks=152d:u console=serial0,115200 console=tty1 root=PARTUUID=543ddb0d-02 rootfstype=ext4 fsck.repair=yes rootwait

I'd typed 152d:u instead of 152d:0579:u. The kernel was receiving a malformed quirks parameter and bailing out during early boot before it could even display kernel messages.

Fixed the typo, saved, put the card back in the Pi, booted again. This time I checked the file with cat -A to see hidden characters:

cat -A /boot/firmware/cmdline.txt

The -A flag shows newlines as $. Critical because:

The cmdline.txt must be exactly one line. Any line break anywhere will break boot.

Raspberry Pi documentation on cmdline.txt

The output showed two \( signs — one at the end of my line, and another on its own. nano had introduced an extra blank line at the end of the file. Removed it, verified one \), rebooted.

This time the Pi came back up. SSH worked. Speed test:

yvette@newerkey-lab:~ $ sudo hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads: 912 MB in 3.01 seconds = 303.39 MB/sec

303 megabytes per second. Healthy USB 3.0 performance. The quirks fix was working.

The before-and-after is dramatic:

Phase 5: Cloning microSD to SSD

With the SSD performing properly, I could clone the running OS from microSD onto the SSD. The community tool rpi-clone handles this cleanly:

sudo apt install -y git
git clone https://github.com/billw2/rpi-clone.git
cd rpi-clone
sudo cp rpi-clone rpi-clone-setup /usr/local/sbin/

Source: rpi-clone GitHub repository

Then I wiped the SSD's existing partition table (it had a stale Pi OS Desktop image from an earlier failed attempt):

sudo wipefs -a /dev/sda

Source: wipefs manpage

And cloned:

sudo rpi-clone sda

The clone took under two minutes thanks to the 303 MB/sec USB 3.0 speeds.

The PARTUUID problem

After cloning, I expected the SSD to be an exact copy of the microSD's running system. I mounted the SSD's boot partition to verify cmdline.txt:

sudo mount /dev/sda1 /mnt/ssd-boot
cat /mnt/ssd-boot/cmdline.txt

The line still referenced root=PARTUUID=543ddb0d-02 — the microSD's root partition PARTUUID. If I booted from the SSD with the microSD removed, the kernel would look for a partition that didn't exist and drop into initramfs.

I checked the SSD's actual PARTUUID with blkid:

sudo blkid

Output showed the SSD's root partition was actually 6692b3d6-02. So the cmdline.txt was pointing at the wrong device entirely.

Lesson: rpi-clone is supposed to update cmdline.txt automatically, but it doesn't always do so reliably. Always verify the PARTUUID matches the destination device after cloning.

I edited the SSD's cmdline.txt to use the correct PARTUUID:

sudo nano /mnt/ssd-boot/cmdline.txt

Changed root=PARTUUID=543ddb0d-02 to root=PARTUUID=6692b3d6-02. Verified with cat -A again — one line, one $ at the end.

I also checked /etc/fstab on the SSD's root partition. Fortunately rpi-clone had updated that one correctly — it already pointed at 6692b3d6-01 and 6692b3d6-02.

The swap

Shut down cleanly:

sudo shutdown -h now

Waited for the green LED to stop flickering. Unplugged power. Removed the microSD card. Confirmed the SSD was still plugged into a blue USB 3.0 port. Plugged power back in.

60 seconds later, SSH connected from my laptop:

yvette@laptop:~$ ssh yvette@ip-of-raspberrypi
yvette@newerkey-lab:~ $

Verification:

yvette@newerkey-lab:~ $ findmnt /
TARGET SOURCE    FSTYPE OPTIONS
/      /dev/sda2 ext4   rw,noatime

Booting from SSD. No more microSD in the system.

yvette@newerkey-lab:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       234G  4.2G  218G   2% /
/dev/sda1       511M   67M  445M  14% /boot/firmware

234GB root filesystem, 218GB available. Three orders of magnitude more storage than the original microSD setup, with significantly more reliable continuous-write endurance.

Phase 6: SSH key authentication

Final task was switching from password authentication to SSH keys on your laptop's terminal, not the raspberry-pi.

Already had a key pair on my laptop (~/.ssh/id_ed25519), so:

• If you do not have it, create a new one ssh-keygen -t ed25519 -C "yourpreferedname"

ssh-copy-id -i ~/.ssh/id_ed25519.pub yvette@ip-of-raspberrypi

One last password prompt, then tested:

ssh yvette@ip-of-raspberrypi

Passwordless login confirmed.

Source: ssh-copy-id manpage

What this actually taught me

The "happy path" version of this day would have taken maybe 90 minutes. Mine took four hours.

But every detour was an actual lesson:

USB controllers matter. Not all SSDs work the same on Raspberry Pi. The JMicron quirks fix is one of those things you only learn by needing it. Now I know to check lsusb and dmesg for the actual controller vendor ID before assuming a drive will work.

Source of truth beats tutorials. Every time I found myself stuck, the answer was in the official Raspberry Pi documentation, the kernel parameters reference, or the source GitHub repo of the tool I was using. Random Stack Overflow answers often gave outdated or wrong fixes. I've started keeping a sources.md file with bookmarked official docs for every tool in the lab.

Verify your assumptions explicitly. I assumed rpi-clone would update cmdline.txt correctly. It didn't. I assumed nano would save cmdline.txt as a single line. It didn't. Now I run cat -A after every config file edit to verify there are no hidden characters or extra newlines.

Hidden characters break systems. A single trailing newline in cmdline.txt is the difference between a working Pi and a grey screen. cat -A is now in my standard toolkit.

The fast path forward is sometimes abandoning the tool. I burned time trying to make Imager's OS customisation work. The 30-second interactive first-boot wizard solved the same problem instantly.

What's running now

Raspberry Pi 4 Model B (4GB)
└── Raspberry Pi OS Lite (64-bit), fully updated
    └── Booting from /dev/sda2 (Intenso 256GB USB SSD)
        ├── Read speed: 303 MB/sec
        ├── Storage: 234GB total, 218GB available
        └── usb-storage.quirks=152d:0579:u applied
            
Hostname: newerkey-lab
SSH: key-based authentication only

The foundation is in place. Permanent lab ready.

Sources:

• Raspberry Pi Imager documentation

• Raspberry Pi bootloader configuration

• Raspberry Pi cmdline.txt documentation

• Linux kernel parameters

• James A. Chambers: Raspberry Pi USB Boot Config Guide

• rpi-clone on GitHub

• systemctl manpage

• ssh-copy-id manpage

• wipefs manpage

If you're following along or doing your own Pi 4 SSD boot setup, the rpi-imager guide on the official Pi site is the right starting point. If you hit JMicron compatibility issues, check lsusb for your drive's vendor:product ID and apply the appropriate usb-storage.quirks parameter.

Configuring AWS environment

This section takes you through installing and configuring the AWS command line(CLI). For everything that can be done on the AWS Management Console, we can use the CLI also.

To install AWS CLI, follow the instructions based on your operating system (https://docs.aws.amazon.com/cli/latest/userguide/getting-started-version.html)

Note: I am using a Unix system for configuration.

Verify that the CLI is properly installed by typing the command. You should see the version, in my case 2.11.1 is installed.

aws --version

Create User

Let's create an IAM User and grant it permissions it needs to access the right AWS resources. It is not advised to use the root user for security reasons. Find out more about how it works https://aws.amazon.com/iam/.

Sign in to AWS Management Console then type IAM in the search bar and click on the result to take you to the IAM dashboard as shown in figure 1.0.

From the left menu, choose Users. Click the Add User button. Then set a name for the user and create the password depending on your preference(also select AWS Management Console access if you want the same user to have access to the console), as shown in figure 1.10.

In the Set Permissions section, assign a policy to the user. In this case, the AmazonS3FullAccess policy, as shown in figure 1.11. If you already have a user group created with the same policy, you can select it instead.

On the next page, you can review and create your user. You can optionally add a tag to the user.

On the final page, you should see the user’s console sign-in details(figure 1.12). You can download the .csv file which contains the details.

Return to the users list, the new user will appear, and click on the user to get its details. To allow access to this user from the CLI for programmatic access, we proceed to create an access key under Security Credentials.

We can then choose how to use the access key shown in figure 1.14 and click next. In our case, we want to be able to use it via the CLI.

In the last section Retrieve access keys section, you can view your access and secret access keys. The recommended way to save these keys is to download .csv file as we won't be able to see it anymore.

Connect to AWS CLI

Now that we have everything we need, let's configure the AWS CLI using the command.

aws configure

Enter the details as prompted in your terminal. Depending on your location, use your default region.

The CLI will store credentials specified in the preceding command in a local file under ~/.aws/credentials (or in %UserProfile%\.aws\credentials on Windows) with the following details.

That should be it, and we have our AWS environment set up.

Context: This was part of my early cloud and infrastructure learning journey. I’m keeping it here as a reference

Ever since I started my journey into Software Engineering, I have known others who have experienced the fast, ever-changing field, which can become overwhelming. They gradually quit at some point or follow the latest trends wherever it leads them.

These trends, however, have the same purpose in common, to solve problems in our everyday lives and society.

Even though I am from another technical background(Materials Engineering), I always find myself stuck whenever I am given a problem to solve in coding and do not know what to do or where to start, hence, this article. I will explore, shortly three main approaches to problem-solving that I discovered.

Question: How is it possible to build or invent a solution or discover a fact?

Mathematical method

• Understand the problem

• Find the connection between the data given and the unknown.

Turning problems into code

• Understand the problem

• Discover Inputs, Processes/methods, and Outputs

• Driving Design with Tests

• Writing the Algorithm in pseudocode

• Writing the code

When coding: Debugging

Read more on debugging written by German Cocca 👉🏽 here

References

1. "Exercises for Programmers 57 Challenges to Develop Your Coding Skills*(Chapter 1)***" - Brian P. Hogan

2. "How to Solve It" - G. Polya

3. "3D game programming for kids: create interactive worlds with JavaScript*(Chapter 2)*"** - Chris Storm