Non-system disk or disk error is at least coming from the boot sector so that's a good sign that something is working (unless it is failing over to the hard drive and it's the VBR generating that message). Does the 386 definitely boot with other floppies? I have run into the floppy head not being able to seek for lack of lubrication, but the grinding sound during the BIOS disk seek made this obvious.

jakethompson1 wrote on Yesterday, 17:14:

Does the 386 definitely boot with other floppies?

Yes, I have an original version of MSDOS 4.01 and it boots on the 386. Also, I tried burning the .img file on different floppies, and I get the error nonetheless.

I assume not a 720k (which 4.01 would be) vs. 1.44mb issue, but I'd think even the boot sector wouldn't load to give you this error in that case.

I suppose sdc is a usb floppy.
I would make an image of an existing good floppy, then dd it back to a blank.

Also , depending what you want to do with this floppy, I like to have a tftp server, then you can boot from network with AllInOne, even with some ISA network cards.
Not exactly an answer to your specific problem here, but it helped me many times for a lot of things.

Are you absolutely certain that the image is good and for the same drive type that you are trying to boot it on.

I see that you are using LInux ... Is yours set up to be able to read a FAT floppy? ... if so, can you ls the content of the floppy? (ie: is the directory good)

Do you happen to have DosBox (or any other Virtual MAchine) installed? If so, can it boot the image? - DosBox> boot imagefile

On my MySite->Downloads you'll find DOSBOOT.ZIP which has known good boot images (I've booted them all in Virtual Machines - and written most of the more recent ones to physical disks and booted them on real hardware) for 13 different editions of DOS, including 6.22

DaveDDS wrote on Yesterday, 21:39:

Do you happen to have DosBox (or any other Virtual MAchine) installed? If so, can it boot the image? - DosBox> boot imagefile

He wrote he tried, and it boot.
I also tried the same Dos6.22.img on 86box and it works.

I'm unfamiliar with sudo, but maybe you need to supply an extra switch to write the boot sector. Try sodo /? and tell me what happens. That should give you some help information.

Hi, I've used to use WinImage on Windows for this purpose.
There's also a 16-Bit version for Windows 3.1x (WinImage 3).
On DOS, there's graphical (menu driven) image software such as Teledisk or Disc Copy Fast (DCF).
The latter supports the *.ima format, too. I've already tried out.

On Linux, there's a graphical image tool, "GNOME Disk Utility", though it's more like Win32 Disk Imager on Windows.
It's more useful for writing/reading images of HDD or SD card images than floppies, I suppose.

Btw, how about using rawrite instead of dd on Linux?
Back in the 90s, I remember, install floppies were often created using rawrite.
Edit: Hm, there's no Linux version. It runs on DOS, Windows..

Boot the 386 with the DOS 4.01 floppy and see if it will even read the DOS 6.22 floppy that you wrote. Before trying to troubleshoot a potential image writing issue (which I don't think it is tbh) you want to make sure the disk is readable across both drives.

Try installing mtools, you can use it on images as well as real floppies. You should be able to 'mdir' the dos622 IMG if it is a real FAT12 disk image.
Of course you should also be able to loop mount the disk image using losetup and mount, or just use the Gnome disk image mounter to check it's working/genuine.

dd is definitely what you should be using, normally for writing dos floppy images I don't use any block size or conv prams, and it just works.

Have you tried any other disks written by your usb floppy? I've a couple of different types of these drives and some are better than others.

NeoG_ wrote on Today, 01:16:

Boot the 386 with the DOS 4.01 floppy and see if it will even read the DOS 6.22 floppy that you wrote. Before trying to troubleshoot a potential image writing issue (which I don't think it is tbh) you want to make sure the disk is readable across both drives.

This. Try just reading the image after booting with a known good boot disk.

nali wrote on Yesterday, 23:12:

He wrote he tried, and it boot.
I also tried the same Dos6.22.img on 86box and it works.

Ok, I've not used 86box, but I do boot floppy images all the time is DosBox, VMware and PcEm - the fact that the image boots tells me it's good.

Which means transfer of the image to a physical diskette isn't working. I don't use Linux much, I'm not intimately familiar with "dd"...
A good exercise might be to transfer the image to a disk, then read it back info another image and see if that matches the original image.
Then... binary compare of the two might help figure out how it is being modified.

popcalent wrote on Yesterday, 17:10:

sudo dd if=Dos6.22.img of=/dev/sdc bs=512 conv=fsync status=progress

I just asked a friend who uses Linux MUCH more than I do, a he said to try dropping "conv" he never uses it and thinks it might add metadata to the output somehow.

i still use windows tools for this no rocket science

zapbuzz wrote on Today, 14:38:

i still use windows tools for this no rocket science

Exactly - this shouldn't be hard - I use my own XDISK(simpler for DOS/BIOS recognized format disks) or ImageDisk(more complex for ANY format disk) under DOS, DSKWRITE or WINIMAGE under Winblows.

But... OP was using "dd" within Linux.

popcalent wrote on Yesterday, 17:10:

$ sudo dd if=Dos6.22.img of=/dev/sdc bs=512 conv=fsync status=progress
1471488 bytes (1.5 MB, 1.4 MiB) copied, 162 s, 9.1 kB/s1474560 bytes (1.5 MB, 1.4 MiB) copied, 162.434 s, 9.1 kB/s

I just noticed this - common DOS disk images(.IMG) sizes are:

1160k    163,840 bytes 
2180k    184,320 bytes
3200k    204,800 bytes
4320k    327,680 bytes
5360k    368,640 bytes
6400k    409,600 bytes
7720k    737,280 bytes
81200k 1,228,800 bytes
91440k 1,474,560 bytes
102880k 2,949,120 bytes

So why exactly did "dd" transfer 1,471,488 bytes - not a full 1.44m disk image size.
There must be some sort of translation going on...