ubuntuusers.de

Hallo Benno, hallo bigboiler!

ich übertrage mal die Infos aus dem Thread und ergänze um ein paar weitere:

Der Bug, der das Booten von Windows im EFI-Modus verhinderte, ist seit kurzem behoben. Das macht es möglich, Versuche mit EFI-Boot und Windows 8/8.1 zu machen.

Zur Produktaktivierung von Windows 8/8.1 habe ich noch ein paar Infos finden können. Gab es bei Windows Vista und 7 noch die SLIC-Tabelle, gibt es jetzt (zusätzlich?) die MSDM-Tabelle, die sich auf gleiche Weise, wie im Artikel für SLIC beschrieben, in die VM integrieren lassen dürfte. Die MSDM-Tabelle enthält insbesondere den Product-Key der OEM-Windows-Versionen, also der vom Hersteller vorinstallierten Windosen, sowie einen Hardware-Hash.

Ich übertrage analog aus dem Artikel:

sudo dd if=/sys/firmware/acpi/tables/MSDM of=~/VirtualBox\ VMs/WindowsRAW/WindowsRAW_MSDM.bin 
sudo chown $USER ~/VirtualBox\ VMs/WindowsRAW/WindowsRAW_MSDM.bin 

VBoxManage setextradata "WindowsRAW" "VBoxInternal/Devices/acpi/0/Config/CustomTable" "$HOME/VirtualBox VMs/WindowsRAW/WindowsRAW_MSDM.bin" 

$VSETED $CFG_PATH/DmiBoardAssetTag      "string:asset"               # "Asset Tag" aus "dmidecode -t2"
$VSETED $CFG_PATH/DmiBoardBoardType     "1234"                       # "Type" aus "dmidecode -t2", muss eine Zahl (Integer) oder <EMPTY> sein
$VSETED $CFG_PATH/DmiBoardLocInChass    "string:locinchass"          # "Location in Chassis" aus "dmidecode -t2"

$VSETED $CFG_PATH/DmiChassisType        "1234"                       # "Type" aus "dmidecode -t3", muss eine Zahl (Integer) oder <EMPTY> sein

Es sind weitere Anpassungen der virtuellen Hardware möglich. Im Skript WindowsRAW_BIOS.sh ist zu ergänzen:

$VSETED $CFG_PATH/DmiBoardAssetTag      "string:asset"               # "Asset Tag" aus "dmidecode -t2"
$VSETED $CFG_PATH/DmiBoardBoardType     "1234"                       # "Type" aus "dmidecode -t2", muss eine Zahl (Integer) oder <EMPTY> sein
$VSETED $CFG_PATH/DmiBoardLocInChass    "string:locinchass"          # "Location in Chassis" aus "dmidecode -t2"

$VSETED $CFG_PATH/DmiChassisType        "1234"                       # "Type" aus "dmidecode -t3", muss eine Zahl (Integer) oder <EMPTY> sein

$VSETED $CFG_PATH/DmiProcManufacturer   "string:Intel"               # "Manufacturer" aus "dmidecode -t4"
$VSETED $CFG_PATH/DmiProcVersion        "string:Intel(R) Pentium(R) M processor"  # "Version" aus "dmidecode -t4"

$VSETED $CFG_PATH/DmiOEMVBoxVer         "string:SMBIOS 2.3"           # "String 1"(?) aus  "dmidecode -t11"
$VSETED $CFG_PATH/DmiOEMVBoxRev         "string:Customer Reference Platform"  # "String 2"(?) aus  "dmidecode -t11"

Eine Liste aller veränderbaren DMI-Parameter findet sich im VirtualBox Manual 9.12. "Configuring the BIOS DMI information".

Edit: Wird das "Efi aktivieren"-Flag gesetzt, muß im Skript

CFG_PATH="VBoxInternal/Devices/pcbios/0/Config"

ersetzt werden durch

CFG_PATH="VBoxInternal/Devices/efi/0/Config"

Hallo,

@Lauscher: Bitte _nicht_ hier den Thread mit How-Tos zuschmeißen - zumindest sehe ich bei deinen letzten beiden Posts kein Wort, dass du das in den Artikel einarbeiten willst.

Wenn du den Artikel überarbeiten möchtest → kurz hier melden, dann schieben wir den Artikel in die Baustelle.

Wenn du alternative Weg testen und ausdiskutieren möchtest → Supportforum.

Gruß, noisefloor

Hallo noisefloor,

Bitte _nicht_ hier den Thread mit How-Tos zuschmeißen - zumindest sehe ich bei deinen letzten beiden Posts kein Wort, dass du das in den Artikel einarbeiten willst.

ja, ich sehe auch, das ist nicht sinnvoll. Es wird schnell unübersichtlich.

Wenn du den Artikel überarbeiten möchtest → kurz hier melden, dann schieben wir den Artikel in die Baustelle.

Wenn du alternative Weg testen und ausdiskutieren möchtest → Supportforum.

Ich habe - bevor ich Deine Antwort hier gesehen habe - einen neuen Artikel in der Baustelle angelegt: Dualboot-Windows virtualisieren - Weiterentwicklung für UEFI und Windows 8. Dort integriere ich die oben gesammelten Howtos, um sie in übersichtliche und editierbare Form zu bringen.

Jetzt, wo Du es sagst, denke ich, es ist sinnvoller, den Artikel als solchen in die Baustelle zu verschieben. Er bleibt ja trotzdem im Wiki sichtbar. Ich hatte den (falschen) Gedanken, daß der Artikel in der Überarbeitungszeit aus dem Wiki verschwindet. (Da die Anpassung an UEFI und Windows 8 noch sehr experimentell ist, kann es lange dauern, bis die Ergebnisse reif für die Veröffentlichung sind).

Jetzt habe ich Unordnung ins Wiki gebracht - kannst Du das bitte wieder aufräumen? (D. h., den neuen Baustellenartikel als Baustelle für den Ursprungsartikel einsetzen?). EDIT: Du kannst auch einfach den neuen Baustellenartikel löschen und Dualboot-Windows virtualisieren in die Baustelle verschieben. Die Änderungen habe ich auf meinem Rechner gesichert.

Danke, und sorry

Lauscher

Hallo,

aha - gut. Also ob ein zweiter Artikel für UEFI sinnvoll ist, kann ich gerade nicht beurteilen. Da es aber noch genug System mit "klassischem BIOS" gibt und Win 7 gibt, macht ein eigener Artikel vielleicht schon Sinn. Wenn man zu viel in einen Artikel rein packt ist das auch nicht gut.

Gruß, noisefloor

Hi Lauscher,

es funktioniert !!!. Cool ☺, Danke für die ganzen Infos!

Notebook Acer Aspire V3-571G
Host: Ubuntu 12.04 64bit
Guest: W8 64bit
VBox: 4.3.20
Boot: EFI (Variante 1, d.h. EFI in VirtualBox Settings aktiviert)
MSDM Tabelle : vorhanden , eingebunden wie beschrieben
Secure/Fast Boot deaktiviert
Nachteil: W8 Aktivierung bleibt (noch..) nicht gültig. Irgendeine Info scheint noch zu fehlen oder scheint nicht zu stimmen.

Tipps: 1) Vorher im EFI Bios *unbedingt* die Bootreihenfolge so einstellen, dass automatsich Windows bootet. Beim start der VM hätte ich hier keine Möglichkeit gehabt, einen Start des Host-Systems zu verhindern.

2) erstmal vor dem Starten der VM Netzstecker ziehen (ich meine den von der Netzwerkkarte ☺ ☺ ), damit W8 nicht automatisch irgendwelche neuen Aktivierungsversuche etc. macht. Wiegesagt, in der VM wird bei mir noch 'nicht aktiviert' angezeigt. Starte ich danach wieder W8 native, wird die gültige Aktivierung weiterhin erkannt.

Hinweis zu den Skripten: Für DmiBoardBoarType & ChassisType wird auch <EMPTY> nicht von VBox akzeptiert. dmidecode liefert bei mir jedoch keine Angabe, also habe ich einfach eine Zahl willkürlich gewählt.

-b.b.

Hallo bigboiler!

bigboiler schrieb:

Hi Lauscher,

es funktioniert !!!. Cool ☺, Danke für die ganzen Infos!

Sehr schön! ☺

Nachteil: W8 Aktivierung bleibt (noch..) nicht gültig. Irgendeine Info scheint noch zu fehlen oder scheint nicht zu stimmen.

Das bekommen wir bestimmt noch hin. Bei W7 war es auch eine ziemliche Tüftelei, aber irgendwann ging es.

Tipps: 1) Vorher im EFI Bios *unbedingt* die Bootreihenfolge so einstellen, dass automatsich Windows bootet. Beim start der VM hätte ich hier keine Möglichkeit gehabt, einen Start des Host-Systems zu verhindern.

Hmm, keine Auswahl? Unschön. Da die Ubuntu-Partitionen nicht eingebunden werden, dürfte nichts allzu schlimmes passieren, außer daß der Bootvorgang hängenbleibt, aber damit ist noch nichts gewonnen. Und die Bootreihenfolge dauerhaft umzustellen, ist auch unvorteilhaft.

Mit Clover/Variante 2 dürfte sich das Problem umgehen lassen, indem nur die EFI-Bootdateien für Windows auf die Clover-Partition übernommen werden. Wärst Du bereit, ein Experiment mit Clover zu machen? Es wäre sinnvoll, dafür eine 2. VM WindowsRAW_Clover anzulegen. Clover hat zudem den Vorteil, einige Konfigurationsmöglichkeiten zu bieten, die bei der Produktaktivierung nützlich sein könnten.

2) erstmal vor dem Starten der VM Netzstecker ziehen (ich meine den von der Netzwerkkarte ☺ ☺ ), damit W8 nicht automatisch irgendwelche neuen Aktivierungsversuche etc. macht.

Ok, ich mache einen Hinweis in die Baustelle, bis das Problem "Produktaktivierung" gelöst ist.

Wiegesagt, in der VM wird bei mir noch 'nicht aktiviert' angezeigt. Starte ich danach wieder W8 native, wird die gültige Aktivierung weiterhin erkannt.

Daß die native Produktaktivierung erhalten bleibt, ist erfreulich und beruhigend!

Hinweis zu den Skripten: Für DmiBoardBoarType & ChassisType wird auch <EMPTY> nicht von VBox akzeptiert. dmidecode liefert bei mir jedoch keine Angabe, also habe ich einfach eine Zahl willkürlich gewählt.

Seltsam. Mein Testskript wird problemlos angenommen (ebenfalls VBox 4.3.20):

#! /bin/bash
VM_NAME="WindowsRAW"                                                          # Name der Virtuellen Maschine
VSETED="VBoxManage setextradata $VM_NAME"
CFG_PATH="VBoxInternal/Devices/pcbios/0/Config"                               # Legacy BIOS wird verwendet ("EFI aktivieren"-Flag ist nicht gesetzt)

$VSETED $CFG_PATH/DmiBoardAssetTag       "string:asset"                       # NEU "Asset Tag" aus "dmidecode -t2"
$VSETED $CFG_PATH/DmiBoardBoardType      "1234"                               # NEU "" aus "dmidecode -t2", muss eine Zahl (Integer) oder <EMPTY> sein
$VSETED $CFG_PATH/DmiBoardLocInChass     "string:locinchass"                  # NEU "Location in Chassis" aus "dmidecode -t2"
$VSETED $CFG_PATH/DmiChassisType         "1234"                               # NEU "Type" aus "dmidecode -t3", muss eine Zahl (Integer) oder <EMPTY> sein

Als Unterschied sehe ich allenfalls, daß Du am Skriptanfang "pcbios" durch "efi" ersetzt haben wirst.

Ein paar Fragen habe ich:

• Hast Du Windows 8.0 oder 8.1?

• Würdest Du mir Deine Ausgabe von "sudo parted -l" für den Artikel zur Verfügung stellen?

• Gibt es außer der MSDM-Tabelle zusätzlich noch eine SLIC-Tabelle?

• Wie groß in Bytes ist die MSDM-Tabelle?

• Könntest Du mit einer Live-CD in WindowsRAW die Anpassungen der virtuellen Hardware überprüfen? Neben dmidecode auch Festplattendaten, CD, Netzwerkadressen und MSDM?

• Läßt sich das "nicht aktivierte" VM-Windows ohne Einschränkungen benutzen?

In der MSDM-Tabelle werden nach meinem bisherigen Wissensstand neben dem Produkt Key auch ein Hardware Hash gespeichert. Wüßten wir mehr über die Berechnung des Hardware Hashes, könnten wir vllt. selbst einen erzeugen und die MSDM-Tabelle anpassen. Doch zu diesem Hash habe ich bisher nur dürftige Infos gefunden.

Ich werde mal weiter recherchieren, ob ich noch Infos zur neuen Aktivierungstechnik finde.

Viele Grüße, und danke fürs Testen!

Lauscher

Hi Lauscher,

herauszufinden, welche Info M$ für den hardware Hash verquirlt, ist irgendwie ein Stochern im Nebel. Und in den Windows Foren steht viel Zeugs, da die Spreu vom Weizen zu trennen ist schwierig.

Ich habe gerade nicht allzuviel Zeit, mich mit der Sache zu befassen, evtl. kann ich nebenher nochmal das eine od. andere testen / überprüfen. Die Clover-Variante fällt daher für mich aus Zeitmangel leider erstmal aus. Das mit der umgestellten Boot-Reihenfolge stört mich auch nicht.

Die Partitionstabelle stelle ich mal hier rein:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system     Name                          Flags
 1      1049kB  420MB   419MB   ntfs            Basic data partition          hidden, diag
 2      420MB   735MB   315MB   fat32           EFI system partition          boot
 3      735MB   869MB   134MB                   Microsoft reserved partition  msftres
 4      869MB   299GB   298GB   ntfs            Basic data partition
 6      299GB   299GB   400MB   ext4
 7      299GB   301GB   1400MB  linux-swap(v1)
 8      301GB   481GB   180GB   ext4
 9      481GB   980GB   500GB   ext4
 5      980GB   1000GB  19.9GB  ntfs            Basic data partition          hidden, diag

Ich bin kein OS Guru, d.h. ich habe einfach Q&D mit der Windows-Datenträgerverwaltung die Volumes verkleinert, ohne jetzt mit externen Tools das letzte GB aus der Platte quetschen zu wollen. In dem freigeräumten Platz habe ich dann Ubuntu installiert. In der ob. Tabelle sind also 1-5 die Windows Partitionen, 6-9 die Linux Partitionen. D.h. für die "-partitions" Option im createrawvmdk Command habe ich entsprechend 1,2,3,4,5 eingetragen. 5 ist wohl so'ne komische Recovery-Partition.

Zu den anderen Fragen:
Es ist W8, nicht 8.1. Und die Kiste hat keine SLIC Table mehr, nur noch die MSDM Table (die anderen im /sys/firmware/acpi/tables Verzeichnis mal nicht mitgezählt). Die MSDM Table ist angeblich (steht in anderen Foren) immer 85 Bytes lang. War bei mir auch so. In den letzten Bytes steht mein W8 Producct Key. Der wird auch (nur die letzten Zeichen) in der W8 Raw VM angezeigt, d.h. VirtualBox scheint die MSDM Table richtig weiterzugeben. Vermutlich errechnet W8 also einen neuen Hardware Hash.
Bislang lässt sich W8 in der VM normal nutzen.

Gruss
-b.b.

PS:
Was den Issue im Skipt anbelangt, meinte ich den Comment. Für BoardType akzeptiert VirtualBox keinen <EMPTY> Eintrag, aber im Comment steht das noch als Möglichkeit. In deinem Beispielskript hast du ja auch eine Integer Zahl eingetragen.

Hallo,

was ist eigentlich Stand der Dinge bzgl. der Baustelle? Wenn die ins Wiki kann bitte kurz Bescheid sagen, dann kommt der finale Check ☺

Gruß, noisefloor

Hallo bigboiler,

danke für die Partitionstabelle und die weiteren Hinweise!

hallo noisefloor,

leider ist der Artikel noch nicht soweit. W8 läßt sich zwar starten, die Produktaktivierung ist aber noch nicht überlistet. Ich werde den Artikel weiter bearbeiten und auch Workarounds beschreiben.

Vor einer Veröffentlichung wäre es hilfreich, noch weitere Tester zu finden. Oder, ich entwickele den Artikel zu einem veröffentlichbaren Level, und verbessere und erweitere ihn auf Basis dann folgender Rückmeldungen.

Viele Grüße, Lauscher

Hallo,

Lauscher schrieb:

Vor einer Veröffentlichung wäre es hilfreich, noch weitere Tester zu finden. Oder, ich entwickele den Artikel zu einem veröffentlichbaren Level, und verbessere und erweitere ihn auf Basis dann folgender Rückmeldungen.

Ok, können wir so machen. Wenn sich niemand meldet bzw du keinen findest, dann nehmen wir die 2. Option ☺

Gruß, noisefloor

Hallo noisefloor,

der Artikel ist jetzt auf dem aktuellen Stand des Wissens und in einem aufgeräumten Zustand. Ich denke, man kann ihn so veröffentlichen.

Bisherige Schwachpunkte:

• Die Produktaktivierung von W8 bleibt in der VM nicht erhalten (im physikalischen Boot ist sie aber wieder da, kann außerdem als kleines Backup gesichert werden).

• Getestet nur für Windows 8.0. Windows 7 und 8.1 sind noch nicht getestet. (W7 dürfte aber anstandslos funktionieren. Vereinzelt gibt es wohl W7 auf UEFI-Rechnern).

• Für die EFI-Virtualisierung sind im Artikel 2 Varianten genannt, getestet ist nur Variante 1 (EFI-Virtualisierung von VirtualBox). Die 2. Variante, EFI-Virtualisierung mit Clover, lasse ich aus 2 Gründen im Artikel:

  • Clover bietet weitere Möglichkeiten der Anpassung der virtuellen Hardware, die sich als wichtig für W8 erweisen könnten.

  • Die EFI-Virtualisierung von VirtualBox funktioniert anscheinend nur, wenn W8 in der physikalischen Bootreihenfolge auf Platz 1 steht. Clover läßt sich konfigurieren.

• Insgesamt gibt es erst 1 Test für den Artikel (mit Ubuntu 12.04 und W8.0).

Es gibt noch einige Ansätze, wie die Produktaktivierung von W8 evtl. doch noch in der VM erhalten werden kann. Sie sind noch nicht artikelreif; ich werde sie hier in der Diskussion zum Artikel veröffentlichen.

Zur Strukturierung im Wiki ist denkbar, den Artikel Dualboot-Windows virtualisieren in einen kurzen Übersichtsartikel umzuwandeln, mit kurzer Einführung in die Thematik und Links zu 2 Unterartikeln, einer für Legacy-BIOS und einer für UEFI-BIOS. Ich bin unsicher, wie die Unterartikel sinnvoll benannt werden sollten, eventuell ganz einfach:

• Dualboot-Windows virtualisieren - Legacy-BIOS

• Dualboot-Windows virtualisieren - UEFI-BIOS

Eleganter wäre vielleicht:

• Dualbootsysteme virtualisieren - Legacy-BIOS

• Dualbootsysteme virtualisieren - UEFI-BIOS

Der bisherige Artikelname "Dualboot-Windows virtualisieren" sollte erhalten bleiben. Zum einen wird die Anwendung in erster Linie Windows-Systeme betreffen, zum anderen ist der bisherige Name auch im www schon etliche Male verlinkt worden.

Was meinst Du?

Viele Grüße, Lauscher

Hallo, Stand der Dinge? Lt Autor fertig. Gruss