From Newsgroup: alt.os.linux.mint

Hi all. I can't see what's up here. Linux Mint 22.2.


Normally, I plug in a usb stick and sundry mount points appear for the vartious partitions.

However, I have a freshly-formatted usb stick - msdos and a single fat32 partition, which shows up on the system but doesn't mount.

When I insert the device, I get the appended stuff in syslog; it shows
the device being detected.

It appears in /dev (label MUSIC in this case):

ls -l /dev/disk/by-label/

total 0
lrwxrwxrwx 1 root root 10 Aug 4 06:29 disk4 -> ../../sda5
lrwxrwxrwx 1 root root 10 Aug 4 06:29 diskb -> ../../sdb1
lrwxrwxrwx 1 root root 15 Aug 4 06:29 home2 -> ../../nvme0n1p4
lrwxrwxrwx 1 root root 10 Aug 4 14:43 MUSIC -> ../../sdc1

I can mount it with 'sudo mount.....'

And also:
~> udisksctl mount -b /dev/sdc1
Mounted /dev/sdc1 at /media/mike/MUSIC

which is what I want to happen, as it usually does, automatically.

It mounts just as expected on my laptop though, iirc the same version of
mint.


I'm stumped - can anyone help please? Thanks.



=====
syslog contents:

2026-08-04T14:42:59.786624+01:00 spock kernel: usb 1-2: new high-speed
USB device number 14 using xhci_hcd
2026-08-04T14:42:59.917621+01:00 spock kernel: usb 1-2: New USB device
found, idVendor=05dc, idProduct=a720, bcdDevice=11.00 2026-08-04T14:42:59.917644+01:00 spock kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
2026-08-04T14:42:59.917647+01:00 spock kernel: usb 1-2: Product: Gizmo! 2026-08-04T14:42:59.917651+01:00 spock kernel: usb 1-2: Manufacturer:
Crucial
2026-08-04T14:42:59.917654+01:00 spock kernel: usb 1-2: SerialNumber: 400B2209082842191007
2026-08-04T14:42:59.919611+01:00 spock kernel: usb-storage 1-2:1.0: USB
Mass Storage device detected
2026-08-04T14:42:59.919634+01:00 spock kernel: scsi host8: usb-storage
1-2:1.0
2026-08-04T14:42:59.932482+01:00 spock mtp-probe: checking bus 1, device
14: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2" 2026-08-04T14:42:59.932812+01:00 spock mtp-probe: bus: 1, device: 14 was
not an MTP device
2026-08-04T14:42:59.967108+01:00 spock mtp-probe: checking bus 1, device
14: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2" 2026-08-04T14:42:59.967217+01:00 spock mtp-probe: bus: 1, device: 14 was
not an MTP device
2026-08-04T14:43:00.932523+01:00 spock kernel: scsi 8:0:0:0:
Direct-Access Crucial Gizmo! 1100 PQ: 0 ANSI: 0 CCS 2026-08-04T14:43:00.932535+01:00 spock kernel: sd 8:0:0:0: Attached scsi generic sg3 type 0
2026-08-04T14:43:00.960513+01:00 spock kernel: sd 8:0:0:0: [sdc] 1966080 512-byte logical blocks: (1.01 GB/960 MiB)
2026-08-04T14:43:00.960517+01:00 spock kernel: sd 8:0:0:0: [sdc] Write
Protect is off
2026-08-04T14:43:00.960517+01:00 spock kernel: sd 8:0:0:0: [sdc] Mode
Sense: 43 00 00 00
2026-08-04T14:43:00.961508+01:00 spock kernel: sd 8:0:0:0: [sdc] No
Caching mode page found
2026-08-04T14:43:00.961510+01:00 spock kernel: sd 8:0:0:0: [sdc]
Assuming drive cache: write through
2026-08-04T14:43:00.964507+01:00 spock kernel: sdc: sdc1 2026-08-04T14:43:00.964509+01:00 spock kernel: sd 8:0:0:0: [sdc]
Attached SCSI removable disk
--
Mike Scott
Harlow, England

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Tue, 8/4/2026 9:55 AM, Mike Scott wrote:

Hi all. I can't see what's up here. Linux Mint 22.2.

Normally, I plug in a usb stick and sundry mount points appear for the vartious partitions.

However, I have a freshly-formatted usb stick - msdos and a single fat32 partition, which shows up on the system but doesn't mount.

When I insert the device, I get the appended stuff in syslog; it shows the device being detected.

It appears in /dev (label MUSIC in this case):

ls -l /dev/disk/by-label/

total 0
lrwxrwxrwx 1 root root 10 Aug-a 4 06:29 disk4 -> ../../sda5
lrwxrwxrwx 1 root root 10 Aug-a 4 06:29 diskb -> ../../sdb1
lrwxrwxrwx 1 root root 15 Aug-a 4 06:29 home2 -> ../../nvme0n1p4
lrwxrwxrwx 1 root root 10 Aug-a 4 14:43 MUSIC -> ../../sdc1

I can mount it with 'sudo mount.....'

And also:

udisksctl mount -b /dev/sdc1

Mounted /dev/sdc1 at /media/mike/MUSIC

which is what I want to happen, as it usually does, automatically.

It mounts just as expected on my laptop though, iirc the same version of mint.

I'm stumped - can anyone help please? Thanks.

=====
syslog contents:

2026-08-04T14:42:59.786624+01:00 spock kernel: usb 1-2: new high-speed USB device number 14 using xhci_hcd
2026-08-04T14:42:59.917621+01:00 spock kernel: usb 1-2: New USB device found, idVendor=05dc, idProduct=a720, bcdDevice=11.00
2026-08-04T14:42:59.917644+01:00 spock kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
2026-08-04T14:42:59.917647+01:00 spock kernel: usb 1-2: Product: Gizmo! 2026-08-04T14:42:59.917651+01:00 spock kernel: usb 1-2: Manufacturer: Crucial 2026-08-04T14:42:59.917654+01:00 spock kernel: usb 1-2: SerialNumber: 400B2209082842191007
2026-08-04T14:42:59.919611+01:00 spock kernel: usb-storage 1-2:1.0: USB Mass Storage device detected
2026-08-04T14:42:59.919634+01:00 spock kernel: scsi host8: usb-storage 1-2:1.0
2026-08-04T14:42:59.932482+01:00 spock mtp-probe: checking bus 1, device 14: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2"
2026-08-04T14:42:59.932812+01:00 spock mtp-probe: bus: 1, device: 14 was not an MTP device
2026-08-04T14:42:59.967108+01:00 spock mtp-probe: checking bus 1, device 14: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2"
2026-08-04T14:42:59.967217+01:00 spock mtp-probe: bus: 1, device: 14 was not an MTP device
2026-08-04T14:43:00.932523+01:00 spock kernel: scsi 8:0:0:0: Direct-Access-a-a-a-a Crucial-a Gizmo!-a-a-a-a-a-a-a-a-a-a 1100 PQ: 0 ANSI: 0 CCS
2026-08-04T14:43:00.932535+01:00 spock kernel: sd 8:0:0:0: Attached scsi generic sg3 type 0
2026-08-04T14:43:00.960513+01:00 spock kernel: sd 8:0:0:0: [sdc] 1966080 512-byte logical blocks: (1.01 GB/960 MiB)
2026-08-04T14:43:00.960517+01:00 spock kernel: sd 8:0:0:0: [sdc] Write Protect is off
2026-08-04T14:43:00.960517+01:00 spock kernel: sd 8:0:0:0: [sdc] Mode Sense: 43 00 00 00
2026-08-04T14:43:00.961508+01:00 spock kernel: sd 8:0:0:0: [sdc] No Caching mode page found
2026-08-04T14:43:00.961510+01:00 spock kernel: sd 8:0:0:0: [sdc] Assuming drive cache: write through
2026-08-04T14:43:00.964507+01:00 spock kernel:-a sdc: sdc1 2026-08-04T14:43:00.964509+01:00 spock kernel: sd 8:0:0:0: [sdc] Attached SCSI removable disk

It confirms to be a 1GB stick, which could be a single-die USB2 flash stick.

https://usb.userbenchmark.com/SpeedTest/1755/UFD-USB-Flash-Drive

You could try

sudo disktype /dev/sdc

and see if it is FAT12 or FAT16 maybe. Perhaps it was
formatted some time ago. They should all work the
same as "FAT" mounts.

It has a unique serial number.

It may have been plugged into the machine before.

You should also

less /etc/fstab
less /etc/mtab

in the various cases, and see what declarations are involved
or whether there is some entry in /etc/fstab that conflicts
with your desire for the automounter to handle it instead.
The /etc/mtab should show how it is currently mounted
(the mount details).

*******
This is a 16GB stick, with a 1GB partition on it. The stick is
used for FAT16 BIOS update files.

[ 150.910852] usb 5-1: new high-speed USB device number 2 using xhci_hcd
[ 151.100153] usb 5-1: New USB device found, idVendor=0930, idProduct=6545, bcdDevice= 1.00
[ 151.100167] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 151.100172] usb 5-1: Product: DataTraveler G3
[ 151.100175] usb 5-1: Manufacturer: Kingston
[ 151.100179] usb 5-1: SerialNumber: 001372997BD5EBB1B52102BA
[ 151.176242] usb-storage 5-1:1.0: USB Mass Storage device detected
[ 151.176459] scsi host8: usb-storage 5-1:1.0
[ 151.176577] usbcore: registered new interface driver usb-storage
[ 151.178795] usbcore: registered new interface driver uas
[ 152.263602] scsi 8:0:0:0: Direct-Access Kingston DataTraveler G3 PMAP PQ: 0 ANSI: 0 CCS
[ 152.264211] sd 8:0:0:0: Attached scsi generic sg2 type 0
[ 153.697588] sd 8:0:0:0: [sdb] 30481152 512-byte logical blocks: (15.6 GB/14.5 GiB)
[ 153.698231] sd 8:0:0:0: [sdb] Write Protect is off
[ 153.698245] sd 8:0:0:0: [sdb] Mode Sense: 23 00 00 00
[ 153.698451] sd 8:0:0:0: [sdb] No Caching mode page found
[ 153.698463] sd 8:0:0:0: [sdb] Assuming drive cache: write through
[ 153.734525] sdb: sdb1
[ 153.734764] sd 8:0:0:0: [sdb] Attached SCSI removable disk

/etc/mtab

/dev/sdb1 /media/bullwinkle/FLASHMSI vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro 0 0

bullwinkle@GRANADA:~$ sudo disktype /dev/sdb

--- /dev/sdb
Block device, size 14.53 GiB (15606349824 bytes)
DOS/MBR partition map
Partition 1: 1 GiB (1073741824 bytes, 2097152 sectors from 2048)
Type 0x0E (Win95 FAT16 (LBA))
FAT16 file system (hints score 4 of 5)
Volume size 1.000 GiB (1073446912 bytes, 65518 clusters of 16 KiB)

Notice that, compared to your sequence, my output from "dmesg" is
not doing mtp-probe . Yours did not do the "usb-core" thing, whatever
that is.

Paul

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Tue, 8/4/2026 9:55 AM, Mike Scott wrote:

Hi all. I can't see what's up here. Linux Mint 22.2.

Normally, I plug in a usb stick and sundry mount points appear for the vartious partitions.

However, I have a freshly-formatted usb stick - msdos and a single fat32 partition, which shows up on the system but doesn't mount.

When I insert the device, I get the appended stuff in syslog; it shows the device being detected.

It appears in /dev (label MUSIC in this case):

ls -l /dev/disk/by-label/

total 0
lrwxrwxrwx 1 root root 10 Aug-a 4 06:29 disk4 -> ../../sda5
lrwxrwxrwx 1 root root 10 Aug-a 4 06:29 diskb -> ../../sdb1
lrwxrwxrwx 1 root root 15 Aug-a 4 06:29 home2 -> ../../nvme0n1p4
lrwxrwxrwx 1 root root 10 Aug-a 4 14:43 MUSIC -> ../../sdc1

I can mount it with 'sudo mount.....'

And also:

udisksctl mount -b /dev/sdc1

Mounted /dev/sdc1 at /media/mike/MUSIC

which is what I want to happen, as it usually does, automatically.

It mounts just as expected on my laptop though, iirc the same version of mint.

I'm stumped - can anyone help please? Thanks.

=====
syslog contents:

2026-08-04T14:42:59.786624+01:00 spock kernel: usb 1-2: new high-speed USB device number 14 using xhci_hcd
2026-08-04T14:42:59.917621+01:00 spock kernel: usb 1-2: New USB device found, idVendor=05dc, idProduct=a720, bcdDevice=11.00
2026-08-04T14:42:59.917644+01:00 spock kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
2026-08-04T14:42:59.917647+01:00 spock kernel: usb 1-2: Product: Gizmo! 2026-08-04T14:42:59.917651+01:00 spock kernel: usb 1-2: Manufacturer: Crucial 2026-08-04T14:42:59.917654+01:00 spock kernel: usb 1-2: SerialNumber: 400B2209082842191007
2026-08-04T14:42:59.919611+01:00 spock kernel: usb-storage 1-2:1.0: USB Mass Storage device detected
2026-08-04T14:42:59.919634+01:00 spock kernel: scsi host8: usb-storage 1-2:1.0
2026-08-04T14:42:59.932482+01:00 spock mtp-probe: checking bus 1, device 14: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2"
2026-08-04T14:42:59.932812+01:00 spock mtp-probe: bus: 1, device: 14 was not an MTP device
2026-08-04T14:42:59.967108+01:00 spock mtp-probe: checking bus 1, device 14: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2"
2026-08-04T14:42:59.967217+01:00 spock mtp-probe: bus: 1, device: 14 was not an MTP device
2026-08-04T14:43:00.932523+01:00 spock kernel: scsi 8:0:0:0: Direct-Access-a-a-a-a Crucial-a Gizmo!-a-a-a-a-a-a-a-a-a-a 1100 PQ: 0 ANSI: 0 CCS
2026-08-04T14:43:00.932535+01:00 spock kernel: sd 8:0:0:0: Attached scsi generic sg3 type 0
2026-08-04T14:43:00.960513+01:00 spock kernel: sd 8:0:0:0: [sdc] 1966080 512-byte logical blocks: (1.01 GB/960 MiB)
2026-08-04T14:43:00.960517+01:00 spock kernel: sd 8:0:0:0: [sdc] Write Protect is off
2026-08-04T14:43:00.960517+01:00 spock kernel: sd 8:0:0:0: [sdc] Mode Sense: 43 00 00 00
2026-08-04T14:43:00.961508+01:00 spock kernel: sd 8:0:0:0: [sdc] No Caching mode page found
2026-08-04T14:43:00.961510+01:00 spock kernel: sd 8:0:0:0: [sdc] Assuming drive cache: write through
2026-08-04T14:43:00.964507+01:00 spock kernel:-a sdc: sdc1 2026-08-04T14:43:00.964509+01:00 spock kernel: sd 8:0:0:0: [sdc] Attached SCSI removable disk

Here is an analysis from a previous time of failure.

"Can't mount USB flash drives"

https://forums.linuxmint.com/viewtopic.php?t=195934

"The usb-storage.ko module was missing."

Paul

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

hi kids !

first u are saying " format a usb key " !

u must to know usb key...don't like if u touch mutch time
the MBR ! u can erase but don't touch the mrb mutch time !
one time, i loose my data !

and, u CAN NOT mount a drive if the volume gestion is down !

they are a menu in mint to active and desactivat the automatique
mount volume !! in menu param|?tre/disk and m|-dia volume

end, try this to know something about your tiny prob|?me :

systemctl status udisks2

or may be

systemctl unmask udisks2


u'll see if...a...day...all...it's ok to use a usb key with linux ????

think for us.
--
Amicalement,

Frenchy Friendly, & French touch !

german
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On 04/08/2026 17:30, Paul wrote:

On Tue, 8/4/2026 9:55 AM, Mike Scott wrote:

Hi all. I can't see what's up here. Linux Mint 22.2.


Normally, I plug in a usb stick and sundry mount points appear for the vartious partitions.

However, I have a freshly-formatted usb stick - msdos and a single fat32 partition, which shows up on the system but doesn't mount.

.....

I'm stumped - can anyone help please? Thanks.

.....

Here is an analysis from a previous time of failure.

"Can't mount USB flash drives"

https://forums.linuxmint.com/viewtopic.php?t=195934

"The usb-storage.ko module was missing."

Paul

Now that's embarrassing. Well, a bit..... I changed nothing, rebooted
and now all works fine.

So no mis-configuration, no missing modules, valid usb structure. Just
crazy behaviour. Maybe it's the heat :-}

Thanks all.
--
Mike Scott
Harlow, England
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

Mike Scott wrote:

I changed nothing, rebooted and now all works fine.

Sometimes 'replugging' fixes.
--
Mike Easter
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On 04/08/2026 19:42, Mike Easter wrote:

Mike Scott wrote:

I changed nothing, rebooted and now all works fine.

Sometimes 'replugging' fixes.

Not in this case. The stick had been in and out, even completely
reformatted as well. The other odd thing I didn't mention is that while fat-formatted sticks wouldn't mount, an ext4 one would. Anyway, I'll
just have to hope it doesn't happen again.


--
Mike Scott
Harlow, England
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

Le 05/08/2026 |a 06:44, Mike Scott a |-crit-a:

On 04/08/2026 19:42, Mike Easter wrote:

Mike Scott wrote:

I changed nothing, rebooted and now all works fine.

Sometimes 'replugging' fixes.

Not in this case. The stick had been in and out, even completely
reformatted as well. The other odd thing I didn't mention is that while fat-formatted sticks wouldn't mount, an ext4 one would. Anyway, I'll
just have to hope it doesn't happen again.

i remember the spec for fat32 max data is 64Go ! if u use a strange part !?#
--
Amicalement,

Frenchy Friendly, & French touch !

german
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Wed, 8/5/2026 1:20 AM, german newsgroups wrote:

Le 05/08/2026 |a 06:44, Mike Scott a |-crit-a:

On 04/08/2026 19:42, Mike Easter wrote:

Mike Scott wrote:

I changed nothing, rebooted and now all works fine.

Sometimes 'replugging' fixes.

Not in this case. The stick had been in and out, even completely reformatted as well. The other odd thing I didn't mention is that while fat-formatted sticks wouldn't mount, an ext4 one would. Anyway, I'll just have to hope it doesn't happen again.

i remember the spec for fat32 max data is 64Go ! if u use a strange part !?#

Not true. FAT32 is good up to 2TB.

https://en.wikipedia.org/wiki/File_Allocation_Table#FAT32

"Max volume size 2 TB (with 512 byte sectors)"

The larger the volume size, the larger the required clusters are.

The maximum individual file size is still a bit less than 4GB per file.

On Windows, the Ridgecrop Consultants utility can prepare disks that way.
The Microsoft limitation was purely artificial in nature.

https://web.archive.org/web/20210126003213/https://www.howtogeek.com/316977/how-to-format-usb-drives-larger-than-32gb-with-fat32-on-windows/

Don't worry, there are no 2TB disk drives here with FAT32 on them :-)

Paul

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Wed, 5 Aug 2026 01:50:34 -0400, Paul wrote:

Not true. FAT32 is good up to 2TB.

https://en.wikipedia.org/wiki/File_Allocation_Table#FAT32

"Max volume size 2 TB (with 512 byte sectors)"

The larger the volume size, the larger the required clusters are.

The maximum individual file size is still a bit less than 4GB per file.

That is the important takeaway. With more and more isos exceeding 4 GB
older thumb drives need to be reformatted with exfat.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Wed, 5 Aug 2026 05:44:28 +0100, Mike Scott wrote:

The other odd thing I didn't mention is that while fat-formatted
sticks wouldn't mount, an ext4 one would.

I recall you checked syslog for messages, did you try rCLdmesg -TrCY as
well? (That might show different messages, I think.)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Wed, 8/5/2026 5:58 PM, rbowman wrote:

On Wed, 5 Aug 2026 01:50:34 -0400, Paul wrote:

Not true. FAT32 is good up to 2TB.

https://en.wikipedia.org/wiki/File_Allocation_Table#FAT32

"Max volume size 2 TB (with 512 byte sectors)"

The larger the volume size, the larger the required clusters are.

The maximum individual file size is still a bit less than 4GB per file.

That is the important takeaway. With more and more isos exceeding 4 GB
older thumb drives need to be reformatted with exfat.

You can segment outputs from things, and place the resulting
output on FAT32. For example, WINZIP likely had output sizes,
like 1.44MB "things" that fit on floppies, 4GB "things" that
fit on FAT32, and so on. You gathered them all up, and you
could convert them back to a solid archive.

But that does not mean I'm happy doing that. Segmenting
things is still a nuisance and can add extra steps to a workflow.

Paul
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On 06/08/2026 04:38, Lawrence DrCOOliveiro wrote:

On Wed, 5 Aug 2026 05:44:28 +0100, Mike Scott wrote:

The other odd thing I didn't mention is that while fat-formatted
sticks wouldn't mount, an ext4 one would.

I recall you checked syslog for messages, did you try rCLdmesg -TrCY as
well? (That might show different messages, I think.)

No. But as I noted, the problem has gone away with a reboot, so I can't
really try that. I'll bear it in mind.

It is a bit concerning that this sort of thing can happen.
--
Mike Scott
Harlow, England
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Thu, 6 Aug 2026 06:21:48 +0100, Mike Scott wrote:

It is a bit concerning that this sort of thing can happen.

I suspect an issue with loading or reloading the kernel module that
handles the FAT filesystems. Maybe the in-kernel context got its
knickers in a twist or something. ThatrCOs why I thought there might be
a clue in the kernel messages somewhere.

I tend to consider fixing Linux problems with a reboot as a last
resort. ;)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Wed, 5 Aug 2026 01:50:34 -0400
Paul <nospam@needed.invalid> wrote:

On Wed, 8/5/2026 1:20 AM, german newsgroups wrote:

Le 05/08/2026 a 06:44, Mike Scott a ocrita:

On 04/08/2026 19:42, Mike Easter wrote:

Mike Scott wrote:

I changed nothing, rebooted and now all works fine.

Sometimes 'replugging' fixes.

Not in this case. The stick had been in and out, even completely reformatted as well. The other odd thing I didn't mention is that while fat-formatted sticks wouldn't mount, an ext4 one would. Anyway, I'll just have to hope it doesn't happen again.

i remember the spec for fat32 max data is 64Go ! if u use a strange part !?#

Not true. FAT32 is good up to 2TB.

https://en.wikipedia.org/wiki/File_Allocation_Table#FAT32

"Max volume size 2 TB (with 512 byte sectors)"

The larger the volume size, the larger the required clusters are.

The maximum individual file size is still a bit less than 4GB per file.

On Windows, the Ridgecrop Consultants utility can prepare disks that way.
The Microsoft limitation was purely artificial in nature.

https://web.archive.org/web/20210126003213/https://www.howtogeek.com/316977/how-to-format-usb-drives-larger-than-32gb-with-fat32-on-windows/

Thanks. But not a LM thing, I've xposted & set FUs to
alt.comp.os.windows-xp
--
Bah, and indeed Humbug.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On 8/4/26 3:55 PM, Mike Scott wrote:

Hi all. I can't see what's up here. Linux Mint 22.2.

Normally, I plug in a usb stick and sundry mount points appear for the vartious partitions.

However, I have a freshly-formatted usb stick - msdos and a single fat32 partition, which shows up on the system but doesn't mount.

When I insert the device, I get the appended stuff in syslog; it shows
the device being detected.

It appears in /dev (label MUSIC in this case):

ls -l /dev/disk/by-label/

total 0
lrwxrwxrwx 1 root root 10 Aug-a 4 06:29 disk4 -> ../../sda5
lrwxrwxrwx 1 root root 10 Aug-a 4 06:29 diskb -> ../../sdb1
lrwxrwxrwx 1 root root 15 Aug-a 4 06:29 home2 -> ../../nvme0n1p4
lrwxrwxrwx 1 root root 10 Aug-a 4 14:43 MUSIC -> ../../sdc1

I can mount it with 'sudo mount.....'

And also:

udisksctl mount -b /dev/sdc1

Mounted /dev/sdc1 at /media/mike/MUSIC

which is what I want to happen, as it usually does, automatically.

It mounts just as expected on my laptop though, iirc the same version of mint.

I'm stumped - can anyone help please? Thanks.

=====
syslog contents:

2026-08-04T14:42:59.786624+01:00 spock kernel: usb 1-2: new high-speed
USB device number 14 using xhci_hcd
2026-08-04T14:42:59.917621+01:00 spock kernel: usb 1-2: New USB device found, idVendor=05dc, idProduct=a720, bcdDevice=11.00 2026-08-04T14:42:59.917644+01:00 spock kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
2026-08-04T14:42:59.917647+01:00 spock kernel: usb 1-2: Product: Gizmo! 2026-08-04T14:42:59.917651+01:00 spock kernel: usb 1-2: Manufacturer: Crucial
2026-08-04T14:42:59.917654+01:00 spock kernel: usb 1-2: SerialNumber: 400B2209082842191007
2026-08-04T14:42:59.919611+01:00 spock kernel: usb-storage 1-2:1.0: USB
Mass Storage device detected
2026-08-04T14:42:59.919634+01:00 spock kernel: scsi host8: usb-storage 1-2:1.0
2026-08-04T14:42:59.932482+01:00 spock mtp-probe: checking bus 1, device
14: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2" 2026-08-04T14:42:59.932812+01:00 spock mtp-probe: bus: 1, device: 14 was
not an MTP device
2026-08-04T14:42:59.967108+01:00 spock mtp-probe: checking bus 1, device
14: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2" 2026-08-04T14:42:59.967217+01:00 spock mtp-probe: bus: 1, device: 14 was
not an MTP device
2026-08-04T14:43:00.932523+01:00 spock kernel: scsi 8:0:0:0: Direct- Access-a-a-a-a Crucial-a Gizmo!-a-a-a-a-a-a-a-a-a-a 1100 PQ: 0 ANSI: 0 CCS 2026-08-04T14:43:00.932535+01:00 spock kernel: sd 8:0:0:0: Attached scsi generic sg3 type 0
2026-08-04T14:43:00.960513+01:00 spock kernel: sd 8:0:0:0: [sdc] 1966080 512-byte logical blocks: (1.01 GB/960 MiB)
2026-08-04T14:43:00.960517+01:00 spock kernel: sd 8:0:0:0: [sdc] Write Protect is off
2026-08-04T14:43:00.960517+01:00 spock kernel: sd 8:0:0:0: [sdc] Mode
Sense: 43 00 00 00
2026-08-04T14:43:00.961508+01:00 spock kernel: sd 8:0:0:0: [sdc] No
Caching mode page found
2026-08-04T14:43:00.961510+01:00 spock kernel: sd 8:0:0:0: [sdc]
Assuming drive cache: write through
2026-08-04T14:43:00.964507+01:00 spock kernel:-a sdc: sdc1 2026-08-04T14:43:00.964509+01:00 spock kernel: sd 8:0:0:0: [sdc]
Attached SCSI removable disk

Well you justg confirmed that "linux" has pertpetium problems with USB.
It will NEVER be solved because linux people just deny the problem.
--
Once an organization gains any influence, it will be corrupted from both within and without.

Edmund
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Sun, 8/9/2026 4:53 AM, Edmund wrote:

On 8/4/26 3:55 PM, Mike Scott wrote:

Hi all. I can't see what's up here. Linux Mint 22.2.


Normally, I plug in a usb stick and sundry mount points appear for the vartious partitions.

However, I have a freshly-formatted usb stick - msdos and a single fat32 partition, which shows up on the system but doesn't mount.

When I insert the device, I get the appended stuff in syslog; it shows the device being detected.

It appears in /dev (label MUSIC in this case):

ls -l /dev/disk/by-label/

total 0
lrwxrwxrwx 1 root root 10 Aug-a 4 06:29 disk4 -> ../../sda5
lrwxrwxrwx 1 root root 10 Aug-a 4 06:29 diskb -> ../../sdb1
lrwxrwxrwx 1 root root 15 Aug-a 4 06:29 home2 -> ../../nvme0n1p4
lrwxrwxrwx 1 root root 10 Aug-a 4 14:43 MUSIC -> ../../sdc1

I can mount it with 'sudo mount.....'

And also:
-a-a~> udisksctl mount -b /dev/sdc1
Mounted /dev/sdc1 at /media/mike/MUSIC

which is what I want to happen, as it usually does, automatically.

It mounts just as expected on my laptop though, iirc the same version of mint.


I'm stumped - can anyone help please? Thanks.



=====
syslog contents:

2026-08-04T14:42:59.786624+01:00 spock kernel: usb 1-2: new high-speed USB device number 14 using xhci_hcd
2026-08-04T14:42:59.917621+01:00 spock kernel: usb 1-2: New USB device found, idVendor=05dc, idProduct=a720, bcdDevice=11.00
2026-08-04T14:42:59.917644+01:00 spock kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
2026-08-04T14:42:59.917647+01:00 spock kernel: usb 1-2: Product: Gizmo!
2026-08-04T14:42:59.917651+01:00 spock kernel: usb 1-2: Manufacturer: Crucial
2026-08-04T14:42:59.917654+01:00 spock kernel: usb 1-2: SerialNumber: 400B2209082842191007
2026-08-04T14:42:59.919611+01:00 spock kernel: usb-storage 1-2:1.0: USB Mass Storage device detected
2026-08-04T14:42:59.919634+01:00 spock kernel: scsi host8: usb-storage 1-2:1.0
2026-08-04T14:42:59.932482+01:00 spock mtp-probe: checking bus 1, device 14: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2"
2026-08-04T14:42:59.932812+01:00 spock mtp-probe: bus: 1, device: 14 was not an MTP device
2026-08-04T14:42:59.967108+01:00 spock mtp-probe: checking bus 1, device 14: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2"
2026-08-04T14:42:59.967217+01:00 spock mtp-probe: bus: 1, device: 14 was not an MTP device
2026-08-04T14:43:00.932523+01:00 spock kernel: scsi 8:0:0:0: Direct- Access-a-a-a-a Crucial-a Gizmo!-a-a-a-a-a-a-a-a-a-a 1100 PQ: 0 ANSI: 0 CCS
2026-08-04T14:43:00.932535+01:00 spock kernel: sd 8:0:0:0: Attached scsi generic sg3 type 0
2026-08-04T14:43:00.960513+01:00 spock kernel: sd 8:0:0:0: [sdc] 1966080 512-byte logical blocks: (1.01 GB/960 MiB)
2026-08-04T14:43:00.960517+01:00 spock kernel: sd 8:0:0:0: [sdc] Write Protect is off
2026-08-04T14:43:00.960517+01:00 spock kernel: sd 8:0:0:0: [sdc] Mode Sense: 43 00 00 00
2026-08-04T14:43:00.961508+01:00 spock kernel: sd 8:0:0:0: [sdc] No Caching mode page found
2026-08-04T14:43:00.961510+01:00 spock kernel: sd 8:0:0:0: [sdc] Assuming drive cache: write through
2026-08-04T14:43:00.964507+01:00 spock kernel:-a sdc: sdc1
2026-08-04T14:43:00.964509+01:00 spock kernel: sd 8:0:0:0: [sdc] Attached SCSI removable disk

Well you justg confirmed that "linux" has pertpetium problems with USB.
It will NEVER be solved because linux people just deny the problem.

The USB stack is mature enough, you can read the messages and
get some idea what is wrong.

It shouldn't be doing mtp-probe, right after the message "USB Mass Storage device detected".
This implies it bailed out at some point (out of USB Mass Storage),
during that phase of analysis.

And notice how the SCSI access starts 100 microseconds after the mtp-probe starts.
Almost like something, out of the blue, lost contact with the device. And the activity caused by the mtp-probe, caused contact with the device to be restored!

Edmund, you are one of our "Linux People". You could pop that trace into
your AI, and have that trace interpreted. as LLM-AI love to write
summaries of text chunks.

You could solve the problem for us! Think of the heros welcome
you would receive. Maybe a brass statue of you, in Linux City...

Paul
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Sun, 9 Aug 2026 18:18:24 -0400, Paul wrote:

Maybe a brass statue of you, in Linux City...

Well, maybe not *in* the city, but out on the outskirts somewhere ...
lots of empty space near the dump ...

Maybe not brass. Maybe not a statue, either ...
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Sun, 8/9/2026 6:18 PM, Paul wrote:

On Sun, 8/9/2026 4:53 AM, Edmund wrote:

On 8/4/26 3:55 PM, Mike Scott wrote:

Hi all. I can't see what's up here. Linux Mint 22.2.


Normally, I plug in a usb stick and sundry mount points appear for the vartious partitions.

However, I have a freshly-formatted usb stick - msdos and a single fat32 partition, which shows up on the system but doesn't mount.

When I insert the device, I get the appended stuff in syslog; it shows the device being detected.

It appears in /dev (label MUSIC in this case):

ls -l /dev/disk/by-label/

total 0
lrwxrwxrwx 1 root root 10 Aug-a 4 06:29 disk4 -> ../../sda5
lrwxrwxrwx 1 root root 10 Aug-a 4 06:29 diskb -> ../../sdb1
lrwxrwxrwx 1 root root 15 Aug-a 4 06:29 home2 -> ../../nvme0n1p4
lrwxrwxrwx 1 root root 10 Aug-a 4 14:43 MUSIC -> ../../sdc1

I can mount it with 'sudo mount.....'

And also:
-a-a~> udisksctl mount -b /dev/sdc1
Mounted /dev/sdc1 at /media/mike/MUSIC

which is what I want to happen, as it usually does, automatically.

It mounts just as expected on my laptop though, iirc the same version of mint.


I'm stumped - can anyone help please? Thanks.



=====
syslog contents:

2026-08-04T14:42:59.786624+01:00 spock kernel: usb 1-2: new high-speed USB device number 14 using xhci_hcd
2026-08-04T14:42:59.917621+01:00 spock kernel: usb 1-2: New USB device found, idVendor=05dc, idProduct=a720, bcdDevice=11.00
2026-08-04T14:42:59.917644+01:00 spock kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
2026-08-04T14:42:59.917647+01:00 spock kernel: usb 1-2: Product: Gizmo!
2026-08-04T14:42:59.917651+01:00 spock kernel: usb 1-2: Manufacturer: Crucial
2026-08-04T14:42:59.917654+01:00 spock kernel: usb 1-2: SerialNumber: 400B2209082842191007
2026-08-04T14:42:59.919611+01:00 spock kernel: usb-storage 1-2:1.0: USB Mass Storage device detected
2026-08-04T14:42:59.919634+01:00 spock kernel: scsi host8: usb-storage 1-2:1.0
2026-08-04T14:42:59.932482+01:00 spock mtp-probe: checking bus 1, device 14: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2"
2026-08-04T14:42:59.932812+01:00 spock mtp-probe: bus: 1, device: 14 was not an MTP device
2026-08-04T14:42:59.967108+01:00 spock mtp-probe: checking bus 1, device 14: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2"
2026-08-04T14:42:59.967217+01:00 spock mtp-probe: bus: 1, device: 14 was not an MTP device
2026-08-04T14:43:00.932523+01:00 spock kernel: scsi 8:0:0:0: Direct- Access-a-a-a-a Crucial-a Gizmo!-a-a-a-a-a-a-a-a-a-a 1100 PQ: 0 ANSI: 0 CCS
2026-08-04T14:43:00.932535+01:00 spock kernel: sd 8:0:0:0: Attached scsi generic sg3 type 0
2026-08-04T14:43:00.960513+01:00 spock kernel: sd 8:0:0:0: [sdc] 1966080 512-byte logical blocks: (1.01 GB/960 MiB)
2026-08-04T14:43:00.960517+01:00 spock kernel: sd 8:0:0:0: [sdc] Write Protect is off
2026-08-04T14:43:00.960517+01:00 spock kernel: sd 8:0:0:0: [sdc] Mode Sense: 43 00 00 00
2026-08-04T14:43:00.961508+01:00 spock kernel: sd 8:0:0:0: [sdc] No Caching mode page found
2026-08-04T14:43:00.961510+01:00 spock kernel: sd 8:0:0:0: [sdc] Assuming drive cache: write through
2026-08-04T14:43:00.964507+01:00 spock kernel:-a sdc: sdc1
2026-08-04T14:43:00.964509+01:00 spock kernel: sd 8:0:0:0: [sdc] Attached SCSI removable disk

Well you justg confirmed that "linux" has pertpetium problems with USB.
It will NEVER be solved because linux people just deny the problem.

A reasonable question regarding what is shown below, is whether the sequence would work better if serialized. Wait for the USB stick to respond to each query. Use a timeout. If the device times out, don't apply any other
procedures to the device, show the error code for the failure to respond. Somebody must have designed it this way for a reason, such as covering
for quirks in some other class of device. I don't think USB-storage
would be loaded, without poking the config space and finding a USB Mass Storage Class Code listed. Without further info, having a race condition on purpose does seem just a tad careless.

**************************** CoPilot answer concerning the log *****************************

**Short answer:**
... The real culprit is almost certainly **a timing race between udev, usb-storage, and mtp-probe**,
triggered by a slow-responding USB controller inside the Crucial "Gizmo!" stick.
The mtp-probe didnrCOt "wake it up" in any intentional way; instead, the device finally responded late,
and the usb-storage driver completed its inquiry only *after* mtp-probe had already tried
(and failed) to classify it.

This kind of behavior is surprisingly common with certain low-cost USB flash controllers.

---

## What the logs actually reveal
LetrCOs walk through the timeline rCo the ordering matters.

### 1. Device enumerates normally

usb 1-2: new high-speed USB device
idVendor=05dc, idProduct=a720
Product: Gizmo!
Manufacturer: Crucial

So far, everything is normal.

### 2. usb-storage binds immediately

usb-storage 1-2:1.0: USB Mass Storage device detected
scsi host8: usb-storage 1-2:1.0

This means the kernel *did* load usb-storage.ko and began SCSI inquiry.

### 3. mtp-probe runs (twice!)

mtp-probe: bus: 1, device: 14 was not an MTP device

This is udevrCOs standard behavior: it tries to classify the device as
MTP/PTP before deciding itrCOs plain USB storage.

### 4. **Long pause** (about 1 second)
This is the key detail.

Between:

mtp-probe: bus: 1, device: 14 was not an MTP device

and:

scsi 8:0:0:0: Direct-Access Crucial Gizmo!

there is a **~1 second delay**.

That delay is *not normal* for USB flash drives.

### 5. SCSI finally responds

sd 8:0:0:0: [sdc] 1966080 blocks
sdc: sdc1

Only now does the kernel get the block device info.

---

## What this means
The USB stickrCOs controller was **slow to respond to the
SCSI INQUIRY / READ CAPACITY commands**. When that happens:

- usb-storage is waiting for the device
- udev continues running other probes (mtp-probe, etc.)
- the device eventually responds
- the block device appears late
- automount may fail because the udev rule that triggers it
has already fired *before* the partition existed

This is why:

- The device appears as /dev/sdc
- But **automount does not happen**
- Rebooting and reinserting later works (the controller responds faster the second time)

---

## Why would the controller behave like this?
Several real-world causes:

### 1. **A marginal or aging USB flash controller**
Cheap controllers often have inconsistent response times.
If the stick is old or has many bad blocks, the firmware may stall during initialization.

### 2. **Power instability on first insertion**
Some USB sticks draw a brief spike of current when waking their internal NAND. If the port undervolts momentarily, the controller may start slowly.

### 3. **Internal wearrCaleveling or selfrCarepair on first access**
If the stick hasnrCOt been used in a while, the controller may perform background block checks before responding to SCSI commands.

### 4. **Race condition between udev rules**
If the device is slow, udev may run:

- mtp-probe
- usb-storage probe
- filesystem identification
- automount rules

in the wrong order, causing the automount rule to fire before /dev/sdc1 exists.

### 5. **Controller firmware bug**
Some Crucial-branded promotional drives (the "Gizmo!" line) are known to
use third-party controllers with inconsistent enumeration timing.

---

## Did mtp-probe "wake it up" ?
Not intentionally.

What likely happened is:

1. usb-storage sent SCSI INQUIRY
2. The device didnrCOt respond quickly
3. mtp-probe ran and failed
4. Meanwhile, the device finally responded to usb-storage
5. The block device appeared
6. But the automount rule had already passed

So mtp-probe didnrCOt fix anything rCo it just happened to run during the delay.

---

## Why reinserting after reboot works
Because:

- The controller is already "warm"
- NAND initialization is faster
- udevrCOs timing aligns correctly
- The block device appears before the automount rule fires

This is classic behavior for borderline USB flash controllers.

---

## Bottom line
The USB stick is **slow to respond**, causing a timing race between:

- usb-storage
- udev
- mtp-probe
- automount rules

This results in:

- The device being detected
- The partition being created
- But automount failing because the block device appeared too late

Reinsertion works because the controller responds faster the second time. **************************** End: CoPilot answer concerning the log *****************************

Paul
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On 8/10/26 12:18 AM, Paul wrote:

On Sun, 8/9/2026 4:53 AM, Edmund wrote:

On 8/4/26 3:55 PM, Mike Scott wrote:

Hi all. I can't see what's up here. Linux Mint 22.2.


Normally, I plug in a usb stick and sundry mount points appear for the vartious partitions.

However, I have a freshly-formatted usb stick - msdos and a single fat32 partition, which shows up on the system but doesn't mount.

When I insert the device, I get the appended stuff in syslog; it shows the device being detected.

It appears in /dev (label MUSIC in this case):

ls -l /dev/disk/by-label/

total 0
lrwxrwxrwx 1 root root 10 Aug-a 4 06:29 disk4 -> ../../sda5
lrwxrwxrwx 1 root root 10 Aug-a 4 06:29 diskb -> ../../sdb1
lrwxrwxrwx 1 root root 15 Aug-a 4 06:29 home2 -> ../../nvme0n1p4
lrwxrwxrwx 1 root root 10 Aug-a 4 14:43 MUSIC -> ../../sdc1

I can mount it with 'sudo mount.....'

And also:
-a-a~> udisksctl mount -b /dev/sdc1
Mounted /dev/sdc1 at /media/mike/MUSIC

which is what I want to happen, as it usually does, automatically.

It mounts just as expected on my laptop though, iirc the same version of mint.


I'm stumped - can anyone help please? Thanks.



=====
syslog contents:

2026-08-04T14:42:59.786624+01:00 spock kernel: usb 1-2: new high-speed USB device number 14 using xhci_hcd
2026-08-04T14:42:59.917621+01:00 spock kernel: usb 1-2: New USB device found, idVendor=05dc, idProduct=a720, bcdDevice=11.00
2026-08-04T14:42:59.917644+01:00 spock kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
2026-08-04T14:42:59.917647+01:00 spock kernel: usb 1-2: Product: Gizmo!
2026-08-04T14:42:59.917651+01:00 spock kernel: usb 1-2: Manufacturer: Crucial
2026-08-04T14:42:59.917654+01:00 spock kernel: usb 1-2: SerialNumber: 400B2209082842191007
2026-08-04T14:42:59.919611+01:00 spock kernel: usb-storage 1-2:1.0: USB Mass Storage device detected
2026-08-04T14:42:59.919634+01:00 spock kernel: scsi host8: usb-storage 1-2:1.0
2026-08-04T14:42:59.932482+01:00 spock mtp-probe: checking bus 1, device 14: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2"
2026-08-04T14:42:59.932812+01:00 spock mtp-probe: bus: 1, device: 14 was not an MTP device
2026-08-04T14:42:59.967108+01:00 spock mtp-probe: checking bus 1, device 14: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2"
2026-08-04T14:42:59.967217+01:00 spock mtp-probe: bus: 1, device: 14 was not an MTP device
2026-08-04T14:43:00.932523+01:00 spock kernel: scsi 8:0:0:0: Direct- Access-a-a-a-a Crucial-a Gizmo!-a-a-a-a-a-a-a-a-a-a 1100 PQ: 0 ANSI: 0 CCS
2026-08-04T14:43:00.932535+01:00 spock kernel: sd 8:0:0:0: Attached scsi generic sg3 type 0
2026-08-04T14:43:00.960513+01:00 spock kernel: sd 8:0:0:0: [sdc] 1966080 512-byte logical blocks: (1.01 GB/960 MiB)
2026-08-04T14:43:00.960517+01:00 spock kernel: sd 8:0:0:0: [sdc] Write Protect is off
2026-08-04T14:43:00.960517+01:00 spock kernel: sd 8:0:0:0: [sdc] Mode Sense: 43 00 00 00
2026-08-04T14:43:00.961508+01:00 spock kernel: sd 8:0:0:0: [sdc] No Caching mode page found
2026-08-04T14:43:00.961510+01:00 spock kernel: sd 8:0:0:0: [sdc] Assuming drive cache: write through
2026-08-04T14:43:00.964507+01:00 spock kernel:-a sdc: sdc1
2026-08-04T14:43:00.964509+01:00 spock kernel: sd 8:0:0:0: [sdc] Attached SCSI removable disk

Well you justg confirmed that "linux" has pertpetium problems with USB.
It will NEVER be solved because linux people just deny the problem.

The USB stack is mature enough, you can read the messages and
get some idea what is wrong.

It shouldn't be doing mtp-probe, right after the message "USB Mass Storage device detected".
This implies it bailed out at some point (out of USB Mass Storage),
during that phase of analysis.

And notice how the SCSI access starts 100 microseconds after the mtp-probe starts.
Almost like something, out of the blue, lost contact with the device. And the activity caused by the mtp-probe, caused contact with the device to be restored!

Edmund, you are one of our "Linux People". You could pop that trace into
your AI, and have that trace interpreted. as LLM-AI love to write
summaries of text chunks.

You could solve the problem for us! Think of the heros welcome
you would receive. Maybe a brass statue of you, in Linux City...

Paul

I know I know and I am not interested enough to waste my time on it.
AI? yup ask the same question 5 times and get 5 different responses.
Then, even IF someone finally fix the USB problem, there is no guaranty
our cut and paste coders won't mess it up again.
--
Once an organization gains any influence, it will be corrupted from both within and without.

Edmund
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On 10/08/2026 08:27, Paul wrote:
...big snip...

## Why reinserting after reboot works
Because:

- The controller is already "warm"
- NAND initialization is faster
- udevrCOs timing aligns correctly
- The block device appears before the automount rule fires

This is classic behavior for borderline USB flash controllers.

---

## Bottom line
The USB stick is **slow to respond**, causing a timing race between:

- usb-storage
- udev
- mtp-probe
- automount rules

This results in:

- The device being detected
- The partition being created
- But automount failing because the block device appeared too late

Reinsertion works because the controller responds faster the second time. **************************** End: CoPilot answer concerning the log *****************************

Paul

OP here.

I appreciate the various followups. I'm afraid I can't acknowledge individually though!

But in respect to this one, can I say that I've just put the stick back
in after some days of sitting on my desk.

It mounts itself very happily, and still logs stuff about mtp, so I
suspect that's a red herring. syslog stuff follows.

Meanwhile, I think this has probably consumed more than enough of
everyone's time, for which thanks again. Hopefully the issue won't return.



2026-08-10T12:24:33.119342+01:00 spock kernel: usb 1-2: new high-speed
USB device number 10 using xhci_hcd
2026-08-10T12:24:33.250358+01:00 spock kernel: usb 1-2: New USB device
found, idVendor=05dc, idProduct=a720, bcdDevice=11.00 2026-08-10T12:24:33.250382+01:00 spock kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
2026-08-10T12:24:33.250386+01:00 spock kernel: usb 1-2: Product: Gizmo! 2026-08-10T12:24:33.250389+01:00 spock kernel: usb 1-2: Manufacturer:
Crucial
2026-08-10T12:24:33.250392+01:00 spock kernel: usb 1-2: SerialNumber: 400B2209082842191007
2026-08-10T12:24:33.253340+01:00 spock kernel: usb-storage 1-2:1.0: USB
Mass Storage device detected
2026-08-10T12:24:33.253364+01:00 spock kernel: scsi host8: usb-storage
1-2:1.0
2026-08-10T12:24:33.260056+01:00 spock mtp-probe: checking bus 1, device
10: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2" 2026-08-10T12:24:33.261072+01:00 spock mtp-probe: bus: 1, device: 10 was
not an MTP device
2026-08-10T12:24:33.304628+01:00 spock mtp-probe: checking bus 1, device
10: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2" 2026-08-10T12:24:33.304802+01:00 spock mtp-probe: bus: 1, device: 10 was
not an MTP device
2026-08-10T12:24:34.265342+01:00 spock kernel: scsi 8:0:0:0:
Direct-Access Crucial Gizmo! 1100 PQ: 0 ANSI: 0 CCS 2026-08-10T12:24:34.266331+01:00 spock kernel: sd 8:0:0:0: Attached scsi generic sg3 type 0
2026-08-10T12:24:34.297281+01:00 spock kernel: sd 8:0:0:0: [sdc] 1966080 512-byte logical blocks: (1.01 GB/960 MiB)
2026-08-10T12:24:34.298259+01:00 spock kernel: sd 8:0:0:0: [sdc] Write
Protect is off
2026-08-10T12:24:34.298267+01:00 spock kernel: sd 8:0:0:0: [sdc] Mode
Sense: 43 00 00 00
2026-08-10T12:24:34.298270+01:00 spock kernel: sd 8:0:0:0: [sdc] No
Caching mode page found
2026-08-10T12:24:34.298272+01:00 spock kernel: sd 8:0:0:0: [sdc]
Assuming drive cache: write through
2026-08-10T12:24:34.302253+01:00 spock kernel: sdc: sdc1 2026-08-10T12:24:34.303254+01:00 spock kernel: sd 8:0:0:0: [sdc]
Attached SCSI removable disk
2026-08-10T12:24:34.582321+01:00 spock udisksd[1299]: Mounted /dev/sdc1
at /media/mike/MUSIC on behalf of uid 1001
--
Mike Scott
Harlow, England
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Mon, 8/10/2026 7:28 AM, Mike Scott wrote:

On 10/08/2026 08:27, Paul wrote:
...big snip...

##-a Why reinserting after reboot works
Because:

- The controller is already "warm"
- NAND initialization is faster
- udevrCOs timing aligns correctly
- The block device appears before the automount rule fires

This is classic behavior for borderline USB flash controllers.

---

##-a Bottom line
The USB stick is **slow to respond**, causing a timing race between:

- usb-storage
- udev
- mtp-probe
- automount rules

This results in:

- The device being detected
- The partition being created
- But automount failing because the block device appeared too late

Reinsertion works because the controller responds faster the second time.
**************************** End: CoPilot answer concerning the log *****************************

-a-a-a Paul

OP here.

I appreciate the various followups. I'm afraid I can't acknowledge individually though!

But in respect to this one, can I say that I've just put the stick back in after some days of sitting on my desk.

It mounts itself very happily, and still logs stuff about mtp, so I suspect that's a red herring. syslog stuff follows.

Meanwhile, I think this has probably consumed more than enough of everyone's time, for which thanks again. Hopefully the issue won't return.

It's important that we understand how stuff works :-)

I didn't know this sequence was possible, or even expected.

Paul

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Mon, 10 Aug 2026 12:28:50 +0100, Mike Scott wrote:

Meanwhile, I think this has probably consumed more than enough of
everyone's time ...

This may sound paradoxical, but all too often it is the user with the
problem who gives up and settles for some quick fix, while others
trying to chime in with helpful suggestions find their curiosity left unsatisfied as to the real root of the problem.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On 11/08/2026 01:40, Lawrence DrCOOliveiro wrote:

On Mon, 10 Aug 2026 12:28:50 +0100, Mike Scott wrote:

Meanwhile, I think this has probably consumed more than enough of
everyone's time ...

This may sound paradoxical, but all too often it is the user with the
problem who gives up and settles for some quick fix, while others
trying to chime in with helpful suggestions find their curiosity left unsatisfied as to the real root of the problem.

I'm not exactly just giving up. There was a problem; it "went away" for
no discernable reason. I now cannot reproduce it.

I don't like it when that happens; I'm well aware it could come back
just as quickly; I'm well aware it means something's not right somewhere
and would be best fixed. But I don't have the time or in-depth knowledge
to investigate further, and in fairness don't expect others to do so on
my behalf. (I get far more help from the net than I can give, and am
grateful that people will spend the time.)

OTOH, if it does come back, there have been some pointers in this thread
to suggest areas to check, which I would certainly do.
--
Mike Scott
Harlow, England
--- Synchronet 3.22a-Linux NewsLink 1.2