Open aGGre55or opened 3 years ago
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 notifications@github.com 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 notifications@github.com 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.
On Sun, 20 Dec 2020 at 13:44, Kalamatee kalamatee@gmail.com wrote:
On Sun, 20 Dec 2020 at 09:10, Eugene notifications@github.com 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
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
CPU
Version It doesn't load at all
Additional context Read Oracle VM VirtualBox logs.. Logs.zip