I'm working with a headless pi4b and can't remotely connect to it via user pi by SHH when using a cloned SSH of a microSD that performs this fine. Pi boots with slightly different output and I'm getting server not available for various docker-based applications that are accessible fine from the microSD boot (see updates at end, as I initially thought it wasn't booting at all from the SSD)


I've tried cloning a microSD that boots fine and was being used up until this point. I've also tried installing a bootable raspberryPi OS Lite (2021-01-11 release) fresh without luck. My biggest caveat is that I can't see errors in output unless it boots (via ssh) as I don't have a micro HDMI cable. I'm hoping that I've done something obviously wrong that might be easy to assume. SSD formatted to Fat32.

I say it cannot boot because it isn't connecting to the network (via ethernet) when attempting to boot from USB. I don't know at what point it stops. Switching back to microSD works fine again.

Possible reasons

My first thought is compatibility. I'm using an Intenso Portable SSD Premium 128gb. Using a powered hub doesn't change things. I can confirm it's recognised as storage if I connect it when the Pi is booting from a microSD (output when the SSD was cloned from a bootable microSD):

Disk /dev/sda: 119.2 GiB, 128035676160 bytes, 250069680 sectors
Disk model: Portable SSD    
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x7f337ec5

Device     Boot  Start      End  Sectors  Size Id Type
/dev/sda1         8192   532479   524288  256M  c W95 FAT32 (LBA)
/dev/sda2       532480 60637183 60104704 28.7G 83 Linux

Attempts at solving

I followed the steps as shown in tomshardware though I had a more recent raspi-config menu and changed the boot order in the 'advanced' menu. USB was listed there fine. The boot ROM version I updated to appeared to be from January and I confirmed it was updated.

Although I updated the Boot ROM and firmware, I believe that my Pi4b was already set up to boot from USB. It's tough to know as a lot of tutorials were made around the time when this was a beta feature. I followed through just to rule it out.

I'm expecting there to be no obvious solution here so apologies for not having the output I'd normally see on a display. I've a micro HDMI adapter ordered today but need to get this running before it arrives.

I'm not very familiar with the technicalities of formatting drives and what a raspberry pi expects to find when booting. A lot of tutorials seem to reference sda1 which concerns me when I see that my ssd is divided as follows:

Device     Boot  Start      End  Sectors  Size Id Type
/dev/sda1         8192   532479   524288  256M  c W95 FAT32 (LBA)
/dev/sda2       532480 60637183 60104704 28.7G 83 Linux

Intuition (all I've got right now) would suggest sda2 is what's relevant to me here? I didn't specifically format the SSD to have the sda1 and sda2 it shows. It's a clone of a microSD which was formatted by balenaEtcher to make a bootlable disk using the latest release of Raspberry Pi OS. This was what it created on the microSD so I don't want to go messing with it. And if it works on the microSD in that partition configuration, I don't understand why it wouldn't provide the bootloader with what it's looking for when presented the same way on the SSD.



I've managed to get an ethernet connection and a display at the same time and it hasn't been as revealing as I'd hoped.

What's clear now is that the pi is booting and is obtaining a correct ip via dhcp from the router. It leaves me at the login prompt with only a single FAILED warning for Bluetooth Modems that appears irrelevant to the issue (though doesn't fail with the microSD boot, only SSD).

What's not happening is that I cannot connect to the pi via ssh as I can when I boot via microsd. Trying:

ssh pi@192.168.X.X

just leaves the command prompt hanging and waiting until it fails. However, if I try:

ssh 192.168.X.X

it asks for a password. It might be a native assumption but does this suggesst ssh is connecting ok (it also outputs it's starting OpenBSD secure shell server) but there's an issue with the user account? If so, I don't understand why a cloned disk wouldn't just carry over the same user account and permissions.

I had various applications start up automatically via docker before and are set to launch on boot. The display output is showing various starting/listening Docker Socket for the API messages without errors. I'm unsure what the output normally is for them but I cannot reach them via 192.168.X.X:XXXX like I can if I boot from microSD.

Unsure of how how to progress from here?

I'm including a screenshot of output at the end of both microSD boot (1) and ssd boot (2). Apologies for not just using the text here but without knowing which bits are relevant and to isolate, it would just be a sea of too much information.

microSD boot output end: microSD boot output

ssd boot output end: ssd boot output

  • 1
    See my answer here – Joep Jan 16 at 17:23
  • @Joep Thanks. Useful to know as a stopgap measure until I find a solution – biscuitstack Jan 17 at 12:09
  • @Joep Note, adding root=/dev/sda2 caused the pi to not boot either. microSD was inserted and USB connected. – biscuitstack Jan 18 at 14:42
  • That's a pity. I've done this with a Pi3 and a 1TB Seagate drive a few days ago and it worked. I have a Pi4 setup that way also, but is in production and I have no spare Pi4 to test with again. – Joep Jan 19 at 21:17
  • Well, on the positive side: The fact it doesn't work might be useful for diagnosing what's causing the problem. Perhaps it boots fine from the SSD and it's an issue with then running root from it in all scenarios I've tried. – biscuitstack Jan 20 at 10:43

The ssh command has a -v option to display verbose information and you can use up to 3 of them, so try ssh -vvv

If that doesn't reveal anything useful, and you can log into the pi using an attached keyboard, you can try to start a new ssh server on another port. Use sshd -D -ddd -p 2222 -D is to not detach, -ddd is lots of debug info and -p 2222 is to use port 2222. Choose something else above 1024 if 2222 is not available. Go back to your client and try ssh -vvv -p2222 and see if it tells you anything.

Also, try to look in the logfiles in /var/log. And check the output of dmesg on the pi.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.