Merry Christmas, really 
Hi @Tithrion!
Well done 
. I am myself about adding the nvme drive to my already upgraded V 5.1 kit. I will set to do it during the Christmas holidays, making good use of the @riban’s OS cloning script.
I have now all the bits in stock (tiny nvme hat, 2242 M.2 SSD, 16 pin cables of various lengths, brass spacers), but I am still wondering how to succeed in disrupting minimally the current assembly, because it is quite hard to get hold of the PCIe port’s plastic lock on the Pi5 - in order to insert the flat cable - without removing the thermal block or the main board from the bottom case, both of which would break the thermal padding.
By the way @jofemodo, should I decide to go this way, could you maybe attach an AliExpress link with a thermal tape of the same kind provided with the official kit? Various options are available on e-commerce, and I am uncertain as for the heat transmittance grade and wether to choose 0.5 mm or 1 mm thickness.
All best regards!
Perhaps with tweezers or curved pliers?
This is a clever idea which I already tried to implement, with a set of tweezer of different shapes. To no avail for the moment, due to the raised metal ridge of the bottom case’s back panel, that definitely reduces movement and vision of the target spot. Small curved pliers for electricians might be a solution: I will have a try!
Thanks for the suggestion 
Hi @riban, I am trying to launch your nvme script copied in /root with the aforementioned syntax, but it returns “command not found”… Am I doing something wrong?
Thanks
EDIT: I made it executable with chmod +x and then run it preceded by ./
It seems to be working nicely, after having created the partitions on the SSD drive. Let’s see!
EDIT 2: Now it seems frozen, apart from mixer view, and not available on webconf or SSH, while copying some synth presets. I will try to hard-restart it.
EDIT 3: Zynth V 5.1 hard-rebooted from last state, fully functional, except I had to re-enable WiFi. Hard to say if now it is running on SD or nvme. I would guess SD because df from CLI returned:
Filesystem 1K-blocks Used Available Use% Mounted on
udev 4081776 0 4081776 0% /dev
tmpfs 824576 13680 810896 2% /run
/dev/mmcblk0p2 60843416 21499888 37443396 37% /
tmpfs 4122816 130256 3992560 4% /dev/shm
tmpfs 5120 48 5072 1% /run/lock
tmpfs 102400 48 102352 1% /tmp
tmpfs 51200 32 51168 1% /var/log
tmpfs 204800 0 204800 0% /var/tmp
/dev/mmcblk0p1 522230 66386 455844 13% /boot/firmware
I may be wrong, but I do not seem to see any mounted SSD drives.
What might I try next?..
Best regards
1 Like
Update: Zynth 5.1 behaves not exactly as ever.
Terminal is slow and hardly responsive, WiFi connection tends to fail often (needs to be reconnected and does it sluggishly) and LAN connection to webconf is difficult and unstable.
I wonder if the nvme hat placement (in front of the PCIe port but tilted 90 degrees, in order to adhere to the vertical ridge of the bottom enclosure) is interfering with network operation or something else.
Anyway, from webconf dashboard it clearly appears that Oram is starting from SD:
I tried to launch again zynthian_sd2nvme.sh from /root, but it is not recognised as a legit command, neither it responds anymore to chmod +x.
My (attempted) SSD setup is as follows:
S2Pi Tiny nvme Hat
256 Gb Orico gen 3 M.2 2242 nvme.
Best regards!
Try to remove the SD, at least then you can be sure that you’re running from NVME.
If a df -h doesn’t show any NVME partitions mounted, than you’re running from sd.
If you are running from sd anyway, then run an lsblk and possibly an lspci to see if the NVME is recognised at all.
I simply ran the script (with chmod +x and ./), made a shutdown, removed the sd and started up again. Used nvme hat is also the S2Pi /GeekPi N10 Tiny NVME hat, but with a Crucial P310.
Hi @Tithrion, thanks. Anyway, I was well aware of the ideal procedure to ascertain wether the SSD unit was alive or not (removing SD card, which therefore is skipped at startup by the boot order set in Raspi Config). I simply wanted to avoid to reopen the enclosure, after a few afternoon hours dedicated to my nvme mod, and it turned out that the webconf dashboard was already showing what I already suspected. 
Thanks for the suggestions, about more CLI commands to see if the nvme drive is detected at all by the system. Still, now the sh script is no longer recognized by chmod as a valid batch command, even a fresh one copied again in /root.
I am fairly sure that the script did not complete the OS copy procedure to nvme, because it remained stuck upon writing to disc, and it never showed the completion message which I have seen at its end in a text editor.
I changed the position of the SSD hat this morning, placing it on the bottom case as showed by @jofemodo, but it does not seem to make any difference to the overall operations of the Z, whose OS activity and computational power appear unaffected. Nevertheless, network connection is discontinuous and unreliable - and it is certainly not router signal related because my other custom Oram Pi5 2409.4 does not show the same symptoms - but I will report it on another thread.
Best regards
As I understand the script, it doesn’t write to the sd. What you’re describing sounds awkward and more like a hardware problem, not necessarily a defect, but maybe a misconfiguration.
While you added the nvme hat, could it be you unintentionally kind of manipulated one or more flat cables working before?
Are you sure the flat cable connection to the nvme hat is correct and stable?
My tiny hat came with a flat cable (actually 2 of them) which was clearly labelled with “to Pi” and “to Hat”.
I also positioned the hat “in extension to the main board”, fixed to the bottom case but that shouldn’t make any difference as long as the flat cable is correctly connected.
1 Like
@Aethermind it looks like you are still booting from SD and that the physical installation of the NVMe has caused problems with the normal operation of zynthian.
You said that you suspect the installation did not complete - this could be your issue. If all the files were not copied to the NVMe then it may fail to boot. Or maybe, whatever caused the failure to copy files is also causing the inability to boot.
If you left the SD inserted and left the boot order as SD first then it will, of course always boot into the SD. You should either remove the SD or change the boot order. I recommend during testing that the SD card is removed and the boot order left as SD first. This allows insertion of a SD to recover a broken NVMe or to test/use another OS/version. It does slow boot by a few seconds so, if you are content that the NVMe is working and want to boot faster then you can change the boot order to make NVMe first.
This is correct. The script prepares the NVMe then copies files from the SD to NVMe.
@Aethermind what NVMe drive are you using? Some are known to cause problems.
Hi @Tithrion,
Thank you for the feedback .
Of course, @riban’s script is meant to write exclusively on nvme, and I was rather certain that Zynth was booting from SD as usual, if only for the occupancy of the available mass storage size, as showed on webconf. Furthermore, the operating system etching on the SSD unit was obviously uncompleted, and I neither attempted to extract the SD and boot from nvme.
As for the 16 pin flat cable, for the PCI Express connection of the SSD drive, I bought a set of different lengths from GeekPi, and used the 80 mm size, respecting the indications “to Hat” and “to Rpi5” printed on the ribbon’s ends.
Kind regards
Hi @riban,
Thanks for chiming in!
I am starting indeed to suspect that the issue could reside in the nvme unit that I’ve got.
I usually only buy Crucial SSDs, but there was an attractive offer on Orico’s nvme drives (PCI 3.0 M.2 2242 256 GB), and, despite the brand was relatively new to this market sector (but well known and respected for computer accessories in general), their SSDs had good reviews and I took the jump.
I am tempted to try and disconnect the nvme hat altogether, and see if network operation resumes as usual, but I hesitate because handling the tiny PCIe plastic connector and the ribbon cable on the S2Pi hat is honestly a hellish task (I had to use a magnifier lens and adhesive tape, and only succeeded after many attempts). Otherwise, I could just disconnect the Orico drive and check if this solves the connection problem. Or, I could resign to buy a costlier Crucial, or the like, and keep the Orico for an external USB 3 memory caddy.
I would be glad to test again your script, but it appears to refuse to run altogether, even with chmod… Anyway, I would ensure that the boot order is set with SD as the primary drive, in order to be able to slide in a recovery Oram upon a faulty nvme startup.
Any further bits of advice?
Before you buy another SSD: maybe try another flat cable.
This could be defective also.
You wrote you choose the 80mm one.
I’m not sure if or how much the timings are affected by the lengths of the calble but I used the “onboard” flat cable which is 40mm.
And timing problems on the PCIe bus could affect different parts of the Pi, i.e. the network interface…
At least worth a try before you spend extra money…
Indeed. I was hesitant to use the longest one (40 mm standard and 60 mm were also in the package), fearing potential timing issues, but it was way easier to manipulate. But, trying another flat cable is a sensitive suggestion. What leaves me perplexed is that at my first attempt with chmod +x the sh script recognised the nvme and proceeded with expected mounting of partitions and following writing process…
I would rule it out honestly, since the only connectors involved in the separation of the two Zynthian case’s halves are the control panel ribbon, the video ribbon and the USB-C connector of my manual upgrade to V 5.1. Each of this system areas worked as expected upon re-powering the Z after the nvme mod.
Regards
Long story short: it happened that my downloaded nvme script was corrupted (rare occurrence but still possible). It popped into my mind to download it again and it definitely showed a slightly different size (the correct one is 170 Kb). In a few words, it worked as expected with chmod +x followed by ./ to execute!
The OS copying routine to nvme was successful, and upon completion it signalled to extract the SD card, power off and then reboot. Unfortunately to no avail, because, once skipped the unavailable SD drive, Zynthian remained blank and inactive (with constant green led on the SBC when switched on) without loading the OS from nvme. I placed back the SD with Oram to start the Zynth regularly, and checked from terminal that the boot sequence was correctly set to SD > nvme, as it indeed was the case.
On the plus side, the network slowness and tendency to disconnection has disappeared completely, arguably due to a deep hardwarre reset undergone by my Internet router.
I don’t know why the internal Raspi5 struggles to read Oram from the Orico 256 Gb M.2, since it was perfectly able to write/read on/from it during the copying process. I wonder if Bookworm64 detects some kind of synchrony issue at startup due to the 80 mm flat ribbon PCI cable, which otherwise worked well and as expected during the data transfer of the sh script.
lsbls returns:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk0 179:0 0 59.5G 0 disk
├─mmcblk0p1 179:1 0 512M 0 part /boot/firmware
└─mmcblk0p2 179:2 0 59G 0 part /
(clearly, no active nvme partitions detected).
lspci returns:
00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 21)
01:00.0 Ethernet controller: Raspberry Pi Ltd RP1 PCIe 2.0 South Bridge
All best regards
1 Like
Do you have an up to date firmware? I has to do a firmware update on my RPi5.
Alright @riban , just sudo apt update (as I have done successfully, to no effect for the OS loading from nvme) or sudo apt upgrade as well…? (or even sudo apt full-upgrade possibly?).
I have read here in the forum that doing so directly might break some of the Zynthian OS specific settings…
EDIT: should I rather launch $ sudo rpi-update or sudo raspi-config > Advanced > Bootloader Version?
Thanks
The script attempts to use the latest boot rom already with the command, raspi-config nonint do_boot_rom E1. I don’t know whether this downloads the ROM or just uses what is already available locally from previous update. If it downloads then there would need to be internet connection when the script is run. If you suspect there wasn’t, you could ruin that command again with internet connection.
To ensure the config tool is at the latest version, run, raspi-config nonint do_update. I should add that to the script.
1 Like
Thank you @riban,
I look forward to trying this, after work and at the desk with the Zynth
There is a bug in raspi-config (which I will report upstream). In non-interactive mode it expects an extra (undocumented) parameter of ‘0’, so the command would be raspi-config nonint do_boot_rom E1 0. IMO this is a bug in the raspi-config script rather than an undocumented parameter because the parameter does nothing but is checked to be ‘0’. I have reported upstream as issue 264.
Also, raspi-config nonint do_update opens the config tool which is rather more interactive than it should be… I have reported upstream as issue 265.