Cannot boot on HD image

[mfld-fr]

Reported by Paul on the mailing list, and reproduced with latest pre-0.3.1 version with the qemu.sh script.

Booting from the default HD image (~32 MB) with MINIX filesystem hangs on VFS prompt asking the user to insert floppy. Kernel reports correctly bda but incorrectly bda4, as this image is flat and not partitioned.

After inserting a MINIX floppy to unblock the initial mount, user can login then mount /dev/bda on /mnt.

User also complains for a missing 'chroot' command.

See also #199 for related open issue.

[pawosm-arm]

It's Paul here. Please notify me of the changes to this ticket.

[jbruchon]

Hey Paul! You're automatically subscribed by commenting, but in the future you can hit the subscribe button on the lower-right sidebar of any issue or pull request and it'll add you to the notification squad. :-)

[georgp24]

MFLD wrote in the forum: https://www.spinics.net/lists/linux-8086/msg00937.html

Hello Paul,
Regression should be fixed now by latest commits.
I selected CONFIG_IMG_HD, set CHS to 80/2/18 and size to 1440 blocks (to mimic a floppy).
After modifying 'qemu.sh' to boot on 'image/hd.bin', got the ELKS login prompt. 

So I tried that. This is my .config file in the elks directory:

#
# Target image
#
CONFIG_IMG_MINIX=y
# CONFIG_IMG_FAT is not set
# CONFIG_IMG_RAW is not set
# CONFIG_IMG_ROM is not set
CONFIG_IMG_LINK=y
# CONFIG_IMG_FD1680 is not set
# CONFIG_IMG_FD1440 is not set
# CONFIG_IMG_FD1200 is not set
# CONFIG_IMG_FD720 is not set
# CONFIG_IMG_FD360 is not set
CONFIG_IMG_HD=y
CONFIG_IMG_DEV=y
CONFIG_IMG_SECT=18
CONFIG_IMG_HEAD=2
CONFIG_IMG_CYL=80
CONFIG_IMG_BLOCKS=1440
CONFIG_IMG_BOOT=y

When I run qemu.sh with IMAGE="-hda image/hd.bin" I get:

Booting from Hard Disk....
ELKS....3!
Press any key

So I cannot boot from this Minix hard disk.

[pawosm-arm]

This is step back comparing to what this bug report is all about (and I guess the topic is slightly misleading). Also, my bug reports are all about the real thing experience, while you seem to failed to boot it into qemu...

[georgp24]

The title says: "Cannot boot on HD image" and MFLD posted his test results in the discussion with you on the forum regarding booting from HD. So I think I can mention my problem here.

[pawosm-arm]

Ah, yeah. What I meant was, you've got some reproducing scenario to something that looks like a regression to me, hence I was thinking it deserves separate ticket.

[pawosm-arm]

For the Kernel reports correctly bda but incorrectly bda4, as this image is flat and not partitioned part it is easy to address with a patch like this:

--- a/elks/arch/i86/drivers/block/genhd.c
+++ b/elks/arch/i86/drivers/block/genhd.c
@@ -25,8 +25,9 @@

 #include <arch/system.h>

-#define NR_SECTS(p)    p->nr_sects
-#define START_SECT(p)  p->start_sect
+#define SYS_IND(p)     ((p)->sys_ind)
+#define NR_SECTS(p)    ((p)->nr_sects)
+#define START_SECT(p)  ((p)->start_sect)

 extern int blk_dev_init();

@@ -122,7 +123,7 @@ static void extended_partition(register struct gendisk *hd, kdev_t dev)
         * First process the data partition(s)
         */
        for (i = 0; i < 4; i++, p++) {
-           if (!NR_SECTS(p) || is_extended_partition(p))
+           if ((!SYS_IND(p)) || (!NR_SECTS(p)) || (is_extended_partition(p)))
                continue;

            /* Check the 3rd and 4th entries -
@@ -152,7 +153,7 @@ static void extended_partition(register struct gendisk *hd, kdev_t dev)
         */
        p -= 4;
        for (i = 0; i < 4; i++, p++)
-           if (NR_SECTS(p) && is_extended_partition(p))
+           if ((SYS_IND(p)) && (NR_SECTS(p)) && (is_extended_partition(p)))
                break;
        if (i == 4)
            goto done;          /* nothing left to do */
@@ -207,7 +208,7 @@ static int msdos_partition(struct gendisk *hd,
     current_minor += 4;
     for (i = 1; i <= 4; minor++, i++, p++) {
        hdp = &hd->part[minor];
-       if (!NR_SECTS(p))
+       if ((!SYS_IND(p)) || (!NR_SECTS(p)))
            continue;
        add_partition(hd, minor, first_sector + START_SECT(p), NR_SECTS(p));
        if (is_extended_partition(p)) {

Unfortunately, this does not help with anything. Rootfs is still looked for in the sector 2:

hd: error: AX = 0x80
BIOSHD: I/O error
dev 380, sector 2
minix: unable to read sb

Well, doing sudo mount -o loop,ro,offset=1024 hd.bin /mnt/loop (sector 2 starts at the offset 1024) fails on my Linux PC too:

[26575.129400] (mount,87331,4):ocfs2_fill_super:1023 ERROR: superblock probe failed!
[26575.129404] (mount,87331,4):ocfs2_fill_super:1225 ERROR: status = -22

...while doing it with offset=0 ends with a successful mount.

[pawosm-arm]

Well, I was wrong about sector 2, this is exactly what was needed. It's the 0x80 that was wrong, it should have been zero. I've prepared simple hack like this:

--- a/elks/arch/i86/drivers/block/doshd.c
+++ b/elks/arch/i86/drivers/block/doshd.c
@@ -686,7 +686,7 @@ static void do_bioshd_request(void)
            end_request(0);
            continue;
        }
-       minor = MINOR(req->rq_dev);
+       minor = 0; /* MINOR(req->rq_dev); */

 #if 0
        part = minor & ((1 << 6) - 1);

And now I have complete boot with init started all from CF card, for a first time.

This is NOT a complete solution as it effectively makes floppy disk drive inaccessible, yet it shows where the problem exists (I guess HD image metadata are wrongly configured to force the kernel to always look into FDD device for rootfs).

[ghaerr]

It's the 0x80 that was wrong, it should have been zero. I've prepared simple hack like this:

--- a/elks/arch/i86/drivers/block/doshd.c
+++ b/elks/arch/i86/drivers/block/doshd.c
-       minor = MINOR(req->rq_dev);
+       minor = 0; /* MINOR(req->rq_dev); */

And now I have complete boot with init started all from CF card, for a first time.

@pawosm-arm: This fixes your problem because block device 3,0 is /dev/bda (hard disk), and by default, the system thinks the root device is 3,128 which is /dev/fd0 (floppy).

@mfld-fr and @tkchia, it seems that the reason that the system isn't booting from an HD image is that VFS thinks the root device is 3,128. It gets this information from setup.S, right? It seems that the ROOT_DEV which used to be at location 508-509 in the boot sector is no longer there (replaced by the EPB), but is in the boot sector of 'Image'. I can't tell if the second 'bootsector.S' is being used. However, when constructing the system, 'build', if not given a 4th parameter, uses a compiled in default of 3,128 for ROOT_DEV, which is placed in the first sector of 'Image', and subsequently used by VFS. What do you think of all this, is this the reason?

I have had a very hard time understanding whether the elks/arch/i86/boot/bootsector.S boot code which is the first block of 'Image' before 'setup' is actually running. In any case, it appears that 'setup.S' is using the wrong location to grab the root device.

[georgp24]

In my script I patch the ROOT_DEV as 0301 (0103 little endian) in the kernel file.

[mfld-fr]

@ghaerr : What is missing is the 'MINIX or FAT boot sector' to pass the BIOS boot drive number to setup, so that it is converted by setup to the right MAJOR / MINOR for the kernel in ROOT_DEV.

When booting from the 'boot blocks', the original 'raw boot sector' that is the first of the Image is just used as a configuration data space (= INITSEG).

All the other stuff to set ROOT_DEV from configuration, scripts, by hand, etc., is the wrong way (except for ROM configuration).

[tkchia]

Hello @mfld-fr,

What is missing is the 'MINIX or FAT boot sector' to pass the BIOS boot drive number to setup, so that it is converted by setup to the right MAJOR / MINOR for the kernel in ROOT_DEV.

Agreed.

Hello @ghaerr,

@mfld-fr and @tkchia, it seems that the reason that the system isn't booting from an HD image is that VFS thinks the root device is 3,128. It gets this information from setup.S, right? It seems that the ROOT_DEV which used to be at location 508-509 in the boot sector is no longer there (replaced by the EPB), but is in the boot sector of 'Image'. I can't tell if the second 'bootsector.S' is being used.

Well, it looks like the Linux/x86-32 Boot Protocol rears its head again (at the risk of repeating myself).

Basically, the situation is as follows (assuming boot disk = root disk, and a Minix filesystem):

            0                                                   0x1fc  0x1fe
            __________________________________________________________________
           |                                    |             |      |        |
Minix      | actual                             | ELKS        | "eL" | 0xaa55 |
filesystem | boot sector                        | disk parms. |      |        |
start      |____________________________________|_____________|______|________|
           |                                                                  |
           | rest of bootloader                                               |
           |__________________________________________________________________|

                                   0x1f1                       0x1fc  0x1fe
            __________________________________________________________________
/linux     |                      |         |        | video  |      |        |
           | dummy                | setup   |  ...   |  mode  | root | 0xaa55 |
           | boot sector          | # sects |        |(unused)| dev. |        |
           |______________________|_________|________|________|______|________|
           |                                                                  |
           | setup (usually 4 sectors, i.e. 2 KiB)                            |
           :                                                                  :
           :                                                                  :
           |__________________________________________________________________|
           | a.out kernel                                                     |
           :                                                                  :
           :                                                                  :
           |__________________________________________________________________|

The dummy boot sector is not actually run,^(*) but both the real (Minix-specific) bootloader and setup code will read parameters from the sector end.

^{(*) Unless CONFIG_IMG_RAW is set, I suppose, but that is a whole other story.}

[tkchia]

Anyway, I doubt that either the Minix bootloader (elks/elkscmd/bootblocks/boot_minix.c) or the FAT bootloader (elks/elkscmd/bootblocks/boot_sect_fat.h) is really equipped at the moment to load a /linux file from a hard disk partition. I think some code changes will be needed.

For the FAT filesystem, there is already a bpb_hidd_sec field, which is precisely used to give the distance from the hard disk MBR to the start of the particular hard disk partition --- so the bootloader code will actually have to honour and use this field (!).

For the Minix filesystem, I suspect that it may be necessary to extend the ELKS parameter block to include this "hidden sectors" information.

In either case, it is probably not wise to assume that the root partition will always be the first primary partition of the boot drive (e.g. /dev/bda1). Probably the really correct thing to do is to let the setup or kernel code accept the "hidden sectors" count as input, and convert it into a partition number.

Thank you!

[ghaerr]

Thank you @mfld-fr and @tkchia. I think I understand now.

So the BIOS drive number is stored in 'drv_num' in the actual boot sector after running. It appears that when 'setup' is running, INITSEG (ds) is set to the dummy boot sector. What defines the segment of the original boot sector so as to be able to get the drive_num value and convert it to a ROOT_DEV?

[tkchia]

Hello @ghaerr,

The real boot sector does not have a fixed address --- it is moved to as high in conventional memory as possible.

I think there is really no need for the setup code to know about the real bootloader. We can let the real boot sector plug in the correct drive number into the dummy boot sector's root_dev slot --- after loading the dummy boot sector into memory --- and let the setup code take it from there.

(We probably also need to find a way to pass the "hidden sectors" count too.)

Thank you!

[pawosm-arm]

From the end-user point of view, having rootfs on partitionless medium (namely, /dev/bda rather than /dev/bda1) isn't that concerning (even if such layout is rather typical to floppies than mass storage devices), as long as the kernel knows it should look for rootfs in the same place where the kernel (namely, /linux file) was found (namely, mount it from HDD if the kernel was loaded from HDD, rather than FDD). I can imagine those who want to install ELKS on the real HDD drive (not merely CF card as I do) would be disappointed by lack of proper partition table (e.g. they may like to share the same disk between ELKS and DOS), but that's another story I guess, since current boot loader does not offer boot menu enabling start of selected OS anyway. So let's not overdo it.

[ghaerr]

I think there is really no need for the setup code to know about the real bootloader. We can let the real boot sector plug in the correct drive number into the dummy boot sector's root_dev slot --- after loading the dummy boot sector into memory --- and let the setup code take it from there.

Ok.

For the FAT filesystem, there is already a bpb_hidd_sec field, which is precisely used to give the distance from the hard disk MBR to the start of the particular hard disk partition --- so the bootloader code will actually have to honour and use this field (!). For the Minix filesystem, I suspect that it may be necessary to extend the ELKS parameter block to include this "hidden sectors" information.

Agreed for the case of MBR. But this 'Cannot boot on HD image' has at least two major issues, the above being support for MBR. I am concerned with the very first issue, that is of just booting from a 'flat' HD image. In that case, we don't need sector offsets, but still need the BIOS drive_num.

[ghaerr]

From the end-user point of view, having rootfs on partitionless medium (namely, /dev/bda rather than /dev/bda1) isn't that concerning

BTW, ELKS doesn't yet differentiate between a raw device /dev/bda and /dev/bda1 (those two names are the same major,minor currently). Creating a raw device is the subject of a different thread.

I'm not certain whether our current disk driver (which handles both floppies and hard drives) handles partitions or not - I think it is supposed to, which would mean that we can't handle booting from a 'flat' image without an MBR without yet further changes to that driver and raw disk support mentioned above.

I can imagine those who want to install ELKS on the real HDD drive (not merely CF card as I do) would be disappointed by lack of proper partition table (e.g. they may like to share the same disk between ELKS and DOS), but that's another story I guess, since current boot loader does not offer boot menu enabling start of selected OS anyway.

I think we're saying the same thing - booting from a 'flat' HD drive would be a good thing at this point?

[pawosm-arm]

I think we're saying the same thing - booting from a 'flat' HD drive would be a good thing at this point?

Si.

[ghaerr]

Hello @tkchia,

We can let the real boot sector plug in the correct drive number into the dummy boot sector's root_dev slot --- after loading the dummy boot sector into memory --- and let the setup code take it from there.

Almost, but not quite: the BIOS drive number and root_dev aren't the same. The BIOS hard drive number needs to be stored as you suggested, but somewhere else, and then setup.S needs to be modified to read that drive number and convert it to a root_dev. In very old versions of the original bootsect.S (prepended to Image), max sectors was used to create a root_dev, only if root_dev was 0 (meaning it could be externally forced, just as 'build' does now). We have very little space in our boot sector, so it seems that setup.S will have to handle this.

[Mellvik]

@pawosm-arm,

consider me one of those end users. ON real (vintage) HW not having a partition table and the ability to switch between OSes is unthinkable. And no menu system is needed, just a DOS floppy with FDISK to change active partition, which I’m doing all the time. Boots in a few seconds (no AUTOEXEC etc.).

BTW it would be just as disappointing not to be able to use FDISK /MBR on such drives, which is why I argued for not putting too much into the MBR work on the ELKS side a few days ago. Believe it or not, boot sector viruses are alive and well on vintage machines (and diskettes). In most cases FDISK /MBR (some times with some ‘topping') is the fast way out.

—Mellvik

3. mar. 2020 kl. 16:33 skrev pawosm-arm notifications@github.com:

From the end-user point of view, having rootfs on partitionless medium (namely, /dev/bda rather than /dev/bda1) isn't that concerning (even if such layout is rather typical to floppies than mass storage devices), as long as the kernel knows it should look for rootfs in the same place where the kernel (namely, /linux file) was found (namely, mount it from HDD if the kernel was loaded from HDD, rather than FDD). I can imagine those who want to install ELKS on the real HDD drive (not merely CF card as I do) would be disappointed by lack of proper partition table (e.g. they may like to share the same disk between ELKS and DOS), but that's another story I guess, since current boot loader does not offer boot menu enabling start of selected OS anyway. So let's not overdo it.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jbruchon/elks/issues/348?email_source=notifications&email_token=AA3WGODKSOQSAYMLBOAKXMLRFUPLRA5CNFSM4KXDDTSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENT6NUA#issuecomment-594011856, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3WGOH6I5M5UTZG3TKK3KDRFUPLRANCNFSM4KXDDTSA.

[ghaerr]

@pawosm-arm and @Mellvik,

I just thought it is a simpler programming solution to start with getting flat images booting first, rather than introducing MBRs and trying to get all that running before basics. However, there are working solutions to MBR in the dev86 codebase.

Speaking of simpler programming solutions, I just want to say that not including a lot more of dev86 two years ago during the compiler switch is a mistake. For instance, as @georgp24 points out, there are all sorts of boot bocks, including MBR boots, in the dev86 codebase, which work now. Other than FAT boot, as lately as a couple of months ago, we're still rewriting boot blocks. My inspection shows that there is lots that the dev86 boot blocks did with regards to our ancient setup that has been lost. @tkchia just pointed out the documentation for the Linux boot protocol (thank you, I hadn't read that), and ELKS is prehistoric, that is, prior to any mentioned in that protocol document. At this point, continuing to unify boot blocks at the expense of ignoring lots of previously working code is hampering the usability of ELKS. That said, there's nothing wrong with creating better/unified/rewritten boot loaders, but since the basic boot->setup->system hasn't changed, we find ourselves rewriting what's already been written (without looking, since the dev86 sources aren't present). A collection of boot blocks would help ELKS at this point, while the grand simplification of boot, setup and system gets slowly done.

Anyways, I guess its a question of focus.

[Mellvik]

@Ghaerr, It’s hard to argue against stuff that works, regardless of age.

Further, since the 'old stuff’ is known to work, it makes the intermediary flat image unnecessary I presume.

—Mellvik

3. mar. 2020 kl. 18:04 skrev Gregory Haerr notifications@github.com:

@pawosm-arm https://github.com/pawosm-arm and @Mellvik https://github.com/Mellvik,

I just thought it is a simpler programming solution to start with getting flat images booting first, rather than introducing MBRs and trying to get all that running before basics. However, there are working solutions to MBR in the dev86 codebase.

Speaking of simpler programming solutions, I just want to say that not including a lot more of dev86 two years ago during the compiler switch is a mistake. For instance, as @georgp24 https://github.com/georgp24 points out, there are all sorts of boot bocks, including MBR boots, in the dev86 codebase, which work now. Other than FAT boot, as lately as a couple of months ago, we're still rewriting boot blocks. My inspection shows that there is lots that the dev86 boot blocks did with regards to our ancient setup that has been lost. @tkchia https://github.com/tkchia just pointed out the documentation for the Linux boot protocol (thank you, I hadn't read that), and ELKS is prehistoric, that is, prior to any mentioned in that protocol document. At this point, continuing to unify boot blocks at the expense of ignoring lots of previously working code is hampering the usability of ELKS. That said, there's nothing wrong with creating better/unified/rewritten boot loaders, but since the basic boot->setup->system hasn't changed, we find ourselves rewriting what's already been written (without looking, since the dev86 sources aren't present). A collection of boot blocks would help ELKS at this point, while the grand simplification of boot, setup and system gets slowly done.

Anyways, I guess its a question of focus.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jbruchon/elks/issues/348?email_source=notifications&email_token=AA3WGOGBOLUDRRP6OGAJ2IDRFU2APA5CNFSM4KXDDTSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENUJ5ZA#issuecomment-594058980, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3WGOETNJPWVFVV6TM6OATRFU2APANCNFSM4KXDDTSA.

[tkchia]

Hello @ghaerr,

For instance, as @georgp24 points out, there are all sorts of boot bocks, including MBR boots, in the dev86 codebase, which work now. Other than FAT boot, as lately as a couple of months ago, we're still rewriting boot blocks.

I think I am of the same opinion as @Mellvik: we should not have to need to touch the generic MBR (from a fdisk /mbr). The ELKS bootloader for a hard disk partition should simply be inside the hard disk partition.

@tkchia just pointed out the documentation for the Linux boot protocol (thank you, I hadn't read that), and ELKS is prehistoric, that is, prior to any mentioned in that protocol document.

Perhaps not --- Linux 1.3.73 (with Boot Protocol 2.00) was released in 1996, while ELKS's change log goes back to 1998, and ELKS 0.0.76 was released in 1999. Most likely, whatever boot protocol ELKS now uses, is based on a rather old version of Linux's.

Thank you!

[ghaerr]

Hi @tkchia,

I think I am of the same opinion as @Mellvik: we should not have to need to touch the generic MBR (from a fdisk /mbr). The ELKS bootloader for a hard disk partition should simply be inside the hard disk partition.

Ok. Don't we need an MBR image (which means source code to create a binary) to create non-flat HD images? Or should ELKS only support mounting an MBR HD image and only create flat HD images?

I am trying to understand what needs to be done to complete the HD boot and image generation open issue problems.

[tkchia]

Hello @ghaerr,

Ok. Don't we need an MBR image (which means source code to create a binary) to create non-flat HD images?

I think it should be enough to generate a hd.bin image for an individual partition, e.g. /dev/sda3 on Linux, rather than an image for an entire hard disk, e.g. /dev/sda. The hd.bin can then contain its own bootloader, which will be placed at the start of the partition, rather than the start of the whole hard disk.

(Meanwhile, it seems that there are some interesting tidbits in the dev86 boot blocks code --- including the code for FAT booting. I will need to study it more closely to see how it might be of use.)

Thank you!

[ghaerr]

Hi @tkchia and thank you for your responses!

I think it should be enough to generate a hd.bin image for an individual partition, e.g. /dev/sda3, rather than an image for an entire hard disk, e.g. /dev/sda. The hd.bin can then contain its own bootloader, which will be placed at the start of the partition, rather than the start of the whole hard disk.

Does the doshd.c floppy/hard disk driver differentiate now between partitions, that is, say /dev/bda2 and /dev/bda3, when mounting a disk on them?

If so, then since /dev/bda and /dev/bda1 are the same minor number, don't we need to create a 'raw' block device for the 'flat' HD disk images, versus the MBR images that will be recognized by the partition code in doshd.c? The flat disk images won't have an MBR. Is either image automatically recognized by /dev/bda and /dev/bda1 whether there is an MBR or not? (Sorry for my confusion).

Finally, since @georgp24 has been talking about wanting his (or a rewritten) script to generate a 32MB MBR hard drive image, we would still want a converted 'mbr.s' for him as well as for testing the partitioned vs flat /dev/bda* drivers, wouldn't we?

(Meanwhile, it seems that there are some interesting tidbits in the dev86 boot blocks code --- including the code for FAT booting. I will need to study it more closely to see how it might be of use.)

LOL, I wasn't kidding when I said we've been rewriting boot sectors :) There's lots of good stuff in there.

I would also like a size utility that spits out an ELKS a.out program's text/data/bss/total sizes. I thought there used to be a size86 utility in dev86, or would gcc-ia16 do that now?

[georgp24]

"I would also like a size utility that spits out an ELKS a.out program's text/data/bss/total sizes."

I wrote such a program that reads the header of the executable and lists the defined sizes. I could commit that.

[mfld-fr]

No need to write a special program for that. Just add the -M option to the linker, and it will issue an executable map. See in elks/arch/i86/Makefile for examples.

[ghaerr]

I found the utility I was thinking of, its called objdump86 in dev86. It produces either a hex dump of an ELKS binary like the following

: 89 ca 89 d8 c3 85 c9 78  12 85 d2 78 03 e9 7f ff  .......x...x....
: e8 12 00 e8 79 ff e8 1a  00 eb 0a e8 15 00 85 d2  ....y...........
: 78 0b e8 6a ff f7 d8 83  d2 00 f7 da c3 e8 f5 ff  x..j............
: e8 5c ff f7 db 83 d1 00  f7 d9 c3 66 90 66 90 90  .\.........f.f..
DATASEG
: 00 00 00 00 0a 00 3e 20  00 75 73 61 67 65 3a 20  ......>..usage:.
: 25 73 20 25 73 0a 00 63  6f 72 65 20 64 75 6d 70  %s.%s..core.dump
: 65 64 00 6b 69 6c 6c 65  64 00 66 6f 72 6b 20 66  ed.killed.fork.f
: 61 69 6c 65 64 00 70 69  64 20 25 64 3a 20 25 73  ailed.pid.%d:.%s

as well as segment sizes used like

Gregs-MBP2:sash greg$ /tmp/objdump86 -s sash
text    data    bss dec hex filename
13760   1248    8376    23384   5b58    sash

I'll port it over as both a host program on Linux/OSX in elks/tools, as well as a useful binary for running within ELKS.

[tkchia]

Hello @ghaerr,

If so, then since /dev/bda and /dev/bda1 are the same minor number, don't we need to create a 'raw' block device for the 'flat' HD disk images, versus the MBR images that will be recognized by the partition code in doshd.c?

I did a check on a running ELKS system: it is /dev/bda0 that has the same minor number as /dev/bda --- and both these device files refer to the entire hard disk. /dev/bda1, /dev/bda2, etc. refer to the individual hard disk partitions.

So it would seem that ELKS already allows one to directly access both a whole hard disk and its individual partitions, just like Linux does.

Finally, since @georgp24 has been talking about wanting his (or a rewritten) script to generate a 32MB MBR hard drive image, we would still want a converted 'mbr.s' for him as well as for testing the partitioned vs flat /dev/bda* drivers, wouldn't we?

Yes --- apologies --- I quite forgot about that.

I think images for individual partitions will be more useful for one who wishes to install ELKS on a real hard disk. Conversely, an image of a whole hard drive --- along with MBR and partition table --- will be better for those who want to try out ELKS in a virtual machine.

For the latter, I guess any generic MBR code should be good to use. Besides the MBR code in dev86, there is also the MBR code in FreeDOS fdisk, and most probably elsewhere too.

I guess one question is whether we should port any chosen MBR source code to GNU assembler syntax, or just leave it in its original as86/nasm/masm/etc. syntax.

Thank you!

[ghaerr]

Hello @tkchia,

Thank you again for answering all my questions, it helps a lot and I really appreciate it.

I think images for individual partitions will be more useful for one who wishes to install ELKS on a real hard disk. Conversely, an image of a whole hard drive --- along with MBR and partition table --- will be better for those who want to try out ELKS in a virtual machine.

Agreed. So we should have the capability to create and test both 'flat' as well as MBR HD images.

For the latter, I guess any generic MBR code should be good to use. Besides the MBR code in dev86, there is also the MBR code in FreeDOS fdisk, and most probably elsewhere too.

I would think staying with dev86 at least for now would be fine, since @georgp24 indicates that the dev86 mbr.s works. It also keeps the assembly in just the (second) as86 format.

I guess one question is whether we should port any chosen MBR source code to GNU assembler syntax, or just leave it in its original as86/nasm/masm/etc. syntax.

My take is that it is more important to get the HD image issues working first (as there are several issues currently open), than it is to spend time rewriting boot blocks, certainly for now, and then evaluate which boot blocks/methods we want to stay with.

Having said that, if as86 were brought over unchanged from dev86 and stuck in elks/tools (just like I did with objdump86), then 'mbr.s' and possibly others could be used in elks/bootblocks quickly. After the HD image issues are solved, we can come back to whether to keep as86 around or not, depending on the number of files involved. This approach will allow changes to 'setup.S' and possibly to 'doshd.c' to be made if required and get both HD image types booting, or at least the larger problems known.

[georgp24]

@tkchia It is great that you can now boot from hard disk! However, at the moment there is no partition table on the disk. My suggestion is, instead of using sfdisk, why not just have build write a predefined partition table to the hard disk image which is not configured by the user? I mean the max size of a hard disk is 30 MB, so either just one partition with 30 MB or two partitions, one 20 MB and one 10 MB. Then you do not need to use sudo and you do not have to make a user-mode version of sfdisk which will run on OS-X.

[ghaerr]

@georgp24: We won't need to use a utility to create a partition, as we'll likely use an assembled 'mbr.s' from dev86 like you suggested works.

I am thinking that perhaps another config option when CONFIG_IMG_HD is selected (CONFIG_IMG_MBR) could add an MBR partition onto the front of the flat disk image. This could all be done using dd.

[ghaerr]

Hello @georgp24,

I mean the max size of a hard disk is 30 MB

Out of curiousity, where are you finding that limitation? My understanding is that the maximum Minix filesystem size is 64MB with 1k blocks, and bigger with larger block/cluster sizes.

[georgp24]

In menuconfig the default setting for HD is 30 MB. I think I tried to increase that about three years ago and that did not work.

[ghaerr]

I've just tested a 64MB hard drive, thanks to @tkchia. A 64MB HD can be created by setting CONFIG_IMG_BLOCKS=65535. Any larger and mfs will report failure.

[georgp24]

Maybe I got confused trying to set the CHS parameters in menuconfig then. What would we do without @tkchia ! :smiley:

[pawosm-arm]

My original issue is fixed now, so I guess this ticket may be closed now (I can't; @mfld-fr opened this one for me).

One thing I observed is that 'Partition check' is still performed while booting flat HD image, giving rubbish list of non-existing partitions. Doing 'Partition check' still makes sense while booting flat FDD image or while booting partitioned HD image. For me it is rather aesthetic subject than a real issue though.

[mfld-fr]

My original issue is fixed now, so I guess this ticket may be closed now (I can't; @mfld-fr opened this one for me).

So closing it.

Edit: remaining problems are tracked in #199.