So, being a VirtualBox "owner", I did some testing. :) First, I tested three methods of installing FreeDOS 1.2: FD12CD.iso, FD12LGCY.iso, and FLOPPY.IMG from FD12FLOPPY.ZIP. The infinite Invalid Opcode loop only occurs for me when booting FD12CD.iso. Oddly enough, booting FD12LGCY.iso on VirtualBox gives the message, "Unfortunately, this method of installation is not supported on this platform. Please try a different installation method.", although you can proceed to run the setup program from the prompt and it launches normally. I didn't run the setup through to completion since I have stuff on my virtual HD that I don't want to lose, but I can test that further with a blank one if it would help. The floppy image from the ZIP boots without issue.
To further isolate the Invalid Opcode issue, I extracted the floppy image (FDBOOT.IMG from the ISOLINUX folder) from the ISO and booted it as a floppy disk in VirtualBox which launched the installer flawlessly. The only difference was taking ISOLinux out of the mix, so it seems to me that VirtualBox is doing exactly what it should, it's just ISOLinux that isn't happy. Hope that helps! Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On July 29, 2018 6:56 PM, Eric Auer <e.a...@jpberlin.de> wrote: > Hi Jim, others, > > > Mercury Thirteen means this: > > > https://sourceforge.net/p/freedos/bugs/212/#1b4c > > > I'm not sure why VirtualBox has this problem. I don't recall that we > > saw this when wen tested the FreeDOS 1.2 distribution, did we? Or > > did VirtualBox have some regression? I use a different VM, so I don't > > know. > > For those without HTTPS SF compatible DOS browsers or extra time... > > Andrew Pennebaker wrote 2018-05-05 about freedos12: > > > I am trying to install FreeDOS in a virtual machine using VirtualBox, > > but a few seconds after I press Enter to begin the installation > > process, I get an infinite scrolling list of "Invalid Opcode" > > errors. > > > I'm using FreeDOS 1.2, in VirtualBox 5.2.10, in macOS 10.13 High > > Sierra. > > Jim originally suggested to use the /NOINVLPG option for JEMM386 based > on http://wiki.freedos.org/wiki/index.php/VirtualBox and disabling AHCI > mode and selecting legacy IDE mode in BIOS setup, but later he wrote: > > > An alternative solution I've seen mentioned elsewhere is adding the > > raw parameter to memdisk in the boot menu. > > > When you boot the FreeDOS install CDROM, when you get the get the > > first "Welcome to FreeDOS 1.2" boot menu, press Tab when you're on > > "Install to harddisk" and add 'raw' (without quotes) to the kernel > > command line, then press Enter to boot. > > > From this: KERNEL /boot/syslinux/memdisk > > > To this: KERNEL /boot/syslinux/memdisk raw > > According tohttps://www.syslinux.org/wiki/index.php?title=MEMDISK > > that magic "raw" parameter is about memory access and sizing: > > https://www.syslinux.org/wiki/index.php?title=MEMDISK#Memory_access_method > > > Memory access method > > > MEMDISK normally uses the BIOS "INT 15h mover" API to access high > > memory. This is well-behaved with extended memory managers which load > > later. Unfortunately, it appears that the "DOS boot disk" from WinME/XP > > deliberately crash the system when this API is invoked. The following > > command-line options tell MEMDISK to enter protected mode directly, > > whenever possible: > > > raw Use raw access to protected mode memory. > > > bigraw Use raw access to protected mode memory, and leave the > > CPU in "big real" mode afterwards. > > > int Use plain INT 15h access to protected memory. This assumes > > that anything which hooks INT 15h knows what it is doing. > > > safeint Use INT 15h access to protected memory, but invoke > > INT 15h the way it was before MEMDISK was loaded. > > This is the default since version 3.73. > > So apparently VirtualBox has a problem in the int 15 memory copy API!? > > If that is the case, then I would expect HIMEM to have problems as > well, while EMM386 should have fewer problems as it uses protected > mode directly in more cases? Or is this just about some special case > of reentrancy? Related to how both MEMDISK and LBACACHE try to use > memory beyond 1 MB, one for the disk image, the other for XMS cache? > In the latter case, LBACACHE should be told to not cache a MEMDISK. > > The best solution would probably be to improve the VirtualBox BIOS?? > > Another idea would be to try the MEMDISK "int" option which respects > int 15 hooks, because HIMEM probably has to hook int 15 as well and > the "safeint" default of avoiding new hooks might be exactly wrong? > > It would be cool if some VirtualBox owners could do some testing :-) > > Thanks! Regards, Eric > > PS: Do we know whether NOINVLPG actually helped in THIS situation? > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
