See: https://en.opensuse.org/How_To_Try_openSUSE_Without_Making_Any_Changes_To_Your_PC
You may try Tumbleweed: https://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-KDE-Live-x86_64-Current.iso
Don’t worry about the German, Karl and I can understand that ;). And most other will probably also be able to interprete what it is saying.
A question (maybe I missed that): In openSUSE you use that USB fd device. Is that also tha case on that Windows system, or does that one still have a floppy drive and do you use it?
You will understand that I am now trying to blame the USB device 
Thanks, I’ll try these. I have already downloaded and checked the iso. However, this has to go side by side with other work to be done. So, it may take a day or so.
Yes, I understand that. If it is the device, I will need to prove that it’s not working to get a replacement. I guess, that would be one possible outcome of this discussion.
However, the Windows system has a built-in floppy drive and that is the one that I’ve been using and which is working. So, it could still be the device, yes.
And what exactly prevents you from testing “the device” under Windows? Which I suspect everyone assumed you have been doing all the time?
Well, actually I have never claimed that I tested the USB-floppy device under Windows. In the original post I mentioned that I tested the disk with the “internal” floopy drive of a Windwos system. This was a test that the floppy can indeed be read, nothing more, so I can use the floppy to test the device under Linux. The use of that Windows XP system is rather inconvenient, because it is in a remote lab, not connected to the internet, and in fact still alive only because we need a specific hard/software combination sometimes.
As I already said in the original post also, I want to be able to read floppies under Linux (which I use regularly, especially now in “home office” in the virus lockdown situation). This is why I never thought of connecting the device to the Windows XP system up to now. But, yes, I agree, this is an additional experiment.
So, I did that test (USB device on Windows XP system), and, well, it fails. Sorry that I can not provide the console output, because this is all on the desktop (translations from German): “new hardware found”, “new hardware installed and can now be used”, “insert medium in drive B:”, and then, after some time, “the medium in drive B: is not formatted. Do you want to format now?” (of course, I didn’t want to).
Is this the end of the story, i.e. does this prove that the device is broken? I am not sure. After all, the Linux tools did show us a file system (vfat) in contrast to the Windows output. I suspect that the different tools and operating systems get their information on different levels of detail. Maybe the experts can draw a clear conclusion?
If we arrive at the conclusion that it IS broken indeed, I could approach the supplier of the device for replacement.
In the meantime, I have already tested Karl’s suggestion to use a Tumbleweed Live Stick - no change, behaves exactly the same as with openSuSE 15.1.
I have also found a reference to the tools dosfsck and used it:
/home/bs> sudo dosfsck -nv /dev/sdb
fsck.fat 4.1 (2017-01-24)
Checking we can access the last sector of the filesystem
0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
Automatically removing dirty bit.
Boot sector contents:
System ID "):ie%IHC"
Media byte 0xf0 (5.25" or 3.5" HD floppy)
512 bytes per logical sector
512 bytes per cluster
1 reserved sector
First FAT starts at byte 512 (sector 1)
2 FATs, 12 bit entries
4608 bytes per FAT (= 9 sectors)
Root directory starts at byte 9728 (sector 19)
224 root directory entries
Data area starts at byte 16896 (sector 33)
2847 data clusters (1457664 bytes)
18 sectors/track, 2 heads
0 hidden sectors
2880 sectors total
Got 3072 bytes instead of 4274 at 5120
Maybe more hints from this?
Best regards and thanks for considering this problem!
I would indeed go back to the shop. You now proved it does not work on Windows and that the floppy does work on a build-in floppy drive on Windows. That is something that even a seller with only Windows knowledge should understand.
Well, I wrote:
Bernd reported the drive to work fine with Windows. But Windows could ignore the errors occurring. To check with Linux use: dd conv=noerror.
https://forums.opensuse.org/showthread.php/539689-USB-floppy-device-can-t-read?p=2931599#post2931599
You referred to that line:
Second piece of information for now is the result of the modified dd command as to Karl (now the device is sdc, because I used another USB device before):
But you ignored some of the content. You didn’t object to my claim. So I assumed to be correct.
So, I did that test (USB device on Windows XP system), and, well, it fails. Sorry that I can not provide the console output, because this is all on the desktop (translations from German): “new hardware found”, “new hardware installed and can now be used”, “insert medium in drive B:”, and then, after some time, “the medium in drive B: is not formatted. Do you want to format now?” (of course, I didn’t want to).
To my experience most users are making this test before asking for help. On the other hand users are different.
https://software.opensuse.org/package/ufiformat?search_term=ufiformat
https://forum.sources.ru/next/index.php?showtopic=71994
For M$ Windows you need a driver: check 8cm CD disk, get here or that.
Seems, I was too much fixated on “Linux use” (because I usually avoid Windows a much as possible), and did not interpret your line correctly. I am sorry about that. However, at least I did learn about a couple of additional commands to use in testing.
Thanks for these additional links. I will try on Linux ufiformat and the tests from the first link - although I don’t want to format the floppy, but rather read its contents.
As for your comment on a driver for Windows: does this means, a Windows system that is supposed to read a floppy through a USB-device will need that additional driver?
If that is the case, the previous test of the device with the Windows XP system would not tell us that the device is broken, and first the driver should be installed, right?
You said these are 1.2 meg floppies not the now standard 1.4 meg that is a very old depreciated format and yes the actual geometry of the disk is different thus needs some form of special driver. Since floppy drivers are dumb devices and the head position etc is totally controlled by the driver the driver must understand the geometry.
I think it is indeed 1.4MB, see the various outputs in this post: https://forums.opensuse.org/showthread.php/539689-USB-floppy-device-can-t-read?p=2931529#post2931529 - the 1.2 MB is the available space, with 188 KB of data on the floppy, adding up to the 1.4 MB shown by lsblk.
1.2 MB diskette is 5.25" HD.
3.5" is 720 kB, 1.44 MB, 2.88 MB.
Nrver saw 5.25" USB drive. But want to see it.
Yes, AFAIU you need a driver to use USB FDD with Windows.
For Linux you need to make some steps:
Mounting:
mknod /dev/fd0 b 2 0
mount -t vfat /dev/fd0 /mnt/floppy -o iocharset=koi8-r,codepage=866
- russian dos codepages. Works with english + russian letters. Change it as you need.
Before ejecting:
umount /mnt/floppy
After changing diskette mount it again.
You may want to add something to a /etc/fstab
/dev/fd0 /mnt/floppy vfat users,iocharset=koi8-r,codepage=866,showexec 0 0
Info comes from https://forum.sources.ru/next/index.php?showtopic=71994.
I never tried it by myself.
The systems deals with the details automagically:
erlangen:~ # grep /test /etc/fstab
UUID=6B7B-E2AB /test vfat user,noauto 0 0
erlangen:~ #
erlangen:~ # mount| grep /dev/sdc
/dev/sdc on /run/media/karl/disk type vfat (ro,nosuid,nodev,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro,uhelper=udisks2)
/dev/sdc on /test type vfat (ro,nosuid,nodev,noexec,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro,user)
erlangen:~ #
You may change defaults that don’t fit in /etc/fstab.
When I almost though this thread to be finished, Svyatko’s post added some new ideas.
Here is a couple of responses.
First, I confirm in part Karl’s comment that the mount is done automagically. The difference is that in my case the uid and gid options were missing (which are also missing in Karl’s most recent post, but were present earlier: https://forums.opensuse.org/showthread.php/539689-USB-floppy-device-can-t-read?p=2931535#post2931535). I had shown here https://forums.opensuse.org/showthread.php/539689-USB-floppy-device-can-t-read?p=2931529#post2931529 the mount command response of my system.
Second, I tested the ufiformat as suggested by Svyatko (in particular his first link (https://fitzcarraldoblog.wordpress.c…rive-in-linux/):
/home/bs> lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 477G 0 disk
├─sda1 8:1 0 500M 0 part /boot
└─sda2 8:2 0 476.5G 0 part
└─cr-auto-1 254:0 0 476.5G 0 crypt
├─system-root 254:1 0 40G 0 lvm /
├─system-swap 254:2 0 16G 0 lvm
└─system-home 254:3 0 420.5G 0 lvm /home
sdb 8:16 1 1.4M 0 disk /run/media/bs/disk
sr0 11:0 1 1024M 0 rom
/home/bs> sudo ufiformat -i -v /dev/sdb
inquire on device=/dev/sdb
vendor: TEAC
product: USB UF000x
write protect: off
media type: 2HD
status block size kb
formatted 2880 512 1440
formattable 2400 512 1200
formattable 1232 1024 1232
formattable 2880 512 1440
What is the “formattable” stuff? In addition, here is the result of fdisk:
/home/bs> sudo fdisk -l /dev/sdb
Disk /dev/sdb: 1.4 MiB, 1474560 bytes, 2880 sectors
Disk model: USB UF000x
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x63657720
Device Boot Start End Sectors Size Id Type
/dev/sdb1 1953718612 3872883128 1919164517 915.1G 75 PC/IX
/dev/sdb2 1330184192 1869160479 538976288 257G 65 Novell Netware 386
/dev/sdb3 538989391 1937352302 1398362912 666.8G 53 OnTrack DM6 Aux3
/dev/sdb4 3910009470 3910074813 65344 31.9M bb Boot Wizard hidden
Partition table entries are not in disk order.
Does this help us further? What are these devices /dev/sdbX? What are these sizes? Something must be wrong (or incorrectly determined) here.
But now comes a surprise: when I plugged in the device after reboot the next day, it worked completely without problems. I can connect the empty device and insert a floppy later or connect the device with the floppy, in any case, the mount is done automatically once a disk is present and I select “Open with File Manager” from the Device Notifier. So, in fact the device is NOT broken.
Working on the command line, everything looks OK (uid/gid are present, dd copies the full 1.4 MB, all files can be listed), I see the following:
/home/bs> mount |grep sdb
/dev/sdb on /run/media/bs/3148-11E3 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
home/bs> sudo dd if=/dev/sdb of=floppy.out
[sudo] password for root:
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB, 1.4 MiB) copied, 58.6954 s, 25.1 kB/s
/home/bs> ls -al /run/media/bs/3148-11E3/
total 194
drwxr-xr-x 2 bs users 7168 1. Jan 1970 .
drwxr-x---+ 3 root root 60 9. Apr 16:25 ..
-rw-r--r-- 1 bs users 1644 30. Jun 1999 Image21.gif
-rw-r--r-- 1 bs users 2052 30. Jun 1999 Image22.gif
-rw-r--r-- 1 bs users 1715 30. Jun 1999 Image23.gif
-rw-r--r-- 1 bs users 98366 30. Jun 1999 pyr1.bmp
-rw-r--r-- 1 bs users 28160 30. Jun 1999 PYR1.doc
-rw-r--r-- 1 bs users 1029 30. Jun 1999 PYR1.htm
-rw-r--r-- 1 bs users 55127 30. Jun 1999 pyr1.pcx
-rw-r--r-- 1 bs users 127 1. Jul 1999 WS_FTP.LOG
One difference to the behavior before is the mount point, which is now no longer /run/media/bs/disk, but rather /run/media/bs/3148-11E3.
I can also read other floppy disks, so the problem seems to be solved, and I can transfer the data on the floppies to my Linux system.
But why? It is a little unsatisfactory if this can not be explained. How can a call of ufiformat or fdisk commands as shown above (I think, these only list some info) change anything?
Thanks for considering!
More efficient forensics require posting of the available logs:
erlangen:~ # journalctl _KERNEL_SUBSYSTEM=scsi --grep **sdd**
-- Logs begin at Sun 2020-03-29 16:41:11 CEST, end at Thu 2020-04-09 17:33:18 CEST. --
-- Reboot --
Mar 31 16:56:14 erlangen kernel: sd 6:0:0:1: [sdd] 15353856 512-byte logical blocks: (7.86 GB/7.32 GiB)
Mar 31 16:56:14 erlangen kernel: sd 6:0:0:1: [sdd] Write Protect is off
Mar 31 16:56:14 erlangen kernel: sd 6:0:0:1: [sdd] Mode Sense: 23 00 00 00
Mar 31 16:56:14 erlangen kernel: sd 6:0:0:1: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Mar 31 16:56:14 erlangen kernel: sd 6:0:0:1: [sdd] Attached SCSI removable disk
-- Reboot --
Apr 04 16:46:25 erlangen kernel: sd 6:0:0:1: [sdd] 15353856 512-byte logical blocks: (7.86 GB/7.32 GiB)
Apr 04 16:46:25 erlangen kernel: sd 6:0:0:1: [sdd] Write Protect is off
Apr 04 16:46:25 erlangen kernel: sd 6:0:0:1: [sdd] Mode Sense: 23 00 00 00
Apr 04 16:46:25 erlangen kernel: sd 6:0:0:1: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Apr 04 16:46:25 erlangen kernel: sd 6:0:0:1: [sdd] Attached SCSI removable disk
Apr 04 16:47:32 erlangen kernel: sd 6:0:0:1: [sdd] Synchronizing SCSI cache
Apr 04 16:47:32 erlangen kernel: sd 6:0:0:1: [sdd] Synchronize Cache(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
-- Reboot --
Apr 05 19:42:23 erlangen kernel: sd 6:0:0:1: [sdd] 15353856 512-byte logical blocks: (7.86 GB/7.32 GiB)
Apr 05 19:42:23 erlangen kernel: sd 6:0:0:1: [sdd] Write Protect is off
Apr 05 19:42:23 erlangen kernel: sd 6:0:0:1: [sdd] Mode Sense: 23 00 00 00
Apr 05 19:42:23 erlangen kernel: sd 6:0:0:1: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Apr 05 19:42:23 erlangen kernel: sd 6:0:0:1: [sdd] Attached SCSI removable disk
-- Reboot --
erlangen:~ #
Make sure to select the correct drive (bold letters).
and:
erlangen:~ # journalctl _KERNEL_SUBSYSTEM=usb
...
Apr 09 07:43:47 erlangen kernel: usb usb1: Product: xHCI Host Controller
Apr 09 07:43:47 erlangen kernel: usb usb1: Manufacturer: Linux 5.6.2-1-default xhci-hcd
Apr 09 07:43:47 erlangen kernel: usb usb1: SerialNumber: 0000:00:14.0
Apr 09 07:43:47 erlangen kernel: hub 1-0:1.0: USB hub found
Apr 09 07:43:47 erlangen kernel: hub 1-0:1.0: 16 ports detected
Apr 09 07:43:47 erlangen kernel: usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.06
Apr 09 07:43:47 erlangen kernel: usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Apr 09 07:43:47 erlangen kernel: usb usb2: Product: xHCI Host Controller
Apr 09 07:43:47 erlangen kernel: usb usb2: Manufacturer: Linux 5.6.2-1-default xhci-hcd
Apr 09 07:43:47 erlangen kernel: usb usb2: SerialNumber: 0000:00:14.0
Apr 09 07:43:47 erlangen kernel: hub 2-0:1.0: USB hub found
Apr 09 07:43:47 erlangen kernel: hub 2-0:1.0: 10 ports detected
Apr 09 07:43:48 erlangen kernel: usb 1-7: new low-speed USB device number 2 using xhci_hcd
Apr 09 07:43:48 erlangen kernel: usb 1-7: New USB device found, idVendor=046a, idProduct=0011, bcdDevice= 1.00
Apr 09 07:43:48 erlangen kernel: usb 1-7: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Apr 09 07:43:49 erlangen kernel: usb 1-8: new low-speed USB device number 3 using xhci_hcd
Apr 09 07:43:49 erlangen kernel: usb 1-8: New USB device found, idVendor=046d, idProduct=c05a, bcdDevice=63.00
Apr 09 07:43:49 erlangen kernel: usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Apr 09 07:43:49 erlangen kernel: usb 1-8: Product: USB Optical Mouse
Apr 09 07:43:49 erlangen kernel: usb 1-8: Manufacturer: Logitech
Apr 09 17:27:35 erlangen kernel: usb 1-5: new full-speed USB device number 4 using xhci_hcd
Apr 09 17:27:35 erlangen kernel: usb 1-5: New USB device found, idVendor=0fcf, idProduct=1009, bcdDevice= 1.00
Apr 09 17:27:35 erlangen kernel: usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 09 17:27:35 erlangen kernel: usb 1-5: Product: ANT USB-m Stick
Apr 09 17:27:35 erlangen kernel: usb 1-5: Manufacturer: Dynastream Innovations
Apr 09 17:27:35 erlangen kernel: usb 1-5: SerialNumber: 192
Apr 09 17:27:35 erlangen kernel: usb_serial_simple 1-5:1.0: suunto converter detected
Apr 09 17:27:35 erlangen kernel: usb 1-5: suunto converter now attached to ttyUSB0
Apr 09 17:30:57 erlangen kernel: usb_serial_simple 1-5:1.0: device disconnected
Apr 09 17:30:57 erlangen kernel: usb 1-5: reset full-speed USB device number 4 using xhci_hcd
Apr 09 17:32:29 erlangen kernel: usb 1-5: reset full-speed USB device number 4 using xhci_hcd
erlangen:~ #
Make them available with susepaste or an external ink, such as http://www.mistelberger.net/bootinfoscript.out
Karl, I have pasted the output of the suggested journalctl commands to
https://paste.opensuse.org/13532405
and
https://paste.opensuse.org/16952726
Output was created after the USB device was successfully attached and files were visible. I’m not sure how to get access to earlier logs when the connection was not succesful.
As a comment, --grep didn’t work as an option to journalctl (also it is not listed in the man page), so I piped through grep.
Hm, you don’t have a permanent journal? https://gist.github.com/JPvRiel/b7c185833da32631fa6ce65b40836887