Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #228236 > unrolled thread
| Started by | Mick Ab <recoverymail123890@gmail.com> |
|---|---|
| First post | 2020-10-26 13:10 +0100 |
| Last post | 2020-10-26 22:00 +0100 |
| Articles | 8 — 5 participants |
Back to article view | Back to linux.debian.user
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
| From | Mick Ab <recoverymail123890@gmail.com> |
|---|---|
| Date | 2020-10-26 13:10 +0100 |
| Subject | Problem 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]
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2020-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]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2020-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]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2020-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]
| From | Mick Ab <recoverymail123890@gmail.com> |
|---|---|
| Date | 2020-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]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2020-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]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2020-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]
| From | Mick Ab <recoverymail123890@gmail.com> |
|---|---|
| Date | 2020-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