Dietpi: RPi | USB boot fails

[netwrkx]

Hello, I can't get my RP3b+ to boot from usb hdd, whenever I boot with sdcard, my RP3B+ can detect my hdd and access it.
Without sdcard, my rp3b+ does not boot

Any idea why?

                                                                      ```

DietPi-Update
─────────────────────────────────────────────────────
Mode: Checking for DietPi updates

[ INFO ] DietPi-Update | Checking mirror: https://raw.githubusercontent.com/MichaIng/DietPi/master/dietpi/server_version-6
[ OK ] DietPi-Update | Using update server: https://raw.githubusercontent.com/MichaIng/DietPi/master/dietpi/server_version-6
[ OK ] DietPi-Update | No update required, your DietPi installation is already up to date:
[ INFO ] DietPi-Update | Current version : v6.26.3 [ INFO ] DietPi-Update | Latest version : v6.26.3
```

[MichaIng]

@netwrkx
Many thanks for your report.

How did you clone the SDcard to the external HDD? At best directly flash the fresh DietPi image onto the USB drive, e.g. Rufus can flash to all USB attached drives from Windows since some versions ago.

In general you need to assure that the first partition is FAT32/vfat, properly aligned with bootloader and kernel on it, just as the SDcard was.

And please do NOT boot with SDcard and then mounting both partitions from USB drive as you can currently. This means that the actual kernel/bootloader/overlays are loaded from SDcard, but on later boot stage root partition and as well /boot mount are done from USB drive. So when you do any changes to config.txt/dietpi.txt, update your kernel/firmware/bootloader (APT packages), then those are written to USB drive, but on reboot all is still loaded from SDcard and you'll wonder why none of the changes applied. Furthermore the /lib/modules/ content does not match the kernel version anymore, hence loading kernel modules will fail completely, which will break certain hardware drivers etc.

So when doing USB boot, do it completely from USB (remove the SDcard to be failsafe) or not at all 😉.

And for completeness: Note the difference between USB boot and only having your root partition on an external drive, like you can do via dietpi-drive_manager. The latter means that bootloader/kernel/overlays stay on SDcard and are as well mounted from there, hence it is of course still required for booting. Best you can do on RPi1/2 and currently RPi4 as well, where full USB boot is not supported.

[netwrkx]

I'm trying to achieve usb booting on RP3+(I.e no sdcard), I made use of balenaEtcher to make my usb hdd bootable & configured dietpi to run as headless system but RP3+ wont boot.

I've verified the wifi login info & went through this https://github.com/MichaIng/DietPi/issues/2659

[MichaIng]

Hmm I just read through: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

So USB boot bit is not required to set on RPi3+. Not sure if there are USB devices which are simply not supported at all for this.

If you find time to verify when booting from SDcard with the USB drive attached:

lsblk -o NAME,PARTUUID

The PARTUUID of both partitions on SDcard and USB drive must match, but this should be guaranteed when flashing the img, which contains UUID and PARTUUID.

[netwrkx]

@MichaIng here's the result of blkid
How do I go from here

root@DietPi:~# blkid
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="F661-303B" TYPE="vfat" PARTUUID="cb7b86f7-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="8d008fde-f12a-47f7-8519-197ea707d3d4" TYPE="ext4" PARTUUID="cb7b86f7-02"
/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="F661-303B" TYPE="vfat" PARTUUID="cb7b86f7-01"
/dev/sda2: LABEL="rootfs" UUID="8d008fde-f12a-47f7-8519-197ea707d3d4" TYPE="ext4" PARTUUID="cb7b86f7-02"
/dev/mmcblk0: PTUUID="cb7b86f7" PTTYPE="dos"

[MichaIng]

@netwrkx
Okay PARTUUIDs match, so all references in fstab and cmdline.txt are correct.
sfdisk -l /dev/sda | grep Disklabel reports "dos" as well? Did you try an fsck on both partitions, just to be failsafe?

[netwrkx]

@MichaIng

root@DietPi:~#
root@DietPi:~# sfdisk -l /dev/sda | grep Disklabel
Disklabel type: dos
root@DietPi:~# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0 465.8G  0 disk
├─sda1        8:1    0  42.9M  0 part
└─sda2        8:2    0   1.6G  0 part
mmcblk0     179:0    0  29.7G  0 disk
├─mmcblk0p1 179:1    0   256M  0 part /boot
└─mmcblk0p2 179:2    0  29.5G  0 part /
root@DietPi:~# fsck -f /dev/sda1
fsck from util-linux 2.33.1
fsck.fat 4.1 (2017-01-24)
/dev/sda1: 186 files, 44074/86467 clusters
root@DietPi:~# fsck -f /dev/sda2
fsck from util-linux 2.33.1
e2fsck 1.44.5 (15-Dec-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 39794/107072 files (0.1% non-contiguous), 239385/428032 blocks
root@DietPi:~#

[MichaIng]

@netwrkx
Okay so everything looks fine, besides:

• I am wondering about the sizes of those partitions. The new DietPi RPi image (which matches your PARTUUIDs) should have a boot partition size of 256M (like your SDcard partition has) while the root partition should have ~650M only (before successful first boot extends it).
• Actually it looks like Etcher adjusted the partition sizes, e.g. to have the boot partition match the current data size.

Does Etcher allow to choose "dd" mode for writing the img to disk, so that it is written as an exact clone?

And if there is any screen output when trying to boot without SDcard, that could be helpful as well.

[netwrkx]

@MichaIng

fresh start, latest image
Etcher does not allow "dd" mode
No screen output when trying to boot without SDcard and It doesn't look like any activity takes place without sdcard, just static red led light on. Nothing else

root@DietPi:~# sfdisk -l /dev/sda | grep Disklabel
Disklabel type: dos
root@DietPi:~# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0 465.8G  0 disk
├─sda1        8:1    0   256M  0 part /boot
└─sda2        8:2    0 657.5M  0 part
mmcblk0     179:0    0  29.7G  0 disk
├─mmcblk0p1 179:1    0   256M  0 part /boot
└─mmcblk0p2 179:2    0  29.5G  0 part /
root@DietPi:~# fsck -f /dev/sda1
fsck from util-linux 2.33.1
fsck.fat 4.1 (2017-01-24)
/dev/sda1: 270 files, 82808/516191 clusters
root@DietPi:~# fsck -f /dev/sda2
fsck from util-linux 2.33.1
e2fsck 1.44.5 (15-Dec-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 17212/46944 files (0.6% non-contiguous), 132808/168305 blocks
root@DietPi:~#

[MichaIng]

@netwrkx
Okay now the SSD partitions have the sizes as it should be.

Things to check:

• External power supply for SSD is in use and sufficient
• Try different USB ports and if available different cases/docking station for the external drive. The USB <> SATA adapter might break things.
• Test with official Raspbian Lite, to check if its specific to DietPi or not.
• Test with a different external drive, e.g. some USB stick.

[netwrkx]

@MichaIng I've finally been able to boot from HDD using raspbian.

I added an empty file named "timeout" with the bootcode.bin on my SD card to increase USB wait time.

Then I bought USB to SATA Cable today and I can boot from hdd using the cable without the a SCard. I will test dietpi tonight

tested & confirmed, DietPi boot from hdd without sdcard.☺

[cdlenfert]

I'm in a similar situation to the original poster. Only for me booting from USB when I restore my SD card image to that USB drive works just fine for booting from USB. However if I put the current Buster image (as of today) on my USB drive, my Pi 3b no longer boots. The last comment in this issue seems to be a fix specific to Rasbian vs. Dietpi. Could the timing issue be present on the base dietpi image, but for some reason not on my SD card backup?

[MichaIng]

@cdlenfert
Try to add rootdelay=10 to /etc/cmdline.txt, which increases the timeout to 10 seconds.
Alternatively:

> /boot/timeout

• This is mentioned above and in the RPi docs, but it raises the timeout from 2 (default) to 5 seconds only, which might still not be enough. However if the first attempt does not help, probably the second is the only way with current RPi firmware: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

Ah and assure that no SDcard is plugged, else it will always try to boot from there.

[cdlenfert]

@MichaIng Thank you. It was easier to create an empty "timeout" file in the boot directory from my Mac, so I went that route. It worked and my Pi 3b is booting from USB successfully now.

[cdlenfert]

I also run into the issue of not being able to ping 1.1.1.1 and the initial dietpi-login proceedure and setup fails. After making the changes to the Dietpi.txt file to use 8.8.8.8 instead it seems to work, but installing any software fails due to errors with Git "Unable to locate package git" or "Package git has no installation candidate". I tried rebooting as well and now I'm no longer able to SSH into the Pi. Seems like it's failed to boot again.

[MichaIng]

@cdlenfert
Okay good that it worked with this. The Stretch image contains an older kernel and firmware/bootloader packages, probably this is the reason it was not required before. Either the USB devices initialize later or the root mount is attempted earlier now or both.

I'll repack the images by times to not contain the Cloudflare IP and domain as default for checks. What router model do you use and can you ping 1.1.1.1 from e.g. your Mac?

Strange about Git. The package is part of the regular Raspbian repo so it must be available. If the RPi now again does not boot, I suggest you reflash, and on first run setup do not select any additional software but check dmesg for any file system errors or such. If none present, reboot first to assure the pure kernel/bootloader/firmware upgrade does not create any issue. If all went fine start with dietpi-software installs.

[cdlenfert]

Thanks @MichaIng I'll try reflashing the base dietpi image and following the setup order you suggest. I was indeed trying to install dietpi-software immediately.

My router is a modem/router combo from Centurylink. Technicolor C2100T. I cannot ping 1.1.1.1 from my Mac either.

[MichaIng]

@cdlenfert

Centurylink. Technicolor C2100T

Interesting, this is a modern one, extremely strange why it would deny that global/public IP. Last resort idea is that some Cloudflare DNS CDN members simply have the ICMP protocol disabled, so the server is reachable as DNS nameserver, but simply does not answer to ping requests. Would be a test to use 1.1.1.1 as DNS server and see whether anything or nothing can be resolved then: ping dietpi.com

[cdlenfert]

I tested 1.1.1.1 as a DNS server and it still fails. Looking further into the issue, it seems this is a problem with the Technicolor C2100T using the 1.1.1.1 address internally and not allowing it to be accessed over the web. On the other hand I can reach cloudflare's 1.0.0.1 address without any issue.

[MichaIng]

@cdlenfert

it seems this is a problem with the Technicolor C2100T using the 1.1.1.1 address internally and not allowing it to be accessed over the web

That is really bad news, actually. I was thinking that it is limited to very old routers from a time where 1.* IPs were not yet used by any www host. But since several years it is used, not only by Cloudflare, a pain that router manufacturers ignore this and break using the internet as intended for their customers...
Moreover, 1.* was never officially intended for local network usage. There are clear IP boundaries:

10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255

And for the local machine only:

127.0.0.0 - 127.255.255.255

Using 1.1.1.1 internally, just because it's easy and beautiful (?), while ignoring official IANA reservations, is ignorant and even dangerous if local software depends on functional public 1.* hosts more seriously.

On the other hand I can reach cloudflare's 1.0.0.1 address without any issue

Okay, this means at least it's 1.1.1.1 only and for Cloudflare DNS the above alternative would then be used automatically. Still not beautiful and something that might be worth the report to Technicolor, but not something serious then, besides the principle 😉.

[Joulinar]

would be good to know if 1.0.0.1 would have fixed the issue for other users as well who reported challenges using 1.1.1.1

[MichaIng]

@Joulinar
Agree, although I remember at least one report where 1.0.0.1 failed just the same, one.one.one.one also in some cases. So it does not change something about the need to using something different for default network+resolver tests.

[Joulinar]

@MichaIng
yep that's true. Let's hope that Quad9 will work better.

[cdlenfert]

@MichaIng

Strange about Git. The package is part of the regular Raspbian repo so it must be available. If the RPi now again does not boot, I suggest you reflash, and on first run setup do not select any additional software but check dmesg for any file system errors or such. If none present, reboot first to assure the pure kernel/bootloader/firmware upgrade does not create any issue. If all went fine start with dietpi-software installs.

So I tried skipping the software install on a clean flash of dietpi on my USB SSD. I added the empty boot > timeout file and everything booted up fine, and SSH worked. I exited the initial setup after the DNS lookup failed and switched from 1.1.1.1 to 8.8.8.8 in /Dietpi/dietpi.txt.

I then ran into issues with initial setup script not being able to access the Raspbian repos:

Command: G_AGUG
Exit code: 100
DietPi version: v6.28.0 (MichaIng/master) | HW_MODEL:3 | HW_ARCH:2 | DISTRO:5
Image creator: DietPi Core Team
Pre-image: Raspbian Lite

 file content:
Failed to fetch
p://raspbian.raspberrypi.org/raspbian/pool/main/b/base-files/base-files_10.3+rpi
0u3_armhf.deb  Could not resolve 'raspbian.raspberrypi.org'
Failed to fetch
p://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/libsystemd0_241-7~deb1
i1_armhf.deb  Could not resolve 'raspbian.raspberrypi.org'
Failed to fetch

Here is a Pastebin for the output of dmesg. Several warnings about "under-voltage detected".

I also tried to increase the timeout via: dietpi-config > Network Options: Misc > G_CHECK_URL Timeout but this did not change the result.

If I ping raspbian.raspberrypi.org from the Pi I get a valid response and no packet loss.

[cdlenfert]

Update: I tried changing /etc/resolv.conf to use 8.8.8.8 instead of my router 192.168.0.1 and attempted the initial install again and this time everything appears to have worked.

[MichaIng]

@cdlenfert

If I ping raspbian.raspberrypi.org from the Pi I get a valid response and no packet loss.

Does this resolve to IPv6 address or IPv4?

By default DietPi comes with cat /etc/apt/apt.conf.d/99-dietpi-force-ipv4, which means that APT is forced to resolve to IPv4 addresses. For ping there is no such possibility via config file, only via cmd option ping4 or ping -4.
Could you try dietpi-config > Network Options: Adapters >Prefer IPv4=>[Off]and see whetherG_AGI net-tools` (just a tiny package for testing) then works fine (resolving to an IPv6 address)?

_I never heard of a case where IPv4 resolving failed while IPv6 worked, but only the other way round, which is the reason we ship images with this by default. However since we use ping and curl in many other cases now, which both have no chance to force using IPv4 via config file, I plan to drop this preference option and instead allow to disable IPv6 altogether when facing any error-handled network-related issue. It does not make sense to place a workaround for some commands while other commands still fail. Either IPv6 is fully supported, then enable and use it wherever possible, or IPv6 is not fully supported, then disable it system-wide 😉._

[Joulinar]

my experience with IPv6 is/was, if not really needed > get it disabled. I have seen some cases where IPv6 was causing some issues on DNS resolution.

@cdlenfert
you could have adjusted dietpi.txt right after flashing before booting your USB SSD first time.

[cdlenfert]

when I pinged it resolved to the IPv4 address.
root@DietPi:~# ping raspbian.raspberrypi.org PING mirrordirector.raspbian.org (93.93.128.193) 56(84) bytes of data. 64 bytes from 93.93.128.193 (93.93.128.193): icmp_seq=1 ttl=57 time=127 ms 64 bytes from 93.93.128.193 (93.93.128.193): icmp_seq=2 ttl=57 time=127 ms 64 bytes from 93.93.128.193 (93.93.128.193): icmp_seq=3 ttl=57 time=128 ms 64 bytes from 93.93.128.193 (93.93.128.193): icmp_seq=4 ttl=57 time=127 ms
since everything seemed good I proceeded to install Plex and that also succeeded (or so I was told) and prompted me for a reboot. After the reboot was initiated the system no longer boots.

Is there a way to tell what might be breaking? How do I get it to boot again while retaining any info of what's causing it to fail to come back up after the initial setup?

@Joulinar where is dietpi.txt in the boot partition? I looked in the Dietpi folder and didn't see it there. You're saying I could have adjusted 1.1.1.1 to 8.8.8.8 (or whatever) prior to the first boot right?

[Joulinar]

@cdlenfert
it's directly on the boot folder/drive. Don't change inside the dietpi directory

[MichaIng]

@cdlenfert
Ah forgot about your pastebin:

• Under-voltage indeed can lead to data loss, disk corruption, boot failures and what not. Your first priority should be to get rid of these:
• Assure that your PSU is sufficient.
• Assure that all attached external drives have their own dedicated power supply instead of using USB power (which is max 1A shared, not enough for any 2,5" drive to run stable and leaving in most cases too few left for the SBC itself.
• As a temporary workaround, if external drives are not the culprit or you cannot unplug them for usage reasons, you might clock down your RPi a bid via config.txt.

[cdlenfert]

thank you. I'll look into this first and foremost. Would a USB SSD need it's own power supply. It's not a 2.5 size, or spinning disk, but a small form solid state from an "ultrabook".

[cdlenfert]

also forgot to mention that a hard boot (unplug / replug) works to bring the system up, but a software reboot fails to.

[MichaIng]

@cdlenfert

Would a USB SSD need it's own power supply.

I would say yes, but of course you can simply try. As long as dmesg does not show undervoltage, it's fine.

Generally I would always give external drives (SSDs as well) a dedicated PSU, aside of USB sticks of course.

[cdlenfert]

@MichaIng I added additional dedicated power to the USB > SSD adapter and was able to reboot without issue. Less warnings in dmesg but still a couple on the end. Does dmesg give you new data after every reboot, or could those be old warnings about Under-voltage?

[MichaIng]

@cdlenfert

Does dmesg give you new data after every reboot, or could those be old warnings about Under-voltage?

Note dmesg output only shows output from current boot session. See the timestamps with are second fractions after boot (zero).

[cdlenfert]

Thank you both @MichaIng @Joulinar for your help in troubleshooting. I've been able to boot repeatedly and install software successfully. I'll say it was most likely related to power management issues outside of the DNS issues my router brings to the table. Fingers crossed I'm able to keep running smoothly for a while.