I thought you were talking about the card and not the SSD…
As for this, yep, I do also use a 2SPi TinyHat for Raspi 5.
BTW, @Lanfranco, what 3D modeller do you use?
I’m interested in taking the plunge with 3D printing, bur so far I haven’t found an open source or freeware app that relates closely to my preferred workflow.
I am a former architect with a fair share of 3D modelling expertise, therefore my reference GUI is the industry standard AutoCAD. For how ingenious and flexible it is, I keep on finding FreeCad rather convoluted and inconvenient, maybe because I am not as used as engineers to parametric modelling.
I have been using Fusion 360 for a year. I started from scratch and I am trying to improve little by little. Fusion 360 is free for personal use… and that does it credit. If you don’t know how to do something, you type it in a search engine and you will surely find an official answer from Autodesk. For me the best thing is the policy of free for personal use…
A question for the Technicians… Isn’t it worth putting the boot order: NVMe > SD > USB? If something doesn’t work on the NVMe, inserting the SD would boot from that… I say this because the very fast boot of Zynthian has slowed down because it rightly looks for the SD first. Thanks
I would set it like that, but am still waiting for my hardware )
With @riban’s script it’s really easy… I did it… and that means it’s really easy… thanks Riban
1 Like
I said before that you can chose whatever boot order you want. The reason I set SD first is to allow me to insert an SD to test other versions of zynthian or carry a SD as a safety OS that can be used if the NMVe becomes corrupt (but still bootable). We can each chose the boot order that best suits our own workflows.
I understood this… I was wondering if by setting the NVMe as the first boot, in case it gets corrupted, Zynthian would boot immediately after from SD if present? Right?
If NVMe can’t boot then yes, it will try the next. Also there is an option to loop so will continue to try each in turn until one becomes available. My concern is NVMe booting but being corrupt of just wrong - then it will never boot from SD. But my main reason was to allow testing of other OS versions without changing boot order.
1 Like
Very clear thanks…at 63 years old I can even wait 5 seconds more during startup…
Forgive my ignorance, i’m assuming that you could the set a new boot order in the Bios, but maybe things are different with RPI’s? I have very little experience with them…
i’ve tried to google this, but only found that you could set boot order from terminal, which i then thought actually would meen that u have to boot to something before you could change boot order And then if the NVME SSD was sort of accepted as the boot medium, but malfunctioning as such, you would have to disconnect it in order to make the RPI skip it and move on to next boot option?
@riban i understand your reason for having SD first - especially for you, i’m imagining that you actually run a lot of different versions of Zynthian OS on a daily basis, I some times fear that i have questions that i should answer myself rather than put them here
From Raspberry Pi documentation:
This configuration tool allows to select from 3 boot order options. If you edit the config file then you can set the order in more detail. So that I can included this in the script, I chose B1 from one of the 3 options. Others may prefer optipn B2. Indeed - that is likely to be the option I end up configuring this machine with to give me faster boot times (which is an advantage of NVMe) but for now, B1 suits my needs.
The whole point of the B1 boot order recommended by @riban, which is also my preferred one for the time being, is to sacrifice a bit of startup speed in order to be able to recover at any time, with a safe operating system written on SD, a possible failure of the main OS written on NVMe.
Since in a Raspberry platform SSDs are not removable media like uSDs or USBs, in case of a misconfigured or corrupted operating system written on NVMe (which can happen, if you are experimenting with new features, testing releases or a custom build) the user may end up with an error loop at bootstrap, without being able to reach the system through SSH.
In this unpleasant predicament, there would be no other options than opening the box, disconnecting physically the NVMe drive, extracting it, booting from SD with a working OS, setting SD as primary drive, mounting again SSD in place and re-starting installation and configuration from scratch.
So, having an SD card as primary boot drive is a way to be allowed to do some system debugging if something goes wrong on SSD, without being forced to erase everything and start again from blank slate.
But, of course, everybody makes a choice according to his tastes and plans!
All best regards 
1 Like
I saw that the SSD heats up a lot and since my Zynthian is inside an ABS and PETG case, I thought of equipping the NVMe support with a very silent Noctua fan…
2 Likes
Lovely gadget!
1 Like
It’s so hard for me to accept that one should not be able to change boot order BEFORE boot. But if it is so, i will surely be following your thoughts and also set mine to boot from SD first.
Thx for setting me straight and all that 
2 Likes
Always a pleasure
Have a really nice Saturday! 
@riban, @jofemodo, @Tithrion, @core.east and all those possibly concerned,
I can announce officially - among blaring noises of trumpets and horns - that the blame for not achieving the NVMe copying process had to be put on the shoulders of a faulty TinyHat SSD base, as it was indeed suggested, and that I succeeded in using the @riban’s script effortlessly, integrated by my simple procedural provisions.
lspci and lsblk returned straight away the correct device listings, immediately after connecting the new hat with the SSD drive on top, therefore I knew that the script was likely going to work effectively.
After installation, and the expected cinematic sequence of lightning-fast screens of files transfer, lsblk showed correctly two active NVMe partitions:
root@zynthian://zynthian# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 476.9G 0 disk
├─nvme0n1p1 259:1 0 511M 0 part /boot/firmware
└─nvme0n1p2 259:2 0 476.4G 0 part /
I understood right away that it was a clean green light for Oram on SSD, and indeed it worked like a charm on first boot after extracting the uSD card.
What remains to be ascertained, in real usage, is how much the NVMe unit warms up during the Zynth activities, without a direct thermal bridge to the bottom case.
For the moment, I have adopted the @Tithrion’s layout with the SSD facing upwards, and can feel a detectable heating under it on the underside of the metal enclosure, which I think is a good sign. A maxed-out snapshot with 16 chains/Midi channels playing an arrangement gives an Rpi5 duty temperature (without overclocking) of about 40° idle and 42-44° while on processing, which seems like an egregious result.
[BTW and off-topic, a large snapshot without overclocking works smoothly without a single x-run on Oram Stable (no DSP563XX emus in that snapshot however). Another one with only OsTIrus and Osirus in multichannel mode causes some very occasional and minor glitches at factory clock, no problems at medium overclock].
So, all in all, it looks like getting Zynthian to work with SSD has become relatively straightforward, and the procedure with @riban’s script is sound, easy and reliable.
All best regards to every Zynthianist!
(not my nickname, but I like it!) 
5 Likes