Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IMGMAKE DMF regression in August 2024 nightlies #5171

Closed
2 tasks done
dajhorn opened this issue Aug 12, 2024 · 10 comments · Fixed by #5172
Closed
2 tasks done

IMGMAKE DMF regression in August 2024 nightlies #5171

dajhorn opened this issue Aug 12, 2024 · 10 comments · Fixed by #5172
Labels

Comments

@dajhorn
Copy link
Contributor

dajhorn commented Aug 12, 2024

Describe the bug

Since sometime after the 2024.07.01 release, IMGMAKE does not apply the -rootdir or -spc parameters when making floppy disk images.

Steps to reproduce the behaviour

This image file is attached below:

C:\> IMGMAKE 2024.08.12-fatcopies1-rootdir32-spc4.ima -t fd_1440 -fatcopies 1 -rootdir 32 -spc 4
$ file 2024.08.12-fatcopies1-rootdir32-spc4.ima
2024.08.12-fatcopies1-rootdir32-spc4.ima: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "MSDOS5.0", FAT  1, root entries 224, sectors 2880 (volumes <=32 MB), sectors/FAT 9, sectors/track 18, serial number 0x99ce3, unlabeled, FAT (12 bit), followed by FAT

$ minfo -i 2024.08.12-fatcopies1-rootdir32-spc4.ima ::
device information:
===================
filename="2024.08.12-fatcopies1-rootdir32-spc4.ima"
sectors per track: 18
heads: 2
cylinders: 80

media byte: f0

mformat command line:
  mformat -t 80 -h 2 -s 18 -d 1 -i "2024.08.12-fatcopies1-rootdir32-spc4.ima" ::

bootsector information
======================
banner:"MSDOS5.0"
sector size: 512 bytes
cluster size: 1 sectors
reserved (boot) sectors: 1
fats: 1
max available root directory slots: 224
small size: 2880 sectors
media descriptor byte: 0xf0
sectors per fat: 9
sectors per track: 18
heads: 2
hidden sectors: 0
physical drive id: 0x0
reserved=0x0
dos4=0x29
serial number: 00099CE3
disk label="NO NAME    "
disk type="FAT12   "

Expected behavior

This image file, created with the 2024.07.01 release, is attached below:

$ file 2024.07.01-fatcopies1-rootdir32-spc4.ima
2024.07.01-fatcopies1-rootdir32-spc4.ima: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "MSDOS5.0", sectors/cluster 4, FAT  1, root entries 32, sectors 2880 (volumes <=32 MB), sectors/FAT 3, sectors/track 18, serial number 0x96581, unlabeled, FAT (12 bit), followed by FAT

$ minfo -i 2024.07.01-fatcopies1-rootdir32-spc4.ima ::
device information:
===================
filename="2024.07.01-fatcopies1-rootdir32-spc4.ima"
sectors per track: 18
heads: 2
cylinders: 80

media byte: f0

mformat command line:
  mformat -t 80 -h 2 -s 18 -d 1 -r 2 -c 4 -i "2024.07.01-fatcopies1-rootdir32-spc4.ima" ::

bootsector information
======================
banner:"MSDOS5.0"
sector size: 512 bytes
cluster size: 4 sectors
reserved (boot) sectors: 1
fats: 1
max available root directory slots: 32
small size: 2880 sectors
media descriptor byte: 0xf0
sectors per fat: 3
sectors per track: 18
heads: 2
hidden sectors: 0
physical drive id: 0x0
reserved=0x0
dos4=0x29
serial number: 00096581
disk label="NO NAME    "
disk type="FAT12   "

What operating system(s) this bug have occurred on?

Windows 11, Version 23H2, Build 22631.3958

What version(s) of DOSBox-X have this bug?

2024.08.11 Nightly Build

Used configuration

dosbox-x.exe -defaultconf

Output log

No response

Additional information

2024.07.01-fatcopies1-rootdir32-spc4.zip
2024.08.12-fatcopies1-rootdir32-spc4.zip

Have you checked that no similar bug report(s) exist?

  • I have searched and didn't find any similar bug report.

Code of Conduct & Contributing Guidelines

  • I agree to follow the code of conduct and the contributing guidelines.
@dajhorn dajhorn added the bug label Aug 12, 2024
@dajhorn
Copy link
Contributor Author

dajhorn commented Aug 12, 2024

The bisection of nightly builds is...

Good: 2024.08.05-fatcopies1-rootdir32-spc4.zip
Bad: 2024.08.07-fatcopies1-rootdir32-spc4.zip

@dajhorn
Copy link
Contributor Author

dajhorn commented Aug 12, 2024

Reverting 4462d88 restores the desired IMGMAKE behavior.

0001-Revert-Fix-incorrect-BPB-of-floppy-images-made-by-IM.patch

revert-git.39052650.zip

@maron2000
Copy link
Contributor

Well, reverting is obviously not a good idea unless you want incorrect BPBs for a standard floppies.
Try the nightly after PR #5172 is merged.

@dajhorn
Copy link
Contributor Author

dajhorn commented Aug 12, 2024

2702fc0 works-for-me in a local build.

Update: The -cps switch is still broken when I compile a 64-bit VS build from maron2000/dosbox-x-1@2702fc0.

Notably:

  • The bundled CHKDSK complains that there is a Suspicious descriptor in boot, but fsck.vfat (dosfstools-4.2) and chkdsk.exe (Windows 11, Build 10.0.22621.1) report that the filesystem is good.

  • chkdsk.exe (Windows 11, Build 10.0.22621.1) reports that the cluster size is 2048 bytes, but minfo (mtools-4.0.43) and file (libmagic 5.45) report a cluster size of 512 bytes.

Seems like a compound problem.

Example image: ChkdskSuspiciousDescriptorInBoot.zip

@dajhorn
Copy link
Contributor Author

dajhorn commented Aug 12, 2024

For testing and comparison:

C:\> IMGMAKE dosbox.ima -t fd_1440 -cps 4 -fatcopies 1 -rootdir 16

Should produce something similar to:

# mformat -i mtools.ima -C -c 4 -d 1 -f 1440 -r 1

Example image: mtools.zip

@dajhorn
Copy link
Contributor Author

dajhorn commented Aug 12, 2024

Another defect:

C:\> IMGMAKE fd1200.ima -t fd_1200 -fatcopies 1 -rootdir 32 -spc 1

The output is immediately malformed:

$ fsck.vfat -v fd1200.ima
fsck.fat 4.2 (2021-01-31)
Checking we can access the last sector of the filesystem
Filesystem has 2390 clusters but only space for 2387 FAT entries.

Unlike fsck.vfat, CHKDSK will report that the filesystem is clean immediately after IMGMAKE creates it, but report lost clusters and crash after the filesystem is populated.

chkdsk_000

Example 5¼" disk image: fd1200.zip

@maron2000
Copy link
Contributor

maron2000 commented Aug 13, 2024

Adjustment of sect_per_fat value was required for floppy images with customized root entries and/or fat copies.
Additional fix in PR #5172 enables fsck.vfat command to run without errors even after several files are copied to the floppy image.
Built-in CHKDSK command warns custom settings as Suspicious so we have to bear that.

IMGMAKE fd1200.ima -t fd_1200 -fatcopies 1 -rootdir 32 -spc 1
$ fsck.vfat -v fd1200.ima
fsck.fat 4.2 (2021-01-31)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "MSDOS5.0"
Media byte 0xf9 (3,5" 720k floppy 2s/80tr/9sec or 5.25" 1.2M floppy 2s/80tr/15sec)
       512 bytes per logical sector
       512 bytes per cluster
         1 reserved sector
First FAT starts at byte 512 (sector 1)
         1 FATs, 12 bit entries
      4096 bytes per FAT (= 8 sectors)
Root directory starts at byte 4608 (sector 9)
        32 root directory entries
Data area starts at byte 5632 (sector 11)
      2389 data clusters (1223168 bytes)
15 sectors/track, 2 heads
         0 hidden sectors
      2400 sectors total
Checking for unused clusters.
fd1200.ima: 31 files, 1148/2389 clusters
$ minfo -i fd1200.ima ::
device information:
===================
filename="fd1200.ima"
sectors per track: 15
heads: 2
cylinders: 80

media byte: f9

mformat command line:
  mformat -t 80 -h 2 -s 15 -d 1 -r 2 -m 249 -i "fd1200.ima" ::

bootsector information
======================
banner:"MSDOS5.0"
sector size: 512 bytes
cluster size: 1 sectors
reserved (boot) sectors: 1
fats: 1
max available root directory slots: 32
small size: 2400 sectors
media descriptor byte: 0xf9
sectors per fat: 8
sectors per track: 15
heads: 2
hidden sectors: 0
physical drive id: 0x0
reserved=0x0
dos4=0x29
serial number: 001230E4
disk label="NO NAME    "
disk type="FAT12   "

@maron2000
Copy link
Contributor

maron2000 commented Aug 13, 2024

I also installed minfo command, and tried the command in your original post.
Cluster size is okay (four sectors) according to fsck.vfat and minfo, and CHKDSK spits no errors (besides the Suspicious ... ).

IMGMAKE 2024.08.12-fatcopies1-rootdir32-spc4.ima -t fd_1440 -fatcopies 1 -rootdir 32 -spc 4
$ fsck.vfat -v 2024.08.12-fatcopies1-rootdir32-spc4.ima
fsck.fat 4.2 (2021-01-31)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "MSDOS5.0"
Media byte 0xf0 (5.25" or 3.5" HD floppy)
       512 bytes per logical sector
      2048 bytes per cluster
         1 reserved sector
First FAT starts at byte 512 (sector 1)
         1 FATs, 12 bit entries
      1536 bytes per FAT (= 3 sectors)
Root directory starts at byte 2048 (sector 4)
        32 root directory entries
Data area starts at byte 3072 (sector 6)
       718 data clusters (1470464 bytes)
18 sectors/track, 2 heads
         0 hidden sectors
      2880 sectors total
Checking for unused clusters.
2024.08.12-fatcopies1-rootdir32-spc4.ima: 31 files, 301/718 clusters
$ minfo -i 2024.08.12-fatcopies1-rootdir32-spc4.ima ::
device information:
===================
filename="2024.08.12-fatcopies1-rootdir32-spc4.ima"
sectors per track: 18
heads: 2
cylinders: 80

media byte: f0

mformat command line:
  mformat -t 80 -h 2 -s 18 -d 1 -r 2 -c 4 -i "2024.08.12-fatcopies1-rootdir32-spc4.ima" ::

bootsector information
======================
banner:"MSDOS5.0"
sector size: 512 bytes
cluster size: 4 sectors
reserved (boot) sectors: 1
fats: 1
max available root directory slots: 32
small size: 2880 sectors
media descriptor byte: 0xf0
sectors per fat: 3
sectors per track: 18
heads: 2
hidden sectors: 0
physical drive id: 0x0
reserved=0x0
dos4=0x29
serial number: 0014C3EB
disk label="NO NAME    "
disk type="FAT12   "

image

@dajhorn
Copy link
Contributor Author

dajhorn commented Aug 14, 2024

maron2000/dosbox-x-1@f0315d7 is giving me a good result in local builds.

Perhaps the Suspicious descriptor in boot glitch in CHKDSK.EXE should be ticketed separately.

@maron2000
Copy link
Contributor

You may want to be reminded that CHKDSK is built and maintained by FreeDOS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
2 participants