GRUB remapping conflicts with MS-DOS mode

[morris]

Hello everybody. Long time lurker here.

Considering the amazing level of knowledge you guys have, I think this is the best place to ask this question.

I'm booting my P3 system from a SATA PCI card, which loads GRUB2, which in turn loads GRUB1 (legacy), which remaps the "second drive" (first drive from the on-board IDE controller) to hd0, and then Windows 98 boots and works perfectly. This long procedure allows me to boot multiple systems from a single menu without having to modify the BIOS every time I want to change.

If I "Restart in MS-DOS mode" it works, but if I exit back to Windows I get this:

While initializing device SHELL:
Cannot find or load required file KRNL386.EXE. The file was not found.

Press any key to continue...

I tried disabling the SCSI controller on Windows 98 but it didn't help. I don't have any more ideas to try to find a workaround.

If I define C as the first booting device in the BIOS, this problem goes away. I can change back and forth between MS-DOS mode and Windows but I lose my fancy menu and it implies entering the BIOS every time I want to change the system and that defeats a little bit the point of this build.

I'm open to suggestions and advice.

Thanks!

[jaclaz]

It is possible that some of the passages you go through alter something in the BIOS drive table.

Are you really using GRUB1 (so-called "legacy")?

Or are you using grub4dos? If not, first thing I would suggest you is to try the grub4dos, which is essentially a "better" GRUB, with a number of features dedicated to DOS and Windows booting.

If you are already using grub4dos, post the contents of the menu.lst entry you are using, maybe something needs to be corrected.

jaclaz

[morris]

Hi jaclaz.

Yes, I do alter the BIOS drive table in order to multi-boot between 98, XP, and different Linux distros and more...

GRUB2 (on the MBR) is fine for most stuff, but if you want to boot a fully functional Win98 you need to remap the drives, and that's where GRUB legacy comes in. I install it to a partition and use it to boot into w98. It does work in most use cases but not for "Restarting in MS-DOS mode" and exiting back to Windows. This is not a deal breaker since I could simply reboot but... I like challenges.

Before I read your post I remembered grub4dos (telepathy?) so I set the Compact Flash as the first boot device and I successfully managed to boot into GRUB2 (SATA disk) with:

rootnoverify (hd1)
chainloader +1 

And I could boot into XP too, with this:

map (hd0) (hd1) 
map (hd1) (hd0)
rootnoverify (hd1,0)
chainloader +1
makeactive

I'm kind of surprised that it can boot into the SATA PCI drive without problems (no need for extra modules).

So it seems this build will end up being a multi boot system but with two menus, one in the Windows 98 disk with GRUB4DOS, and one in the SATA drive with GRUB2 for extra functionality.

Thanks for the idea!

Now I'll see how I sort everything out.

Edited May 9, 2023 by morris

[morris]

I have one more question. Why is Win98 able to stop working and boot back into DOS but you can't start GRUB... it means it's not real "real mode"?

What are the limitations? Worse performance/compatibility? Could you provide examples?

[jaclaz]

Well, you are not really remapping anything with:

Quote

map (hd0) (hd1)

map (hd1) (hd0)

rootnoverify (hd1,0)

chainloader +1

makeactive

no offence intended, but in grub4dos those are "wrong".

You probably want instead :

map (hd0) (hd1)

map (hd1) (hd0)

map --hook

root (hd0,0)

chainloader +1

the key here is the "map --hook" that makes the exchange of the drive visible outside grub4dos.

Then you want to normally use root (and not rootnoverify) if the target is an actual bootsector (such as (hd0,0)).

The makeactive directive is not needed for XP AFAICR (it may be needed for DOS/Win9x, though).

If you are not hooking the map in the DOS/WIndows 9x menu.lst, it may boot but what was passed to the IO.SYS by grub4dos may not be  the same thing the BIOS provides when the OS later rand it is likely to be at least part of the issue you were having.

I am not sure to understand:

39 minutes ago, morris said:

I have one more question. Why is Win98 able to stop working and boot back into DOS but you can't start GRUB... it means it's not real "real mode"?

What are the limitations? Worse performance/compatibility? Could you provide examples?

There could be a number of issues both connected to your speciific machine or commands you are using, but also to the specific version of grub4dos you are using.

0.4.4 version 16 October 2009 should be the only one of the 0.4.4 series that can be used (earlier versions had several bugs)

If you are using the 0.4.5c, use the latest available.

0.4.6  (any version) is not recommended as quite a few things were changed in it and not much testing has been done with DOS/W9x/Me, mind you if it works it is fine.

jaclaz

 

[morris]

2 hours ago, jaclaz said:

Well, you are not really remapping anything with:

no offence intended, but in grub4dos those are "wrong".

No offense taken! I appreciate your input. I come from the GRUB 2 and GRUB legacy world. I see there are some differences.
I come from GRUB legacy and GRUB2, and this is the normative way to boot Windows 9x. Only GRUB legacy supports rootnoverify. And it works fine and it only poses problems if you plan to Restart in MS-DOS mode and then again go back to Windows. Only in those circumstances it presents a problem.

2 hours ago, jaclaz said:

You probably want instead :

map (hd0) (hd1)

map (hd1) (hd0)

map --hook

root (hd0,0)

chainloader +1

the key here is the "map --hook" that makes the exchange of the drive visible outside grub4dos.

Then you want to normally use root (and not rootnoverify) if the target is an actual bootsector (such as (hd0,0)).

The makeactive directive is not needed for XP AFAICR (it may be needed for DOS/Win9x, though).

If you are not hooking the map in the DOS/WIndows 9x menu.lst, it may boot but what was passed to the IO.SYS by grub4dos may not be  the same thing the BIOS provides when the OS later rand it is likely to be at least part of the issue you were having.
 

 

Thanks for all the information and clarifications.
Your commands and the ones I posted both work to boot XP (SATA as secondary disk) from GRUB4DOS, but I couldn't successfully boot Windows 9x with the CompactFlash as secondary disk (starting GRUB4DOS from a floppy). It freezes when it's loading the desktop, you can only see the wallpaper.

2 hours ago, jaclaz said:

There could be a number of issues both connected to your speciific machine or commands you are using, but also to the specific version of grub4dos you are using.

0.4.4 version 16 October 2009 should be the only one of the 0.4.4 series that can be used (earlier versions had several bugs)

If you are using the 0.4.5c, use the latest available.

0.4.6  (any version) is not recommended as quite a few things were changed in it and not much testing has been done with DOS/W9x/Me, mind you if it works it is fine.

jaclaz

I'm using the latest 0.4.4 and it works quite well (I confirm it does load in "Restart in MS-DOS mode"). The only major drawback is that it doesn't support ext4. I tried 0.4.6a and while it does support ext4 there's no linux nor initrd command to load the kernel and initramfs.

So my solution is to leave the Compact Flash as primary, and with the aid of GRUB4DOS boot XP if necessary or chainload the SATA disk to use my full GRUB2 menu. I'll see how I implement it the most convenient way

Edited May 9, 2023 by morris

[morris]

12 hours ago, jaclaz said:

0.4.4 version 16 October 2009 should be the only one of the 0.4.4 series that can be used (earlier versions had several bugs)

If you are using the 0.4.5c, use the latest available.

0.4.6  (any version) is not recommended as quite a few things were changed in it and not much testing has been done with DOS/W9x/Me, mind you if it works it is fine.

What do you think about newer 0.4.4 versions such as grub4dos-0.4.4-2009-12-03 ?

I'm looking at this website and the latest 0.4.5 seems to be grub4dos-0.4.5c-2016-01-18

What's the difference between them? Have you tried them?

There's also 0.4.6 under active development (there's even a UEFI version).

[jaclaz]

That 0.4.4 version 2009-12-03 is probably fine, as it is later than the 16 october one (which is the most tested/used), and it fixed a nasty dd issue, introduced BTW after the 2009-10-16 version:

Quote

2009-12-02 (chenall)fixed a bug in color_func(builtins.c).
2009-12-01 (chenall)fixed a bug which caused dd/write to write onto the wrong sector of the disk(fsys_ntfs.c).
2009-11-29 (chenall)fixed a bug when using (md) to access memory at 2G and above(bios.c). improved memmove64 to support overlap(asm.S).

2009-11-25 Caution! Reports say build 2009-11-08 and later will write wrong data onto disk when using dd and/or write commands.

2009-11-13 (chenall)added --replace option for cat. This will write to file. Caution!
2009-11-11 let PXE_BUF use BUFFERADDR. cancelled (hd+) support. added (hd) and (hd-N) support.
2009-11-09 moved FSYS_BUF and some other buffers up at 0x3E0000. (chenall)added (hd+) support for map.
2009-11-08 map memdrive images at memory address above 4GB(only for 64-bit CPU). deleted SETUP, INSTALL and EMBED commands.

2009-10-16 Turned off int13/AX=4B01/DL=7F cdrom query which may hang on some machines. Commented out DMA code related to running via KEXEC. Implemented 64-bit int13 memdrive block moving code.

And yes, that is the latest 0.4.5 version, you should use that one if you need the added features that 0.4.4 misses.

The 0.4.6 is the version in development BUT at a certain point (some time after the 0.4.5c 2016-01-18) new features and more than a few changes were introduced in it, and this has reportedly caused some compatibility issues with older motherboards and old OSes.

The suggestion (for your case use) is:

1) try using 0.4.4 2009-10-16, you don't need any of the features added in later versions, but if for *any reason* you have issues, then

2) try using 0.4.5c 2016-01-18, you don't need any of the features added in later versions, but if for *any reason* you have issues, then

3) try using latest 0.4.6a

Generally speaking, the older versions have been tested more extensively with older OS such as DOS/Win9x/Me, and while the good grub4dos developers are usually very fast in correcting issues, due to the continuous evolution of 0.4.6a, it is well possible that bugs with older OSes exist and have not been found simply because they were not tested in a given combination of hardware/Bios+old Os.

Cannot say about the partial boot you are having with Win9x, if you post your setup (which hd numbers and partitions you get in grub4dos and which commands you are using) maybe I can suggest some variations to try.

I am not sure to understand what you mean, linux is not a grub4dos command (it is a GRUB2 one), you use kernel instead, initrd is there alright.

jaclaz

Edited May 10, 2023 by jaclaz

[morris]

Thank you very much for your detailed comparison and for remembering me that I should use "kernel" instead of "linux".

GRUB4DOS is much closer to GRUB legacy (which also has the kernel command) than GRUB2 (linux command).

I was able to boot GNU/Linux but only 0.4.6a is compatible with ext4 partitions.

I found 0.4.4 to be more stable when chainloading Windows XP. I got the best results by chainloading GRUB2 on the SATA drive and then starting XP with GRUB legacy.

There's a big difference between 0.4.4 and 0.4.6a but I didn't find anything new/improved about 0.4.5.

By the way, what's the difference between "map --hook" and "map --rehook"?

My setup:
IDE CF - Win98 - HDD0 (internal motherboard controller)
SATA SSD - GRUB2 - XP, Linux, GRUB legacy, etc (bootable PCI SATA controller), identified as "SCSI" by the motherboard.

Currently I boot the CF and in the CONFIG.SYS Menu I can choose between Windows 98 or chainloading GRUB2 (using GRUB4DOS 0.4.4).

[jaclaz]

map --hook and map --rehook, it depends, for a period of time (in 0.4.2, 0.4.3, and possibly 0.4.4 versions) subsequent hooks needed to use the rehook command, later (but cannot really say when) you can use always the "normal" hook (to be fair, it is a rare case that you need to hook and then hook again the mappings).

There are quite a few added features in 0.4.5 most notably the dd command is reliable, small files on NTFS are accessible, and grub4dos batches are possible, but additionally there are lots of bug fixes (mainly for particular usage or on particular motherboards/setups and/or OS combinations).

A few examples  of possibly useful grub4dos batches:

http://reboot.pro/index.php?showtopic=17728

http://reboot.pro/index.php?showtopic=22739

http://reboot.pro/index.php?showtopic=22554

For "basic" use any version that works for your OS if fine, when/if you need some advanced features, you will see the improvements in 0.4.5 over 0.4.4.

Normally you can "switch" to another version of grub4dos easily, by chainloading the grldr or using grldr.exe as argument of the linux directive, so you can have more versions in different directories to experiment with.

You are seemingly always loading DOS first then either go on loading Win9x or go to GRUB2 (why?) to load XP.

Generally speaking the loading of grub.exe from DOS is more prone to issues, in your setup I would (mind you these are only personal preferences) rather have on the CF card:
1) the "normal" DOS/Win9x MBR code[1]
2) a (FAT) bootsector loading grldr on the active partition (on the CF card)
3) in menu.lst the choice between chainloading IO.SYS on the CF card and chainloading (after remapping disks if needed) the NTLDR on the SATA disk + (if needed) whatever entry for Linux(es)

You don't really *need* GRUB2 at all, let alone GRUB ("legacy")

jaclaz

 

[1] this is really only a pet peeve of mine, I personally do not like to have code written to the first few "hidden sectors", so I try to avoid using grldr.mbr code where possible.

 

Edited May 13, 2023 by jaclaz

[awkduck]

7 hours ago, jaclaz said:

You don't really *need* GRUB2 at all, let alone GRUB ("legacy")

In general/normal use case scenarios, I' have to completely agree with you.

Grub2 seems limited, in some important ways. At least in ways that matter to me. However, time and time again, I run into odd machines that will not work "completely" with Syslinux or Grub4dos. USB booting (stuck at USB1.1 speeds or no USB boot at all), strange hardware initializing timings, and legacy USB mouse/keyboard not properly releasing.

I've had one machine that would not boot from USB using Grub4dos, unless I first initialized Grub2's USB modules. This must have removed the bios issue preventing Grub4dos from working. A different machine worked fine, without the Grub2 USB modules; but would not work if I had the Grub2 USB modules loaded.

You can also edit MSRs with Grub2.

But as I've said, these are things you would "typically"  not be dealing with.

[jaclaz]

Yes, sometimes it is a hit and miss game, and you have to try *everything* before finding something that does work, GRUB2 (besides a couple of IMHO stupid development decisions, such as the new grub.cfg syntax and the update mechanism) is fine, though it has (when it comes to non-linux) less features than grub4dos, but again, unless you need some "advanced" features any will do (whatever works is good enough), what I would try to avoid if possible is multiple chainloading of different loaders as it tends to be more prone to errors, but when and if is needed, it is needed, just as an example in some cases PloP works when both grub4dos and GRUB2 have issues, in many cases (in my experience) the issue is with installing the initial loader to the MBR+hidden sectors.

jaclaz

[awkduck]

15 hours ago, jaclaz said:

besides a couple of IMHO stupid development decisions

Grub2 will eventually develop beyond usefulness, for the more minority use cases.

[jaclaz]

9 hours ago, awkduck said:

Grub2 will eventually develop beyond usefulness, for the more minority use cases.

I think it is already past that point, particularly because as soon as you exit the "common, normal" situations (and working BIOS/UEFI) you have very little documentation and (not that I have much experience with GRUB2) the concept of installable modules is in theory a very smart thing, but in practice make things very complicated, the way it is installed (or created/compiled) is - to say the least - confusing.

The update mechanism (and having a settings fie that you should NOT edit) is only the tip of the iceberg.

BTW the only clear explanation of the mechanism for grub.cfg I could find is on dedoimedo:

https://www.dedoimedo.com/computers/grub-2.html

https://www.dedoimedo.com/computers/grub-2.html#mozTocId542243

If you installl a Linux distro everything is automated, but when/if you need anything outside what the good guys putting together the distro decided to include/pre-set/etc. things become problematic.

I believe that the good people of GRUB2 (or of the various distros) read the U in grUb more as Unique than as Unified.

jaclaz

 

[awkduck]

2 hours ago, jaclaz said:

BTW the only clear explanation of the mechanism for grub.cfg I could find is on dedoimedo:

I should probably write something up. I've been meaning to.

I only use the file that you are never supposed to edit. I never use Grub2 via Linux (install/configure). I've only compiled it on Linux.

I don't know why they don't publish documentation, on using GRUB.CFG. I suppose because it is designed against that. But the syntax seems simple enough, once you actually know what it is. The boot core can be built per your needs, which is neat. Having everything managed by the system, aside from a 2nd config file (using almost completely different syntax), seems to be the kinda thing that made people really dislike systemd.

There is a fork of Grub2 "Supergrub2". But I haven't looked into it. I think they moved it away from Linux isolation. Development may have ended.