Description of problem: As title says, Virtualbox 7.0.x has regressions. It doesn't run earlier created Windows XP and Windows 2k guests. See: https://www.virtualbox.org/ticket/21221 https://www.virtualbox.org/ticket/21191 https://forums.virtualbox.org/viewtopic.php?f=6&t=107495&start=15 I can confirm, that virtualbox-7.0.2-1.mga8.x86_64 package has this issue as well. Version-Release number of selected component (if applicable): x86_64: dkms-virtualbox-7.0.2-1.mga8.x86_64.rpm virtualbox-7.0.2-1.mga8.x86_64.rpm Steps to Reproduce: 1. Create Windows XP guest vm with VBox 6.1.40 or earlier. 2. Update VBox to 7.0.2 & install corresponding VirtualBox Extension Pack. 3. Try to run earlier created WinXP guest vm. Temporal workaround: Downgrade to Virtualbox 6.1.40.
Reading your links, all from virtualbox forums and bugs, indicates that this is a widespread problem, not just one involving Mageia. Consequently, it's probably an upstream bug, and not likely one that we are going to solve. But that doesn't stop us from looking at it. My 32-bit XP guest, created so many years ago that I don't remember when I did it, is working just fine with our latest virtualbox. When I updated, I removed the 6.1.40.extension pack, and left the "experimental" extension that was supplied with the update. XP guest additions had to be inserted manually by putting the downloaded CD iso in the virtual optical drive. I did not install any 7.0.2 extension pack, because it's not supposed to be needed now if all you use it for is usb 2.0/3.0 support. Hmmm. That reminds me... Back when I got my first host machine with usb 3.0 hardware, I had to change the virtualbox usb 3.0 chip emulation from the default Intel chip to one from Renesas, and install a specific Renesas driver before XP could use it. The instructions can be found at https://forums.virtualbox.org/viewtopic.php?f=28&t=74575 I'm wondering if, off the top of my head, because usb 2.0/3.0 emulation has been moved from the extension pack, XP guests will now crash because they are trying to deal with an emulated chip for which they have no driver. Probably not, but it might be worth looking at.
CC: (none) => andrewsfarm
Hi, this problem is definitely not USB related. I already had those USB 3.0 settings in-place, removing them and even disabling USB controller completely doesn't change anything - old WinXP VM is getting stuck in boot loop. What I have found so far: Creating new WinXP VM under VBox 7.0.2 with default settings - Guest OS installation works as expected. Creating new WinXP VM under VBox 7.0.2 with more than 1 CPU core (System > Processor) or with ticked "Enable I/O APIC" option (System > Motherboard) - Guest OS installation getting stuck indefinitely at "Setup is starting Windows" screen. Also, fiddling with the above options and old VM will make it hang completely after choosing any boot mode.
Well, it was a thought. My XP guest is 32-bit, so it can't really use more than one processor, anyway. And I never really needed any more performance than the default settings gave me, so I haven't tried changing them much. And with that, I have pretty much exhausted my expertise on the subject.
A reversion is a reversion: > Virtualbox 7.0.x has regressions. > It doesn't run earlier created Windows XP and Windows 2k guests > workaround: > Downgrade to Virtualbox 6.1.40 Assigning to kernel group, as VB normally goes there.
Keywords: (none) => UPSTREAMAssignee: bugsquad => kernel
Update: https://www.virtualbox.org/ticket/21256#comment:3 link contains temporal working solution for VBox 7.0.x users. >We reproduced the issue and a re investigating this. >As a temporary workaround you could run the following command: VBoxManage setextradata <VM name> "VBoxInternal/HM/TPRPatchingEnabled" 0 >That should make it work even with the correct guest OS type.
Great :) ...and comment 4 now: >This will b fixed in the next maintenance release of VirtualBox
CC: (none) => fri
There is now a virtualbox-7.0.2-1.1.mga8 currently building and heading to updates_testing with a possible fix for this (and the same fix for Cauldron in virtualbox-7.0.2-2.mga9)
Patched virtualbox-7.0.2-1.1.mga8 from 'updates_testing' works with old WinXP VMs as expected. What I did for testing: 1. Executed 'VBoxManage setextradata myxpvm "VBoxInternal/HM/TPRPatchingEnabled" 1' command on unpatched virtualbox-7.0.2-1.mga8.x86_66 to undo a workaround from comment #5. 2. Double-checked that my WinXP VM is unbootable again. 3. Installed patched virtualbox-7.0.2-1.1.mga8.x86_64.rpm & dkms-virtualbox-7.0.2-1.1.mga8.x86_64.rpm packages from 'updates_testing'. 4. Executed my old WinXP VM, which booted successfully.
Great, lets push it through QA for updates. Advisory: type: bugfix subject: Updated virtualbox packages fix regression with vms running legacy Windows OSes src: 8: core: - virtualbox-7.0.2-1.1.mga8 - kmod-virtualbox-7.0.2-1.1.mga8 description: | The update to Virtualbox 7.0.2 released in MGAA-2022-0138 introduced a regression in running vms with legacy Windows operating systems like Windows 2000 and Windows XP. This update backports an upstream change that resolves this issue. references: - https://bugs.mageia.org/show_bug.cgi?id=31079 SRPMS: virtualbox-7.0.2-1.1.mga8.src.rpm kmod-virtualbox-7.0.2-1.1.mga8.src.rpm i586: virtualbox-7.0.2-1.1.mga8.i586.rpm virtualbox-guest-additions-7.0.2-1.1.mga8.i586.rpm x86_64: dkms-virtualbox-7.0.2-1.1.mga8.x86_64.rpm python-virtualbox-7.0.2-1.1.mga8.x86_64.rpm virtualbox-7.0.2-1.1.mga8.x86_64.rpm virtualbox-devel-7.0.2-1.1.mga8.x86_64.rpm virtualbox-guest-additions-7.0.2-1.1.mga8.x86_64.rpm virtualbox-kernel-5.15.74-desktop-1.mga8-7.0.2-1.1.mga8.x86_64.rpm virtualbox-kernel-5.15.74-server-1.mga8-7.0.2-1.1.mga8.x86_64.rpm virtualbox-kernel-desktop-latest-7.0.2-1.1.mga8.x86_64.rpm virtualbox-kernel-server-latest-7.0.2-1.1.mga8.x86_64.rpm backport kmods: SRPMS: kmod-virtualbox-7.0.2-w.1.mga8.src.rpm x86_64: virtualbox-kernel-5.19.16-desktop-1.mga8-7.0.2-2.1.mga8.x86_64.rpm virtualbox-kernel-5.19.16-server-1.mga8-7.0.2-2.1.mga8.x86_64.rpm virtualbox-kernel-desktop-latest-7.0.2-2.1.mga8.x86_64.rpm virtualbox-kernel-server-latest-7.0.2-2.1.mga8.x86_64.rpm
Assignee: kernel => qa-bugsKeywords: UPSTREAM => (none)
i5-2500 mga8-64 Plasma system, using kernel-desktop 5.15.74. I was unable to reproduce the issue, probably because my XP guest is 32-bit rather than 64, so I can't comment on whether this issue is fixed. However... No installation issues. Rebooted after the update, just to be sure, then ran my XP guest, my 64-bit Windows 7 guest, and a couple of Mageia 8 guests. No issues noted. OK here, as far as I can tell.
Quick check OK my Windows 7 and mga8 guests still can surf internet and access USB stick.
I acquired an old WinXP 64-bit install disk from a relative, and created an iso from it. On a system still using VirtualBox 6.1.38, I took a couple of hours to create a very basic XP guest that used two cores and 4GB of RAM, and inserted guest additions. Then I updated the host, with kernel 5.15.74 and VirtualBox 7.0.2, added the extension pack, and attempted to boot the new XP guest once more. The guest did boot, but almost immediately crashed. I used qarepo to get the above updates, which installed with no issues. I booted the XP guest again, this time with no issues, ran it long enough to insert the guest additions, and rebooted once again. Everything looks normal, or as normal as XP ever gets. I was going to OK and validate, but upon further consideration this should probably have additional tests with a backported kernel first.
Same hardware as comment 12, different install, this one recently updated to the 5.19.16 kernel. Rather than creating a new XP guest, I exported this one from the comment 12 system and imported it here. Interestingly, the XP guest ran fine this time in the initial test. (Speculation on the reason: The exported guest has the 7.0.2 guest additions installed, where the original comment 12 guest had 6.1.38 guest additions.) Anyway, I updated the packages, and ran the XP guest again, and it still works. So, I'm giving this an OK and validating. Advisory in comment 9.
Whiteboard: (none) => MGA8-64-OKCC: (none) => sysadmin-bugsKeywords: (none) => validated_update
Keywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2022-0144.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED