[SOLVED] usb thumb drive set up to mount at startup but fails over time

Tem2 · 03-25-2022, 12:48 PM

I use the below six step procedure to mount my usb thumb drive at startup. It works fine, until it stops working for no apparent reason. When it fails, attempts to mount the drive with Disks eventually are successful, but it takes a long time before it mounts.

I've tried adding the drive to the /etc/fstab file, but I was having trouble with that, so I went to this startup alternative. I don't recall what the problem was with the fstab.

This procedure works for days and days, but then for some reason it just doesn't work anymore. Where can I find evidence for such a failure? Is there a log I can look at? Should I be rebooting my operating system more frequently? Sometimes I don't reboot for many days.

This thumb drive is used for Back-In-Time scheduled backups, which run daily in the middle of the night. Sometimes the backup runs and then at some point after gets "unmounted." Sometimes the backup doesn't run because the drive was already "unmounted."

What could be causing such behavior? Why does the drive all of a sudden get into a state where it will mount but only after a long time? The drive is fairly new.

1. create script and make it executable... save in /usr/bin

Code:

/usr/bin/mounter.sh:

#!/bin/bash                                                                    

mount /dev/sdb1 /media/root/0cf08a6e-ba27-4c52-8681-4e5819c60f84

2. save the following in /etc/systemd/system/mounter.service

Code:

[Unit]
Description=Example systemd service.

[Service]
Type=simple
ExecStart=/bin/bash /usr/bin/mounter.sh

[Install]
WantedBy=multi-user.target

3. make number 2. executable...

Code:

sudo chmod 644 /etc/systemd/system/mounter.service

4. start the service..

Code:

sudo systemctl start mounter

5. check status of service...

Code:

sudo systemctl status mounter

6. enable service for startup...

Code:

sudo systemctl enable mounter

michaelk · 03-26-2022, 07:02 AM

Quote:

What could be causing such behavior? Why does the drive all of a sudden get into a state where it will mount but only after a long time? The drive is fairly new.

Basically when the drive not cleanly unmounted, at next mount the journal is replayed which "finishes" any pending writes. I assume this is causing the delay.

Check the output of the dmesg command and syslog. Does the system hibernate?

jailbait · 03-26-2022, 01:20 PM

Quote:

Originally Posted by Tem2

Code:

/usr/bin/mounter.sh:

#!/bin/bash                                                                    

mount /dev/sdb1 /media/root/0cf08a6e-ba27-4c52-8681-4e5819c60f84

The device name and partition number can vary depending on what you attach to a USB port and in what order. I suggest that you label the thumb drive first partition Cicero and use this command to mount it.

Code:

/usr/bin/mounter.sh:

#!/bin/bash                                                                    

mount -t ext4 -L Cicero /media/root/0cf08a6e-ba27-4c52-8681-4e5819c60f84

You can also get a meaningful error message by using this code:

Code:

# Mount the usb hard drive
if ! (mount -t ext4 -L Cicero /media/root/0cf08a6e-ba27-4c52-8681-4e5819c60f84);
then
echo "mount failed for Cicero partition on usb thumb drive"
exit
fi

To expand on michaelk's reply. When systemd has one its subtasks stumble systemd will start a 90 second wait to see if the task in trouble manages to correct itself. You should get an error message and a minute and a half countdown if systemd is doing this.

Tem2 · 03-26-2022, 09:40 PM

Quote:

Originally Posted by michaelk

Basically when the drive not cleanly unmounted, at next mount the journal is replayed which "finishes" any pending writes. I assume this is causing the delay.

Check the output of the dmesg command and syslog. Does the system hibernate?

The system does not hibernate. Everything seems ok except when I launch Back-In-Time it can't find the usb drive.

Forgive me for asking, but what should I grep in the dmesg command to find related errors?

Tem2 · 03-26-2022, 09:45 PM

Quote:

Originally Posted by jailbait

The device name and partition number can vary depending on what you attach to a USB port and in what order. I suggest that you label the thumb drive first partition Cicero and use this command to mount it.

/usr/bin/mounter.sh:

Code:

#!/bin/bash                                                                    

mount -t ext4 -L Cicero /media/root/0cf08a6e-ba27-4c52-8681-4e5819c60f84

Ok. Thanks for the advice!

ondoho · 03-27-2022, 04:39 AM

Quote:

Originally Posted by Tem2

This thumb drive is used for Back-In-Time scheduled backups, which run daily in the middle of the night. Sometimes the backup runs and then at some point after gets "unmounted." Sometimes the backup doesn't run because the drive was already "unmounted."

Wouldn't it be more feasible to leave the drive unmounted, and only mount when required?

If you do wnat to mount it at startup - and I'm not 100% sure about these systemd things, but shouldn't
WantedBy=multi-user.target
be
WantedBy=local-fs.target
instead?

Also you might have to specify a Requires= or After= in your [Unit] section, see 'man systemd.unit'.

michaelk · 03-27-2022, 08:49 AM

Along those lines I might look at using systemd automount or autofs to automatically the drive is accessed. It will automatically unmount after an idle timeout period. Basically more of a workaround then a solution.

As a start I would search for the drive's device ID.

Tem2 · 03-27-2022, 09:16 PM

Quote:

Originally Posted by michaelk

Basically when the drive not cleanly unmounted, at next mount the journal is replayed which "finishes" any pending writes. I assume this is causing the delay.

Check the output of the dmesg command and syslog. Does the system hibernate?

Code:

SYSLOG OUTPUT:

Mar 27 19:03:19 master-Latitude-E6440 kernel: [29833.035143] EXT4-fs error (device sdb1): __ext4_find_entry:1611: inode #2: comm python3: reading directory lblock 0
Mar 27 19:03:25 master-Latitude-E6440 kernel: [29839.140503] Aborting journal on device sdb1-8.
Mar 27 19:03:25 master-Latitude-E6440 kernel: [29839.140516] Buffer I/O error on dev sdb1, logical block 14712832, lost sync page write
Mar 27 19:03:25 master-Latitude-E6440 kernel: [29839.140522] JBD2: Error -5 detected when updating journal superblock for sdb1-8.

DMESG OUTPUT:

[29833.035143] EXT4-fs error (device sdb1): __ext4_find_entry:1611: inode #2: comm python3: reading directory lblock 0
[29839.140503] Aborting journal on device sdb1-8.
[29839.140516] Buffer I/O error on dev sdb1, logical block 14712832, lost sync page write
[29839.140522] JBD2: Error -5 detected when updating journal superblock for sdb1-8.

This doesn't look good. Does it mean my usb drive is toast?

This error occurred randomly from my perspective. I wasn't using the drive at the time it failed.

SlowCoder · 03-27-2022, 10:03 PM

I have some old USB2 sticks that take forever to write to. (they work, so no sense in wasting). I find that although my gui shows the write is complete, it's actually cached and waiting write. It can take 10-15 minutes to write a 2g file, and since there's not a visual indicator, I execute "sync" and wait for it to return to verify it's done. No problems.

Side: While it's not recommended to run sync on a server, where intensive cached IO is common, I'm doing this on my personal laptop, where this is not an issue.

ondoho · 03-28-2022, 12:35 AM

Quote:

Originally Posted by Tem2

This doesn't look good. Does it mean my usb drive is toast?

This error occurred randomly from my perspective. I wasn't using the drive at the time it failed.

It looks like the same error at the same time? Meaning, it happened only once, not twice. If it happened only once I wouldn't worry just yet, it could have been some random fluke.

But why python?
And was it mounted at that time?

I have an external drive and I get a (different) error message about it after each boot, but that's when it's not mounted.

Tem2 · 03-28-2022, 12:51 PM

Quote:

Originally Posted by ondoho

It looks like the same error at the same time? Meaning, it happened only once, not twice. If it happened only once I wouldn't worry just yet, it could have been some random fluke.

But why python?
And was it mounted at that time?

I have an external drive and I get a (different) error message about it after each boot, but that's when it's not mounted.

The drive was mounted at the time, and I have no idea why python is involved.

Right now I've been running the following command against the drive:

Code:

sudo badblocks -w -s -o error.log /dev/sdc

It's been running with no errors for 15 and a half hours.

Tem2 · 03-29-2022, 02:16 PM

I ran badblocks against the drive for 17 hours and got no errors.

Then I ran f3write for less than 15 minutes and it failed with errors.

I think the drive has issues.

Based on that, I'll mark this thread as "solved."