Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #228236 > unrolled thread

Problem unplugging a USB drive

Started byMick Ab <recoverymail123890@gmail.com>
First post2020-10-26 13:10 +0100
Last post2020-10-26 22:00 +0100
Articles 8 — 5 participants

Back to article view | Back to linux.debian.user


Contents

  Problem unplugging a USB drive Mick Ab <recoverymail123890@gmail.com> - 2020-10-26 13:10 +0100
    Re: Problem unplugging a USB drive Joe <joe@jretrading.com> - 2020-10-26 13:20 +0100
      Re: Problem unplugging a USB drive Curt <curty@free.fr> - 2020-10-26 15:20 +0100
        Re: Problem unplugging a USB drive David Wright <deblis@lionunicorn.co.uk> - 2020-10-26 16:30 +0100
          Re: Problem unplugging a USB drive Mick Ab <recoverymail123890@gmail.com> - 2020-10-26 18:10 +0100
            Re: Problem unplugging a USB drive Stefan Monnier <monnier@iro.umontreal.ca> - 2020-10-26 21:20 +0100
            Re: Problem unplugging a USB drive David Wright <deblis@lionunicorn.co.uk> - 2020-10-26 21:50 +0100
              Re: Problem unplugging a USB drive Mick Ab <recoverymail123890@gmail.com> - 2020-10-26 22:00 +0100

#228236 — Problem unplugging a USB drive

FromMick Ab <recoverymail123890@gmail.com>
Date2020-10-26 13:10 +0100
SubjectProblem unplugging a USB drive
Message-ID<B49u1-67y-1@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

A USB memory stick has been plugged into a USB 3 port for quite a few days.
The stick was left there after it was discovered that the kernel does not
recognise it (e.g. fdisk - l does not show the stick).

It was decided to unplug the stick. Subsequently the command
cat  /var/log/messages was run and the messages revealed that just before
the stick was unplugged, the kernel suddenly found the stick and
automatically mounted it to /media/usb0. While the stick was being
unplugged, the system performed a 'lazy' unmount from /media/usb0.

The stick was later plugged back into the USB 3 port and the dmesg command
issued. The dmesg messages revealed that the stick was probably corrupted
due to the lazy unmount.

My question is :-

Why did the kernel suddenly find the stick and automatically mount it just
before the stick was unplugged ?

[toc] | [next] | [standalone]


#228238

FromJoe <joe@jretrading.com>
Date2020-10-26 13:20 +0100
Message-ID<B49DJ-6aM-21@gated-at.bofh.it>
In reply to#228236
On Mon, 26 Oct 2020 12:08:11 +0000
Mick Ab <recoverymail123890@gmail.com> wrote:

> A USB memory stick has been plugged into a USB 3 port for quite a few
> days. The stick was left there after it was discovered that the
> kernel does not recognise it (e.g. fdisk - l does not show the stick).
> 
> It was decided to unplug the stick. Subsequently the command
> cat  /var/log/messages was run and the messages revealed that just
> before the stick was unplugged, the kernel suddenly found the stick
> and automatically mounted it to /media/usb0. While the stick was being
> unplugged, the system performed a 'lazy' unmount from /media/usb0.
> 
> The stick was later plugged back into the USB 3 port and the dmesg
> command issued. The dmesg messages revealed that the stick was
> probably corrupted due to the lazy unmount.
> 
> My question is :-
> 
> Why did the kernel suddenly find the stick and automatically mount it
> just before the stick was unplugged ?

When you say 'just before', are you talking milliseconds or minutes?

USB 'plugs' are appalling, and I've known sticks to be unrecognised, but
found after wiggling the device slightly.

-- 
Joe

[toc] | [prev] | [next] | [standalone]


#228242

FromCurt <curty@free.fr>
Date2020-10-26 15:20 +0100
Message-ID<B4bvQ-7iT-5@gated-at.bofh.it>
In reply to#228238
On 2020-10-26, Joe <joe@jretrading.com> wrote:
>
> When you say 'just before', are you talking milliseconds or minutes?
>
> USB 'plugs' are appalling, and I've known sticks to be unrecognised, but
> found after wiggling the device slightly.
>

I have a USB port like that; it's fickle. But I only actually realized
or pinpointed it was the port being fickle (to interpret a certain
semeiology I won't go into here) because David Wright mentioned the
phenomenon in this forum not long ago.

[toc] | [prev] | [next] | [standalone]


#228250

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2020-10-26 16:30 +0100
Message-ID<B4cBA-7VW-1@gated-at.bofh.it>
In reply to#228242
On Mon 26 Oct 2020 at 13:56:36 (+0000), Curt wrote:
> On 2020-10-26, Joe <joe@jretrading.com> wrote:
> >
> > When you say 'just before', are you talking milliseconds or minutes?
> >
> > USB 'plugs' are appalling, and I've known sticks to be unrecognised, but
> > found after wiggling the device slightly.
> >
> 
> I have a USB port like that; it's fickle. But I only actually realized
> or pinpointed it was the port being fickle (to interpret a certain
> semeiology I won't go into here) because David Wright mentioned the
> phenomenon in this forum not long ago.

https://lists.debian.org/debian-user/2020/08/msg00506.html

With caddies, I'd add that things aren't improving at the other end of
the cable. My USB2 caddies have a small connector (I think they're
Mini B) on a 6ft flexible cable at the caddy end. If you hold the
cable a foot away from the caddy and move it side to side, the
miniplug is stable as a rock.

With the newer caddies, their connectors (3.0 Micro B, I believe)
are on a shorter, stiffer cable. Move the cable in the same way,
and the connector rocks from side to side, eventually generating
errors (or falling out).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]


#228255

FromMick Ab <recoverymail123890@gmail.com>
Date2020-10-26 18:10 +0100
Message-ID<B4eam-vR-17@gated-at.bofh.it>
In reply to#228250

[Multipart message — attachments visible in raw view] — view raw

Why did the kernel automatically mount the stick ?

Usually mounts have to be made manually for this port.
On 26 Oct 2020 15:24, "David Wright" <deblis@lionunicorn.co.uk> wrote:

> On Mon 26 Oct 2020 at 13:56:36 (+0000), Curt wrote:
> > On 2020-10-26, Joe <joe@jretrading.com> wrote:
> > >
> > > When you say 'just before', are you talking milliseconds or minutes?
> > >
> > > USB 'plugs' are appalling, and I've known sticks to be unrecognised,
> but
> > > found after wiggling the device slightly.
> > >
> >
> > I have a USB port like that; it's fickle. But I only actually realized
> > or pinpointed it was the port being fickle (to interpret a certain
> > semeiology I won't go into here) because David Wright mentioned the
> > phenomenon in this forum not long ago.
>
> https://lists.debian.org/debian-user/2020/08/msg00506.html
>
> With caddies, I'd add that things aren't improving at the other end of
> the cable. My USB2 caddies have a small connector (I think they're
> Mini B) on a 6ft flexible cable at the caddy end. If you hold the
> cable a foot away from the caddy and move it side to side, the
> miniplug is stable as a rock.
>
> With the newer caddies, their connectors (3.0 Micro B, I believe)
> are on a shorter, stiffer cable. Move the cable in the same way,
> and the connector rocks from side to side, eventually generating
> errors (or falling out).
>
> Cheers,
> David.
>
>

[toc] | [prev] | [next] | [standalone]


#228260

FromStefan Monnier <monnier@iro.umontreal.ca>
Date2020-10-26 21:20 +0100
Message-ID<B4h8d-2hQ-3@gated-at.bofh.it>
In reply to#228255
> Why did the kernel automatically mount the stick ?

FWIW, I'm pretty sure the kernel didn't: the only partition mounted
directly by the kernel is the root partition when booting.  After that,
partitions are only booted upon explicit request from some program
(could be something part of udev or systemd or anything else).


        Stefan

[toc] | [prev] | [next] | [standalone]


#228261

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2020-10-26 21:50 +0100
Message-ID<B4hBf-2rz-5@gated-at.bofh.it>
In reply to#228255
On Mon 26 Oct 2020 at 17:09:17 (+0000), Mick Ab wrote:
> > > > > […] the messages revealed that just before
> > > > > the stick was unplugged, the kernel suddenly found the stick and
> > > > > automatically mounted it to /media/usb0.

> Why did the kernel automatically mount the stick ?

>From the mount point chosen, I would guess that it was mounted by
some kind of automounter. (My guess is based on conversations here:
I don't run either DE or an automounter.)

> > > > > While the stick was being
> > > > > unplugged, the system performed a 'lazy' unmount from /media/usb0.

That seems logical for a automounter. When you pull the stick,
it prevents umount from failing because the device was busy.
Assuming you weren't writing to the stick at the time, the
amount of corruption that would occur is likely to be influenced
by the filesystem on it. In my experience with vfat, it's likely
to be as little setting the dirty bit.

> > > > > The stick was later plugged back into the USB 3 port and the dmesg command
> > > > > issued. The dmesg messages revealed that the stick was probably corrupted
> > > > > due to the lazy unmount.

I didn't know that dmesg was that precise in diagnosis. I frequently see
"Volume was not properly unmounted. Some data may be corrupt. Please run fsck."
AIUI that's just the dirty bit speaking.

I've seen worse, for example:

[47557.370417] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[47689.952378] FAT-fs (sdb1): error, fat_get_cluster: invalid start cluster (i_pos 0, start cdc8429e)
[47689.952384] FAT-fs (sdb1): Filesystem has been set read-only
[47689.952491] FAT-fs (sdb1): error, fat_get_cluster: invalid start cluster (i_pos 0, start 2c494d0f)

In this case, the stick was on its way out.

The flakiness of your usb ports might have some influence on disk
corruption in any case. Do you have   errors=remount-ro   is the
appropriate place(s)? (fstab, in my configuration.)

> Usually mounts have to be made manually for this port.

Even if I knew how your machine was configured, I'm not sure I would
know the answer. When I see people using an automounter, but mounting
on a mount point of their choosing, I've always presumed that they're
using a bind mount (assuming that they haven't configured rules for
their automounter).

I generate only mountpoints automatically with my own rules, but
I mount and unmount devices manually.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]


#228263

FromMick Ab <recoverymail123890@gmail.com>
Date2020-10-26 22:00 +0100
Message-ID<B4hKV-2uW-1@gated-at.bofh.it>
In reply to#228261

[Multipart message — attachments visible in raw view] — view raw

The automatic mount and unmount were performed by the USB mount system.

The stick was newish and hasn't been previously written to.

The stick's filesystem is FAT32, in common with most USB sticks.

The auto mount command included the -tvfat option.

I got the message that you frequently see, so it looks as though the stick
just has a dirty bit.
On 26 Oct 2020 20:45, "David Wright" <deblis@lionunicorn.co.uk> wrote:

> On Mon 26 Oct 2020 at 17:09:17 (+0000), Mick Ab wrote:
> > > > > > […] the messages revealed that just before
> > > > > > the stick was unplugged, the kernel suddenly found the stick and
> > > > > > automatically mounted it to /media/usb0.
>
> > Why did the kernel automatically mount the stick ?
>
> >From the mount point chosen, I would guess that it was mounted by
> some kind of automounter. (My guess is based on conversations here:
> I don't run either DE or an automounter.)
>
> > > > > > While the stick was being
> > > > > > unplugged, the system performed a 'lazy' unmount from
> /media/usb0.
>
> That seems logical for a automounter. When you pull the stick,
> it prevents umount from failing because the device was busy.
> Assuming you weren't writing to the stick at the time, the
> amount of corruption that would occur is likely to be influenced
> by the filesystem on it. In my experience with vfat, it's likely
> to be as little setting the dirty bit.
>
> > > > > > The stick was later plugged back into the USB 3 port and the
> dmesg command
> > > > > > issued. The dmesg messages revealed that the stick was probably
> corrupted
> > > > > > due to the lazy unmount.
>
> I didn't know that dmesg was that precise in diagnosis. I frequently see
> "Volume was not properly unmounted. Some data may be corrupt. Please run
> fsck."
> AIUI that's just the dirty bit speaking.
>
> I've seen worse, for example:
>
> [47557.370417] FAT-fs (sdb1): Volume was not properly unmounted. Some data
> may be corrupt. Please run fsck.
> [47689.952378] FAT-fs (sdb1): error, fat_get_cluster: invalid start
> cluster (i_pos 0, start cdc8429e)
> [47689.952384] FAT-fs (sdb1): Filesystem has been set read-only
> [47689.952491] FAT-fs (sdb1): error, fat_get_cluster: invalid start
> cluster (i_pos 0, start 2c494d0f)
>
> In this case, the stick was on its way out.
>
> The flakiness of your usb ports might have some influence on disk
> corruption in any case. Do you have   errors=remount-ro   is the
> appropriate place(s)? (fstab, in my configuration.)
>
> > Usually mounts have to be made manually for this port.
>
> Even if I knew how your machine was configured, I'm not sure I would
> know the answer. When I see people using an automounter, but mounting
> on a mount point of their choosing, I've always presumed that they're
> using a bind mount (assuming that they haven't configured rules for
> their automounter).
>
> I generate only mountpoints automatically with my own rules, but
> I mount and unmount devices manually.
>
> Cheers,
> David.
>
>

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.user


csiph-web