Won't boot from NVME
March 14, 2024, 14:10
I used Raspberry Pi Imager from a Raspberry Pi OS running on an installed SD card to image a fresh Raspberry Pi OS image onto a connected NVME SSD drive. It completed and said it was successful after verifying the image that was installed.
I removed the SD card with intention to boot from the NVME.
It won't boot, though I changed the boot order to begin with NVME.
I plugged in another Raspberry Pi instance that is on a USB drive and it will successfully boot from USB after failing to boot from the NVME.
The NVME is seen by the Raspberry Pi, but as seen in GParted, the two partitions created on the NVME are "unknown" and either damaged, unformatted, or a device entry is missing, or something.
1. Can RPi Imager not install Raspberry Pi OS on an NVME drive?
2. If so, how should it be done, and how should the drive be prepared first (partition table, unformatted or with a filesystem)?
3. If not, what would be the best way to install Raspberry Pi OS onto this NVME drive so that it will boot from it?
4. Image shows Gparted reproting the NVME drive partitions
5. Can Raspberry Pi OS handle being installed on a drive that is ~ 500 GB, or does it have to be smaller instead?
6. I don't want to "copy" an install from an SD card, rather install "fresh" on the NVME
7. Oops, need to mention this is a Raspberry Pi 5
8. It appears the filesystem setup on the nvme drive is corrupted or otherwise wrong.
1. Yes it can. But first you need to upgrade the firmware on the (I will assume that it is a Raspberry Pi 5) Pi 5.
2. You just use Raspberry Pi Imager (download the latest release)
rpi-upgrade?
rpi-eeprom-update
And enable the PCIe
/boot/config.txt is a link to /boot/firmware/config.txt, they are the same file
sudo nano /boot/config.txt
Then add the following comment;
# Enable the PCIe External connector. dtparam=pciex1 # This line is an alias for above (you can use either/or to enable the port). dtparam=nvme
If I remember correctly, I did that some weeks ago
I have a "Pimoroni NVMe HAT" and I followed their guide.
I'm using an Argon40 nvme case with a built-in NVME adapter, not sure if that adds anything to the situation
(https://argon40.com/products/argon-one-v3-m-2-nvme-case )
Looks like the eeprom is already updated
I'll walk you through the process on what I did once I'm on desktop so ping me in like an hour and a half
Thank you
I think the problem I'm seeing relates to how the NVME drive is prepared with the Raspberry Pi Imager
I've tried it multiple times, including creating a GPT or MBR partition table, ExFAT or EXT4 partition or unformatted
And unlike other linux installs, it seems RPi OS likes to fill up a drive after install to utilize all the space, so I'm not sure if I can or cannot manually specify the partition sizes and types.
Also, the image shown in Gparted (that I included in this thread) is exactly the result of using RPi Imager to install RPi OS onto this NVME drive -- why are the filesystems marked "unknown" and why did it partition the way it did with the partition size as it did? Is there a limit to partition sizes in Raspberry Pi OS?
Here are two images showing the working external USB drive and the non-working NVME drive. Both were prepared using the RPi Imager, so I would expect both to work and be bootable. Why is there not a known "/boot/firmware" and "/" partion on the NVME?
One thing that may help is to ask "starting from scratch, how should I prepare the NVME drive?"
1. Remove all partitions
2. Create partition table (can it be GPT or does it have to be MBR, and if it has to be MBR, why?)
3. Leave it unformatted or write a filesystem to it (why does Raspberry Pi OS's image seem to overwrite whatever I set up, can I not manually assign partitions like in other linux distibutions?
4. And then how best to image the drive?
<@1071178789939331253> Ready to continue fixing this NVME boot issue
I'm very late aren't i
ok pi 5 right?
yeah it is
yes, Pi 5
ok good
then what I used is imager in the cli so you let's use that
download the image you want onto your pi and name it "os" or something you'll remember
I have the image downloaded and also verified its sha-256 checksum
run man rpi-imager to find out all about it
also I forgot so can you copy and paste what this shows?
I haven't renamed it yet, but know the filename
ok good
is rename just so I can recognize it among other downloads?
do you also have a display and micro hdmi cable btw? it is needed for this
just so you can use it easily later yes. no real reason
Pi is currently connected to a monitor, booted from an external USB
and running
ok good
now run this
man page shows
copy and paste it here for me?
because I've got the memory of a captive goldfish
uh oh : )
hafta put it on network and pull up this chat on it... one moment
Is there a way to capture a screen or window on raspberry pi OS?
Looks like gnome-screenshot will do the trick...
sure as long as it's readable
sorry for the inconvenience
no problem : )
Troubleshooting screenshot, standby ....
that didn't work
kazam works though
...trouble there too, not worknig as I thought, hold on
nvm I might be able to do it myself now
oh btw you do need to install it sudo apt install rpi-imager -y
give me a minute on that I need to do update my kernel and if don't do it now I'll forget
K
I'll be back in 4 minutes
ok I got it
sudo rpi-imager --cli <os file> <device>
wait no
Does it have a flag for showing progress throughout the imaging process?
While I'm waiting, I wonder why it's been so hard to get a screenshot?
Tried multiple apps and none have worked yet
I don't know why but a lot of people have had problems on the pi with screenshots
It's like they all crash
one second I'll shall help you with that
I'm trying to get one that lets me select an area
rpi-imager is installed, btw
and up to date
and have you ran it?
I have before, using the GUI
today's run using the CLI will be my first
but, not to fear, I'm comfortable with the cli
try scrot
I like it even more than gui
does scrot let you select an area?
I don't know it's been a while since I've used gui on my pi and I've never did a screenshot when I did
looking now
almost there...
I'll keep trying in the background to provide a screenshot, scrot is not giving me a picture after
Instead, it gives a message:
$ scrot -u
X Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request: 14 (X_GetGeometry)
Resource id in failed request: 0x1
Serial number of failed request: 8
Current serial number in output stream: 8
Looks like I can cut and paste cli, manually
yes. did rpi-imager work?
well, I haven't run it yet, except the
man rpi-imager
command
I saw your last comment:
"ok I got it
sudo rpi-imager --cli <os file> <device>
wait no"
so I thought you might be modifying that command before telling me to run it
question though -- shall I use gparted to remove the partitions on that NVME drive before running imager?
and should I create a new partition table?
yes I just modified it
oh : )
I forgot to unzip the image
a nice way to do that in a cli?
use mkfs <Device> -f ext4
and should the partition table be GPT or does it have to be MBR?
never heard of those
I guess more specifically, Gparted lets me choose 'msdos' or 'gpt'.
Will gpt work?
this formats the nvme btw
I'll try gpt and see, it's one of a few partition tables available
gpt is newer than old msdos
$ mkfs /dev/nvme0n1 -f ext4
mkfs.ext2: invalid option -- 'f'
Usage: mkfs.ext2 [-c|-l filename] [-b block-size] [-C cluster-size]
[-i bytes-per-inode] [-I inode-size] [-J journal-options]
[-G flex-group-size] [-N number-of-inodes] [-d root-directory]
[-m reserved-blocks-percentage] [-o creator-os]
[-g blocks-per-group] [-L volume-label] [-M last-mounted-directory]
[-O feature[,...]] [-r fs-revision] [-E extended-option[,...]]
[-t fs-type] [-T usage-type ] [-U UUID] [-e errors_behavior][-z undo_file]
[-jnqvDFSV] device [blocks-count]
MKFS(8) System Administration MKFS(8)
NAME
mkfs - build a Linux filesystem
SYNOPSIS
mkfs [options] [-t type] [fs-options] device [size]
DESCRIPTION
This mkfs frontend is deprecated in favour of filesystem specific
mkfs.<type> utils.
$ sudo mkfs.ext4 /dev/nvme0n1
mke2fs 1.47.0 (5-Feb-2023)
Found a gpt partition table in /dev/nvme0n1
Proceed anyway? (y,N) y
Discarding device blocks: done
Creating filesystem with 117212884 4k blocks and 29310976 inodes
Filesystem UUID: a7420a67-a6e3-4a61-8ea8-1a418e8dc783
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000
Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done
great now run rpi-imager
oops I still need to unzip it
tar -xvf <zipped-image> ?
I think yes
k, working on it
Pi 5 is workin oin it, more correctly : )
$ xz --decompress 2024-03-12-raspios-bookworm-arm64-full.img.xz -k -v
2024-03-12-raspios-bookworm-arm64-full.img.xz (1/1)
6.9 % 193.2 MiB / 1,168.3 MiB = 0.165 12 MiB/s 1:34 22 min
59% complete
100% complete
great
write to /dev/nvme0 or to /dev/nvme0n1 ?
I think it's 0
I'll give it a whirl
It complained, but nvme0n1 seems to be writing ok
52%...
is it a slow SSD or usb? mine took like a minute or less
Well, it should be faster, I think. but it's at 63% and the USB drive is a usb3 so something is weird here
slow nvme then
I think you're right
sorry bout that
I don't know why it's still at 63% after about 4 minutes now, but it appears to still be accessing the USB drive
don't stop it
it usually takes a while normally, the only thing is it should be slightly faster here because you've already downloaded the os
I'll let it continue. Maybe it's working but not updating to let me know
it failed
"Error extracting archive: basic_string::_S_construct null not valid"
Should I try it without unzipping the zipped image?
I rebooted the Pi and tried again, and it went much faster and wrote successfully
Then I rebooted the Pi again after changing the boot order and it only booted back into the USB
And in Gparted, I see the nvme looks bad, the same as it did in the picture I posted before in this thread
I'll hop away for a bit but check occasionally to see if there are more posts
remove the usb
I forgot to mention that I removed the USB and it did not boot into NVME. Rather, it showed the Raspberry Pi screen that shows it attempting to boot NVME, then USB, then SD, and also allows the option to net boot. No luck booting from the NVME, even when all other boot options are not available since I physically removed them and left only the NVME attached. Also the filesystems of the two paritions are "unknown", suggesting that something did not set up as it should. I compare that with the GParted report of the working USB, and it has a FAT32 and EXT4 partition, but the NVME only has two "unknown" partitions. Something seems off when comparing the two
Why are the filesystems "unknown"?
the thing is what I did is download it and unpack it on my computer and put it on my pi via sftp so that may be the problem
Previously I unpacked it on my computer and connected the nvme drive (in an enclosure) and imaged it there. It was the same result with "unknown file"
no I'm mean plug the usb drive out and and download the os (from here https://www.raspberrypi.com/software/operating-systems/ ) and unpack it on your computer then copy it over to a file on the usb
and then boot the pi off of the same usb and do all the steps I mentioned
I'll add details in case it is helpful:
USB external SSD drive - has RPi installed and bootable -- it's the OS running on the PI, which is curerntly booting off of USB
NVME enclosure is a thunderbolt type, so I cannot plug it into the Pi, but once the NVME is imaged I can take it out of the enclosure and connect it to the Pi -- and I did try this before and got the same failure I'm dealing with
There's the download from raspberrypi.com, which comes in an .xz compressed format
There's the image .img that we get when we uncompress it
I have uncompressed that downloaded file using the Pi, and also using my computer. I ran a SHA256 against the result on both the Pi and on my computer -- if we both did that I think we would have the same result if we compared them. If we question the integrity of the uncompressed image, we could test it this way. For the one I downloaded, the checksums are:
Raspberry Pi OS with desktop and recommended software
Release date: March 12th 2024
System: 64-bit
Kernel version: 6.6
File: 2024-03-12-raspios-bookworm-arm64-full.img.xz
SHA256: 36da44c3caea8f309a3c006af1af3605442ca27db77634b044da61da36cdb720
After uncompressing the .img.xz file, I get a 2024-03-12-raspios-bookworm-arm64-full.img file and the SHA256 for it is: 3ba85c1d0e0e8f1f570b9580a2efbbaccc42b4cb522c577d97882073b91a4491
I tried uncompressing this file on both RPi and my computer and the checksums match
If I copy that image to the NVME like I would a regular file (drag and drop), I end up with a file on an NVME drive and it won't boot (and same with a USB drive, I'd just have a file sitting on it). However, if I use the RPi imager, I end up with the Pi OS installed on a USB drive, or the NVME drive -- although in my case the result is success with a USB drive (it boots fine), and for the NVME I end up with two partitions with unknown file type and a third unused portion that I'm wondering why it was left unused (and the NVME does not boot)
Now, I could try to clone the image from my USB drive to the NVME, using the linux disk duplicator cli program called dd. I haven't done that yet. I could try, but would not RPi Imager be able to image the NVME properly on its own? (It appears that RPi Imager is unable to successfully image my NVME, whether I do it from my computer, or from the Pi itself)
A img file is a image of a disk, partition structure and file/path content.
You can not boot from an img file. You can dd a img file to a disk and the opposite.
So the process you describe is incorrect.
"NVME enclosure is a thunderbolt type"
Maybe that's the reason?
My cases all have USB and USB C ports and I've never had any problems with them.
I agree.
The NVME enclosure I referred to is a thunderbolt type that can connect to my computer and I can use my computer to image the NVME drive
But to connect the NVME drive to the Pi, I must take it out of that Thunderbolt enclosure and put it into the Argon40 case that the Pi is in, which case includes its own place to connect an NVME drive.
So the thunderbolt enclosure was used to connect the NVME to my computer long enough to use RPi Imager to put the RPi image onto the NVME
Once the NVME is moved to the Pi, the thunderbolt enclosure I talked about is now out of the picture.
As for not being able to boot from an image file,
Yes, that is correct. I cannot simply copy an image file to the NVME drive and expect it to boot. I must instead use the Raspberry Pi Imager, or the linux "dd" tool, to accomplish that task.
I have been using the Raspberry Pi Imager to do this job. It is officially supported and ...should, work
*
I have imaged the NVME drive in two different places with multiple attempts. One was with my computer using that thunderbolt enclosure (since that is the only thing I currently have that provides a way to connect the drive to that computer)
The other way was using the Raspberry Pi, running Pi Imager to do it.
Both result in the same filesystem setup and failure I mentioned
Have you checked that the SSD is "Raspberry Pi 5" copatible?
That is my suspicion.
The RP5 can write to that NVME drive
It can read from it
Gparted can edit partitions on it
RPi Imager can image the Raspberry Pi OS to it -- but for an unknown reason, though the RPi can read and write to the drive, the result of the RPi imager is two partitions of an unknown file type -- why does it turn out that way?
*
How may we check if a certain SSD is compatible with Raspberry 5?
Closest I find so far is a list in the description for this adapter: https://thepihut.com/products/nvme-base-for-raspberry-pi-5-nvme-base
Guess I'll have to obtain another SSD and see if things improve.
If it does improve, I'll know that an OWC Aura Pro is one of the drives that are not compatible
Im not 100% sure, I used the combability list that Pimoroni had in their "NVMe HAT" posting
I think we both found the same list
Ok, well, without another thing to try yet, I'll try to get another SSD brand
and hope
That link you posted has the same drives as in the Pimoroni list
After pulling out the Aura P12 Pro and installing a Samsung 980 Pro, it worked!
Ok, I guess we add two more SSDs to the list, one that doesn't work with the Pi, and one that does
The Aura Pro has the word PHISON on what may be the controller. Adding this for more info in case it is useful to others
oh great
weird that other ssd doesn't work even after a reformat