aros-development-team
AROS64 doesn't load with any of the menu options in VirtualBox 6.1
Describe the bug Oracle VM VirtualBox 6.1.4 r136177 (Qt5.6.2) Image: aros-pc-x86_64.iso from AROS-20201214-pc-x86_64-boot-iso (ABIv1) Default settings, VBoxVGA, 128M VideoRAM, No accellerated
To Reproduce Steps to reproduce the behavior: trying to boot from the gnu grub 2.04 menu:
AROS64 with native Gfx - critical error, Ignore, full freeze AROS64 with VESA Gfx @ 640x480-8bpp - critical error, Ignore, full freeze AROS64 with VESA Gfx @ 800x600-8bpp - critical error, Ignore, full freeze AROS64 with VESA Gfx @ 1024x768-8bpp - critical error, Ignore, full freeze AROS64 with VESA Gfx @ 1280x1024-8bpp - critical error, Ignore, full freeze AROS64 with VESA Gfx @ 640x480-16bpp - critical error, Ignore, full freeze AROS64 with VESA Gfx @ 800x600-16bpp - critical error, Ignore, full freeze AROS64 with VESA Gfx @ 1024x768-16bpp - critical error, Ignore, full freeze AROS64 with VESA Gfx @ 1280x1024-16bpp - critical error, Ignore, full freeze AROS64 with VESA Gfx @ 640x480-32bpp - critical error, Ignore, full freeze AROS64 with VESA Gfx @ 800x600-32bpp - critical error, Ignore, full freeze AROS64 with VESA Gfx @ 1024x768-32bpp - critical error, Ignore, full freeze AROS64 with VESA Gfx @ 1280x1024-32bpp - critical error, Ignore, full freeze AROS64 with VESA Gfx @ 32bpp and legacy drivers) - critical error, Ignore, full freeze AROS64 with VGA @ 640x480-4bpp - critical error, Ignore, full freeze AROS64 with VGA @ 640x480-4bpp (slow ATA) - critical error, Ignore, full freeze
Expected behaviour I was waiting for the system to boot in any of the proposed options. Otherwise I don't understand: why are they offered to me?
Screenshots
Architecture
- pc (native)
CPU
- x86_64
Version It doesn't load at all
Additional context Read Oracle VM VirtualBox logs.. Logs.zip
This is likely due to the changes that where being done in SetMem, and should be resolved in current builds.
I also failed with AROS-20201217-pc-x86_64-boot-iso.zip Maybe I should press the "e" button and play around with the grub options?
Depending on your machine, you may need to specify "noioapic" to disable support for the io-apic (routes hardware interrupts) - it is known to have problems with some systems which incorrectly report the PIT timers interrupt, or have it incorrectly configured in hardware.
FWIW - if you are able, you can configure a serial port to output the debug information for the build to a file, and add "debug=serial sysdebug=all" to the boot command line to have AROS output it.
On Thu, 17 Dec 2020 at 21:56, Eugene [email protected] wrote:
I also failed with AROS-20201217-pc-x86_64-boot-iso.zip https://sourceforge.net/projects/aros/files/nightly2/20201217/Binaries/AROS-20201217-pc-x86_64-boot-iso.zip/download Maybe I should press the "e" button and play around with the grub options?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/aros-development-team/AROS/issues/168#issuecomment-747725969, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACWCNPH2CU66H2HWJUAM7ZDSVJ475ANCNFSM4U47TOPA .
unfortunately everything that was captured in 20201217 with add "debug=serial sysdebug=all":
AROS64 - The AROS Research OS
64-bit build. Compiled Dec 17 2020
[EXEC] Init: Post-kernel init
[EXEC] Init: Memory page size: 16
I will investigate this more, but later.
thanks for pointing out the methodology.
On Sun, 20 Dec 2020 at 09:10, Eugene [email protected] wrote:
unfortunately everything that was captured in 20201217 with add "debug=serial sysdebug=all": AROS64 - The AROS Research OS 64-bit build. Compiled Dec 17 2020 [EXEC] Init: Post-kernel init [EXEC] Init: Memory page size: 16 I will investigate this more, but later. thanks for pointing out the methodology.
Yeah - I wouldn't worry about that build, it was expected to be broken. A newer nightly should work correctly though.
If you have any queries though the slack channel is the best place to ask - AROS Exec doesn't really have anyone involved visiting it any more, and is just a handful of people.
https://join.slack.com/t/arosdevteam/shared_invite/enQtOTc4Mzg0NDIzNzQ0LWQ2NWZmNmMwNGIwNGEyNTgxNzU3MGFjMTk3ZThmOTQ1MTVjMzhmNTllYWQ0ZTUxMjBjMGE0Y2VjMDJmNTc5MzI
On Sun, 20 Dec 2020 at 13:44, Kalamatee [email protected] wrote:
On Sun, 20 Dec 2020 at 09:10, Eugene [email protected] wrote:
unfortunately everything that was captured in 20201217 with add "debug=serial sysdebug=all": AROS64 - The AROS Research OS 64-bit build. Compiled Dec 17 2020 [EXEC] Init: Post-kernel init [EXEC] Init: Memory page size: 16 I will investigate this more, but later. thanks for pointing out the methodology.
Yeah - I wouldn't worry about that build, it was expected to be broken. A newer nightly should work correctly though.
I was able to run AROS-20210210-pc-x86_64-boot-iso in VMware Workstation 15 Player (15.5.2 build-15785246) with default grub settings. However, this image is still not loaded into VirtualBox 6.1.4 The error occurs after the message "Not in text mode!" for "VESA=1024x768x16 ATA=32bit AHCI=disable NVME=disable". For AROS64 Native Gfx with "ATA=32bit AHCI=disable NVME=disable" i read normal -- 80x25 --, but further the same "GUI: User request to power VM off on Guru Meditation." This error is state independent IOAPIC in VBox interface.
00:00:04.882225 ERROR [COM]: aRC=E_UNEXPECTED (0x8000ffff) aIID={4680b2de-8690-11e9-b83d-5719e53cf1de} aComponent={DisplayWrap} aText={Screenshot is not available at this time}, preserve=false aResultDetail=-52
I'm attaching logs for both cases (with and without VESA) VBox_NoVESA.log VBox_VESA32.log