A very exciting start to my week… my new (first ever in my case) portable Solid State Drive just arrived for my Raspberry Pi 4 –
According to Royal Mail the unit came from Online Retailer SWTL – but to the rest of us, from BANGGOOD.
I was expecting some unassuming package – instead a spiffy trademark-style Blitzwolf box and inside… a beautiful drive complete with USBC to USB3 adaptor – and a normal USBC lead as well.
And here it is…
If you are wondering since when did the Raspberry Pi 4 get USB boot capability – check out this blog entry – this SSD works with all variations of RPi4 from 2GB to 8GB. And no, it is probably not worth the cost or bother on the Raspberry Pi 3 (USB 2 only hence a lot slower) unless you are really looking for any performance boost you can get.
I have NO idea why the adaptor is USB3 FEMALE so that’s out – I guess I’m using the lead on my 2GB Raspberry Pi 4.. and here is a screen-copy of my first clean CLONE using RPI-CLONE, already tested on USB sticks and SD-in-a-USB-adaptor arrangements in preparation for my SSD arriving. Read elsewhere and you’ll see the challenges I had getting USB boot on the Pi4, resolved JUST in time for this Blitzwolf 256GB SSD drive to arrive.
Starting the clone:
sudo rpi-clone -f -U sda
Personally I have that down to a bash function – one word “cclone” with a normal clone having only one “c”.
That CLEAN clone (including partitioning) took a STUNNINGLY short 8 minutes. Until now it has ALWAYS taken a long time for a clean clone – like half an hour normally with an SD in a USB3 adaptor – but not with this new SSD.
Did it work? Wheeeeeee. That’s the fastest start of a Raspberry Pi EVER. Just a few seconds and it’s UP. I’m excited. Remember when I say clean clone I mean including partitioning the destination. This is NOT a fresh RPI source installation, it’s the one we’ve been experimenting with using HASS, Node-Red and the Zigbee2MQTT dongle – and it all just WORKS on the new SSD.
The next challenge… given an SSD in SDA running the show and an SD-in-USB sitting there as a potential clone in the OTHER USB3 socket, how do I ensure the Pi boots off the right one.
Meanwhile – a test – a normal clone from my spiffy new SSD to an SD (can’t leave the latter in the socket). No surprises there as the SD is the limiting factor – but it works. Beware this is not one of your £25 cheapo SSD drives – £55 so depending on your budget and requirements, it might do well or be overkill.
For my main home control I need a good brand name but I have several RPIs of less importance so I’ll keep checking now I know SSD will work on the Pi4.
As for the speed of the actial USB3 connection – it seems I have the faster UAS connection – see this for UAS versus BOT – if anyone has any new information on this – comments below please. In the photo below you are looking at firstly the USB2 adaptor powering the SSD in my RPI4 here in Spain – the second entry is the 4-port hub in the Pi itself.
Comments more than welcome!
Dear Pete. Maybe the female adapter goes on the cable so it works C to C ?
Eric
Hi Eric – maybe – well, in my case, the USB C connector on the RPI4 is for power, not general USB – so – another spare lead.
Hello Pete
changeing boot order to 0x14 does NOT work, whether you put
sd card in the raspi holder or in the usb, in the end it boots
from the sd card. There is a message hub1 a pause then boots from SD.
It could be timeing, but as its a work in progress I will leave
it to the boys in the higher paygrade.
The blank sd worked in both cases.
regards Brian
Hello Pete
you could just put a blank sd in the 2nd usb then at boot the default
would be sd(nothing there!!) usbssd. Works I just tried it.
pi@raspberrypi:~ $ sudo rpi-clone sda -f -U
Booted disk: sdb 120.0GB Destination disk: sda 32.0GB
—————————————————————————
Part Size FS Label Part Size FS Label
1 /boot 256.0M fat32 — 1 256.0M fat32 —
2 root 111.5G ext4 — 2 29.6G ext4 —
—————————————————————————
== Initialize: IMAGE partition table – forced by option ==
1 /boot (51.0M used) : MKFS SYNC to sda1
2 root (3.5G used) : RESIZE MKFS SYNC to sda2
—————————————————————————
Run setup script : no.
Verbose mode : no.
———————–:
** WARNING ** : All destination disk sda data will be overwritten!
———————–:
Initializing
Imaging past partition 1 start.
=> dd if=/dev/sdb of=/dev/sda bs=1M count=8 …
Resizing destination disk last partition …
Resize success.
Changing destination Disk ID …
=> mkfs -t vfat -F 32 /dev/sda1 …
=> mkfs -t ext4 /dev/sda2 …
Syncing file systems (can take a long time)
Syncing mounted partitions:
Mounting /dev/sda2 on /mnt/clone
=> rsync // /mnt/clone with-root-excludes …
Mounting /dev/sda1 on /mnt/clone/boot
=> rsync /boot/ /mnt/clone/boot …
Editing /mnt/clone/boot/cmdline.txt PARTUUID to use eb0bcb76
Editing /mnt/clone/etc/fstab PARTUUID to use eb0bcb76
===============================
Done with clone to /dev/sda
Start – 17:08:51 End – 17:21:00 Elapsed Time – 12:09
unmounting /mnt/clone/boot
unmounting /mnt/clone
===============================
You could boot on ssd insert sdin usb when the system is booted
all ensure boot by ssdusb
regards brian
Hello Pete
my old ssd drive was 120Gb works well using rpiclone the time taken only 5min 19secs to clone.
You could try changing the boot order.
Here a snip from
BOOT_ORDER
The BOOT_ORDER setting allows flexible configuration for the priority of different bootmodes. It is represented as 32bit unsigned integer where each nibble represents a bootmode. The bootmodes are attempted in lowest significant nibble to highest significant nibble order.
E.g. 0x41 means try SD first followed by usb boot then stop. Whereas 0x4 would mean try usb boot and then stop without trying to boot from the SD card.
The retry counters are reset when switching to the next boot mode.
BOOT_ORDER fields
The BOOT_ORDER property defines the sequence for the different boot modes. It is read right to left and up to 8 digits may be defined.
0x0 – NONE (stop with error pattern)
0x1 – SD CARD
0x2 – NETWORK
0x3 – USB device boot usbboot – Compute Module only.
0x4 – USB mass storage boot
0xf – RESTART (loop) – start again with the first boot order field.
Default: 0x1
Version: pieeprom-2020-04-16.bin
pieeprom-2020-05-15.bin – BETA
Boot mode 0x0 will retry the SD boot if the SD card detect pin indicates that the card has been inserted or replaced.
The default boot mode is now 0xf41 which means continuously try SD then USB mass storage.
You could change this to 0x14 then would try cycling msd(usb) pause then SD pause usb etc upto max set tries.
lots more information to change the settings in EEPROM here
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md
regards Brian
Hi Brian – did you ever get to clarifying the issue of booting from a specific USB? Does anyone else have clarification on this? I’m generally running my RPI4 devices on SSD now with an SD-in-a-USB-adaptor for making clone backups and I find myself removing the clones once done, for fear of accidentally booting from the wrong device. Clearly that is not a good thing. Until the new USB boot came online, it was always clear that the PI would start in SD… today I’d like to me sure that boot would always prioritize the TOP USB3 connection – is that possible? While I’m here, I note my USB3 adaptor is UASP – apparently much faster than BOT. For those who don’t know the difference between UASP and BOT – join the club – I only became aware of the differnce this morning – see the END of this blog entry for details.