
System: Host: opihi Kernel: 6.4.0-150600.23.30-default arch: x86_64 bits: 64 Desktop: KDE Plasma v: 5.27.11 Distro: openSUSE Leap 15.6 I've got a microSD chip, the car wants a fat32 so that's what it got, that's causing me problems. I suspect that it's bad, or going bad. Here's what's happening. The first copy. bill@opihi:/home/Cars> rsync -acprv --delete Winter /run/media/bill/CARZ sending incremental file list Winter/ Winter/200000.mp3 Winter/200010.mp3 ... Winter/206740.mp3 Winter/206750.mp3 sent 6,605,314,161 bytes received 12,736 bytes 8,495,597.30 bytes/sec total size is 6,669,006,725 speedup is 1.01 Unmount the device and remove it. Then mount the device and rerun the rsync command. Get 4 files rewritten. Repeat the unmount/remove/mount, rsync and get 3 other files rewritten. So I tried to test it. bill@opihi:/home/Cars> sudo badblocks -sv /dev/sdb Checking blocks 0 to 15196159 Checking for bad blocks (read-only test): done Pass completed, 0 bad blocks found. (0/0/0 errors) bill@opihi:/home/Cars> sudo badblocks -nsv /dev/sdb1 /dev/sdb1 is mounted; it's not safe to run badblocks! bill@opihi:/home/Cars> sudo badblocks -nsv /dev/sdb /dev/sdb is apparently in use by the system; it's not safe to run badblocks! Unmount the device, but don't unplug it. bill@opihi:/home/Cars> sudo badblocks -nsv /dev/sdb1 badblocks: No such file or directory while trying to determine device size bill@opihi:/home/Cars> sudo badblocks -nsv /dev/sdb badblocks: No medium found while trying to determine device size The smartctl told me nothing of any use. So, where can I go from here?

On 12-28-2024 02:32PM, Bill Swisher wrote:
System: Host: opihi Kernel: 6.4.0-150600.23.30-default arch: x86_64 bits: 64 Desktop: KDE Plasma v: 5.27.11 Distro: openSUSE Leap 15.6
I've got a microSD chip, the car wants a fat32 so that's what it got, that's causing me problems. I suspect that it's bad, or going bad. Here's what's happening.
The first copy. bill@opihi:/home/Cars> rsync -acprv --delete Winter /run/media/bill/CARZ sending incremental file list Winter/ Winter/200000.mp3 Winter/200010.mp3 ... Winter/206740.mp3 Winter/206750.mp3 sent 6,605,314,161 bytes received 12,736 bytes 8,495,597.30 bytes/sec total size is 6,669,006,725 speedup is 1.01
Unmount the device and remove it. Then mount the device and rerun the rsync command. Get 4 files rewritten. Repeat the unmount/remove/mount, rsync and get 3 other files rewritten.
So I tried to test it.
bill@opihi:/home/Cars> sudo badblocks -sv /dev/sdb Checking blocks 0 to 15196159 Checking for bad blocks (read-only test): done Pass completed, 0 bad blocks found. (0/0/0 errors)
bill@opihi:/home/Cars> sudo badblocks -nsv /dev/sdb1 /dev/sdb1 is mounted; it's not safe to run badblocks! bill@opihi:/home/Cars> sudo badblocks -nsv /dev/sdb /dev/sdb is apparently in use by the system; it's not safe to run badblocks!
Unmount the device, but don't unplug it.
bill@opihi:/home/Cars> sudo badblocks -nsv /dev/sdb1 badblocks: No such file or directory while trying to determine device size bill@opihi:/home/Cars> sudo badblocks -nsv /dev/sdb badblocks: No medium found while trying to determine device size
The smartctl told me nothing of any use. So, where can I go from here?
Hi, I would like to tell you about this article from CubicleNate < https://cubiclenate.com/?s=f3read The 'f3' program is natively available (Tumbleweed) and can help you verify the flash medium in question for validity. zypper se -si f3 Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+----------+---------+-----------+--------+----------- i+ | f3 | package | 8.0-1.17 | x86_64 | repo-oss i | libvmaf3 | package | 3.0.0-2.2 | x86_64 | repo-oss Perhaps giving you a more secure footing to move forward with. -Greatest Hopes

On 2024-12-28 21:32, Bill Swisher wrote:
System: Host: opihi Kernel: 6.4.0-150600.23.30-default arch: x86_64 bits: 64 Desktop: KDE Plasma v: 5.27.11 Distro: openSUSE Leap 15.6
I've got a microSD chip, the car wants a fat32 so that's what it got, that's causing me problems. I suspect that it's bad, or going bad. Here's what's happening.
The first copy. bill@opihi:/home/Cars> rsync -acprv --delete Winter /run/media/bill/CARZ sending incremental file list Winter/ Winter/200000.mp3 Winter/200010.mp3 ... Winter/206740.mp3 Winter/206750.mp3 sent 6,605,314,161 bytes received 12,736 bytes 8,495,597.30 bytes/sec total size is 6,669,006,725 speedup is 1.01
Unmount the device and remove it. Then mount the device and rerun the rsync command. Get 4 files rewritten. Repeat the unmount/remove/mount, rsync and get 3 other files rewritten.
So I tried to test it.
bill@opihi:/home/Cars> sudo badblocks -sv /dev/sdb Checking blocks 0 to 15196159 Checking for bad blocks (read-only test): done Pass completed, 0 bad blocks found. (0/0/0 errors)
bill@opihi:/home/Cars> sudo badblocks -nsv /dev/sdb1 /dev/sdb1 is mounted; it's not safe to run badblocks! bill@opihi:/home/Cars> sudo badblocks -nsv /dev/sdb /dev/sdb is apparently in use by the system; it's not safe to run badblocks!
Unmount the device, but don't unplug it.
How did you umaount? Did you use the umount command in a terminal, or did you use your desktop button? The later also removes the device. You have to insert it again.
bill@opihi:/home/Cars> sudo badblocks -nsv /dev/sdb1 badblocks: No such file or directory while trying to determine device size bill@opihi:/home/Cars> sudo badblocks -nsv /dev/sdb badblocks: No medium found while trying to determine device size
The smartctl told me nothing of any use. So, where can I go from here?
-- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)

On 12/28/24 15:27, Carlos E. R. wrote:
How did you umaount? Did you use the umount command in a terminal, or did you use your desktop button? The later also removes the device. You have to insert it again.
Ahhh...did not know that. Thank you. I did a umount from the console, that's what I get for using the GUI, and it's running a non-destructive r/w test right now.

On 2024-12-29 00:28, Bill Swisher wrote:
On 12/28/24 15:27, Carlos E. R. wrote:
How did you umaount? Did you use the umount command in a terminal, or did you use your desktop button? The later also removes the device. You have to insert it again.
Ahhh...did not know that. Thank you. I did a umount from the console, that's what I get for using the GUI, and it's running a non-destructive r/w test right now.
Most desktops do umount + eject. I do not know a command to reverse the eject. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)

On 2024-12-29 01:53, Carlos E. R. wrote:
I do not know a command to reverse the eject.
If you mean to close the tray, use the eject command with -T or -t, if the device supports it. man eject <snip> -T, --traytoggle With this option the drive is given a CD-ROM tray close command if it’s opened, and a CD-ROM tray eject command if it’s closed. Not all devices support this command, because it uses the above CD-ROM tray close command. -t, --trayclose With this option the drive is given a CD-ROM tray close command. Not all devices support this command. -- /bengan

On 2024-12-29 12:32, Bengt Gördén wrote:
On 2024-12-29 01:53, Carlos E. R. wrote:
I do not know a command to reverse the eject.
If you mean to close the tray, use the eject command with -T or -t, if the device supports it.
man eject <snip> -T, --traytoggle With this option the drive is given a CD-ROM tray close command if it’s opened, and a CD-ROM tray eject command if it’s closed. Not all devices support this command, because it uses the above CD-ROM tray close command.
-t, --trayclose With this option the drive is given a CD-ROM tray close command. Not all devices support this command.
Ah! Worth a try. Telcontar:~ # mount | grep media /dev/sde1 on /media/openSUSE_Leap_15.5_Rescue_CD type iso9660 (ro,nosuid,nodev,relatime,nojoliet,check=s,map=n,blocksize=2048,uid=1000,gid=100,dmode=555,fmode=444,iocharset=utf8,uhelper=udisks2) eject with desktop Telcontar:~ # eject -t /dev/sde1 eject: /dev/sde1: not found mountpoint or device with the given name Telcontar:~ # eject -t /dev/sde eject: /dev/sde: not found mountpoint or device with the given name Telcontar:~ # connect again Telcontar:~ # mount | grep media /dev/sde1 on /media/openSUSE_Leap_15.5_Rescue_CD type iso9660 (ro,nosuid,nodev,relatime,nojoliet,check=s,map=n,blocksize=2048,uid=1000,gid=100,dmode=555,fmode=444,iocharset=utf8,uhelper=udisks2) Telcontar:~ # eject -t /dev/sde1 eject: /dev/sde1: not found mountpoint or device with the given name Telcontar:~ # eject -t /dev/sde eject: /dev/sde: not found mountpoint or device with the given name Telcontar:~ # mount | grep media /dev/sde1 on /media/openSUSE_Leap_15.5_Rescue_CD type iso9660 (ro,nosuid,nodev,relatime,nojoliet,check=s,map=n,blocksize=2048,uid=1000,gid=100,dmode=555,fmode=444,iocharset=utf8,uhelper=udisks2) Telcontar:~ # umount /dev/sde1 Telcontar:~ # eject /dev/sde Telcontar:~ # eject -t /dev/sde Telcontar:~ # mount /dev/sde1 /media/ mount: /media: WARNING: source write-protected, mounted read-only. Telcontar:~ # eject -t /dev/sde Telcontar:~ # eject -t /dev/sde1 Telcontar:~ # mount /dev/sde1 /media/ mount: /media: /dev/sde1 already mounted on /media. Telcontar:~ # umount /dev/sde1 /media/ umount: /media/: not mounted. Telcontar:~ # eject -t /dev/sde1 Telcontar:~ # eject /dev/sde1 Telcontar:~ # eject -t /dev/sde1 eject: /dev/sde1: not found mountpoint or device with the given name Telcontar:~ # Telcontar:~ # eject -t /dev/sde Telcontar:~ # And the desktop shows the usb stick ready to be mounted. It works if I eject with the command line, but not if I eject with the xfce desktop. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)

On Sat, 28 Dec 2024 13:32:49 -0700, Bill Swisher <bill@luddites.org> wrote:
System: Host: opihi Kernel: 6.4.0-150600.23.30-default arch: x86_64 bits: 64 Desktop: KDE Plasma v: 5.27.11 Distro: openSUSE Leap 15.6
I've got a microSD chip, the car wants a fat32 so that's what it got, that's causing me problems. I suspect that it's bad, or going bad. Here's what's happening.
The first copy. bill@opihi:/home/Cars> rsync -acprv --delete Winter /run/media/bill/CARZ sending incremental file list Winter/ Winter/200000.mp3 Winter/200010.mp3 ... Winter/206740.mp3 Winter/206750.mp3 sent 6,605,314,161 bytes received 12,736 bytes 8,495,597.30 bytes/sec total size is 6,669,006,725 speedup is 1.01
Unmount the device and remove it. Then mount the device and rerun the rsync command. Get 4 files rewritten. Repeat the unmount/remove/mount, rsync and get 3 other files rewritten.
[...]
When doing an rsync copy to or from a FAT filesystem, you should use the option, --modify-window=1, due to the coarse timestamp resolution on FAT causing rsync to make a wrong determination of older/newer. -- Robert Webb

On 12/28/24 15:37, Robert Webb via openSUSE Users wrote:
When doing an rsync copy to or from a FAT filesystem, you should use the option, --modify-window=1, due to the coarse timestamp resolution on FAT causing rsync to make a wrong determination of older/newer.
Thanks, it seems to have worked better with that option. I'll fiddle around with it more after the badblocks run gets done, the man page wasn't kidding when it said it's slow... 27.5 minutes to do 10% of a small 16GB chip.

On 2024-12-29 00:39, Bill Swisher wrote:
On 12/28/24 15:37, Robert Webb via openSUSE Users wrote:
When doing an rsync copy to or from a FAT filesystem, you should use the option, --modify-window=1, due to the coarse timestamp resolution on FAT causing rsync to make a wrong determination of older/newer.
Thanks, it seems to have worked better with that option. I'll fiddle around with it more after the badblocks run gets done, the man page wasn't kidding when it said it's slow... 27.5 minutes to do 10% of a small 16GB chip.
If that badblocks command was designed for a hard disk, and it is probing the media by doing multiple writings and readings, it will trash your card or stick. They have limited writes. I would stop the command ASAP. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)

Le 29/12/2024 à 01:56, Carlos E. R. a écrit :
If that badblocks command was designed for a hard disk, and it is probing the media by doing multiple writings and readings, it will trash your card or stick. They have limited writes. I would stop the command ASAP.
same you can also use "f3probe" to test if the sd chip is real or fake given the very low price of such chip, I would trash any suspect one ! jdd -- https://dodin.org

On 12/28/24 5:39 PM, Bill Swisher wrote:
On 12/28/24 15:37, Robert Webb via openSUSE Users wrote:
When doing an rsync copy to or from a FAT filesystem, you should use the option, --modify-window=1, due to the coarse timestamp resolution on FAT causing rsync to make a wrong determination of older/newer.
Thanks, it seems to have worked better with that option. I'll fiddle around with it more after the badblocks run gets done, the man page wasn't kidding when it said it's slow... 27.5 minutes to do 10% of a small 16GB chip.
Well ... Don't forget to report results. I'm curious. I've got a number of MicroSD cards -- none going bad yet, but am interested if you found anything further or had anymore to add? -- David C. Rankin, J.D.,P.E.
participants (7)
-
-pj
-
Bengt Gördén
-
Bill Swisher
-
Carlos E. R.
-
David C. Rankin
-
jdd@dodin.org
-
Robert Webb