RasPi3B was booting from SSD, stopped working?

Setup, Configuration and Use Installation
1
  • Platform information:
    • Hardware: RasPi 3B
    • OS: openHABian
    • openHAB version: 2.5.4

I had my RasPi3B booting from a SSD. However that failed at some date and I could never get it back to boot from the SSD.
Meanwhile the RasPi 3B is booting from the SD Card again. Each and every trial to get it booting from the SSD, even with a new openHABian image were not successfull.
Mounting the SSD on the running RasPi does work, booting from it does not.
The option to boot_From_USB in the OTP is still set (checked it anyhow).
I measured the power on the USB, which showed 5.1 V 0.15 A . Those values are showing when trying to boot from thr device and when mounting on the running RasPi. To me that sounds OK.

What else could I check? What else could go wrong?

2

Is program_usb_boot_timeout=1 set ?
See https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/host.md

1 Like
3

Hi @opus,

I had the problem you describe not too long ago. I was booting my Raspberry Pi 3 from USB for maybe a year or two. Then one day it crashed.(or so I presume) and I couldn’t get it to boot again. The SSD was fine as I could read it on another box. The Pi was also fine as I could boot via micro SD card. I ended up fixing it by increasing the USB boot timeout. By default, the Raspberry Pi 3 waits 2 seconds for USB devices to enumerate. Sometimes this is not enough. Although it doesn’t make much sense to me given the fact SSDs are electronic and booting worked before, changing the timeout to 5 seconds (maximum allowed) solved my SSD boot issue.

Regards,
Burzin

1 Like
4

Thanks for this one, however it doesn’t change the situation.
I checked if this setting is performed (vcgencmd otp_dump | grep 66 gives 66:01009daa).
Still searching…

What makes me wonder is this the following display when the SSD is connected to the running RasPi:

 sudo lsblk -o UUID,NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL,MODEL
UUID                                 NAME        FSTYPE  SIZE MOUNTPOINT LABEL  MODEL
                                     sda                29,5G                   SSD_32GB
F661-303B                            ├─sda1      vfat    256M            boot
8d008fde-f12a-47f7-8519-197ea707d3d4 └─sda2      ext4    1,8G            rootfs
                                     mmcblk0            14,9G
F661-303B                            ├─mmcblk0p1 vfat    256M /boot      boot
8d008fde-f12a-47f7-8519-197ea707d3d4 └─mmcblk0p2 ext4   14,6G /          rootfs

The first entry is the SSD (32 GB), the second one the SD Card (16 GB).
Both storage devices have the same UUIDs?? Never seen that. Both storage device were started with an openbian image, would that cause the same IDs?
The SD Card used to boot has settings for the mountpoint (/boot and /), the SSD doesn’t. Would that be a point? (Then, how to set those?) The SSD holds so far only an unused openhabian image.

5

Yes. If both disks ( SD, SSD ) are based on the same image and the image is copied to the disk e.g. bz using dd then they will get the same UUIDs.

What do you mean with settings for the mountpoint ?

6

Thanks for the response.
When checking the storage devices amongst UUID and size also the “Mountpoint” was displayed (see in the above post). The SD Card had /root and / while the SSD had nothing set there.

7

:flushed:
I tried the oldest icy-box I have (one with two USB connectors!) and this one works!

Why it started to not work with the newer box, I can’t say.
Thanks for the support.

8

This means while the command lsblk was executed the SD Card was mounted with it’s partitions at the related mountpoints. No mountpoints were shown for the SSD because it was not mounted.
I assume that the fstab contains the UUIDs and where to mount them.

1 Like
9

Did you ever figure out why your SSD didn’t work with the new one?
I have since two hours a similar problem.

RasPi3 was running Openhab 2.5.9 Stable for more than a year off the SSD (128GB, through a USB hub). This morning I updated the system through Openhabcli-config, and first when Openhab2 service restarted, it didn’t display the values from the persistence, so I decided to reboot the system, and it has been down since.

I tried connecting the system to a monitor, but there is absolutely not output at all! Just black screen. Upon connecting the SSD to a windows machine, I can see there are two partitions and at least the small boot partition with 256MB is accessible. I can also connect it later to another RasPi and see what can be read. The question is:

Is there any thing that can be done to change the settings/files in SSD and plug it in the RasPi again or should I start from scratch again? I do have daily openhab backups (up until this morning!), but there are of course more things than just openhab backups, for example many other scripts/programs that would need to be reinstalled. Any suggestions anyone?

Thanks in advance!

Edit: I must add, I got this error below immediately upon updating in the openhabclient. I have also got this error before, so not sure whether it is significant.

The unit file, source configuration file or drop-ins of openh
ab2.service changed on disk. Run 'systemctl daemon-reload' to reload units

EDIT2: So I plugged the SSD into a Raspi4 running default Raspbian installed through NOOBS and I am able to see the files in SSD. There are two partitions boot and rootfs. Are there any files that I could fix/check there? Some things that seem odd.

  • The boot partition has an empty overlays folder.
  • The rootfs partition has boot and boot.bak folders, but the boot folder is empty! Boot.bak on the other hand has many files like images etc., but the timestamps are from Feb 2020.

Should I try and rename the boot.bak to boot and see whether it boots up? The good thing is that I am able to recover my old files if necessary and I could reinstall. But if there is a way to fix the SSD easily, I would much rather prefer that.

Thanks!

10

Nope!
The raspi is running g find since then (multiple fingers crossed!), so I won’t touch it ( at least theSSD setup).