DEV Community: eapreko

Redundancy Transformation Plan - Your Redundancy is a Disguised Setup for Your Next Great Chapter

eapreko — Tue, 10 Mar 2026 15:29:29 +0000

Have you ever felt that sudden, jarring shift? That moment when the ground beneath your feet seems to give way, and a wave of uncertainty washes over you? It seems like your whole world is imploding after being told in a meeting or via email that you've been made redundant? In that instant, it's easy for doubt to creep in, for fear to try and take root. But I'm here to tell you today, with every fibre of my being, that this is not the end of your story. This is not a setback; it is a possibly disguised setup for your next great chapter, a powerful redirection towards the productive life you were always meant to live. Get ready, because your comeback is already in motion!

Embracing the Shift: Understanding Your New Beginning

When the news of redundancy arrives, it can feel like a personal affront, a judgment on your worth. But let's reframe this moment. This isn't about what you've lost; it's about the incredible space that's just been created for what's next. It's an opportunity to shed what no longer serves you and step into a season of unprecedented growth and opportunity. You are not defined by a job title or a company's decision; you are defined by the limitless potential within you.

First, it's crucial to understand the mechanics of what has just happened. Knowledge is power, and clarity dispels fear. Many employers follow specific criteria when making redundancy selections. These can include factors like Last In, First Out (LIFO), performance, skills, attendance, disciplinary records, or even cost. While employers have a degree of flexibility, these criteria must be objective and non-discriminatory. It's important to understand that subjective criteria, such as flexibility, must be backed by clear management notes, and cost-based criteria can carry risks of age discrimination. Take a moment to review your selection scoring. Was it fair? Was it consistent? Was it free from bias? Understanding this process isn't about dwelling on the past, but about empowering yourself with information for your future¹.

Next, consider the settlement agreement. From an employer's perspective, these agreements are often about achieving "finality" and mitigating tribunal risks. They are paying for peace of mind, to avoid hassle and potential legal battles. This insight is powerful, because it means you have leverage. If you understand their motivation, you can better gauge the "premium" they might be willing to pay on top of statutory redundancy to secure that clean break². Don't just accept; understand the value you bring to the negotiation table.

Now, here’s a truth that might surprise you: being made redundant can be awesome! I know, it sounds counter-intuitive when you’re in the midst of it. But hear me out. Many successful individuals look back at redundancy as the necessary "reset" that propelled them to something far greater. It’s often the catalyst for a better role, higher pay, or a completely new, more fulfilling direction. If you find yourself on "garden leave," resist the temptation to treat it as a vacation. Instead, treat it like a job. Wake up early, maintain a schedule, and use this precious time to polish your skills, network, and strategise your next move. The initial sting is real, but the long-term trajectory can be overwhelmingly positive if you maintain your momentum and mindset³.

And what about the emotional journey? The feelings of shame, rejection, or even anger are natural. But what if this moment is actually a powerful correction course? What if it’s an invitation to confront what truly defines you? Many have found that redundancy broke their attachment to a job title or external validation, allowing them to pivot towards a career they genuinely loved. It’s about "surrendering" to the uncertainty, accepting the situation rather than fighting it. When you release the need to control every outcome, you create space for clarity and purpose to emerge. This isn't just a job change; it's an opportunity for profound personal transformation, leading you to more meaningful work⁴.

Charting Your Course: Mastering the Job Search & Interview

Now that you’ve embraced this powerful shift, let’s talk strategy. The traditional job search—mindlessly applying to countless positions—is often a broken system. It’s a lottery, with Applicant Tracking Systems (ATS) and sheer volume making it incredibly difficult to stand out. Smart, capable people often fail not because they lack talent, but because they rely on a passive system. It’s time to take control. Instead of waiting to be chosen, create a "reliable system" for interviews by directly reaching out to decision-makers, not just HR. Identify a specific business problem you can solve, and pitch that solution directly to a hiring manager. This bypasses the "compliance" trap of standard applications and positions you as a proactive problem-solver⁵.

When you get that interview, forget the old ways. The standard STAR (Situation, Task, Action, Result) method can be too slow, burying your most impressive outcomes. Instead, adopt the HERO framework: Headline (start with the impressive outcome), Effect (why it mattered to the business), Rationale (the strategic choices and trade-offs you made), and Operations (the execution). This framework ensures you sound like a leader, focused on return on investment and strategy, rather than just a "doer" listing tasks. It positions you as a peer, ready to contribute at a high level⁶.

Interviewing is an elite discipline, and there are secrets to mastering it. Stop memorising trivia and start studying the business’s financial pain points. Understand their challenges, their goals, and how you can be the solution. Embrace the "Google XYZ formula": Accomplished X as measured by Y, by doing Z. Quantify your impact. But beyond the technicalities, manage your energy, not your ego. Project calm "poise" rather than bravado. And always, always, close consultatively. Summarise the company’s challenges and validate if your proposed focus aligns with the manager’s vision. This shows you’re not just looking for a job; you’re looking to make a significant difference⁷.

And here’s a provocative thought: sometimes, "lying" gets you hired. Now, I’m not talking about deceit; I’m talking about framing. Total honesty, like sharing every negative thought about a past employer, is a liability. An interview is an audition. When asked "How are you?" it’s a test of emotional regulation, not an invitation for a therapy session. Learn to select the "version of the truth" that serves the business narrative. Frame resume gaps confidently as planned breaks or periods of upskilling. Address "weaknesses" by focusing on growth and learning. Never hand an interviewer a reason to say "no." Always present yourself as the solution, the asset, the answer to their needs⁸.

Elevating Your Impact: Working Smarter, Not Just Harder

Once you’ve landed that next incredible opportunity, the journey of growth continues. Many believe that hard work alone leads to career advancement. But often, hard work is useless if it doesn’t solve a problem your manager actually cares about. Think of it like "Product-Market Fit" for your career. You might be building an amazing "product" (your skills, your clean code), but if there’s no "market" (a problem your manager values), it won’t lead to growth. The key is to conduct "market research" in your 1-on-1s. Identify your manager’s "expensive pain"—their biggest challenges—and then apply your unique skills to solve that specific problem. This shifts you from being merely "helpful" to becoming absolutely "essential"⁹.

Don’t let your achievements go unnoticed. Due to recency bias, managers can easily forget your early-year accomplishments by review time. The solution? Create a "Brag Book." This is a living document where you log your wins, mapping them to promotion criteria, even using AI to help you articulate your impact. Understand communication "altitude"—how to explain your work differently to peers (technical details) versus leadership (business impact). And make your work "loud." Send regular updates, praise others publicly, and normalise sharing your successes. If you don’t narrate your value, it effectively doesn’t exist¹⁰.

Have you ever felt like an impostor, despite your successes? That nagging feeling that you’re not good enough, that you’ll be found out? Lean into it, don’t give into it! Impostor syndrome is often a sign of a healthy, high-achieving mind. Narcissists rarely feel it. High performers feel like frauds because they focus on their internal "resume of failures," while everyone else sees their external achievements. Reframe this anxiety as "growing pains." If you feel out of your depth, it means you are in a zone of development, stretching beyond your comfort zone. Use this feeling as data to identify where you need to upskill, rather than letting it paralyse you. It’s a sign you’re on the right track, pushing boundaries and expanding your capabilities¹¹.

For those who aspire to elite performance, consider the wisdom gleaned from billion-dollar boardrooms. It’s about more than just what’s presented; it’s about "listening to ghost notes"—noticing what’s missing from a presentation, the unspoken truths. It’s about "optimising for error"—viewing mistakes not as failures, but as necessary data for growth, much like AI learning. Develop "adaptive tension"—the ability to remain calm and effective in high-stakes conflicts. And cultivate "cathedral thinking"—planning with a 7-year horizon, focusing on long-term impact over short-term gains. Shift your focus from "What will this get me?" to "Who will this make me?" This journey is about identity and lasting value, not just temporary status¹².

Future-Proofing Your Journey: Levelling Up Skills for Tomorrow

In this rapidly evolving world, especially with the rise of Artificial Intelligence, staying relevant is not just an advantage—it’s a necessity. While AI is a powerful tool, it’s crucial to understand its nuances. It’s excellent for prototyping and "vibe coding," but it can also create technical debt and sloppy code in production, potentially slowing down experienced developers. And be warned: using AI to "cheat" in interviews is easily spotted by seasoned hirers. The real opportunity lies in mastering the integration of AI. Focus on skills like integrating AI into applications and Retrieval-Augmented Generation (RAG). Don’t let AI replace your critical thinking; instead, master how to leverage it as a powerful augmentative tool to stay highly employable¹³.

Indeed, AI literacy is no longer just for tech roles; it’s mandatory for all roles. We are transitioning from "doing" tasks to "managing" intelligent agents, making the ability to critically evaluate AI output a key leadership skill. Experts predict that 39% of current skills may be outdated within five years. This calls for a "skills-first" approach to career development. Demonstrating "AI fluency" and a commitment to continuous learning—a deep sense of curiosity—is the best way to future-proof your career against the rapid obsolescence of technical skills. View AI not as a threat, but as a tool for augmentation, empowering you to achieve more and contribute at a higher level¹⁴.

Your Unstoppable Comeback

Despite how you feel right now remember you are not a victim of circumstance; you are a victor in the making. This moment of redundancy is not a period of loss, but a powerful punctuation mark, signalling the beginning of your greatest chapter yet. Embrace the shift, master the strategy, elevate your impact, and future-proof your journey. Your comeback is not just coming; it is already here, waiting for you to step into it with faith, courage, and an unstoppable spirit. Get ready to live the next chapter of your purposeful life!

Please share this with anyone you know who may find this helpful or beneficial and let me know your thoughts and contributions in the comments!

PLEASE NOTE: This article is a carefully curated collation of wisdom from experts and high-performers, designed to provide you with the most effective and productive tools to navigate your career transition successfully. Thanks and all acknowledgments to the original content creators and below are citations for all references made above.

References

Complete Guide: Raspberry Pi LVM Setup with M.2 SSD - Improved Performance Boost

eapreko — Tue, 26 Aug 2025 11:38:52 +0000

TL;DR

🚀 Impressive performance improvement over microSD
🛡️ Data protection through LVM volume separation
📊 Benchmark results explanations included
⚡ 250+ MiB/s sequential read speeds achieved

Raspberry Pi LVM Setup Guide - The Smart Way to Manage Storage

🚀 Quick Start for Technical Users: Skip the introduction and jump straight to the technical implementation

Introduction & Overview

Introduction: Why Your Pi Deserves Better Storage Management
What is LVM? Explain Like I'm 5
Why Would I Want This?
- The Problem with Standard Pi Setup
- The Improved Solution

Planning & Comparison

The Convenience vs. Flexibility Trade-off
- Raspberry Pi Imager: Convenient but Limiting
- Why This Matters for Large SSDs
Pros and Cons Comparison
- When to Use Standard Setup
- When to Use LVM Setup

Use Cases & Benefits

Real-World Scenarios
- Scenario 1: Home Media Server
- Scenario 2: Development Workstation
- Scenario 3: Learning Environment
Performance Benefits You'll See
What We'll Accomplish

Technical Implementation

Technical Implementation Guide
- Prerequisites and Safety
- Required Hardware & Systems
- Before You Begin
- Important Notes About This Workflow

Step-by-Step Process

Step 1: Initial OS Installation and Backup Creation (Ubuntu Laptop)
- 1.1 Connect SSD to Ubuntu Laptop
- 1.2 Write Initial OS Image to SSD
- 1.3 Mount and Create Backups
- 1.4 Unmount Partitions Safely
Step 2: Create Optimal Partition Layout (Ubuntu Laptop)
- 2.1 Design New Partition Scheme
- 2.2 Create New Partition Table
- 2.3 Verify New Partition Layout
Step 3: Create Filesystems and LVM Structure (Ubuntu Laptop)
- 3.1 Format Standard Partitions
- 3.2 Set Up LVM Infrastructure
- 3.3 Verify LVM Setup
Step 4: Restore System Data to New Partitions (Ubuntu Laptop)
- 4.1 Restore Boot Partition
- 4.2 Restore Root Partition
Step 5: Update System Configuration (Ubuntu Laptop)
- 5.1 Get Partition UUIDs
- 5.2 Update Boot Configuration
- 5.3 Update Filesystem Mount Configuration
Step 6: Final System Preparation (Ubuntu Laptop)
- 6.1 Verify Configuration Files
- 6.2 Clean Unmount All Filesystems
- 6.3 Safe Device Ejection

Pi Setup & Testing

Step 7: Pi Boot and Verification
- 7.1 First Boot on Raspberry Pi
- 7.2 Test Basic Functionality (Pi)
Step 8: Performance Benchmarking (Pi)
- 8.1 Install Benchmarking Tools
- 8.2 Quick Performance Tests
- 8.3 Understanding Your Results

Management & Maintenance

Step 9: LVM Management and Maintenance
- 9.1 Create Snapshots for Safety
- 9.2 Expand Volumes as Needed
Step 10: Ubuntu Laptop Cleanup (Optional)
- 10.1 Clean Up Backup Files
- 10.2 Remove Temporary Mount Points
- 10.3 Package Cleanup (Optional)

Troubleshooting & Recovery

Troubleshooting
- Boot Issues
- LVM Not Found
- Mount Failures
Emergency Recovery
- Method 1: Full Recovery from Ubuntu Laptop (Recommended)
- Method 2: Access System from microSD (Pi-based recovery)

Advanced Procedures

Complete SSD Wipe Procedure
- Prerequisites for SSD Wipe
- Step 1: Remove LVM Infrastructure
- Step 2: Delete All Partitions
- Step 3: Complete Disk Wipe
- Step 4: Fresh Start Verification
- When to Use Complete SSD Wipe

References

Summary
References and Acknowledgments
- Technical Documentation
- Performance Data
- Methodology
- Community Resources

Introduction: Why Your Pi Deserves Better Storage Management

If you've ever felt frustrated by running out of space on your Raspberry Pi, struggled with OS upgrades, or wished you could separate your data from your operating system, this guide is for you. We're going to transform your Pi from a simple microSD-based system into a storage powerhouse using LVM (Logical Volume Manager) on a high-performance M.2 SSD.

What is LVM? Explain Like I'm 5

Imagine your SSD is like a big house, but instead of having one giant room where you keep everything mixed together, you have separate rooms:

The office room (Operating System) - where all the important work stuff lives
Your bedroom (Your personal files/projects) - where your personal stuff stays safe
The guest room (Future storage) - ready for when you need more space
The storage closet (Snapshots) - where you keep backup copies of important things

LVM is like having magic walls that can:

Move and resize - make rooms bigger or smaller as needed
Take photos of how each room looks before you change it
Keep rooms separate - if you renovate the office, your bedroom stays untouched

In computer terms:

Physical Volume (PV) = Your big house (the SSD)
Volume Group (VG) = The house's floor plan and organisation system
Logical Volume (LV) = Each individual room (data storage, projects, etc.)

Why Would I Want This?

The Problem with Standard Pi Setup

When you use the Raspberry Pi Imager on a large SSD (let's say 512GB), here's what actually happens:

Standard Pi Imager Result:
┌────────────────────────────────────────────────────────┐
│              M.2 SSD - 500GB Total Capacity            │
├────────────────────────────────────────────────────────┤
│         Single 476GB Partition (after formatting)      │
│ ┌──────────┬─────────────────────────────────────────┐ │
│ │    OS    │            Available Space              │ │
│ │   4GB    │                472GB                    │ │
│ │ ████████ │ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░│ │
│ └──────────┴─────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────┘

Legend: ████ OS/System Files    ░░░░ Available Space

Problem: Root partition expands to use entire disk - OS and data mixed

Problems with this approach:

OS upgrades risk your data - everything mixed in one expanding partition. Imagine upgrading your smartphone's operating system to the latest version to fix a minor or major security patch, shiny new features, etc and having to worry about the possibility of losing all your irreplaceable photos, conversations, etc should something go wrong each time you consider doing this!
No separation - OS and user data compete for the same space and I/O
No snapshots - can't easily backup/restore just the OS or just your data
Inflexible - can't resize or reorganise without complex operations
Poor performance optimisation - can't tune different areas for different workloads

The Improved Solution

With our approach, you get clean separation:

Optimised Setup with LVM for Data:
┌────────────────────────────────────────────────────────┐
│              M.2 SSD - 500GB Total Capacity            │
├────────────────────────────────────────────────────────┤
│           Optimised Setup with LVM for Data            │
│         476GB Available Space (after formatting)       │
│ ┌──────────┬──────────────────────────────────────────┐│
│ │    OS    │            LVM-Managed Data Space        ││
│ │   50GB   │ ┌──────────┬────────────┬──────────────┐ ││
│ │ (ext4)   │ │   Home   │  Projects  │    Future    │ ││
│ │ ████████ │ │  200GB   │   150GB    │    76GB      │ ││
│ │ ████████ │ │  (LV)    │    (LV)    │  (unused)    │ ││
│ │ ████████ │ │ ████████ │ ░░░░░░░░░░ │ ░░░░░░░░░░░░ │ ││
│ └──────────┴─┴──────────┴────────────┴──────────────┘─┘│
└────────────────────────────────────────────────────────┘

Legend: ██ Used Space ░░ Available/Future Space LV = Logical Volume

Benefits: OS isolated, data flexible/snapshottable/expandable

The Convenience vs. Flexibility Trade-off

Raspberry Pi Imager: Convenient but Limiting

What Pi Imager Does Well:
✅ Dead simple - just click and flash

✅ Handles all the boot configuration automatically

✅ Configures WiFi, SSH, users in one step

✅ Works every time without technical knowledge

Where Pi Imager Falls Short:
❌ Uses entire disk as one partition - no flexibility

❌ Mixes OS and data - upgrades risk your personal files

❌ No volume management - can't resize without pain

❌ No snapshots - can't easily backup/restore states

❌ One size fits all - can't optimise for different use cases

Why This Matters for Large SSDs

When you flash Pi OS onto a 512GB SSD:

# What you get (after formatting):
/dev/sda1    512M  boot partition (FAT32)
/dev/sda2    475G  root partition (ext4) - OS + data mixed!

# What you actually need:
/dev/sda1    512M  boot partition  
/dev/sda2     50G  OS only (isolated, upgradeable safely)
/dev/sda3    300G  home directory (your data, safe from OS changes)
/dev/sda4    100G  projects/docker/databases (separate performance)
# Remaining 25G reserved for snapshots and future use

Pros and Cons Comparison

Aspect	Standard Pi Setup	Pi with LVM
Setup Complexity	⭐⭐⭐⭐⭐ Dead simple	⭐⭐ Requires technical knowledge
OS Upgrade Safety	⭐⭐ Risk losing data	⭐⭐⭐⭐⭐ Data completely isolated
Storage Flexibility	⭐ Fixed partition sizes	⭐⭐⭐⭐⭐ Resize volumes on demand
Backup/Restore	⭐⭐ Full system only	⭐⭐⭐⭐⭐ Snapshot individual volumes
Performance	⭐⭐⭐ All I/O on one partition	⭐⭐⭐⭐ Separate performance profiles
Space Utilisation	⭐⭐ Entire disk	⭐⭐⭐⭐⭐ Optimal space allocation
Troubleshooting	⭐⭐⭐⭐ Simple structure	⭐⭐ Need LVM knowledge
Future Growth	⭐ Hard to expand	⭐⭐⭐⭐⭐ Add storage easily

When to Use Standard Setup

Learning/experimentation - you just want Pi to work
Temporary projects - not concerned about long-term data
Simple applications - basic web browsing, simple scripts
SD card based - small storage, frequent re-flashing

When to Use LVM Setup

Development work - need to separate projects and tools
Media server - large amounts of data to organise
Database/Docker hosting - different performance needs per service
Long-term use - system will grow and evolve over time, reliability and data safety matter
Large SSDs - 256GB+ where space management matters

Real-World Scenarios

Scenario 1: Home Media Server

# Without LVM - Everything mixed together
/dev/sda2  500GB  [OS + Movies + TV Shows + Photos + System logs]
# Problem: OS upgrade could corrupt media, can't optimise performance

# With LVM - Clean separation
/dev/vg_main/os       40GB   [Operating System only]
/dev/vg_main/media   300GB   [Movies, TV, optimised for sequential read]  
/dev/vg_main/photos  100GB   [Photos, backed up separately]
/dev/vg_main/apps     50GB   [Plex, etc., can snapshot before updates]

Scenario 2: Development Workstation

# Without LVM - Chaos
/dev/sda2  500GB  [OS + Docker + Projects + Databases + Build artifacts]
# Problem: Everything on one partition, if something goes wrong impact could be undesirable

# With LVM - Organised
/dev/vg_main/os       40GB   [OS, can snapshot before updates]
/dev/vg_main/docker  100GB   [Container storage, separate performance]
/dev/vg_main/projects 150GB   [Source code, backed up to git]
/dev/vg_main/data    100GB   [Databases, optimised for random I/O]
/dev/vg_main/build   100GB   [Temp space, can be wiped safely]

Scenario 3: Learning Environment

# Without LVM - Fear of breaking things
/dev/sda2  500GB  [Everything mixed - scared to experiment]

# With LVM - Confidence to experiment  
/dev/vg_main/os       40GB   [Snapshot before trying new things]
/dev/vg_main/stable  100GB   [Known-good configurations]
/dev/vg_main/experiment 50GB [Break things safely]
/dev/vg_main/backup   50GB   [Quick local restore point]

Performance Benefits You'll See

Based on real testing with quality M.2 SSDs on Raspberry Pi:

Operation	MicroSD Card	Standard SSD	LVM SSD
Boot Time	60-90 seconds	30-45 seconds	15-25 seconds
Package Install	Very slow	Fast	Very fast
Database Operations	Painful	Good	Excellent*
File Operations	Slow	Fast	Optimised*
Docker Containers	Barely usable	Good	Excellent*

*Because different workloads can be placed on optimised volumes

What We'll Accomplish

By the end of this guide, you'll have:

Noticeably fast Pi - M.2 SSD performance (15-50x faster than SD card)
Bulletproof upgrades - OS and data completely separated
Flexible storage - resize volumes as your needs change
Professional setup - snapshot capabilities, proper backup strategy
Future-proof system - easy to expand and modify

The process uses a backup/restore methodology giving you complete control over your storage layout from day one.

Ready to transform your Raspberry Pi? Let's dive into the technical implementation...

Technical Implementation Guide

Prerequisites and Safety

Required Hardware & Systems

Raspberry Pi 4/400/5/500 with current microSD card setup
256GB+ M.2 SSD (or similar high-capacity storage)
Ubuntu laptop/desktop for partitioning tasks (much safer than doing this on the Pi)
USB-to-M.2 adapter or M.2 enclosure to connect SSD to Ubuntu laptop

Before You Begin

CRITICAL: Create a full backup of your existing Pi system before proceeding
Have SSH access to your Pi for final testing
Install required tools on Ubuntu laptop: sudo apt update && apt install -y rpi-imager parted lvm2
Ensure you have at least 10GB free space on Ubuntu laptop for temporary backups

Important Notes About This Workflow

All operations performed on Ubuntu laptop (safer, more reliable)
Device names will differ between systems (/dev/sdb on laptop vs /dev/sda on Pi)
Always verify device names with lsblk before proceeding
This guide uses DEVICE as a placeholder - replace with your actual device name

Step 1: Initial OS Installation and Backup Creation (Ubuntu Laptop)

1.1 Connect SSD to Ubuntu Laptop

# Connect M.2 SSD via USB adapter to your Ubuntu laptop
# Verify it's detected
lsblk
sudo fdisk -l

# Identify your SSD device (likely /dev/sdb, /dev/sdc, etc.)
# CRITICAL: Verify this is correct before proceeding
export DEVICE=/dev/sdX  # SET THIS TO YOUR ACTUAL DEVICE

# Double-check you have the right device
echo "Working with device: $DEVICE"
sudo fdisk -l $DEVICE

1.2 Write Initial OS Image to SSD

Use Raspberry Pi Imager GUI to:

Select your Raspberry Pi model
Choose your preferred OS (Raspberry Pi OS or Ubuntu Server)
Select your SSD as destination device
Configure advanced options: WiFi, SSH, username, etc.
Write the image

After writing, verify partitions were created

lsblk $DEVICE

Expected output (Ubuntu Server example):
DEVICE1 - system-boot partition (~512MB, FAT32)
DEVICE2 - writable partition (~3-4GB, ext4)

1.3 Mount and Create Backups

# Create mount points for backup operations
sudo mkdir -p /mnt/pi_boot /mnt/pi_root 

# Mount the newly written root partition
sudo mount ${DEVICE}2 /mnt/pi_root     # Root partition

# Verify mounts
df -h | grep mnt

# Create backup directory
mkdir -p ~/pi_backups
cd ~/pi_backups

Create boot partition backup

⚠️ Warning:

cloud-init is very sensitive to the exact filesystem structure of the boot partition.
Using dd preserves the precise FAT32 filesystem metadata that cloud-init depends on to properly detect and process its configuration files.
This is actually documented behaviour - cloud-init expects specific filesystem characteristics on the boot partition that only bit-for-bit copying (like dd) can guarantee.

sudo dd if=${DEVICE}1 of=boot_backup.img bs=1M status=progress

# Create root partition backup. Grab a cup of coffee, 
# this might take a few minutes :) 
sudo tar -czf root_backup.tar.gz -C /mnt/pi_root .

# Verify backups were created successfully
ls -lh ~/pi_backups/
# Should show both .tar.gz (~1.2GB) and .img (~512MB) files with reasonable sizes

1.4 Unmount Partitions Safely

# Unmount partitions before repartitioning
sudo umount /mnt/pi_root

# Verify unmounts
mount | grep $DEVICE
# Should return nothing

Step 2: Create Optimal Partition Layout (Ubuntu Laptop)

2.1 Design New Partition Scheme

# Display current disk information
sudo fdisk -l $DEVICE

Plan your partition layout (example for 512GB SSD = ~476GB usable):
Partition 1: Boot (FAT32) - 2GB (larger for future kernels/overlays)
Partition 2: Root (ext4) - 50GB (generous space for OS)

2.2 Create New Partition Table

⚠️ DANGER ZONE: This destroys existing data. Ensure backups are safely created before proceeding

echo "About to repartition $DEVICE - backups created: $(ls -1 ~/pi_backups/*.tar.gz ~/pi_backups/*.img | wc -l) files"

# Start parted
sudo parted $DEVICE

# In parted interactive mode:
# Create new MBR partition table
mklabel msdos

# Confirm data destruction
# Type: yes

# Create boot partition (2GB)
mkpart primary fat32 0% 2GB

# Create root partition (50GB total = 2GB to 56GB)
mkpart primary ext4 2GB 56GB

# Create LVM partition (remaining space)
mkpart primary 56GB 100%

# Set boot flag on partition 1
set 1 boot on

# Set LVM flag on partition 3
set 3 lvm on

# Verify partition layout
print

# Expected output (512GB SSD example):
# Number  Start   End     Size    Type     File system  Flags
#  1      1.0MB   2.0GB   2.0GB   primary  fat32        boot, lba
#  2      2.0GB   55.0GB  50.0GB  primary  ext4
#  3      55.0GB  476GB   424GB   primary               lvm

# Exit parted
quit

2.3 Verify New Partition Layout

# Refresh partition table
sudo partprobe $DEVICE

# Verify new partitions
lsblk $DEVICE
sudo fdisk -l $DEVICE

# Should show three partitions with correct sizes

Step 3: Create Filesystems and LVM Structure (Ubuntu Laptop)

3.1 Format Standard Partitions

# Format boot partition (FAT32)
sudo mkfs.vfat -F32 ${DEVICE}1

# Format root partition (ext4)
sudo mkfs.ext4 ${DEVICE}2

# Verify filesystem creation
sudo blkid ${DEVICE}1  # Should show TYPE="vfat"
sudo blkid ${DEVICE}2  # Should show TYPE="ext4"

3.2 Set Up LVM Infrastructure

# Create LVM Physical Volume
sudo pvcreate ${DEVICE}3

# Create Volume Group (using meaningful name)
sudo vgcreate vg_main ${DEVICE}3

# Create Logical Volume for home directory (adjust size as needed)
# Leave some space unallocated for snapshots/future use
sudo lvcreate -L 350G -n lv_home vg_main

# Format home logical volume
sudo mkfs.ext4 /dev/vg_main/lv_home

# Alternative: Use percentage instead of fixed size
# sudo lvcreate -l 90%VG -n lv_home vg_main  # Uses 90% of VG space

3.3 Verify LVM Setup

# Display LVM configuration
sudo pvs        # Physical volumes
sudo vgs        # Volume groups  
sudo lvs        # Logical volumes

# Detailed displays
sudo pvdisplay ${DEVICE}3 && \
sudo vgdisplay vg_main && \
sudo lvdisplay /dev/vg_main/lv_home

# Expected output should show:
# - PV using full partition 3 (~424GB)
# - VG with ~424GB total space
# - LV with 350GB allocated, ~74GB free for snapshots

Step 4: Restore System Data to New Partitions (Ubuntu Laptop)

4.1 Restore Boot Partition

# Extract boot backup to new boot partition
cd ~/pi_backups
sudo dd if=boot_backup.img of=${DEVICE}1 bs=1M

# Create fresh mount points
sudo mkdir -p /mnt/new_boot /mnt/new_root

# Mount boot partition
sudo mount ${DEVICE}1 /mnt/new_boot

# Verify boot files were restored
ls -la /mnt/new_boot/
# Should show boot files like config.txt, cmdline.txt, etc.

4.2 Restore Root Partition

# Mount new partitions
sudo mount ${DEVICE}2 /mnt/new_root

# Verify all mounts
df -h | grep /mnt/new

# Extract root backup to new root partition
sudo tar -xzf root_backup.tar.gz -C /mnt/new_root/

# Verify root filesystem was restored
ls -la /mnt/new_root/
# Should show standard Linux directories: bin, boot, etc, home, etc.

# Check critical directories exist
sudo ls -la /mnt/new_root/etc/
sudo ls -la /mnt/new_root/home/

Step 5: Update System Configuration (Ubuntu Laptop)

5.1 Get Partition UUIDs

# Get UUIDs for all partitions (needed for reliable mounting)
BOOT_UUID=$(sudo blkid -s UUID -o value ${DEVICE}1) && \
ROOT_UUID=$(sudo blkid -s UUID -o value ${DEVICE}2) && \
HOME_UUID=$(sudo blkid -s UUID -o value /dev/vg_main/lv_home)

# Display UUIDs for reference
echo "Boot UUID: $BOOT_UUID" && \
echo "Root UUID: $ROOT_UUID" && \
echo "Home UUID: $HOME_UUID"

# Save UUIDs to file for reference
cat > ~/pi_backups/partition_uuids.txt << EOF
Boot UUID: $BOOT_UUID
Root UUID: $ROOT_UUID
Home UUID: $HOME_UUID
EOF

5.2 Update Boot Configuration

# Backup original cmdline.txt
sudo cp /mnt/new_boot/cmdline.txt /mnt/new_boot/cmdline.txt.backup

# Update cmdline.txt to use new root UUID
sudo sed -i "s/root=[^ ]*/root=UUID=$ROOT_UUID/g" /mnt/new_boot/cmdline.txt

# Verify cmdline.txt was updated correctly
cat /mnt/new_boot/cmdline.txt
# Should contain: root=UUID=your-root-uuid

# Alternative manual method if sed fails:
# sudo nano /mnt/new_boot/cmdline.txt
# Find the root= parameter and change it to: root=UUID=<ROOT_UUID>

5.3 Update Filesystem Mount Configuration

# Backup original fstab
sudo cp /mnt/new_root/etc/fstab /mnt/new_root/etc/fstab.backup

# Create new fstab with correct UUIDs
sudo tee /mnt/new_root/etc/fstab > /dev/null << EOF
# Raspberry Pi Partition Configuration
# Root partition
UUID=$ROOT_UUID /               ext4    defaults,noatime        0       1

# Boot partition  
UUID=$BOOT_UUID /boot/firmware  vfat    defaults                0       1

# Home directory (LVM)
UUID=$HOME_UUID /home           ext4    defaults,noatime        0       2
EOF

# Verify fstab contents
cat /mnt/new_root/etc/fstab

Step 6: Final System Preparation (Ubuntu Laptop)

6.1 Verify Configuration Files

# Double-check critical configuration files
echo "=== Boot Configuration ==="
cat /mnt/new_boot/cmdline.txt

echo "=== Filesystem Configuration ==="
cat /mnt/new_root/etc/fstab

echo "=== Partition Information ==="
sudo blkid ${DEVICE}1 ${DEVICE}2 /dev/vg_main/lv_home

6.2 Clean Unmount All Filesystems

# Sync all pending writes
sudo sync

# Unmount in reverse order (deepest first)
sudo umount /mnt/new_root 
sudo umount /mnt/new_boot

# Deactivate LVM (critical for clean transfer to Pi)
sudo vgchange -an vg_main

# Verify no mounts remain
mount | grep $DEVICE
# Should return nothing

# If unmounting fails, use force unmount
if mount | grep -q $DEVICE; then
    echo "Forcing unmount..."
    sudo umount ${DEVICE}1 2>/dev/null || true
    sudo umount ${DEVICE}2 2>/dev/null || true
    sudo lvchange -an /dev/vg_main/lv_home 2>/dev/null || true
    sudo vgchange -an vg_main
fi

6.3 Safe Device Ejection

# Final sync and eject
sudo sync
sudo eject $DEVICE

# SSD is ready for Raspberry Pi!
# Backup files location: ~/pi_backups/
# Next: Connect SSD to Pi and boot

Step 7: Pi Boot and Verification

7.1 First Boot on Raspberry Pi

# Connect SSD to Raspberry Pi and boot
# SSH to Pi once booted (device names will be different on Pi)

# On Pi: Check system status
df -h
# Should show:
# /dev/sda2 mounted on /
# /dev/sda1 mounted on /boot/firmware  
# /dev/mapper/vg_main-lv_home mounted on /home

# Verify LVM status
sudo pvs
sudo vgs
sudo lvs

7.2 Test basic functionality (Pi)

sudo apt update  # Test package management
systemctl status  # Check service health
touch ~/test_file && rm ~/test_file  # Test home directory write

Step 8: Performance Benchmarking (Pi)

8.1 Install Benchmarking Tools

sudo apt update
sudo apt install -y fio hdparm iotop

8.2 Quick Performance Tests

# Quick read test
sudo hdparm -t /dev/sda

# Comprehensive benchmarks 
fio --name=random-read --ioengine=libaio --rw=randread --bs=4k --size=1G --numjobs=1 --runtime=60 --time_based

fio --name=random-write --ioengine=libaio --rw=randwrite --bs=4k --size=1G --numjobs=1 --runtime=60 --time_based

fio --name=seq-read --ioengine=libaio --rw=read --bs=1M --size=2G --numjobs=1

fio --name=seq-write --ioengine=libaio --rw=write --bs=1M --size=2G --numjobs=1

8.3 Understanding Your Results

📝 Note: The Raspberry Pi USB 3.0 implementation might create a bottleneck here, not your SSD. The Pi's USB controller typically maxes out around 300-350 MiB/s in real-world scenarios so dont expect the full advertised performance for your SSD.

What Good Performance Looks Like:

# Excellent M.2 SSD Results (what to expect):
Random Read:  15-20 MiB/s,  4000-8000 IOPS
Random Write: 40-60 MiB/s,  10000-15000 IOPS  
Sequential Read:  300-400 MiB/s
Sequential Write: 100-200 MiB/s

# MicroSD Card Results (for comparison):
Random Read:  2-5 MiB/s,   100-500 IOPS
Random Write: 1-3 MiB/s,   50-200 IOPS
Sequential Read:  20-25 MiB/s  
Sequential Write: 10-15 MiB/s

Performance Indicators:

Random Read >15 MiB/s: Excellent for database operations, file system responsiveness
Random Write >40 MiB/s: Outstanding for logging, package installs, system updates
Sequential Read >300 MiB/s: Near USB 3.0 limit, excellent for large file operations
Sequential Write >100 MiB/s: Very good for backups, media processing

If Results Are Poor:

Check SSD is connected to USB 3.0 port (blue connector)
Verify Pi power supply is adequate (official 5V 3A+ recommended)
Test different USB 3.0 cables - some limit speed
Ensure SSD enclosure supports USB 3.0 speeds

Step 9: LVM Management and Maintenance

9.1 Create Snapshots for Safety

# Create snapshots before major changes
sudo lvcreate -L 5G -s -n lv_home_snapshot /dev/vg_main/lv_home

# List snapshots
sudo lvs

# Remove snapshots when no longer needed
# sudo lvremove /dev/vg_main/lv_home_snapshot

9.2 Expand Volumes as Needed

# Check available space in volume group
sudo vgs vg_main

# Extend home volume if needed (example: add 50GB)
sudo lvextend -L +50G /dev/vg_main/lv_home
sudo resize2fs /dev/vg_main/lv_home

# Verify expansion
df -h /home

Troubleshooting

Boot Issues

Problem: Pi won't boot from SSD
Solutions:

Check cmdline.txt has correct root UUID
Verify fstab uses correct UUIDs
Boot from microSD and mount SSD to fix configuration

LVM Not Found

Problem: LVM volumes not available at boot
Solutions:

Install lvm2 package: sudo apt install lvm2
Update initramfs: sudo update-initramfs -u
Enable LVM service: sudo systemctl enable lvm2-monitor

Mount Failures

Problem: Partitions won't mount
Solutions:

Check UUIDs: sudo blkid
Verify fstab syntax: sudo mount -a
Check filesystem health: sudo fsck /dev/device

Emergency Recovery

Method 1: Full Recovery from Ubuntu Laptop (Recommended)

Connect SSD to Ubuntu laptop - safer environment for troubleshooting
Mount partitions and diagnose issues with better tools
Fix configuration files using laptop's text editors
Reformat and repartition if needed
Restore from backup files in ~/pi_backups/
Update UUIDs and configuration
Test mount points before returning to Pi

Method 2: Access System from microSD (Pi-based recovery)

Boot Pi from original microSD card
Connect SSD and mount partitions manually
Fix configuration files as needed
Test changes before switching back to SSD boot

Summary

This backup/restore approach offers several advantages:

Clean Implementation: Fresh partitions designed for optimal LVM layout
Reliability: Use tar archives for data backup
Flexibility: Easy to customise partition sizes
Safety: Clear separation between backup and restore phases

The method successfully migrates your Raspberry Pi to M.2 SSD with LVM while maintaining data integrity and providing substantial performance improvements.

You now have a professional-grade Raspberry Pi setup that can grow with your needs, protect your data during OS upgrades, and deliver noticeably faster performance for years to come.

Step 10: Ubuntu Laptop Cleanup (Optional)

Once you've confirmed your Pi is working perfectly with the new LVM setup, you can clean up the Ubuntu laptop used for provisioning.

10.1 Clean Up Backup Files

# After confirming Pi works perfectly for several days
cd ~/pi_backups

# Review backup files one final time
ls -lah

# Archive backups to a safe location (optional but recommended)
tar -czf pi_lvm_project_backups.tar.gz *.tar.gz *.img *.txt
mv pi_lvm_project_backups.tar.gz ~/Documents/  # or your preferred backup location

# Remove working backup files
rm -rf ~/pi_backups

10.2 Remove Temporary Mount Points

# Clean up mount points created during setup
sudo rmdir /mnt/pi_boot /mnt/pi_root /mnt/new_boot /mnt/new_root 2>/dev/null || true

# Verify cleanup
ls /mnt/

10.3 Package Cleanup (Optional)

# If you installed packages specifically for this project, you can remove them
# Only run if you don't use these tools for other projects
sudo apt autoremove rpi-imager parted lvm2

# Update package cache
sudo apt update

Complete SSD Wipe Procedure

⚠️ DANGER ZONE: This completely destroys all data on the SSD. Only use when starting completely fresh or repurposing the drive.

If you need to completely wipe your SSD and start over, follow these steps on your Ubuntu laptop:

Prerequisites for SSD Wipe

# Connect SSD to Ubuntu laptop
# Identify the correct device
lsblk
export DEVICE=/dev/sdX  # SET THIS TO YOUR ACTUAL DEVICE

# CRITICAL: Verify this is the correct device
echo "About to COMPLETELY WIPE: $DEVICE"
sudo fdisk -l $DEVICE
# Confirm this shows your SSD, not your laptop's main drive!

Step 1: Remove LVM Infrastructure

# Deactivate any active LVM volumes
sudo vgchange -an vg_main 2>/dev/null || true

# Remove logical volumes
sudo lvremove vg_main/lv_home 2>/dev/null || true

# Remove volume group
sudo vgremove vg_main 2>/dev/null || true

# Remove physical volume
sudo pvremove ${DEVICE}3 2>/dev/null || true

# Confirm LVM cleanup
sudo pvs; sudo vgs; sudo lvs
# Should show no volumes related to your SSD

Step 2: Delete All Partitions

# Use parted to remove all partitions
sudo parted $DEVICE

# In parted interactive mode:
print                    # Show current partitions
rm 1                     # Remove partition 1
rm 2                     # Remove partition 2  
rm 3                     # Remove partition 3
print                    # Confirm all partitions gone
quit                     # Exit parted

Step 3: Complete Disk Wipe

# Wipe filesystem signatures
sudo wipefs -a $DEVICE

# Completely destroy partition table
sudo sgdisk --zap-all $DEVICE

# Optional: Secure wipe (takes a long time!)
# sudo dd if=/dev/zero of=$DEVICE bs=1M status=progress
# Use only if you need to securely erase sensitive data

# Verify complete wipe
sudo fdisk -l $DEVICE
# Should show no partitions, just raw disk space

Step 4: Fresh Start Verification

# After wipe, the disk should be completely clean
lsblk $DEVICE
# Should show only the main device with no partitions

# The SSD is now ready for fresh partitioning/formatting
# You can start over with Step 1 of this guide if needed

When to Use Complete SSD Wipe

Use this procedure when:

Starting completely over due to configuration errors
Repurposing the SSD for a different project
Selling or giving away the SSD (use secure wipe option)
Testing different partition layouts or filesystems
LVM has become corrupted and needs complete rebuild

Don't use if:

You just want to resize partitions (use LVM resize instead)
Minor configuration fixes needed (use recovery procedures)
You want to keep any data on the drive

References and Acknowledgments

Technical Documentation

LVM2 Commands: Based on standard Linux LVM2 utilities documentation
fio Benchmarking: Performance testing using Flexible I/O Tester (fio) - industry standard storage benchmarking tool
Partition Management: Standard Linux partitioning tools (fdisk, parted, wipefs)
Raspberry Pi Boot Process: Official Raspberry Pi Foundation boot configuration documentation

Performance Data

All benchmark results: Original testing conducted by the author using real hardware
Hardware compatibility: Based on actual testing with M.2 SSD and USB 3.0 adapters
Performance comparisons: MicroSD vs SSD metrics derived from author's empirical testing

Methodology

Backup/restore approach: Original methodology developed by the author
Safety procedures: Industry best practices for disk partitioning and data preservation
Ubuntu laptop workflow: Author's original approach for safer SSD provisioning

Community Resources

Raspberry Pi Community: General knowledge and best practices from the Pi community
Linux System Administration: Standard practices for storage management and filesystem operations

Note: All performance results, specific configurations, and the backup/restore methodology represent original work and testing by the author. No copyrighted tutorials or guides were directly copied or adapted.

DEV Community: eapreko

Redundancy Transformation Plan - Your Redundancy is a Disguised Setup for Your Next Great Chapter

Embracing the Shift: Understanding Your New Beginning

Charting Your Course: Mastering the Job Search & Interview

Elevating Your Impact: Working Smarter, Not Just Harder

Future-Proofing Your Journey: Levelling Up Skills for Tomorrow

Your Unstoppable Comeback

References

Complete Guide: Raspberry Pi LVM Setup with M.2 SSD - Improved Performance Boost

TL;DR

Raspberry Pi LVM Setup Guide - The Smart Way to Manage Storage

Table of Contents

Introduction & Overview

Planning & Comparison

Use Cases & Benefits

Technical Implementation

Step-by-Step Process

Pi Setup & Testing

Management & Maintenance

Troubleshooting & Recovery

Advanced Procedures

References

Introduction: Why Your Pi Deserves Better Storage Management

What is LVM? Explain Like I'm 5

Why Would I Want This?

The Problem with Standard Pi Setup

The Improved Solution

The Convenience vs. Flexibility Trade-off

Raspberry Pi Imager: Convenient but Limiting

Why This Matters for Large SSDs

Pros and Cons Comparison

When to Use Standard Setup

When to Use LVM Setup

Real-World Scenarios

Scenario 1: Home Media Server

Scenario 2: Development Workstation

Scenario 3: Learning Environment

Performance Benefits You'll See

What We'll Accomplish

Technical Implementation Guide

Prerequisites and Safety

Required Hardware & Systems

Before You Begin

Important Notes About This Workflow

Step 1: Initial OS Installation and Backup Creation (Ubuntu Laptop)

1.1 Connect SSD to Ubuntu Laptop

1.2 Write Initial OS Image to SSD

After writing, verify partitions were created

1.3 Mount and Create Backups

Create boot partition backup

1.4 Unmount Partitions Safely

Step 2: Create Optimal Partition Layout (Ubuntu Laptop)

2.1 Design New Partition Scheme

2.2 Create New Partition Table

2.3 Verify New Partition Layout

Step 3: Create Filesystems and LVM Structure (Ubuntu Laptop)

3.1 Format Standard Partitions

3.2 Set Up LVM Infrastructure

3.3 Verify LVM Setup

Step 4: Restore System Data to New Partitions (Ubuntu Laptop)

4.1 Restore Boot Partition

4.2 Restore Root Partition

Step 5: Update System Configuration (Ubuntu Laptop)

5.1 Get Partition UUIDs

5.2 Update Boot Configuration

5.3 Update Filesystem Mount Configuration

Step 6: Final System Preparation (Ubuntu Laptop)

6.1 Verify Configuration Files

6.2 Clean Unmount All Filesystems

6.3 Safe Device Ejection

Step 7: Pi Boot and Verification

7.1 First Boot on Raspberry Pi

7.2 Test basic functionality (Pi)

Step 8: Performance Benchmarking (Pi)

8.1 Install Benchmarking Tools

8.2 Quick Performance Tests

8.3 Understanding Your Results

Step 9: LVM Management and Maintenance

9.1 Create Snapshots for Safety

9.2 Expand Volumes as Needed