Re: [Freedos-user] Can FreeDOS Be Installed By Means Of UNIX Commands?

[C. M. <pu...@ul...>]

Hi,

On at 2023-07-16 09:21 -0500, Jay F. Shachter via Freedos-user wrote:
> 
> Esteemed Colleagues:
> 
> I have a computer, with an MBR-partitioned disk, that is configured to
> perform Legacy boot.  Microsoft Windows is installed on three primary
> partitions, because that is what Windows does, and every other
> operating system on this computer must find a home for itself within
> the logical partitions carved out of the fourth, extended partition.
> 
> I want to install FreeDOS on a logical partition.  So my first
> question is: Does FreeDOS even support this?  Many operating systems
> do not, and only support installation on primary partitions, and on
> GPT-partitioned disks.

The FreeDOS kernel expects its FDCONFIG.SYS ("altconfig", the preferred 
alternative) or CONFIG.SYS ("oldconfig", the old fallback) on whatever 
file system it detects as the C: drive. Technically, this is the *only* 
file you need on what is detected as drive C:, as you can use lines like 
"device=f:\..." and "shell=f:\command.com /p:f:\fdauto.bat" to make use 
of a different drive for other things. (Some DOS programs may expect to 
use drive C: regardless, so watch out.)

(Using the kernel command line extension I added [1] to the kernel in 
2022, you can specify different CONFIG/ALTCONFIG/OLDCONFIG pathnames to 
try a file on a different drive than drive C:, but the only ways to pass 
a kernel command line are currently to boot into my debugger (lDebug 
[2], with a small L) and use it to load the kernel; or to pack the 
kernel executable into my iniload + fdkernpl stages then boot it as 
Multiboot1 or Multiboot2 specification kernel from GRUB which allows to 
pass along a command line as well. I can give more detailed instructions 
on those if you want.)

The kernel will detect drive C: based on which partitions are primary 
and logical. If you have only a single HDD, then probably the first 
visible primary FAT FS partition gets to be drive C: (regardless the 
actual placement on the hard disk; only the position in the partition 
tables should matter).

The kernel is loaded in its entirety by the boot sector loader, or 
whatever is fulfilling its role. That means the kernel itself doesn't 
need to know what drive/partition it was loaded from. Technically, the 
loader will pass along the boot sector with a BPB/EBPB of what partition 
it loaded from, but the kernel does not (yet) make any use of it. (Not 
true if you replace the FreeDOS kernel file by my debugger executable, 
lDebug does make use of this info.) This includes that it does not use 
it for the determination of what drive gets to be drive C:.

As for the boot sector loader, FreeDOS's originals should be able to 
load from a logical partition if you correctly set up the hidden sectors 
field (should give LBA sector number of the boot sector itself in the 
total disk unit, not uninitialised and not counting within the extended 
partition) and possibly the two CHS geometry fields (if the sector will 
use CHS access to load the kernel). All you need to do then is to 
instruct your prior loader to chainload the boot sector loader, either 
from a dump file or from the actual boot sector of the logical partition.

(In my ldosboot repo [3] I provide alternative loaders which can with 
some degree of success auto-detect the hidden sectors and CHS geometry. 
However, not all of these features are available in combination with the 
FreeDOS load protocol because of how much code it requires. But you 
could instead use the lDOS boot loaders to load lDebug, then use lDebug 
to load the FreeDOS kernel.)

To install the proper superblock values into a boot sector dump file, or 
inversely install the proper boot loader into the actual sector while 
leaving intact the superblock values (called the BPB or EBPB), you can 
use a DOS tool like my instsect (a build is included in lDebug packages) 
or the kernel's SYS utility (comes with kernel builds). SYS will 
obviously default to install the loader corresponding to its kernel; 
instsect has default loaders built-in but you can specify a file to read 
the loader from instead. (Do not try lDebug's instsect's default 
built-in loader with the unmodified FreeDOS kernel -- it will fail to 
load it, even if you change the filenames to match. This is because 
these loaders load using the lDOS load protocol rather than the FreeDOS 
one.)

SYS can write the resulting sector to a drive or to a dump file, 
likewise instsect. What I think is a feature unique to instsect is to 
operate on a partition image that appears to DOS as a file, rather than 
a drive, both for reading the superblock values as well as installing 
the resulting sector. However, both programs are DOS programs, so you 
need some sort of DOS running on the system or with access to the drive 
(image) that you want to install to.

The core feature of SYS and instsect is not super difficult to replicate 
using dd. You just need to copy over the (E)BPB of the superblock to 
combine it with the boot sector loader, and write the result either to 
the boot sector or to a boot sector dump file. The exact numbers can be 
looked up. For example, here is the spot [4] at which instsect does 
this, and here are the structures defining those offsets [5].

The default FreeDOS boot sector loaders can be obtained from my 
automatic current FreeDOS kernel build at [6] in the boot/ subdirectory. 
They aren't difficult to build from source using NASM, either. You want 
fat12com.bin for FAT12 FS, fat16com.bin for FAT16 FS, fat32chs.bin for 
FAT32 FS accessed using CHS, or fat32lba.bin for FAT32 FS accessed using 
LBA (this one currently requires running a 386+ machine).

Depending on how current your GRUB is, you can also use the "freedos" 
command to load the FreeDOS kernel directly, no boot sector loader / 
chainloader needed. In recent years I had several patches merged into 
GRUB2 development to fix this command, so now a recent GRUB2 will also 
pass along the (E)BPB / boot sector of its root file system (not yet 
used by the kernel, as mentioned) and also allows the kernel file to 
exceed 64 KiB in size. (As also mentioned before, if you pack the kernel 
into my iniload + fdkernpl stages you can also load it from GRUB(2) as a 
Multiboot1/2 kernel, or as an MS-DOS (IO.SYS) kernel, or IBM-DOS 
(IBMBIO.COM) kernel.)

If you absolutely do not want an FDCONFIG.SYS file on your first primary 
partition used by MSWindows, or want your logical FreeDOS partition to 
appear as drive C: to improve compatibility, then you will have to look 
into boot loaders that allow to hide partitions before booting other 
partitions. I believe that GRUB may provide something like this, too. I 
do not have much experience with those.

There is one more trick you may want to use: Our DRVEXCH [7] allows to 
re-order FAT FS drives after the fact. So if you boot with FreeDOS 
installed on drive F:, but FDCONFIG.SYS on what appears as drive C:, 
then you can use DRVEXCH after booting to swap these drives. (Or swap 
repeatedly until drive F: moves down to the drive C: spot while moving 
up all drives between them.)


> If the answer to the first question is Yes, then I can continue this
> narrative, otherwise the remainder of this posting is moot.

It's basically, "No, but...".

> I copied
> FD13FULL.img to a USB stick, stuck it into the above-described
> computer, and instructed it to boot from the USB device.  The
> installation procedure scares me.  I have already partitioned my disk
> and designated in my mind the logical slice onto which I want to
> install FreeDOS, but the installation procedure on FD13FULL.img
> implies that I must repartition my disk, and I am afraid to proceed,
> lest I irretrievably trash my entire computer.

Others can reply to this better than I can, as I last used the installer 
in the FreeDOS 1.0 days in 2008 or so.

> Is it possible to install FreeDOS using UNIX commands, which I know
> how to control?  I envision doing a "mkfs -t vfat" on the logical
> slice of disk on which I want to install the system,

That should work.

> mounting the USB
> stick on some arbitrary directory, and then populating the
> newly-created vfat filesystem by means of the cp and unzip commands
> (the packages, I noticed -- and there is a huge number of them -- are
> zip files,

Indeed.

> but there are also some files that are fundamental to
> system that are already present without having to be unzipped, which I
> envision simply copying over).

The most important files are KERNEL.SYS (FreeDOS kernel), COMMAND.COM 
(FreeCOM shell), and the FDCONFIG.SYS which as I mentioned needs to live 
on what is mounted as drive C: (initially). The two executables can be 
found in my current builds as well [6] [8]. You also want some sort of 
AUTOEXEC.BAT (or FDAUTO.BAT or whatever other name you want). You can 
use files found in the installer or live systems as examples for the 
configuration files.

> And then finally I envision using the
> dd command in some way to populate the first block of the vfat
> filesystem with a bootloader, so that GRUB can boot FreeDOS with
> something along the lines of "chainloader (hd0,msdos11)+1".  Or
> perhaps a bootloader is unnecessary, perhaps GRUB can be given the
> name of the FreeDOS kernel and boot directly into it without having to
> use the chainloader command.

As mentioned above. You can use the chainloader (either to a dumped file 
with the proper superblock values, or to the actual sector), or you can 
use GRUB2's "freedos" command. (Or the "multiboot" or "multiboot2" 
commands, if you use my custom kernel stages.)

> Is this possible?  If a FreeDOS system is populated in this way, will
> the kernel be able to boot and then figure out how big the disk is and
> all the other things that will be different than they were in
> FD13FULL.img?

Yes, none of this is hardcoded.

> If not, is there anyone reading this who is willing to
> gently and patiently walk me thru the native install procedure and
> assure me that it will not trash my hard drive?
> 
> As always, thank you in advance for any and all replies.

Regards,
ecm


[1]: 
https://github.com/FDOS/kernel/commit/b562983222fa84d834035402ffa56ded4d212fc9
[2]: https://pushbx.org/ecm/web/#projects-ldebug
[3]: https://pushbx.org/ecm/web/#projects-ldosboot
[4]: https://hg.pushbx.org/ecm/instsect/file/18edcefc9877/instsect.asm#l1734
[5]: https://hg.pushbx.org/ecm/instsect/file/18edcefc9877/instsect.asm#l44
[6]: https://pushbx.org/ecm/download/fdkernel.zip
[7]: https://www.bttr-software.de/products/drvexch/
[8]: https://pushbx.org/ecm/download/freecom.zip