Grub4DOS does not boot in PC Emulator and 86Box #261
Comments
|
Try the new version . |
|
Thank you very much for looking into this issue, Yaya! And yes, the GRUB.EXE contained in https://github.com/chenall/grub4dos/files/6395742/grub4dos-0.4.6a-2021-04-28.7z.txt (time-stamped 04:37) does boot from PC-DOS 2.0 in PC Emulator, whereas the regular binary contained in http://dl.grub4dos.chenall.net/grub4dos-0.4.6a-2021-04-28.7z (time-stamped 04:40) fails to do so. Now that the latest GRUB.EXE is available for further tests in PCem, it quickly appears that it does not yet behave as expected, failing to "root" in the experiment described in post 15: The error message is: "Error 17:(http://grub4dos.chenall.net/e/17) Cannot mount selected partition", with a missing help text at that URL. The partition number can be checked with the "geometry" command which outputs: "Partition num: 2, active, Filesystem type is fat12, partition type 0x01". So the more portable formulation suggested in post 18 does not help: However, the desired booting of a second DOS instance that autoexecutes an editor with already opened configuration files was possible in PCem with the aforementioned version http://dl.grub4dos.chenall.net/grub4dos-0.4.6a-2014-01-17.7z and earlier. And with the new GRUB.EXE contained in https://github.com/chenall/grub4dos/files/6395742/grub4dos-0.4.6a-2021-04-28.7z.txt the desired booting is indeed possible in VirtualBox. It does not help if the partitioning made with FDISK from PC-DOS 2.0 (which causes code to be written immediately after the master boot record) is instead made with FDISK from MS-DOS 3.31 (which leaves empty space there). Gerolf |
|
I still had to test the modified GRLDR from the new 0.4.6a version dated 21-04-28 (time-stamped 04:37). It booted successfully, but skipped the FAT12 partition as "non-MS" and refused to read from it. GRLDR thus had to be copied to a non-hidden FAT16 logical partition to be found. Partitioning had to be made with FDISK of MS-DOS 3.31 to leave empty space for GRLDR.MBR following the master boot sector. The command "bootlace 0x80" failed in PC Emulator with a "Warning: EBIOS not present! It is not reliable running under DOS without EBIOS." So VirtualBox was used for the following steps. On a newly created VHD with 1023/16/63 geometry, I created partitions as reported by FDISK of MS-DOS 3.31: Partition Status Type Start End Size Display Logical DOS Drive Information with 33 cylinders being the minimum size for FAT16. Here's the partition table: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 01 I formatted drive D: from Windows at the command line, having temporarily mounted this FAT16 partition as ImDisk VirtualDisk. Then I booted from a PC-DOS 2.0 disk to install that system with FORMAT C: /S so that it can boot from the 16 cylinder FAT12 partition. I booted from another DOS disk with the new GRLDR and BOOTLACE.COM on it and entered the commands "COPY GRLDR C:" and "BOOTLACE 0x80". This is what happened at reboot: Try (hd0,1): non-MS: skip The IBM Personal Computer DOS C>dir GRLDR Volume in drive C has no label GRLDR 331101 4-28-21 4:37a So the installed GRLDR.MBR boots, rejects the FAT12 partition, but then chainloads the previous MBR and boots PC-DOS 2.0 from exactly this partition, so that I can autoexecute GRUB.EXE as a fallback. I prepared the partition as described in post 11. AUTOEXEC.BAT looks like this: SET GRUBDIR=C:_PRO\GRUB4DOS\6A210428 MENU.LST has this entry: title Editor\n\n Edit AUTOEXEC.BAT and MENU.LST Again, it can be booted to PC-DOS 2.0 and the editor can be executed in VirtualBox, but not in PC Emulator, where it gives an error 17 message. At the command line, "root" returns: "(hd0,0) Filesystem type is fat12, partition type 0x01", and "geometry" returns: drive 0x80(CHS): C/H/S=1023/16/63, Sector Count/Size=1031184/512 Now I could copy GRLDR to the FAT16 partition, which allowed for direct booting to the Grub4DOS menu. Again, the editor could be started in VirtualBox, but not in PC Emulator. The same after I tried a workaround, moving the editor boot image from the FAT12 partition to the FAT16 partition: (hd0,0)/_SYS/PCD200/PCD200ED.IMG => (hd0,4)/_SYS/PCD200/PCD200ED.IMG. Gerolf |
|
Typo correction: "Try (hd0,0): non-MS: skip" Gerolf |
|
Keeping the observed FAT12 anomaly in mind, I should reduce complexity for the sake of error searching. My initial intention was to boot various old operating systems, starting with PC-DOS 2.0; hence the need for a boot manager, but maybe not for partitioning, if only "map" or "partnew" work. Now I created a new fixed-size VHD of 1023/16/63 geometry (with PCem) and one partition of maximum size (with FDISK of MS-DOS 3.31 as the oldest system that can handle 503 MiB in a single partition, totaling one cylinder less than before): Partition Status Type Start End Size For comparison, on another disk, I created such a partition under MS-DOS 8.0 (as the latest of the following systems whose FDISK no longer show cylinder numbers): Partition Status Type Volume Label Mbytes System Usage For the maximum size, the created partition tables look the same: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 01 I installed MS-DOS 3.31, GRUB.EXE and GRLDR (like in post 11, step 6, for folder C:_SYS\MSD331). AUTOEXEC.BAT now looks like this: SET GRUBDIR=C:_PRO\GRUB4DOS\6A210428 I had to build a new editor disk MSD331ED.IMG (like in post 15, for folder C:_SYS\MSD331) so that the large partition can be accessed. The image consists of the MSDOS 3.31 system files, FreeDOS editor, and another AUTOEXEC.BAT: C: This is the MENU.LST entry for the editor: title Editor\n\n Edit AUTOEXEC.BAT and MENU.LST In VirtualBox, this arragement boots MS-DOS 3.31 and autoexecutes GRUB.EXE. The editor can be started from the menu, as desired, and returns to it. In PC Emulator, the "root (fd0)" command causes an error 17 message. (Could this be a consequence of the missing EBIOS functionality? I might configure another ROM.) At the command line, "root" says: "(hd0,0) Filesystem type is fat16, partition type 0x06". To this information, "geometry" adds: "Partition num: 0, active". Something unexpected happened when reboot came after I had executed "bootlace 0x80" (under VirtualBox, due to the EBIOS missing in PCem, AUTOEXEC.BAT temporarily absent): Try (hd0,0): non-MS: skip Microsoft(R) MS-DOS(R) Version 3.31 C>dir GRLDR Volume in drive C has no label GRLDR 331101 4-28-21 4:37a In both VBox and PCem, GRLDR, in this one-partition scenario, cannot be found and booted though it is present; but if AUTOEXEC.BAT is present, GRUB.EXE, from the DOS chainloaded as a fallback by the MBR, loads the menu. The editor can be started successfully in VirtualBox, but fails in PC Emulator with the known error 17. Gerolf |
|
a) In PCem, for the editor image, it helped in that a "rootnoverify (fd0)" passed without complaint, but next line "chainloader (fd0)+1" hanged with "Error 25: Disk read error". Exactly the same (either error 17 at "root" or 25 at "chainloader") happened when I used fat12grldr.img with an analogous MENU.LST entry. In VirtualBox, fat12grldr.img from old version 0.4.2 correctly booted to the menu and allowed returning to MS-DOS 3.31. b) I took the VHD I already had partitioned for maximum size under MS-DOS 8.0 (Windows ME bootdisk). In PCem, I prepared it now with FORMAT C: under that version. Then I transferred MS-DOS 3.31 using SYS C: and COPY COMMAND.COM C: and re-installed everything as described in my previous post. In VBox, I executed "bootlace 0x80". The results were still the same, with "Try (hd0,0): non-MS: skip" and "Cannot find GRLDR", even in VBOX, and error 17 or error 25 in PCem. Sometimes, again, there was an additional line before "try", namely: "BIOS: Drive=0x80, H=16, S=63". c) In PCem, I created a fresh 1023/16/63 VHD and partitioned it for maximum size under MS-DOS 3.31.I mounted the VHD as ImDisk Virtual Disk in Windows Explorer. The formatting dialog popped up immediately. I selected file system type FAT and standard cluster size and unmounted the disk after formatting. I tried to transfer MS-DOS 3.31 using SYS C: but received an error message: "No room for system on destination disk". MS-DOS 8.0 required the system files to be at their standard locations already, but SYS C: worked with MS-DOS 7.0 (Windows 95 boot disk). I re-installed everything in analogy to my previous post, except for a folder named "C:_SYS\MSD700" and an editor boot image named "MSD700ED.IMG". In VBox, I executed "bootlace 0x80" and purposely removed C:\GRLDR, so in PCem, at reboot, I got the message "Try (hd0,0): FAT16: No GRLDR", signaling the file system was recognized. After re-installation, GRLDR could directly boot to the menu. But when I wanted to boot the editor disk in PCem, errors 17 or 25 remained. Gerolf |
|
Post # 35: The "Try (hd0,0): non-MS: skip" issue is solved, regardless of the partition size, with a FAT16-formatting being done under Windows 10, which seems too hard a condition to be acceptable for a boot manager. Errors 17 or 25 did not occur in version 0.4.6a of 2014-01-17, see post # 19. |
|
Use RMPrepUSB - Drive Info - P1 to display contents of partition 1 PBR. |
|
Hallo Steve, thank you for making me look into this detail again, so when reformatting the FAT16 partition in question (the second partition, post 35), I discovered that I have to correct an error I made: Formatting under Windows 10 is indeed NOT required, MS-DOS 5.0 is enough. Only MS-DOS 3.31 and older create a format that is rejected by the installed GRLDR.MBR saying "Try (hd0,1): non-MS: skip". See post # 38 for the lengthy RMPrepUSB output. Gerolf |
|
The FAT sector has IBM as identifier, so I guess it is correct in that it is a non-MSDOS partition? |
|
I don't think so. I repeated the test with PC-DOS 5.02 and PC-DOS 4.01, which have "IBM 5.0" and "IBM 4.0" strings in the FAT sector, respectively. Both file systems are accepted by the installed GRLDR.MBR, saying "Try (hd0,1): FAT16". Gerolf |
|
Does RMPrepUSB recognise those PBRs (5.02 and 4.01)? |
|
Yes, I'll post the output at reboot.pro. |
|
Post # 42: Even FAT12 is enough to get GRLDR.MBR say "Try (hd0,0): FAT12" if only the formatting is done with DOS 4.01 or above (and RMPrepUSB can recognize the PBR data then). This does not help much, though, because PC-DOS 2.0 will only boot if it has formatted the partition by itself. And worse, it will only boot if a DOS MBR is present and will fail to do so after GRLDR.MBR has been bootlace'd. Some bytes in the DOS MBR must be required to boot PC-DOS 2.0. This thought immediately leads to a workaround to fix the dual-boot setup in post # 35: chainload the DOS MBR. (...) That way I can boot PC-DOS 2.0 from Grub4DOS (well, you cannot tell the kids the whole story of DOS and Windows without PC-DOS 2.0). Now it is not so important if GRLDR cannot be found on partitions formatted under MS-DOS 3.31 or below. The main problem under PCem is that "root" still fails after "map", limiting the multibooting options to switching the active and hidden states of primary partitions and to the "partnew" method (post # 36) that screws up the partition table. Gerolf |
Excerpts from http://reboot.pro/index.php?showtopic=22454:
Post # 1:
Do I observe correctly that it is not possible to boot Grub4DOS from VHD in PCem due to a gate A20 hickup?
I get a first message from Grub4DOS: "Try (hd0,0): FAT 12:", and then it hangs saying "A20 Debug: C806 done! ..."
Post # 7:
There are very old versions of Grub4DOS that do not show this error in PCem and 86Box. The oldest version I had lying around was a grub4dos-0.4.4-2009-12-03. Here, GRUB.EXE successfully boots to the command line, while GRLDR still fails, showing another strange message (not in VirtualBox):
Try (hd0,0): FAT16: No GRLDR
Try (hd0,1): invalid or null
Try (hd0,2): invalid or null
Try (hd0,3): invalid or null
Try (fd0): invalid or null
Cannot find grldr in all drives. Press Ctrl+Alt+Del to restart.
Post # 11:
Unlike one might have expected, a FAT12 partition (at least one with a H/S = 16/63 geometry) and (at least if that partition starts at cylinder 0) PC-DOS 2.0 indeed are enough to boot GRUB.EXE (at least in its first available version 0.4.4 of 2009-11-14).
Post # 19:
It turned out that the latest GRUB.EXEs that can boot in PCem under PC-DOS 2.0 date from 2014-01-17. During these tests I always expected to get a message like "unsupported DOS version", but that was not the case. Instead, GRUB.EXE either booted correctly or hang with a black screen and a blinking cursor in the upper left corner.
If I observed correctly, some of the "good" binaries shortly showed the "A20 Debug: C806 done! ..." message I had mentioned in my first post and then booted nevertheless, so I think this message is just informative and does not stem from the critical error that causes the hang-up, but rather happens to be just the last message written to screen before the error occurs.
It is noteworthy that the GRUB.EXE binaries were fixed once shortly after they broke, but then broke again one year later. And this appeared at the same dates with both 0.4.5c and 0.4.6a versions, so the bug must be in the code that was ported back or forth. In detail:
(...)
http://dl.grub4dos.chenall.net/grub4dos-0.4.5c-2012-12-05.7z boots
http://dl.grub4dos.chenall.net/grub4dos-0.4.6a-2012-12-05.7z boots
http://dl.grub4dos.chenall.net/grub4dos-0.4.5c-2012-12-16.7z hangs
http://dl.grub4dos.chenall.net/grub4dos-0.4.6a-2012-12-16.7z hangs
http://dl.grub4dos.chenall.net/grub4dos-0.4.5c-2012-12-31.7z hangs
http://dl.grub4dos.chenall.net/grub4dos-0.4.6a-2012-12-31.7z hangs
http://dl.grub4dos.chenall.net/grub4dos-0.4.5c-2013-01-13.7z boots
http://dl.grub4dos.chenall.net/grub4dos-0.4.6a-2013-01-13.7z boots
(...)
http://dl.grub4dos.chenall.net/grub4dos-0.4.5c-2014-01-17.7z boots
http://dl.grub4dos.chenall.net/grub4dos-0.4.6a-2014-01-17.7z boots
http://dl.grub4dos.chenall.net/grub4dos-0.4.5c-2014-06-24.7z hangs
http://dl.grub4dos.chenall.net/grub4dos-0.4.6a-2014-06-24.7z hangs
(...)
From ChangeLog_GRUB4DOS.txt of grub4dos-0.4.6a-2014-06-24:
"2013-01-12 (tinybit)cancel r313. add eltorito.sys. set safe_mbr_hook=1."
This would be my fixing tip.
Surely I should repeat those tests with higher DOS versions, a FAT16 boot partition, and an updated master boot record, but my first impression is that this issue does not depend on the DOS version.
Post # 20:
I see WinVBlock developer Sha0 asked Tinybit to set asm.S variable safe_mbr_hook=0 on 2012-12-13, just three days before the error occurred first:
http://reboot.pro/in...showtopic=17881
Gerolf
The text was updated successfully, but these errors were encountered: