| Summary: | Virtualbox 7.0.2 doesn't run earlier created Windows XP and Windows 2k guests. | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Alexander Krylov <kafra2005> |
| Component: | RPM Packages | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | andrewsfarm, fri, sysadmin-bugs |
| Version: | 8 | Keywords: | advisory, validated_update |
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | MGA8-64-OK | ||
| Source RPM: | virtualbox-7.0.2-1.mga8.src.rpm | CVE: | |
| Status comment: | |||
|
Description
Alexander Krylov
2022-11-05 15:34:51 CET
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) =>
UPSTREAM 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.rpmAssignee:
kernel =>
qa-bugs 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-OK
Thomas Backlund
2022-11-15 08:25:58 CET
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) =>
FIXED |