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
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
