1

I just upgraded my server to Debian Buster (Raspbian). However, when I now boot, my USB hard drives aren't mounting. I see something like the following on my splash screen:

mount: /media/PiHDD: can't find UUID=<string>

If I manually sudo mount -a, then all hard drives are mounted

The following is /etc/fstab:

proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults          0       0
/dev/mmcblk0p2  /               ext4    defaults,noatime  0       0
UUID=<string> /media/PiHDD ext4 defaults,noatime 0 0
UUID=<string2> /media/PiHDD2 ext4 defaults,noatime 0 0
...

which worked fine before the update to Buster.

I've also tried identifying the hard drives using PARTUUID or LABEL, based on the output of blkid, but these also fail on boot with can't find LABEL, etc.

I'm not using systemd (PID 1 is init, and file /sbin/init gives an executable). /sbin/init --version gives SysV init version: 2.93. I've updated to the latest (testing) kernel 4.19.57-v7+.

On boot, I think my system is seeing the USB devices before it tries to mount them. I can see New USB device found before the mounting fails. I also see Attached SCSI disk after the device is found, but I'm not sure if it's before or after the failed mounting. This is all in /var/log/syslog, but for some reason the mount… can't find UUID errors that I see on boot are not in any file in /var/log.

How can I get my system to automatically mount my USB hard drives on boot?

Here are the contents of /etc/inittab.

# /etc/inittab: init(8) configuration.
# $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $

# The default runlevel.
id:2:initdefault:

# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS

# What to do in single-user mode.
~~:S:wait:/sbin/sulogin

# /etc/init.d executes the S and K scripts upon change
# of runlevel.
#
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Normally not reached, but fallthrough in case of emergency.
z6:6:respawn:/sbin/sulogin

# What to do when CTRL-ALT-DEL is pressed.
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

# Action on special keypress (ALT-UpArrow).
#kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work."

# What to do when the power fails/returns.
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop

# /sbin/getty invocations for the runlevels.
#
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
#
# Format:
#  <id>:<runlevels>:<action>:<process>
#
# Note that on most Debian systems tty7 is used by the X Window System,
# so if you want to add more getty's go ahead but skip tty7 if you run X.
#
1:2345:respawn:/sbin/getty --noclear 38400 tty1 
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

# Example how to put a getty on a serial line (for a terminal)
#
#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100

# Example how to put a getty on a modem line.
#
#T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3


#Spawn a getty on Raspberry Pi serial line
T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
  • It might be a boot problem, your initrd's fstab may not have the right UUID and that may be the reason for the drive not mounting at boot time but mounting without a problem once the system has finished booting. – YoMismo Jul 10 at 11:15
  • @YoMismo I'm not sure what initrd is, but I tried to (m)locate it, and I could mostly see it in /lib/systemd. Am I looking at the right thing? Also, AFAIK I only specified the UUID in the one place. Finally, given that I get slightly different errors if I specify PARTUUID or LABEL, I'm assuming that only the one modified file (/etc/fstab) is being read at boot. – Sparhawk Jul 10 at 11:28
  • Initrd should be in your root partition most probably linked to your /boot directory. It contains the basics for the system to boot, one of those basics is a /etc/fstab. Maybe that is the problem or maybe @sam68 answer is the way to go. To check initrd contents check this guide: access.redhat.com/solutions/24029 you'll basically need to zcat /initrd.img|cpio -idmv to uncompress your initrd. – YoMismo Jul 10 at 14:36
  • @YoMismo Hmm, I don't have any /boot/init* at all. I tried to locate initrd, but partial matches are only in /lib/systemd/system/ and /usr/{lib,share}/. – Sparhawk Jul 11 at 5:56
  • It could also be called initramfs, check /boot – YoMismo Jul 11 at 7:24
0

With sysvinit you have three early bootup scripts: "sysinit", "bootwait" and "boot" (via /etc/inittab). They mount devices and load modules etc BEFORE runlevels are started.

Root is already mounted, /proc is the first one needed. /sys probably too.

Try to mount the UUID devices a bit LATER. That means you have to split up your mount -a a bit, and distribute the (no)auto options in /etc/fstab differently. /proc and an external storage don't really belong in the same mount step.

Think of systemd and all these "dependencies".

It must be some module (driver) that is needed before that UUID-USB device can be mounted.

(If you use initrd it gets a bit complicated. I know how it can hang waiting for a "by-label" device)


To change you would have to look at /etc/inittab. Here are some lines from mine:

...
# Simple "old Linux" inittab from manpage:
# one (default) runlevel, 4 gettys, one bootwait rc-script
id:2:initdefault:

# sysinit/boot-scripts, they run first
#si::sysinit:/etc/sysinit.init 

bw::bootwait:/etc/boot.init

# b::boot:/etc/rc
...

And this is /etc/boot.init (the "bootwait" script):

#! /bin/bash
# Boot script, as defined in sysv inittab

echo  "$0: starting...."

mountpoint /proc || mount -v -t proc  Proc /proc   
mountpoint /sys || mount -v -t sysfs Sys  /sys 

# root ro -> rw ?
# fed is ro, arch rw...
mount -o remount /

# Modules: for keyboard
modprobe -a xhci-pci usbhid hid-generic         # i2c-hid 

echo 0 > /sys/devices/virtual/graphics/fbcon/cursor_blink

echo "...$0 done"

This is all I need when I boot with sysvinit. Essential part was the keyboard module! Nothing can work if your keybord is dead! The mounting of proc and sys is a bit luxurious - just note how I mount these two virtual devices manually. I had tried to use /etc/fstab, but it didn't make much sense. The minimal command is just mount -t proc none /proc

The mountpoint ... || mount command I needed because a systemd initrd already comes with proc, sys and run (tmpfs) mounted. And I didn't want to see the "already mounted" error, but a correct output. This is not systemd, but with a simple script you can get the basics done.

  • Thank you for the answer. This makes some sense. However, to actually solve my issue, what specifically should I change? – Sparhawk Jul 10 at 10:52
  • I would first LOOK at /etc/inittab, and the scripts (files) it defines. If you can confirm one early "mount -a", and if you don't mind modifying the bootup procedure, I would try using mount twice, as explained. mount proc, modprobe, mount /media/xxx. It depends on the overall situation. But if you don't understand what I mean, then this might be the wrong solution. – user359065 Jul 10 at 11:03
  • If you can add /etc/inittab and then these scripts I could easily tell if my idea works. The lines that define the 3 scripts contain the names I mentioned ("bootwait" etc.). – user359065 Jul 10 at 11:06
  • I've added the contents of /etc/inittab to the question. I'm not 100% sure what you mean, but are you talking about grepping bootwait in this file? If so, I can't find it. – Sparhawk Jul 10 at 11:20
  • I was talking about looking at...so it is "sysinit" with the script /etc/init.d/rcS. The first things happen there. If it is not here then I have to give up because then it will be in the runlevel specific scripts. Or just /etc/init.d/rc plus an argument? – user359065 Jul 10 at 11:45
0

I looks like SysV is now poorly maintained. I moved to systemd and without any configuration change, my drives are now mounted on boot as expected.

FWIW on Debian/Raspbian, I just did sudo apt-get purge sysvinit-core, which also automatically installed libnss-systemd and systemd-sysv.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.