I can’t seem to boot from my NVMe even though I’ve set it to be the first in the boot order. Has anyone been able to boot from NVMe?
Thanks,
Harry
Hi @harrylnorris !
This is exactly the same installation plan as mine.
I am just about to try and achieve the same result, replicating the boot order setting procedure used for starting the system with Bookworm from NVMe.
I will let you know how it goes over here 
Check the changes haven’t been reverted in config.txt as the webconf used to like to blat it.
2 Likes
Hi @harrylnorris and @Baggypants ,
I am stuck too to not being able to boot Zynthian on Pi5 from nvme. I thought it might have been wiser to start with the latest stable (2401) and to see if Zynthian loads from nvme, upgrading to Oram at a second stage, once the video (general 1920x1080 HDMI) and audio department (Presouns Studio 26c) has been configured in webconf.
I etched the OS with Balena on the Pi, set the nvme boot order priority in raspi-config and tried to boot ZynthianOS from the SSD drive. To no avail: the Pi5 attempts to start Zynthian and swiftly reverts to a Raspberry OS screen, stating that an OS should be installed on the nvme in order to start the system (and rightly so). Afterwards, it automatically searches for Raspberry OS on USB or SD, where it finally boots Raspberry OS from. After rebooting, the nvme-usb-sd boot order sequence has to be reset in raspi-config.
Any hints from @Baggypants, @jofemodo, @le51 or @riban ?
Should I try instead to flash Oram directly on nvme? And if so, how do I access the current testing Oram image without upgrading my other running Zynthians, with projects in the workings which for the moment I would avoid to imperil with system updates?
Can I download Oram on a working Zynthian switching repos to testing, without inherently updating the system?
Thanks for any advice/solution/roads to walk offered!
EDIT: I have been able to spot these passing lines during the brief nvme boot attempt with ZynthianOS:
nvme: off
timeout: xxxxxxxx …
nvme: error …
failed to open device: ‘nvme’
It seems that nvme is not activated at startup, but it worked previously as a primary boot device with Raspberry OS installed.
hi @Aethermind
so far I understand, you’ve got Zynthian Os already flashed to NVMe drive but it won’t boot on it and then switch to RaspiOs (on SD Card I presume).
This looks like the bug described by @Baggypants : wrong settings in cmdline.txt
once your in RaspiOs, use command
lsblk
to identify all the attached drives and partitions.
(should be something like /dev/nvmeblk0p1 and /dev/nvmeblk0p2 for the nvme drive)
mount the first nvme partition (if you’re under a RaspiOs graphical interface, just double click on the drive) and edit file /boot/cmdline.txt so that root= point to the second nvme partition.
Also, I’ve read elswhere (here : https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#nvme-ssd-boot) that an update of raspi firmware is needed. I don’t know if this applies for RBPi5
1 Like
Thanks @le51! This is exactly my current scenario.
I will implement your suggested steps, after performing a further EEPROM update, which I had already evoked.
Will let you know if your path works!
I can’t even understand what you’re asking 
He refers to running the Zynthian operating system from an internal SSD unit (NVMe), through an appropriate kit which comprises a sister board mounted on top or aside the Pi-5 single board computer.
1 Like
Hi @le51
I am getting back to you with some updates, on starting ZynthianOS from NVMe on RPi5.
I updated the Eeprom several times, and checked the cmdline.txt file, substituting the default boot unit pointed at by root= with nvmen0p2 (second boot partition of the NVMe drive hosting ZynthianOS).
I was then able to shoot a video of the bootstrap sequence, discovering that there was a briefly flashing screen (attached), reporting that the detected OS (ZynthianOS) did not declare support for RPi5, followed by another startup screen reporting nvme switched off, and boot order reverted to USB and then SD, according to the load sequence set in raspi-config.
I therefore enabled the flag os_check=0 in config.txt, as per suggestion on the Rpi start screen, only to fall in an endless cycle of attempted ZynthianOS loading, with no HDMI monitor output whatsoever.
I tried to reach the Rpi5 trough LAN on an external Windows laptop, to see if Zynthian had been loaded at least partially and was visible on Zynthian.local, or on an IP address, or via WinSCP, but no similar server loaded on the Raspi appeared to be available on the local net.
Eventually, I found a way to exit the faulty ZynthianOS NVMe boot sequence, using the shift key at startup and loading a recovery Raspberry OS through an ethernet connection.
So, after being able to start again Raspberry OS I am basically back to point zero.
Any suggestions @le51 and @jofemodo?
My next experiment will be to download the Oram image from the Zynthian software online repository, and see if I manage to start it from NVMe on RPi5, with the same procedure attempted for ZynthianOS.
Could it be @jofemodo (just guessing) that a specific flag/switch must be enabled in the Zynthianos/Oram cmdline.txt or config.txt, in order to make it possible to boot from NVMe as it is already possible for Raspberry OS?
I also modified the cmdline.txt files and was not able to boot. I gave up at that point…
Harry
1 Like
Your going to ignore that missing device tree file error in the screenshot?
please note, I do not own a RBPi5 
But message is quiet clear, system can’t find RBPI5 firmware blob. It seems Bookworm has moved all this stuff in /boot/firmware
Perhaps edit /boot/firmware/cmdline.txt instead of /boot/cmdline.txt
Thank you @le51, I will try to edit instead boot/firmware/cmdline.txt, and see what happens, and report to the Discourse 
Also be sure you’ve done that:
raspi-config
Under Advanced Options > Bootloader Version, choose Latest. Then, exit raspi-config with Finish
There’s a confusing validation screen before you exit, choose “no”
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#nvme-ssd-boot
1 Like
Hi @Baggypants!
It appears that it is not possible to ignore the warning about the OS check not seeing the 0 flag (apparently stating that the OS itself is alright).
The only way to skip that bottleneck was to flag in command.txt the OS check as zero, apparently/probably stating that the operating system about to be loaded was compatible with RPI 5.
I did so and the Raspi5 fell in an endless loading loop.
(not sure whether this was what you were asking for)
well most important in message is that the loader can’t find the *.dtb file.
Possible reasons could be (imho)
- wrong path setting or
- not an up to date bootloader
Hi @le51
At this point I am beginning to be rather confused: cmdline.txt in /boot/firmware is a protected read-only file, unless I am missing something to gain root authorisation…
This is the cmdline.txt content:
console=serial0,115200 console=tty1 root=PARTUUID=d59c818e-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles cfg80211.ieee80211_regdom=IT
Thank you: I checked and had already done that, but decided to perform the procedure again anyway 
I’m not on m’y computer but
blkid
Or maybe
lsblk
Could help To ses if the above uuid correspond to the right NVME partition
I will check tomorrow and get back to you. Thanks!