Will not boot with multiple USB external drives attached.

[mernamer]

Creating a bug report/issue

I set up a Raspberry Pi 3 B to boot to DietPi from a USB device, works without issue, but when attaching any additional USB external drives, device appears to not complete boot when both are plugged in (green LED does not light, solid light on bootable USB device, where it tends to flicker on both at boot, is solid, and not accessible via network, set up for headless login via SSH) have to unplug the other drive to get the boot to occur on the original USB drive correctly, then plug the other external drive back in.

This is a pain, but would be okay as a problem solving step, except if I have to unplug the drive at start, it skips the fstab step, can't automount, and have to manually complete the mount each time which is, again, a pain. Also introduces a significant source of potential user error in normal use.

Required Information

• DietPi version | G_DIETPI_VERSION_CORE=8
  G_DIETPI_VERSION_SUB=7
  G_DIETPI_VERSION_RC=1

• Distro version | bullseye 0

• Kernel version | 5.15.56-v8+ #1575 SMP PREEMPT Fri Jul 22 20:31:26 BST 2022 aarch64 GNU/Linux

• SBC model | RPi 3 Model B

• Power supply used | Power supply from Raspberry Pi (has the logo, details aren't visible)

• SD card used | None, booting from USB external drive

Additional Information (if applicable)

• Can this issue be replicated on a fresh installation of DietPi? Yes, issue recurs with fresh install.

Steps to reproduce

1. Uses these steps to boot DietPi from usb drive: https://www.instructables.com/Booting-Raspberry-Pi-3-B-With-a-USB-Drive/, used most current Raspbian light for the SD card, but when complete, successfully booted DietPi from USB drive, was able to remove SD card, and multiple reboots without issue, successfully boots to DietPi each time.
2. ...Plug in an external harddrive, completed obligatory set up steps in DriveManager or fstab (tried both, both with and without a clean DietPi install)
3. Reboot

Expected behaviour

• ...Should boot from the USB drive, but also mount the additional external drive.

Actual behaviour

• ...have to unplug the other drive to get the boot to occur on the original USB drive correctly, then plug the other external drive back in.

Extra details

• Output from mount below.
  /dev/sda2 on / type ext4 (rw,noatime,lazytime)
  /dev/sda1 on /boot type vfat (rw,noatime,lazytime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
  /dev/sdb1 on /mnt/piDrive type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
  binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)

[Joulinar]

You could have installed DietPi on your SD card and enable USB on our configuration options. Once done simply flash the image to the USB drive 😉

But this is not your issue. How do you power the attached USB drives? Do they have an own PSU? If not I recommend to use something like a powered USB hub because USB ports of an RPi are not designed to.power something larger than a pen. It might gonna work but on peak situation like a boot process, power might not be an enough.

[mernamer]

Appreciate the note on using the DietPi tools, I keep forgetting to use what's there because I've spent a few years on Raspbian light on the command line, and I'm just not used to having these things available lol. Will also be helpful if I need to do another clean install.

The boot drive is just a thumb drive, and is plugged in directly, but the other external drive is connected to a powered usb hub. Maybe they both need to be powered?

Also, thanks for your rapid response. :)

[Joulinar]

You need to enable USB boot just once. It will stay enable even if you flash a new system.

So your 2nd drive is already powered? Did you tried different USB ports? Are you able to attach a screen to check what happens during boot?

[mernamer]

Yeah, already powered. Did try different ports, each time the drive appears to function correctly (can mount and view on DietPi) but if plugged in at boot, just won't boot.

I was able to attach a screen to check and it's just dark screen. The screen does display when following the step to troubleshoot, only keeping the boot drive plugged in and plugging in the external drive / usb hub after boot has started, so know it's not the monitor or the HDMI port.

ETA: The additional drive was a legacy ntfs drive, so going to try updating to more linux friendly ext4, see how that rolls, maybe explore syncing the boot partition somehow, if the problem is the board is trying the drive without it first and stopping there.

Will update if either of those work lol

[Joulinar]

Does the drive contain any boot partition the RPI is trying to read? Can you format the whole drive?

The dirve available drives can be shown as follow once system has been booted.

lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid

[mernamer]

The additional drive does not have a boot partition now, did format Ext4 + a second drive, just to check it's the device.

For now, both drives have Ext4 filesystem, and issue persists.

But they also stay on the fstab and more readily connect to the right place when I plug them in after starting boot with the original bootable thumb drive. So saving some time, even if the original issue persists.

Output from lsblk:

NAME FSTYPE LABEL   SIZE RO TYPE MOUNTPOINT PARTUUID                             UUID
sda                 7.6G  0 disk                                                
├─sda1
│    vfat           128M  0 part /boot      df909cde-01                          441B-9770
└─sda2
     ext4           7.5G  0 part /          df909cde-02                          952cc7ca-2953-4406-bd25-9dd2feee5eac
sdb               465.8G  0 disk                                                
└─sdb1
     ext4         465.8G  0 part /mnt/piDri 30e4b01e-c999-4aea-9940-f4b908db9a0b c5f28a3f-c231-4f8d-b3bc-63de9a0c1f69

[Joulinar]

UUID's looking fine. No issue there.

@MichaIng
any ideas?

[MichaIng]

Does

dmesg -l emerg,alert,crit,err

show any errors when you attach and use it after boot?

Please try to set/change

initial_turbo=0

In dietpi.txt or via dietpi-config performance options. If this worked, it would still indicate a power issue.

A UART adapter/serial console or persistent system logs can be used to further debug, although system logging stage isn't reached, I guess.

[mernamer]

From dmesg:
[ 5.288300] sd 2:0:0:0: [sdc] No Caching mode page found [ 5.290797] sd 2:0:0:0: [sdc] Assuming drive cache: write through

Turned off async, issue persists. The internet thinks this doesn't mean anything... but underpowered still a possibility. Tried initial_turbo=0, no luck.

Sounds like I'm buying a new usb powered hub, will update whether that works.

[MichaIng]

Yes, the caching mode warning is common in combination with USB-attached drives, definitly not related.

Hmm a serial console / UART adapter would be very helpful indeed to know for sure where it is hanging.

Before you buy a new hub, let's at least try whether system log is printing something already by making them boot-persistent:

dietpi-software uninstall 103
mkdir /var/log/journal
poweroff

Attach both drives and let it trying to boot for a while. Then power cycle and unplug the second drive again to allow for boot. Then check

journalctl

Whether anything has been logged from the failing boot session. You can revert the RAM logging via:

systemctl stop systemd-journald
rm -R /var/log/journal
systemctl start systemd-journald
dietpi-software install 103
reboot

[Power-onoff]

I have the same problem

The board I used is Odroid N2

There was no problem with the Debian buster version installed around February 2021

This is the problem that came out when I installed the new Debian bullseye version

Install the dietpi image on the eMMC and operate normally However, if you connect only USB 3.0 HDD, it will not boot

I've been using this server for a long time, so I don't think it's a HDD low voltage problem

The picture below shows the screen image that appears when the boot fails

Is there any possibility of a problem with the u-boot loader?

[MichaIng]

I answered on the other issue where it fits better: #5634 (comment)
Different SBC means very different possible issues 😉.

[MichaIng]

@mernamer
Does your issue persist with recent RPi kernel? If so, for debugging, persistent kernel logs would be helpful: #5729 (comment)

[MichaIng]

Marking as closed due to outstanding reply. Feel free to reopen if required.

[mernamer]

Issue currently resolved: Flashed DietPi to external drive as suggested, appears to be working with same two external drives attached.

Trouble initially because... I knew Ext4 on linux = good, missed that Ext4 on Win10 default=bad. No clue why great drive on DietPi showed nothing on Win10. Learned that, then resolved via portable DiskGenius, which showed drive, let me see it before I flashed over it and backup or remove what I wanted to keep, and even let me see details about a scam 2 tb thumb drive I bought* by error that were useful.

Otherwise, I've reproduced recently after starting from scratch, most recently I used Drive Manager to transfer rootfs from an SD card to a harddrive, that worked most consistently a few reboots before going back to the black screen of death (BSOD)@, before the above resolution.

Also, did not collect logs from SD card/drives before flashing because, again, didn't yet know was possible LOL.
Also, tried a new powered hub I had to purchase for something else anyway, no difference, as predicted.

If issue recurs, I'm starting with the serial console / UART adapter.

And will start with last steps graciously provided above first in #5729, and try to update here if anything relevant shows up.
Thanks again for your help, very much appreciate it, sorry for wandering off a bit.

*I share I fell for this dumb scam, there is no possible way a 2 TB drive could be that small or that cheap, because they are everywhere right now, report them wherever you see them, they're even showing up on NewEgg and Walmart it's such a prevalent scam, which makes it easier to believe nonsense like it's even possible because even those retailers have them, please help do something about it if you have the opportunity.