Raspberry Pi 5 OS - Impossible to boot

[kikaragyozov]

I'm trying to ditch my current SD card and switch entirely to a portable SSD connected via USB.

Things I did:

1. Deleted all partitions on my SSD.
2. Manually created partitions equal to the ones on my SD card, with minimum space matching the ones on the SD card:

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS           FSTYPE UUID                                 PARTUUID                             LABEL
sda           8:0    0 931.5G  0 disk
├─sda1        8:1    0   512M  0 part /media/pi/FF61-CD85   vfat   FF61-CD85                            deb0b539-01
└─sda2        8:2    0   931G  0 part /media/pi/Extreme Pro ext4   335884ab-a981-4e26-a064-d61879180b66 deb0b539-02                          Extreme Pro
mmcblk0     179:0    0  14.9G  0 disk
├─mmcblk0p1 179:1    0   512M  0 part /boot/firmware        vfat   D735-E67D                            41d867f7-01                          bootfs
└─mmcblk0p2 179:2    0  14.4G  0 part /                     ext4   b69628b0-b5d6-474c-9bed-477305ae01ad 41d867f7-02                          rootfs

3. Ran sudo rpi-clone sda
4. Process completed successfully.
5. Used raspi-config to change boot order to USB.
6. Realized I should have done this before cloning/syncing.
7. Restarted device.
8. Ran again sudo rpi-clone sda without literally doing anything else.
9. Process completed successfully.
10. Shut down Raspberry Pi.
11. Setup failed to boot into SSD, and as a fallback it booted into my SD card.
12. Verified via an HDMI cable connection that the issue for not booting into the SSD (with an unplugged SD card) was due to a unable to read partition as FAT (partition 0) error.

I'm at a complete loss. Any help would be appreciated. I verified fstab entries - they seem to be correct. PARTUUIDS match with the ones specified there. I'm really not sure what's going on.

Fstab file:

proc            /proc           proc    defaults          0       0
PARTUUID=deb0b539-01  /boot/firmware  vfat    defaults          0       2
PARTUUID=deb0b539-02  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

[kikaragyozov]

I've solved my issue by utilizing the built-in SD copier. Still no clue what went wrong with rpi-clone.

[wboerhout]

same issue here. rpi-clone works on bookworm an all my raspberries (running the prescribed Debian), but boot fails on the one Raspberry Pi 5.

[framps]

all my raspberries

Do you also have a RPi4 and tried to clone a SD card to nmve?

I unfortunately don't own a RPi5 and cannot try to reproduce your issue. But it sounds to me it's not related to RPi4 but to clone an SD card to a nvme drive. If I'm right the same scenario will fail if you use a RPi4. Would be great if you can double check with a RPi4.

[wboerhout]

All works fine on RPi 4. I do not have NVMEs but my targets are the new Samsung USB 3.2 sticks from the PiHutGroet,Wilm(Verstuurd vanaf mijn telefoon, dus wat korter dan gewoonlijk.)(Sent from my phone, so a bit more compact than usual)Op 27 nov 2024 om 18:28 heeft framp ***@***.***> het volgende geschreven: all my raspberries Do you also have a RPi4 and tried to clone a SD card on nmve? I unfortunately don't own a RPi5 and cannot try to reproduce your issue. But it sounds to me it's not related to RPi4 but to clone an SD card on a nvme drive. If I'm right the same scenario should will fail if you use a RPi4. Would be great if you can double check with a RPi4. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[wboerhout]

RPi 4 works fine with the new Sandisk (not Samsung, sorry) USB 3.2 SDCZ430 drives

[framps]

Did you test the ssd to nvme move with RPi4? If it fails I'm able to try to reproduce the issue because I have a RPi4 with nvme storage.

[wboerhout]

As I said, I have no NVME. I have a Kingston SSD on a USB 3 adapter as source (the Debian system I'm running rpi-clone on, and a Sandisk USB 3.2 USB stick as target. This setup runs fine on RPi4 bookworm (i.e., rpi-clone runs error free and new target will boot the copy)

On Rpi 5, rpi-clone runs error free as well, but the target disk is stuck early in the boot cycle (in a state where I cannot find a log from), but the on screen messages suggest that (the copy of) partition 1 is not bootable for some reason

[framps]

rpi-clone unfortunately misses logging which makes it - at least for me who has no RPi5 - impossible to recreate and debug your issue :-(

Crossing fingers somebody else owns a RPi5 and can recreate and debug your issue.

If you're willing to donate to get me to buy a RPi5 - please see this page

[wboerhout]

I will think about it. I really appreciate the work you are doing.

[framps]

I got a donation from @geerlingguy (Thank you very much!!!) and just ordered a RPi5 which will arrive next week.

No NVMe hat and SSD but I expect your issue is not nvme related and I can reproduce your issue when I clone the SD card to an USB disk attached via USB.

@geerlingguy I tried to contact you on X but you don't accept any PN 😢

[geerlingguy]

@framps - Odd! What's your X username? I thought I had DMs open but I guess not!

[framps]

I just checked my DM settings and it was disabled. It's obviously the default setting. My username is @linuxframp.

[wboerhout]

OK this is the issue more documented. Same process works fine on all Rpi execept Rpi5

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0    7:0    0    92M  1 loop /snap/core/17201
loop1    7:1    0    20K  1 loop /snap/hello-world/29
sda      8:0    0 111,8G  0 disk
├─sda1   8:1    0   512M  0 part /boot/firmware
└─sda2   8:2    0 111,3G  0 part /
sdb      8:16   1  57,3G  0 disk
├─sdb1   8:17   1   512M  0 part
└─sdb2   8:18   1  56,8G  0 part

sda is my Kingston SATA SSD connected via a SATA/USB adapter to the bottom USB-3 port on the Rpi 5. This is my usual boot setup.
sdb is the new SanDisk Ultra Fit USB 3.2 Flash Drive and the target for rpi-clone and it is in the top USB-3 port.

Now sudo rpi-clone -f sdb works without errors, and upon manual inspection, all files seem to be in place. However, booting the new disk fails. See the attached screenshot (literally, with a camera) of what happens. The Rpi 5 keeps trying and the last few lines reappear in what seems to be an endless loop.

[framps]

Which OS do you use? Please show the output of cat /etc-os-release and uname -a.

[wboerhout]

pi@raspi5 ~ $ cat /etc/os-release

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

pi@raspi5 ~ $ uname -a

Linux raspi5 6.6.51+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.51-1+rpt3 (2024-10-08) aarch64 GNU/Linux