user_data on external drive mounted to a USB hub doesn't seem to mount at startup.

[TDuffinNTU]

Creating a bug report/issue

Required Information

• DietPi version | 8.22.3 branch master
• Distro version | bullseye 0
• Kernel version | Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
• SBC model | Rpi4B
• Power supply used | 5v1a
• SD card used | sandisk ultra

Additional Information (if applicable)

Steps to reproduce

1. Move dietpi_userdata to external SSD
2. unmount and connect said SSD to powered USB hub
3. remount ssd
4. reboot

Expected behaviour

Boots normally

Actual behaviour

Because userdata isn't mounted, dietpi seems to fail to initialise properly. I can't use the terminal over ssh because it gets stuck at the Debian terminal MOTD.

Extra details

This is my external hub. The switches for the USB sockets remember their state after power cycles so they should be working fine:

https://www.amazon.co.uk/dp/B08GKGXZKM?psc=1&ref=ppx_yo2ov_dt_b_product_details

[TDuffinNTU]

I think this might just be a configuration thing but it's hard to diagnose since userdata not being available at system boot seems to cause dietpi to, to put it lightly, crap itself :'D

I would just keep dietpi_userdata on the SD card but since moving nextcloud's data directory is far too involved for me I've preferred to move the userdata dir.

[MichaIng]

How did you unmount and remount the SSD? Verify that /etc/fstab still contains the related entry. It is based on the filesystem's UUID, so it does not matter which USB port the drive is mounted to, whether it is attached via HUB, directly or even another storage device/connector. Safest is probably to:

1. Move dietpi_userdata to external SSD
2. poweroff
3. connect said SSD to powered USB hub
4. Boot up again

If the drive is indeed not mounted, please check whether it is detected at all:

lsusb
lsblk

[TDuffinNTU]

I'll try that when i get back :)

Thing is, when I moved it back to the hub and powered it on, the drives did get redetected and mounted fine. I think my problem is more that for some reason the mount process occurs after dietpi looks for dietpi_userdata and hangs/errors out before my hub can mount the drives.

[MichaIng]

Because userdata isn't mounted, dietpi seems to fail to initialise properly. I can't use the terminal over ssh because it gets stuck at the Debian terminal MOTD.

Do you really mean the "Debian" MOTD, that is shown on login but before the DietPi banner, or do you mean the DietPi banner? And in case, do you have the DietPi userdata free space option enabled, and does it help to disable it? Otherwise there is actually nothing accessing DietPi userdata (aside of services, the Nextcloud database etc, but not on login). But if something does, it would trigger systemd automount, which indeed hangs the console until 90 seconds timeout of until the drive succeeds to mount.

[luisimasd]

Somehow similar issue here:

Platform RPI Zero 2w

Plugged 1TB usb sitck on any USB port with a micro usb adapter (which is confirmed to work as well the usb stick) Nothing changes on the system.

# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mmcblk0     179:0    0 117.8G  0 disk
├─mmcblk0p1 179:1    0   128M  0 part /boot
└─mmcblk0p2 179:2    0 117.6G  0 part /

# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

# lsmod
Module                  Size  Used by
binfmt_misc            20480  1
brcmfmac              331776  0
brcmutil               24576  1 brcmfmac
cfg80211              925696  1 brcmfmac
rfkill                 32768  4 cfg80211
raspberrypi_hwmon      16384  0
i2c_bcm2835            16384  0
uio_pdrv_genirq        16384  0
uio                    24576  1 uio_pdrv_genirq
i2c_dev                20480  0
i2c_bcm2708            16384  0
fuse                  135168  1
dm_mod                139264  0
ip_tables              32768  0
x_tables               53248  1 ip_tables
ipv6                  557056  40

# uname -a
Linux pichiserver1 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux

# cat /etc/debian_version
12.4

# 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/"

I tested the same release on a virtualbox and it detects the usb but also, the usb modules are loaded as expected (usb_storage, usbcore....)

Any idea?

[TDuffinNTU]

For my particular case, I've not had issues since (to the point where the most recently reply I'd forgot I left this open!)

I think it might have had something to do with re-mounting the drive with dietpi-drivemanager just to refresh the fstab listing. Memory is a bit hazy and I'm being hammered by COVID rn, though!

[Joulinar]

Probably challenge is with the micro usb adapter, as the drive is not even detected by the kernel.

[luisimasd]

I tried 2 different types of adapters, and it works. I mean, it works if I plug a physical keyboard with each of them, It should work with the USB. In particular, one of the usb adapters only connect pins, it doesn't do anything else. I believe it can be related with voltage? I dont know. I will install the latest one or even the same version on another pi zero 2 with a new sd card and I will check again.

[Joulinar]

you can try watching dmesg while connecting the adapter, to see if it is even detected or not.

[luisimasd]

@Joulinar I did, I always check that, aside lsusb, lsblk and lsmod... but no, no movement under "dmesg", which I expected it as not usb modules are loaded either.

[Joulinar]

did you try RPi OS? Does this detect your USB adapter?

[luisimasd]

I found the reason. The culprit is this adapter i was using. Whatever i plugged on the micro usb port was captured by the usb type a port and presented to the router, so the pi zero didn't see it.