Moving Swap to SSD?

So, I’m new to running linux on ARM systems, but have been running linux on x86 workstations and servers for ~20 years.

So, it came as some surprise to see the swap filesystem being set up on a ramdisk… But, understanding that microSD cards don’t have the IO performance really needed for a swap partition, it makes sense.

But, I’ve just ordered in (and received) a large (1TB) SSD, and the USB cable needed to hook it up to my Pi 400.

Is there any issue moving to a swap partition on an SSD, and removing the ramdisk swap? My plan is to:

  1. dd the current image from my microSD card to the SSD. (On my laptop.)
  2. Use gparted to (a) extend the root partition, and (b) create a swap partition.
  3. Mount the root parition and add the swap filesystem to the fstab.
  4. Unmount the SSD and move it over to tthe Pi and boot it.
  5. Verify the new swap partition mounted.
  6. Disable the zswap-arm service.
  7. Reboot.

So, thiscomes down to two questions:

  1. As asked earlier: is moving the swap to the SSD a good idea? Or are there likely to be issues?
  2. Does the procedure above look like a good plan?

Thanks for any feedback.


yes you can replace the sd card complete by an ssd/hdd via usb.

search for “raspberry boot usb”
take care that there are some differences between raspi 3 and 4 but the general procedure is the same. you create the installation image at a sd and the usb-disc. install first via sd card. create the " program_usb_boot_mode" parameter after installation at the sd card, reboot and install again from usb. shutdown, disconnect the sd card and reboot full via usb.

Welcome to the world of ARM + SBC! :slight_smile:

If you are old enough, you may recall working on a PC with floppy drives… the good ol’ DOS floppy in drive A. Sure, you can add a hard drive/SSD but the “boot floppy” (SD) will be your savior.

I see you are getting a 1TB SSD. That is a significant size for a RPi4. What you will find is each OS uses its’ own version of the firmware which must be located in a FAT16/32 partition (EFI). So having multiple installs on a device does not work too well.

UEFI firmware is getting close. This will allow for a bit more flexibility but until the firmware becomes baked, various flavors will exist. So…

To make better use of your SSD… think /boot on SD and everything else on partitions. RPi4 recently gained the ability to read GPT partition tables. This way you can boot any OS by swapping the SD and the /boot/cmdline.txt can point to any OS partition on the SSD.

Oh… and about your SSD. If it uses advanced format (4096 byte blocks), you will not be able to boot from it. Only 512 byte block devices are currently supported for booting. This I just learned, have not seen it documented but I never really thought to look for it. Once booted, 4096 byte blocks work fine… but not for the bootloader firmware.

On a side note… OpenSUSE builds a different system. They use the beta UEFI firmware + uboot to load grub2 which then loads the kernel. I was able to add a USB ethernet dongle, the installer did not recognize the onboard ethernet and “install” the OS via an ISO. It failed at the very end due to a grub install issue (could have been due to the 4096 byte block issue) but it is very close to working. I am looking forward to trying Tumbleweed again, once they get the 5.10 kernel working.

I believe the RPI Foundation worked hard to get all of the basic RPi4 hardware into the 5.10 kernel. So 5.10 + UEFI should be a golden ticket, once the kinks are worked out.

[quote=“Olli, post:2, topic:45352”]
take care that there are some differences between raspi 3 and 4 but the general procedure is the same.[/quote]

Okay, since I’m on a Pi 400 I’d be sticking with the RPi4 process.

That sounds like the process for them CM3, 3B, etc. The Pi 400 appears to be much easier:

“To boot the Pi 400 from a USB mass storage device, simply image the USB drive with Raspberry Pi OS 2020-08-20 or newer using the Raspberry Pi Imager utility:…”

The one thing to do after that is change the boot order in the eeprom config to avoid timing out on the SD card.

Or am I way off on this?


The truth about me is scarier… The first system I worked on was an IMSAI 8080 with 64K of RAM, which ran CP/M from an 8" single-sided floppy. (I didn’t build the system, it was in my high school. I just spent most of my time writing BASIC code, and attempting to get a FORTH interpreter to work from magazine code…I didn’t get far with that one.)

This would make sense if I wanted to multi-boot the system… But I’m really going to use this more as a stripped back desktop… Hence the reason I was looking to move the swap partition – free up s much of the 4gig of RAM as possible to run applications.

Thanks for pointing this out – I didn’t know about this either… But looking at fdisk I see:

Disk /dev/sda: 931.52 GiB, 1000207286272 bytes, 1953529856 sectors
Disk model: ASM105x
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes

Which is the same sector size as the SD card, so I think this should work.


I finally ran across a reference to 512 vs. 4096 blocks for booting: Gentoo docs

One other thing to note, the Raspberry pi currently only supports booting from usb mass storage devices (including external hard drives) that 
have a 512 byte logical sector size. You may need to reformat (with the drive manufacturer's utility) them to enable 512 byte emulation.

After we talked about this I read something in the Raspberry Pi docs that I think was a reference to this, but it was quite vaguely worded.