All the sys command really does perform a file copy of two or three files to be placed in the first file positions in the file system, because that is how the DOS boot works with those files at the beginning locations, and sets some attributes. Your backup and restore process is not actual taking an image, but just copying the files across in whatever order, isn't it? You will also likely need to mark the partition bootable and write the correct mbr. Or you can take a full image of the drive to avoid this altogether.

Thanks for your answer the3dfxdude!

Yes, I considered modifying my backup / restore scripts to make a "raw" image of the partition, but it has some drawbacks if the partition size is different than the original one. Also, I like to be able to inspect or modify easily the files in my image (and yes, it's a simple tar | 7zipped file).

Now that you've mentionned it, maybe just extracting the files in the right order and then patching some few sectors at the beginning of the partition could do the job ? I was assuming that SYS.COM was locating the sector position of the different .SYS files and patching that in the boot code so that it can load those files easily (without a full FAT implementation), but maybe it's a bit simpler than that (unless the partition first sectors contain information about the FAT or directory positions...). I'll give it a try.

The DOS boot loader should find the first file no matter what, as long as everything is written where it should be. I don't think it is really patching anything. All this is possible with fdisk, setting the boot flag, or fdisk /mbr sometimes, format, then sys if done separately.

Taking disk/partition images should be "bigger" than simple archives of all the files. That is because that is necessary information that you threw away, and now have to recreate.

Generally, I find it simple enough to boot a DOS floppy disk to setup any hard disk and transfer the initial system files. Then boot with the drive in a linux system, and copy the other files over you backed up, except the system files, since you don't need to have those in the backup to restore. Another way could be to boot up linux and run dosemu with a bootable floppy disk image, and direct access to the hard drive you wish to set up. Then go through the same steps. Otherwise you'd be looking at writing a script to skip the initial dos setup and do the hard disk setup on your own, or doing a fuller backup and restore of the entire disk/partition.

The only other thing about disk images (other than they are bigger), is that they will not fit the same on another drive. But there are tools to handle that.

The boot sector code depends of the OS it's supposed to boot:
- for PC DOS, it's supposed to load and run IBMBIO.COM and IBMDOS.COM
- for MS-DOS, it's supposed to load and run IO.SYS and MSDOS.SYS, in later versions only IO.SYS
- for other systems, other file names and loading procedures

In effect, the only tools that can be trusted to install proper boot record code are those provided with the OS you want to boot.

But if you really insist on installing DOS boot record from Linux, then OK, it's perfectly possible:
- dumping/restoring of 16 sectors is too much, this way you're probably also overwritting FAT table(s), corrupting the filesystem
- the entire boot record code is located in the first sector
- in the first sector, however, there's more than the code - there are also data
- the data depend on diskette/partition size and geometry, they are properly generated by the FORMAT command, and hopefully by the Linux mkfs.vfat as well
- so, dump and restore only the part of the first sector that contains the code
- keep in mind the boot sector code isn't very intelligent - it may require the IO.SYS to be the first root directory entry, and the file not to be fragmented
- the above conditions can be easily satisfied by copying IO.SYS as the first file onto an empty diskette/partition
- it may be required for the IO.SYS to have certain attributes (RO, Hidden, System), search for stuff like https://manpages.ubuntu.com/manpages/jammy/ma … /fatattr.1.html and https://man7.org/linux/man-pages/man2/ioctl_fat.2.html

I guess another way to deal with this would be to create a very small partition (fat16 or fat32 filesystem) with just the system files in actual DOS, image with dd in linux. And then the first steps at restoring would be to write the image, and then do a filesystem resize, and then copy the rest of the files over.

I missed this part of the mkfs.vfat man page:

BUGS
mkfs.fat can not create boot-able filesystems. This isn't as easy as you might think at first glance for var‐
ious reasons and has been discussed a lot already. mkfs.fat simply will not support it 😉

the3dfxdude wrote on 2023-12-18, 15:49:

I guess another way to deal with this would be to create a very small partition (fat16 or fat32 filesystem) with just the system files in actual DOS, image with dd in linux. And then the first steps at restoring would be to write the image, and then do a filesystem resize, and then copy the rest of the files over.

OK, but how to resize a FAT filesystem from Linux?

For other filesystems, there are the tools:
- resize2fs
- xfs_growfs

Is there something equivalent for FAT?

I just did the following experiment: make a binary dump of my original Windows 98 partition (not diskà, then restore the partition with my tool, fix it with SYS.COM A: C: and do another binary dump of the partition.

I then checked what has changed between the two dumps:
* Byte at offset 36 changed from FBh to F8h.
* Bytes at offset 1000 changed from B9h 14h 07h 00h 02h 00h to FFh FFh FFh FFh 1Bh E7h.
* Of course everything is changed starting from the FAT location...

Not sure yet what this mean... As this is the beginning of the partition it should be the "VBR" (Volume Boot Record) ? Documentation on this VBR strcuture seems a bit harder to find compared to the MBR (Master Boot Record). Not sure if SYS.COM modifies things or not in the MBR (I should have made a dump of the whole disk and not just the partition...).

Grzyb wrote on 2023-12-18, 16:01:

OK, but how to resize a FAT filesystem from Linux? […]
Show full quote

the3dfxdude wrote on 2023-12-18, 15:49:

I guess another way to deal with this would be to create a very small partition (fat16 or fat32 filesystem) with just the system files in actual DOS, image with dd in linux. And then the first steps at restoring would be to write the image, and then do a filesystem resize, and then copy the rest of the files over.

OK, but how to resize a FAT filesystem from Linux?

For other filesystems, there are the tools:
- resize2fs
- xfs_growfs

Is there something equivalent for FAT?

gparted? There are others.

@the3dfxdude : your suggestion looks very interesting indeed ! I'll probably need to not overwriting the existing files, that implies to have different RAW / dd images depending on the OS to restore.

I'll check for the CLI tool that could do the resize automatically...

EDIT: The GUI version of GParted can indeed resize a FAT32 partition in both directions without any issue.

I just use the clonezilla linux image, much easier =)

Louthrax wrote on 2023-12-18, 15:57:

I missed this part of the mkfs.vfat man page: […]
Show full quote

I missed this part of the mkfs.vfat man page:

BUGS
mkfs.fat can not create boot-able filesystems. This isn't as easy as you might think at first glance for var‐
ious reasons and has been discussed a lot already. mkfs.fat simply will not support it 😉

The problem for a FOSS project is that bootable disks contain copyrighted boot code. There is no technical reason that you couldn't write out a copy of the necessary MBR/VBR with the necessary parameters to make it bootable. You can even do it manually with a sector editor.

There is good info on the various boot sectors here: https://thestarman.pcministry.com/asm/mbr/index.html

I finally have a working script using the "fatresize" Linux tool. It's only resizing the file system, but as mkfs.fat uses to whole available space to initialize a partition, that's not an issue.

Also, this surprised me a bit, but no files are required in the dd | 7z raw image (they are present after restoration anyway). I was assuming that the boot code was containing some sector indexes, but that does not seem to be the case after all.

I can share details or even my scripts for those interested.

So everything was working well and I was happy, until one of my 128MB memory stick went fault this morning (confirmed by MemTest...).

Anyway, thanks to everyone here for the quick and helpful answers 😀 !

giantclam wrote on 2023-12-18, 23:22:

I just use the clonezilla linux image, much easier =)

Yes, I remember I had a look at the tool in the past (that was a long time ago) but decided to go for my own solution. I do not remember why !

Would it work on "old" PCs (~384MB RAM) and be easily customized to have a configured NAS ?

You can use "ms-sys" to write DOS IPL to MBR and partition boot record.

Louthrax wrote on 2023-12-19, 14:26:

giantclam wrote on 2023-12-18, 23:22:

I just use the clonezilla linux image, much easier =)

Yes, I remember I had a look at the tool in the past (that was a long time ago) but decided to go for my own solution. I do not remember why !

Would it work on "old" PCs (~384MB RAM) and be easily customized to have a configured NAS ?

I use a separate circa 2010 mainboard for this stuff with IDE (PATA) ports ~ 'vintage' hardware is too slow....(in theory MFM & 16bit XT IDE drives are supported if the mainboard used supports the hardware)... I ?think? clonezilla requires a 686, but I might be wrong (I'm only interested in speed of operation anyhow)...

....clonezilla can save/restore images from NAS, ftp, network share as well as physical media... you can customize operations with profiles...(or command lines)..

....many folks are reticent to remove the HDD from their older machines for such operations ~ I can restore a base win98 install for instance is less than 5minutes. When you compare that to 'reinstalling windows', removing and reinstalling the HDD is likely the longer job, compared to the restore operation itself....(and reinstalling win98 from scratch as you know is a drawn out event) ....moving a HDD about is much faster and simpler =)

After some investigations (the StarMan's website mentionned by bakemono was really helpful), I think I've identified the "code only" portions of the Volume Boot Record for Windows 98 (it's split in 2 parts).

This bash code seems to work for Windows 98:

1mbr_code='33C08ED0BC007CFB5007501FFCBE1B7CBF1B065057B9E501F3A4CBBEBE07B104382C7C09751583C610E2F5CD188B148BEE83C610497416382C74F6BE10074EAC3C0074FABB0700B40ECD10EBF2894625968A4604B4063C0E7411B40B3C0C74053AC4752B40C64625067524BBAA5550B441CD1358721681FB55AA7510F6C101740B8AE0885624C706A106EB1E886604BF0A00B801028BDC33C983FF057F038B4E25034E02CD137229BE7507813EFE7D55AA745A83EF057FDA85F67583BE3F07EB8A9891529903460813560AE812005AEBD54F74E433C0CD13EBB80000805201195633F656565250065351BE1000568BF45052B800428A5624CD135A588D6410720A4075014280C702E2F7F85EC3EB74496E76616C696420706172746974696F6E207461626C652E2053657475702063616E6E6F7420636F6E74696E75652E004572726F72206C6F6164696E67206F7065726174696E672073797374656D2E2053657475702063616E6E6F7420636F6E74696E75652E00000000000000000000000000008BFC1E578BF5CB00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
2
3vbr_code1='FA33C98ED1BCF87B8EC1BD7800C576001E561655BF2205897E00894E02B10BFCF3A48ED9BD007CC645FE0F8B46188845F9384E407D258BC199BB0007E89700721A83EB3A66A11C7C663B078A57FC750680CA0288560280C31073EDBF0200837E160075458B461C8B561EB903004940750142BB007EE85F007326B0F84F741D8B463233D2B903003BC8771E8B760E3BCE73172BF103461C13561EEBD1730BEB27837E2A007703E9FD02BE7E7DAC9803F0AC84C074173CFF7409B40EBB0700CD10EBEEBE817DEBE5BE7F7DEBE098CD165E1F668F04CD194156666A00525006536A016A108BF460807E020E7504B442EB1D919233D2F7761891F776184287CAF7761A8AF28AE8C0CC020ACCB801028A5640CD13618D64105E720A40750142035E0B4975B4C3031801270D0A496E76616C69642073797374656D206469736BFF0D0A4469736B20492F4F206572726F72FF0D0A5265706C61636520746865206469736B2C20616E64207468656E20707265737320616E79206B65790D0A000000494F2020202020205359534D53444F532020205359537E010057494E424F4F5420535953000055AA'
4
5vbr_code2='FA660FB64610668B4E2466F7E16603461C660FB7560E6603C233C9668946FC66C746F8FFFFFFFFFA668B462C6683F8020F82CFFC663DF8FFFF0F0F83C5FC660FA4C210FB5250FA66C1E010660FACD0106683E802660FB65E0D8BF366F7E3660346FC660FA4C210FBBB00078BFBB90100E8BEFC0F82AAFC382D741EB10B56BED87DF3A65E741903F983C7153BFB72E84E75D6585AE8660072AB83C404E964FC83C4048B75098B7D0F8BC6FA66C1E0108BC76683F802723B663DF8FFFF0F733366486648660FB64E0D66F7E1660346FC660FA4C210FBBB000753B90400E852FC5B0F823DFC813F4D5A750881BF0002424A7406BE807DE90EFCEA0002700003C013D203C013D2E81800FA26668B016625FFFFFF0F660FA4C210663DF8FFFF0FFBC3BF007EFA66C1E010660FACD010660FB74E0B6633D266F7F1663B46F87444668946F86603461C660FB74E0E6603C1660FB75E2883E30F74163A5E100F83A4FB52668BC8668B462466F7E36603C15A52660FA4C210FB8BDFB90100E8B4FB5A0F829FFBFB8BDAC300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055AA'
6
7echo $mbr_code | xxd -r -p | dd of=/dev/sda
8
9echo $vbr_code1 | xxd -r -p | dd of=/dev/sda1 bs=1 seek=90
10echo $vbr_code1 | xxd -r -p | dd of=/dev/sda1 bs=1 seek=3162
11
12echo $vbr_code2 | xxd -r -p | dd of=/dev/sda1 bs=1 seek=1024
13echo $vbr_code2 | xxd -r -p | dd of=/dev/sda1 bs=1 seek=4096

It should not impact any "data" areas created by Linux's sfdisk and mkfs.vfat (so it can be applied after creating your partitions and file systems), and do the same thing as what "SYS.COM" does, except it does not copy any system files (no interest for this if you restore all your files including the system ones from a backup after that).

Maybe a more versatile script containing different versions of the MBR and VBR for Windows 2000 / NT / XP could be done (with some parameter to choose between them) could be done...