Have you tried to configure the custom boot options from the advanced hardware options in the webconf? Perhaps it works …
If not, I will solve ASAP
Regards
I put in a suggestion on the bug report that when the command.txt is written you should check which device is mounted to /
Have not tried it yet.
I found that if you burn image onto the nvme directly and change the cmdline.txt on a boot partition (1st partition) so the root points to nvme (2nd partition) Zynth boots, but with all sorts of problems. I can provide the UI Log (there are lot of errors and missing stuff). Even changing Audio device to Dummy does not work and every reboot changes the ROOT to default (SD card partition).
But if you burn the ZynthOS to the sd card, start from there, configure it (at least the Audio device) and than copy the SD card into the NVME with DD and change the cmdline.txt same as before everything works. cmdline.txt is not changed after. I have noticed some first_boot_shell script (that might by problematic???).
Still I have noticed some strange behaviour in the channel control, i.e. the screen with controls, I can select almost everything there (move the knobs, select mixer, learn etc.), but I cannot select anything from the middle portion of the screen (marked with red) that contains controls, pedals, settings etc. I am usig LCD with touch, have not tried it with the mouse or via VNC yet.
Are you fully up to date? This bug that was fixed in the past week.
Well I’ve thought so.
I’ve downloaded the 22.5 release and there is not “refresh” icon on the GUI.
Yep, there is an update pending.
Hmmm… This is exactly the bug or unexpected behaviour which @Baggypants had reported.
Being this the current state of things, I surmise that it would not make much difference to clone Oram with the dd command, after the first successful startup, because Oram would meddle anyway with the cmdline thereafter.
I wonder if @jofemodo might find a way to instruct the Zynthian OS not to reject the nvme storage, always pointing to SD as more or less mandatory priority path.
Unless, there is something in the Pi5 instruction set or input/output implementation which misinterprets specific lines of the Zynthian code.
I guess that, had that been straightforward, the Zynth developers would have already provided a testing Oram version compiled for Rpi5…
Repeat … have you tried this?
Regards,
@jofemodo does this mean we would paste the (edited to point to 2nd NVMe drive) text from cmdline.txt in /boot/firmware into the custom boot options box? Just checking…
Thanks,
Harry
Just try. You wont break nothing.
I put: root=/dev/nvme0n1p2 rootfstype=ext4 fsck.repair=yes rootwait console=tty3 logo.nologo quiet splash vt.global_cursor_default=0 modules-load=dwc2,libcomposite
into custom boot options and the Zynthian started up ok but when I look at “dmesg | mounted” I only see the 2nd uSD partition but when I “df -h | grep firmware” it returns /dev/nvme0n1p1
???
Also I now realize it’s possible to boot from one device and set another as root and, just to be clear, my hope was to be able to boot from and have root on the NVMe drive.
Harry
Probably this would be enough.
Would not that require to have both SD card nad NVME disk at the same time?
Or am I missing something here? GUI is on the partiotion 2 so when I change the custom boot option it changes the cmdline.txt file on SD card’s partition 1 to point to NVME partition 2, but it wont boot without sd card.
I’m not sure this will work because the sdcard one will still be written to the file. You’ll end up with two root= stanzas.
If anyone wants to test you can use a usb drive instead.
My tip for today is to double check what you buy. Even though they have the same form factor and fit into the keyed slot, SATA drive is not the same as NVMe. 
I bought the right drive from my local second hand computer shop and now have Zynthian booting from NVMe. Here is what I did and what still needs to be done in Zynthian software:
- Build a RPi5 *GB + active heatsink + Pimoroni NVMe Base + PC Specialist G930E 256GB M.2 NVMe
- Add power - I got 4 long and 4 short green LED pulses indicating “Unsupported board type”. It needed a bootloader update…
- Used Raspberry Pi Imager to flash USB+NVMe bootloader to a spare uSD card
- Inserted the uSD with bootloader in RPi5 and powered - after a few seconds the green LED flashes continuously to indicate success
- You could write the Zynthian OS directly to the NVMe - I didn’t have this facility so uses ZynthianOS do do so thus:
- Used
ddor Raspberry Pi Imager to flash 2024-05-22-zynthianos-bookworm-aarch64-oram-2405 to 32GB uSD - Booted RPi5 with ZynthianOS uSD
- Waited for reboot - note, Zynthian will be in a restart loop due to no audio - don’t worry yet…
- Connected network cable to RPi5
- ssh to Rpi5 using
ssh root@zynthian - Run
raspi-configand select 6. Advanced Options, A4 Boot Order, B2 NVMe/USB Boot wget https://os.zynthian.org/test/2024-05-22-zynthianos-bookworm-aarch64-oram-2405.zipunzip 2024-05-22-zynthianos-bookworm-aarch64-oram-2405.zipdd if=2024-05-22-zynthianos-bookworm-aarch64-oram-2405.img of=/dev/nvme0n1mount /dev/nvme0n1p1 /medianano /media/cmdline.txt- change root parameter toroot=/dev/nvme0n1p2then ctrl+x to exit (I prefer vim but most users won’t.)reboot- should now boot to ZynthianOS from NVMe- Connect web browser to http:\zynthian and set audio to Dummies. (I didn’t do this earlier because it would have set it on the uSD and would need doing again.
- Reboot
These steps have been written mostly from memory and with some modification from what I actually did, which is not good in an old codger like me so there maybe errors. Please report back so that we can update this guide.
[Edit] Removed info about issue editing root partition mount point - fixed.
[Edit] Fixed path to NVMe drive.
7 Likes
@riban I’ve seen this mentioned here before. Is it better to write to an Sd then transfer to NVME via dd?
I did wrote zynthian image straight to my NVME drive using a usb to NMVE adpater. I was able to boot but ran into all kinds of trouble which I was able to find answers for throughout the forum. Main issue is edit the cmdline.text file for the correct NVME partition names which sometimes works and sometimes it switches back.
I’ve read someone in here mentioning that writing straight to NVME caused a lot of issues but I found that’s a weird behavior.
I did not have a mechanism for writing directly to the NVMe, except for booting the RPi in an OS, hence I used Zynthian as that OS. You should be able to write the image to the NVMe any way you want / can and it should work. I outlined my approach but yes, that part of the guide could be updated to exlain that you just need to get the image on there.
I have now removed the uSD but need to remember to manually update /boot/firmware/cmdline.txt after each time I update via webconf. I am looking at this webconf issue now…
1 Like
Great! Thank you.
I have fixed the issue with updates and config changes, e.g. via webconf changing the root mount point. It will now reuse what is set in /boot/firmware/cmdline.txt so we should have a reliable NVMe boot environment. It may be nice to simplify / automate some of the steps.
5 Likes