On DietPi or raspbian?
raspbian lite
Puhh that looks more like hardware issue honestly
I really hope that isn’t the case. I haven’t done anything to this Pi that could cause that. It even worked fine with dietpi several months ago. Is there a diagnostic script I could run or something?
I’m not aware on a diagnostic script that can be used to have this checked. Maybe MichaIng has an idea how to find out.
I’ve started having issues with external drives. I have an RPi 4 as well as the OP. The problems have occurred on both an SSD and an HDD. Key thing here is that I have moved the rootfs to the HDD/SSD so when the USB error occurs, I lose access to everything (command not found error).
I was running an SSH window following the kernel and I did catch an error. Unfortunately, I did not save it exactly, but it was along the lines of
xHCI host not responding to stop endpoint command.
I think it may be a kernel error/bug.
This error happened a couple of times and I put it down to the cheap SSD I had bought having googles the error. However, I have subsequently moved to a WD PiDrive (so an HDD rather than an SSD) that has run fautlessly when connected to a PiB+ for several years, and have experienced exactly the same issue again. However, as I was no expecting an issue, I did not have a journalctl window following the kernel.
My initial conclusions are that there is an issue with the kernel driver for the USB2 ports on the RPi4.
I currently have a couple of SSH sessions open and following the kernel messages so waiting to see what happens.
[edit]
Always the way, been searching for ages, post this search again and something new pops up.
This sticky post on the RPi forum suggests it is an issue with the quirks blacklist. I am surprised this HDD is not in it if there is a problem with it.
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=245931
I would agree, looks like it
So I did a quick test, if you don’t mind me reviving this a bit.
I had my Pi’s power supply on an Amazon Basics power strip. The only other item plugged into it was my network switch.
Shut down the Pi and plugged it directly into the wall, HDMI signal has been on for the past six minutes. If you recall, the signal died within a minute or two before. So I guess the power strip I used didn’t supply enough power for it with another item attached.
I haven’t tried with a USB/HDD/SSD just yet, but the USB I did have plugged in from the original test was still on. When I booted it the first time while it was in the wall, it actually was trying to read off of it for some reason. I’m not familiar with what reasons it would have for that, but I will try again on dietpi (as I was doing a separate test on raspbian lite) with this new information.
Running a few tests with a USB flash drive, I noticed that using dietpi-drive_manager appends x-systemd.automount which makes systemd handle it. The device eventually goes idle and then becomes inaccessible. I can’t unmount the drive normally because it’s busy according to dietpi-drive_manager, and doing sudo umount /mnt/media doesn’t let me re-mount it.
to un-mount a device, ensure you are not located on a file system hosted on it. otherwise you can get a device busy. Do a simple cd before un-mounting.
to find out who is using your mount, you can do the following:
lsof /dev/sda[1-9]
fuser -m /dev/sda[1-9]
once you know who is blocking the device, you can kill the process. Or go the hard way by using -l option. This will force to un-mount (with all consequences).
umount -l /dev/sda<ID>
Yeah, checking what was using it was root via mount.
I disabled device power off, which helped because a manual mount didn’t timeout. However, transferring files can still cause random I/O errors.
Probably the issue is the automated drive spin down via hdparm. We have this by default enabled on /dev/sda which does not make much sense in case of SSD and flash drive and is not wanted with root on external drive. The plan is to make this an optional feature per-drive and enable for spinning non-root devices only. Could you try:
rm /etc/hdparm.conf
reboot
And see if the issue persists?
I’ve given up on HDD/SSD with DietPi currently. As I posted elsewhere, moving the rootfs to an HDD/SSD (I tried both) caused it to continually disconnect and crash. I also tried it on a Pi3 (where it used to work) as well as the Pi4 I first saw the issues on. I’ve now installed Rasbian Lite and moved the rootfs and it is fine, so it is definitely a DietPi issue. It used to work OK and I like DietPi, but it simply does not work at the moment.
Okay, I just reviewed the code and made some failsafe changes, but there was nothing that would break it on our current RPi image, from what I see.
Just to be sure, the external drive has a dedicated power supply? Does Raspbian have max USB power enabled in config.txt after moving root fs?
So I tried it
- with the Pi4 and an SSD and a genuine Pi4 Power supply
- with the Pi4 and a WD PiDrive powered by the pi4 PS and the Drive by the PiDrive PS
- with the Pi3 and an SSD and a genuine Pi Power supply
- with the Pi3 and a WD PiDrive powered by the PiDrive PS with the split cable (this is the config that last worked with a stretch image).
All configurations stopped responding clearly having lost contact with the rootfs on the external drive.
As I say, a Raspbian Lite image, manually moving the rootfs works flawlessly on the Pi4 with SSD (where I started). No need for quirks or any fiddling with USB power settings.
Can you paste from Raspbian (after successully moving rootfs): cat /boot/{cmdline,config}.txt
pi@raspberrypi:~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 223.6G 0 disk
└─sda1 8:1 0 223.6G 0 part /
mmcblk0 179:0 0 14.9G 0 disk
├─mmcblk0p1 179:1 0 256M 0 part /boot
└─mmcblk0p2 179:2 0 14.6G 0 part
pi@raspberrypi:~ $ cat /boot/{cmdline,config}.txt
console=serial0,115200 console=tty1 root=PARTUUID=20cb7aed-01 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
#dtoverlay=vc4-fkms-v3d
So it works fine in your case without rootdelay=10 which we add to cmdline.txt when moving root to external drive. However besides the delay this should not break boot.
Yes what I have works fine on Raspbian and doesn’t on DietPi in any of the configurations I tried.
It doesn’t break boot - the disk boots fine. Just after running for a while (20 mins or so) the root folder on the SSD appears to become disconnected. If there is an SSH session connected, no commands work, just get an IO error or command not found and the only solution is to remove the power supply.
Nothing in logs.
I wondered about kernel version?
The kernel it the same on Raspbian and DietPi. Probably automated spindown is an issue. Did you try:
rm /etc/hdparm.conf
reboot