efi - virtuell

Dieses Forum behandelt Fragen über alle Bereiche, die nicht zur Erstellung der Distribution gehören. Das kann beispielsweise Webseiten-Entwicklung, Marketing, usw. sein.

Re: efi - virtuell

Beitragvon unklar » Apr 30th, '15, 12:05

Nun habe ich am 28.04.2015 mit der um 13.54 Uhr zur Verfügung stehenden boot-nonfree.iso (Version mit "unfreier Firmware") eine Netzwerkinstallation durchgeführt. Wieder hatte ich mir eine qcow2-Datei angelegt.

Um es gleich vornweg zu nehmen, es wurde ein Fiasko.
Hier in diesem Rechner steckt eine ATI und ich war der Meinung, die unfreie Firmware hilft mir da über den Berg. Falsch!
Gleich zu Beginn konnte er mir kein X zur Verfügung stellen, weil der Treiber fehlt. Schließlich stellte er mir die Textkonsole. Das da ca. 20% rechts fehlten,
nahm ich zu diesem Zeitpunkt noch gar nicht für voll. Ich wählte, um es möglichst kurz zu machen, "anderer Desktop" (was die bei Mageia immer noch anders bewerten und es damit nicht wirklich kurz wird).
Bei der Installation des Bootloader machten sich diese fehlenden 20% dahingehend bemerkbar, ich konnte nicht sehen /dev..(und fand auch keine Möglichkeit), wohin er den, von den drei angebotenen Möglichkeiten, installieren wollte. Also vertraute ich seiner Veriante.

Der Neustart zeigte, er hatte alles korrekt auf "sda" installiert. :lol: Ich wollte aber sdb haben.

Damit startete im qemu jetzt immer diese ICEWM-Variante der Netzwerkinstallation. Das läßt sich mit der efi-shell auf Grund der Anleitung vom Lutz
einfacher korrigieren, als ich das bisher über chroot oder init3 kannte. Die efi-Shell startet eben den Kernel von mga5-kde problemlos und dann kann man den grub2 wieder auf sda installieren.

In der Folgezeit habe ich erfolglos versucht, die Icewm mit in die sda von kde zu bekommen. Obwohl sie eine eigene UUID hat, ist sie dennoch auch "sda" und ich kriege sie als "2.Platte" in der "1.Platte-kde" nicht zu Gesicht.
Zuletzt geändert von unklar am Apr 30th, '15, 21:12, insgesamt 1-mal geändert.
El Conkystador (el conquistador = der Sieger) ein Markenzeichen für @Sector11 8-)
unklar
 
Beiträge: 1468
Registriert: Jun 1st, '11, 15:06

Re: efi - virtuell

Beitragvon lula » Apr 30th, '15, 17:48

unklar hat geschrieben:Hier in diesem Rechner steckt eine ATI und ich war der Meinung, die unfreie Firmware hilft mir da über den Berg. Falsch!
Gleich zu Beginn konnte er mir kein X zur Verfügung stellen, weil der Treiber fehlt.
Den Zusammenhang verstehe ich jetzt nicht, die Graka des Hosts hat doch nichts mit der des Gasts zu tun, der Gast sieht doch die Hardware, die Du über -vga angibst (bzw. die cirrus, wenn man's weglässt):
man qemu hat geschrieben:
Code: Alles auswählen
       -vga type
           Select type of VGA card to emulate. Valid values for type are

           cirrus
               Cirrus Logic GD5446 Video card. All Windows versions starting from Windows 95 should recognize and use this graphic
               card. For optimal performances, use 16 bit color depth in the guest and the host OS.  (This one is the default)

           std Standard VGA card with Bochs VBE extensions.  If your guest OS supports the VESA 2.0 VBE extensions (e.g. Windows XP)
               and if you want to use high resolution modes (>= 1280x1024x16) then you should use this option.

           vmware
               VMWare SVGA-II compatible adapter. Use it if you have sufficiently recent XFree86/XOrg server or Windows guest with a
               driver for this card.


unklar hat geschrieben:In der Folgezeit habe ich erfolglos versucht, die Icewm mit in die sda von kde zu bekommen. Obwohl sie eine eigene UUID hat, ist sie dennoch auch "sda" und ich kriege sie als "2.Platte" in der "1.Platte-kde" nicht zu Gesicht.
Hier ist mir auch nicht klar, was Du versuchst, kannst Du das mal ein bisschen ausführlicher (z. B. mit ein paar kommentierten Ausgaben von fdisk, blkid, lsblk, etc.) beschreiben?
lula
 
Beiträge: 644
Registriert: Feb 10th, '12, 20:13

Re: efi - virtuell

Beitragvon unklar » Apr 30th, '15, 21:06

lula hat geschrieben:Den Zusammenhang verstehe ich jetzt nicht, ..

Da hat er natürlich Recht! Habe den Satz mal ganz schnell durchgestrichen, weil - nicht "um die Ecke gedacht".

Eine vga hatte ich im Befehl von qemu nicht angegeben. Genau wie der Befehl zur Installation der KDE.iso, nur mit dem anderen "Device" name2.qcow2. Trotzdem bekam ich die EE - Meldung vom fehlenden X-Treiber.
Ist jetzt auch egal, weil mit dem Einbinden der nonfree-Quellen bei der Installation dann der Neustart mit X erfolgte.

Hier ist mir auch nicht klar, was Du versuchst, kannst Du das mal ein bisschen ausführlicher (z. B. mit ein paar kommentierten Ausgaben von fdisk, blkid, lsblk, etc.) beschreiben?
Hier die Netzwerk-Installation Icewm:
efibootICEWM2.jpg
Sie ist praktisch identisch mit der von KDE (weiter oben ;) )
virt.Platte name1.qcow2 dynamisch 10G 3 Partitionen (KDE) als sda angelegt
virt.Platte name2.qcow2 dynamisch 8G 3 Partitionen (IceWM) als sda angelegt

Der Unterschied sind nur (logisch) die UUID's.
Korrigiert habe ich nur, das die efi den Bootloader von KDE wieder benutzt.

Wahrscheinlich mein Fehler, dass ich nicht weiß, wie der qemu die zweite Installation auf sdb anlegt.

In der Zwischenzeit habe ich herausgefunden, wie ich das Image name2.qcow2 mounten kann:
Code: Alles auswählen
modprobe nbd max_part=16  (das wußte ich da noch nicht; das erstellt unter /dev/nbd0-15 Blockdevice)
>>Kontrolle zweites Terminal: journalctl -f
..
Apr 30 16:58:35 localhost kernel: nbd: registered device at major 43
...
qemu-nbd --connect=/dev/nbd0 /home/VM/name2.qcow2
...
>> und der Kernel im zweiten Terminal antwortet:
Apr 30 19:31:53 localhost kernel:  nbd0: p1 p2 p3  (Partition 1 - 3)

mount /dev/nbd0p2 /mnt

>> und der Kernel
Apr 30 19:37:37 localhost kernel: EXT4-fs (nbd0p2): mounted filesystem with ordered data mode. Opt...null)(ext4 erkannt+einge-
hängt)
Hier weiß ich aber im Moment auch nicht, ob das Sinn hat weiter zu verfolgen (ala > chroot) :?:
El Conkystador (el conquistador = der Sieger) ein Markenzeichen für @Sector11 8-)
unklar
 
Beiträge: 1468
Registriert: Jun 1st, '11, 15:06

Re: efi - virtuell

Beitragvon lula » Apr 30th, '15, 21:38

Du willst also das System auf der 2. Platte starten, oder habe ich das Problem immer noch nicht verstanden? Im ersten Fall würde ich nicht lange mit dem EFI rumdaddeln, sondern dem funktionierenden Grub der Installation einen Abschnitt für die andere Installation verpassen, so wie man das traditionell mit einem grub im MBR auch machen würde.
lula
 
Beiträge: 644
Registriert: Feb 10th, '12, 20:13

Re: efi - virtuell

Beitragvon lula » Mai 1st, '15, 10:50

Ich habe mal versucht Dein Vorgehen mit 2 Platten nachzuvollziehen. Platte1: kde-Installation, Platte2: xfce-Installation, beide von der DVD im Textmodus installiert (wg. nicht startendem X-Server (s. o.)). Die folgenden Ausgaben kommen aus der xfce-Installation, die als -hdb im qemu angegeben war.
Code: Alles auswählen
[root@localhost ~]# fdisk -l

Festplatte /dev/sda: 16 GiB, 17179869184 Bytes, 33554432 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: B560A52D-2855-4878-B679-130658F554D0

Device       Start      End  Sectors  Size Type
/dev/sda1     2048   409600   407553  199M EFI System
/dev/sda2   411648  2787328  2375681  1,1G Linux filesystem
/dev/sda3  2789376 33554398 30765023 14,7G Linux filesystem

Festplatte /dev/sdb: 16 GiB, 17179869184 Bytes, 33554432 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: 15C45C6F-7180-4433-83AB-AB40BB9F0316

Device       Start      End  Sectors  Size Type
/dev/sdb1     2048   409600   407553  199M EFI System
/dev/sdb2   411648  2506752  2095105 1023M Linux filesystem
/dev/sdb3  2508800 33554398 31045599 14,8G Linux filesystem

[root@localhost ~]# df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
devtmpfs        995M       0  995M    0% /dev
tmpfs          1001M     92K 1001M    1% /dev/shm
tmpfs          1001M    440K 1001M    1% /run
/dev/sdb3        15G    2,8G   11G   20% /
tmpfs          1001M       0 1001M    0% /sys/fs/cgroup
tmpfs          1001M     52K 1001M    1% /tmp
/dev/sdb1       196M    119K  196M    1% /boot/EFI
tmpfs           201M    8,0K  201M    1% /run/user/1000

[root@localhost ~]# efibootmgr -v
BootCurrent: 0006
Timeout: 0 seconds
BootOrder: 0006,0000,0001,0002,0003,0004,0005,0007
Boot0000* EFI DVD/CDROM ACPI(a0341d0,0)PCI(1,1)ATAPI(1,0,0)
Boot0001* EFI Floppy    ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,0)
Boot0002* EFI Floppy 1  ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,1)
Boot0003* EFI Hard Drive        ACPI(a0341d0,0)PCI(1,1)ATAPI(0,0,0)
Boot0004* EFI Network   ACPI(a0341d0,0)PCI(3,0)MAC(525400123456,1)
Boot0005* EFI Internal Shell    MM(b,900000,10fffff)FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0006* mageia        HD(1,800,63801,4af73ea5-2221-4692-8062-55f33a8b35c5)File(\EFI\mageia\grubx64.efi)
Boot0007* EFI Hard Drive 1      ACPI(a0341d0,0)PCI(1,1)ATAPI(0,1,0)

Der Booteintrag Boot0006 zeigt auf grubx64.efi auf der 2.Platte (sdb), also habe ich noch einen weiteren für sda hinzugefügt:
Code: Alles auswählen
[root@localhost ~]# efibootmgr --create --disk /dev/sda --part 1 --label "Mageia5_sda" --loader "\EFI\mageia\grubx64.efi"
BootCurrent: 0006
Timeout: 0 seconds
BootOrder: 0008,0006,0000,0001,0002,0003,0004,0005,0007
Boot0000* EFI DVD/CDROM
Boot0001* EFI Floppy
Boot0002* EFI Floppy 1
Boot0003* EFI Hard Drive
Boot0004* EFI Network
Boot0005* EFI Internal Shell
Boot0006* mageia
Boot0007* EFI Hard Drive 1
Boot0008* Mageia5_sda

[root@localhost grub2]# efibootmgr --verbose
BootCurrent: 0006
Timeout: 0 seconds
BootOrder: 0008,0006,0000,0001,0002,0003,0004,0005,0007
Boot0000* EFI DVD/CDROM ACPI(a0341d0,0)PCI(1,1)ATAPI(1,0,0)
Boot0001* EFI Floppy    ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,0)
Boot0002* EFI Floppy 1  ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,1)
Boot0003* EFI Hard Drive        ACPI(a0341d0,0)PCI(1,1)ATAPI(0,0,0)
Boot0004* EFI Network   ACPI(a0341d0,0)PCI(3,0)MAC(525400123456,1)
Boot0005* EFI Internal Shell    MM(b,900000,10fffff)FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0006* mageia        HD(1,800,63801,4af73ea5-2221-4692-8062-55f33a8b35c5)File(\EFI\mageia\grubx64.efi)
Boot0007* EFI Hard Drive 1      ACPI(a0341d0,0)PCI(1,1)ATAPI(0,1,0)
Boot0008* Mageia5_sda   HD(1,800,63801,5b21e8cb-67b1-4ecd-8ff8-9abf1021ae6a)File(\EFI\mageia\grubx64.efi)

Der efibootmgr legt einen neuen Eintrag Boot0008 an und stellt ihn in der Bootreihenfolge nach vorne. Ist es das, was Du vorhast?
lula
 
Beiträge: 644
Registriert: Feb 10th, '12, 20:13

Re: efi - virtuell

Beitragvon unklar » Mai 9th, '15, 16:06

Hallo @lula,
ich war ein paar Tage weg (und schon funktioniert hier nichts mehr). Dazu später.
lula hat geschrieben:Ist es das, was Du vorhast?
Nein, dies ist doch schon "Expertenwissen".
Es wird wohl kaum möglich sein, auf Grund der vielfältigen Konfigurationen und Implementierungen der Hersteller, dem "gemeinen User" einen Leitfaden an die Hand zu geben.
Mit meinen Test's will ich nur ein Gefühl bekommen, was der (zwangs-beglückte) efi-User erlebt bei Installationen auf einer Platte / Partition und mehreren Platten / Partitionen und OS. Dazu will ich mich nur auf den Installer von Mageia verlassen.

Nun das "Später:
Es scheint, dass das Host-System (MGA4-KDE-x86_64), speziell dbus wieder kaputt ist. Denn nach einem Update u.a.
Code: Alles auswählen
lib64qtdbus4-4.8.6-1.3.mga4.x86_64
erlebe ich die gleichen Fehler wie im Oktober 2014 bei der Anmeldung an das System.
https://forums.mageia.org/en/viewtopic.php?f=24&t=8564

Frustrierend... :lol:
Und, das betrifft auch den Laptop mit diesem OS.
El Conkystador (el conquistador = der Sieger) ein Markenzeichen für @Sector11 8-)
unklar
 
Beiträge: 1468
Registriert: Jun 1st, '11, 15:06

Re: efi - virtuell

Beitragvon man-draker » Mai 9th, '15, 17:19

unklar hat geschrieben:Nun das "Später:
Es scheint, dass das Host-System (MGA4-KDE-x86_64), speziell dbus wieder kaputt ist. Denn nach einem Update u.a.
Code: Alles auswählen
lib64qtdbus4-4.8.6-1.3.mga4.x86_64
erlebe ich die gleichen Fehler wie im Oktober 2014 bei der Anmeldung an das System.
https://forums.mageia.org/en/viewtopic.php?f=24&t=8564

Frustrierend... :lol:
Und, das betrifft auch den Laptop mit diesem OS.

Interessant.
Was haben die beiden Maschinen gemeinsam, dass sie - so unterschiedlich sie zu sein scheinen - dasselbe Fehlerbild zeigen?
Und was unterscheidet sie vom fast ganzen Rest der Welt, der das Problem nicht?
"Die letzte Stimme, die man hört, bevor die Welt explodiert, wird die Stimme eines Experten sein, der sagt: 'Das ist technisch unmöglich.'"
(Peter Ustinov)
Benutzeravatar
man-draker
 
Beiträge: 4992
Registriert: Jun 1st, '11, 12:56

Re: efi - virtuell

Beitragvon unklar » Mai 9th, '15, 19:52

Hallo @man-draker,

:D :D

ich weiß ja nicht, ob du mich foppen willst...
Ich schrieb von das Gleiche und nicht von dasselbe. ;)
El Conkystador (el conquistador = der Sieger) ein Markenzeichen für @Sector11 8-)
unklar
 
Beiträge: 1468
Registriert: Jun 1st, '11, 15:06

Re: efi - virtuell

Beitragvon lula » Mai 9th, '15, 22:28

unklar hat geschrieben:Es wird wohl kaum möglich sein, auf Grund der vielfältigen Konfigurationen und Implementierungen der Hersteller, dem "gemeinen User" einen Leitfaden an die Hand zu geben.
Das hoffe ich sehr wohl, da Linux eigentlich immer den Standards folgt und deshalb Tools zur Verfügung stellt (z. B. efibootmgr), die diesen entsprechen. Inwieweit das auf die Hard-/Softwarehersteller zutrifft, wird sich zeigen.
lula
 
Beiträge: 644
Registriert: Feb 10th, '12, 20:13

Re: efi - virtuell

Beitragvon man-draker » Mai 10th, '15, 11:50

Die Vielfalt ist allerdings erschreckend.

Z.B. bei Oracles VirtualBox ist die EFI-Unterstützung noch als "experimentell" bezeichnet.
Sie wissen auch warum.
So gelingt es zwar dem Installer, Mageia im Bootmenu einzutragen, aber nicht als zu bootende Option zu aktivieren. Daher landet man immer in der EFI-Boot-Shell.
Änderungen aus dem laufenden System heraus, z.B. mit efiboomgr werden nicht gespeichert.
Nur ein Verändern der startup.nsh bringt Mageia an den Start.

Auf meinem Lenovo x121e werden USB-Sticks mit Mageia-ISO nicht als Bootmedium erkannt, während solche mit Debian 8 und Linuxmint problemlos starten.

Und so kann das mit jedem Mainboard und jeder EFI darauf munter weiter gehen.
Die Technik ist halt noch sehr jung im Verhältnis zum BIOS und anspruchsvoller zu implementieren, als letzteres.
"Die letzte Stimme, die man hört, bevor die Welt explodiert, wird die Stimme eines Experten sein, der sagt: 'Das ist technisch unmöglich.'"
(Peter Ustinov)
Benutzeravatar
man-draker
 
Beiträge: 4992
Registriert: Jun 1st, '11, 12:56

Re: efi - virtuell

Beitragvon doktor5000 » Mai 10th, '15, 13:03

man-draker hat geschrieben:Auf meinem Lenovo x121e werden USB-Sticks mit Mageia-ISO nicht als Bootmedium erkannt

Wie hast du die erstellt? Siehe https://wiki.mageia.org/de/Installation ... USB-Sticks
Ich bin nicht böse, sondern nur ehrlich. Und wer lesen kann, ist klar im Vorteil.
----
Mageia - the magic continues
Benutzeravatar
doktor5000
 
Beiträge: 5946
Registriert: Jun 2nd, '11, 09:39

Re: efi - virtuell

Beitragvon man-draker » Mai 10th, '15, 14:04

doktor5000 hat geschrieben:
man-draker hat geschrieben:Auf meinem Lenovo x121e werden USB-Sticks mit Mageia-ISO nicht als Bootmedium erkannt

Wie hast du die erstellt? Siehe https://wiki.mageia.org/de/Installation ... USB-Sticks

Oh, Mist, kalt erwischt: Nach alter Väter Sitte per dd.
Das teste ich heute Abend gleich mal.
"Die letzte Stimme, die man hört, bevor die Welt explodiert, wird die Stimme eines Experten sein, der sagt: 'Das ist technisch unmöglich.'"
(Peter Ustinov)
Benutzeravatar
man-draker
 
Beiträge: 4992
Registriert: Jun 1st, '11, 12:56

EFI nicht virtuell

Beitragvon man-draker » Mai 10th, '15, 17:57

1. Mit manuell erzeugter FAT32-Partition auf dem USB-Stick und ebenfalls manuell darauf kopiertem Inhalt der per loop-Device eingebundenen ISO, bootet der Laptop vom Stick.

2. Bei Nutzung der Option "Install from USB" tritt wieder der Fehler "in /boot/EFI muss eine FAT32 Partition eingebunden sein" auf.

3. Bei Nutzung der Option "Install" und anschließender manueller Wahl des Installationsmediums, erscheint der Fehler "failed to add partition #1 on /dev/sda".

4. Das Benutzen der Benutzerdefinierten Partitionierung scheitert beim Schreiben der Partitionstabelle.

5. Erst nach radikalem Löschen der Platte, bequemt sich RpmDrake seine Arbeit zu tun.

Installation läuft.
"Die letzte Stimme, die man hört, bevor die Welt explodiert, wird die Stimme eines Experten sein, der sagt: 'Das ist technisch unmöglich.'"
(Peter Ustinov)
Benutzeravatar
man-draker
 
Beiträge: 4992
Registriert: Jun 1st, '11, 12:56

Re: efi - virtuell

Beitragvon doktor5000 » Mai 10th, '15, 19:42

Dann schau mal, ob du das nicht auf der qa-discuss Mailingliste meldest. Ähnliche Probleme sind noch in Bearbeitung bzw. bereits gelöst worden.
Links zu Bugs evt. später wenn ich wieder an mein Mail-Archiv rankomme.

Siehe aber evtl. https://bugs.mageia.org/show_bug.cgi?id=15482

und
https://bugs.mageia.org/show_bug.cgi?id=15627
https://bugs.mageia.org/show_bug.cgi?id=15689
https://bugs.mageia.org/show_bug.cgi?id=15805
https://bugs.mageia.org/show_bug.cgi?id=15242
https://bugs.mageia.org/show_bug.cgi?id=15472

wo es überall um diesen Themenkomplex geht.
Ich bin nicht böse, sondern nur ehrlich. Und wer lesen kann, ist klar im Vorteil.
----
Mageia - the magic continues
Benutzeravatar
doktor5000
 
Beiträge: 5946
Registriert: Jun 2nd, '11, 09:39

Re: efi - virtuell

Beitragvon lula » Mai 14th, '15, 18:48

lula hat geschrieben:Ich bin auch gerade mit der RC am Testen. Mit der DVD (Mageia-5-RC-x86_64-DVD.iso) kriege ich (bis jetzt) noch keinen X-Server gestartet, mal sehen, ob das noch klappt.
Jetzt habe ich einen Workaround gefunden, der bei mir mit beiden Grafik-Karten funktioniert:

Im Grub-Abschnitt "Start Mageia 5 (Cauldron) Install" vor die linux-Zeile folgendes einfügen:
Code: Alles auswählen
set gfxpayload=1024x768x32
dann startet der X-Server für die Installation

Edit: Der Workaround oben, funktioniert nur mit -vga std, für die Cirrus-Karte muß die Auflösung auf 800x600x32 heruntergesetzt werden
Code: Alles auswählen
set gfxpayload=800x600x32
Dateianhänge
grub.png
grub-Screenshot
grub.png (10.71 KiB) 3471-mal betrachtet
lula
 
Beiträge: 644
Registriert: Feb 10th, '12, 20:13

Re: efi - virtuell

Beitragvon unklar » Mai 20th, '15, 15:12

Habe dieser Tage eine Installation von mga5/Cauldron vom USB-Stick mit der EFI ohne Erfolg versucht.

Das betrifft sowohl die spezielle Präparierung des Stick nach hier: https://wiki.mageia.org/en/UEFI_how-to
als auch diese Variante aus dem int.Forum: https://forums.mageia.org/en/viewtopic. ... 795#p56663

Zur Ehrenrettung von MGA und quasi als Gegenprobe diente mir arch-linux, was schon länger keinen speziellen Stick benötigt: https://wiki.archlinux.de/title/UEFI_Installation

Der Host; mga4-x86_64 und der Befehl (in zig Varianten ausprobiert)
Code: Alles auswählen
qemu-kvm -enable-kvm -k de -smp 2 -m 2048 -monitor stdio -snapshot -usb -usbdevice host:0781:5408,Mageia-5-RC-LiveDVD-KDE4-x86_64-DVD.iso,MGALIVE -pflash /home/unklar/Downloads/efi/OVMF-X64/OVMF.fd -boot d

Zusätzlich unter siduction als Host, weil hier der Qemu aktueller und das booten von usb immer noch experimentell ist
Code: Alles auswählen
qemu-system-x86_64 -enable-kvm -k de -smp 2 -m 2048 -vga vmware -usbdevice tablet -pflash /home/unklarer/Downloads/efi/OVMF-X64/OVMF.fd -monitor stdio -snapshot -usb -usbdevice host:0930:6545,Mageia-5-LiveDVD-KDE4-test-x86_64-DVD.iso,media=drive -boot d


In allen Fällen bietet die efi-shell zum Schluß nichts an (um sich 'durch-zu-hangeln').
Die Maus ist in der Regel blockiert und wird im qemu nicht freigegeben.

Die Faxen habe ich erst mal dicke... :evil:
El Conkystador (el conquistador = der Sieger) ein Markenzeichen für @Sector11 8-)
unklar
 
Beiträge: 1468
Registriert: Jun 1st, '11, 15:06

Re: efi - virtuell

Beitragvon doktor5000 » Mai 20th, '15, 17:33

unklar hat geschrieben:Das betrifft sowohl die spezielle Präparierung des Stick nach hier: https://wiki.mageia.org/en/UEFI_how-to

Das ist die aktuelle Anleitung, steht auch oben in der Einleitung. https://wiki.mageia.org/en/Installing_o ... I_firmware

Desweiterem gibt es seit kurzem ein Test-Image, welche direkt per dd auf den Stick geschrieben werden kann.
Da die ersten Rückmeldungen positiv waren, werden höchstwahrscheinlich alle UEFI-fähigen Images so erstellt für das finale Release.

Ansonsten ist der Test von UEFI in einer VM kein wirkliches Release-Kriterium, wichtiger ist dass das auf richtiger Hardware funktioniert.
Ich bin nicht böse, sondern nur ehrlich. Und wer lesen kann, ist klar im Vorteil.
----
Mageia - the magic continues
Benutzeravatar
doktor5000
 
Beiträge: 5946
Registriert: Jun 2nd, '11, 09:39

Re: efi - virtuell

Beitragvon lula » Mai 20th, '15, 18:37

unklar hat geschrieben:Habe dieser Tage eine Installation von mga5/Cauldron vom USB-Stick mit der EFI ohne Erfolg versucht.
Warum machst Du diese Verrenkungen über usbdevice? Wenn Du auf HW von einem Stick bootest, ist der im System doch auch eine Festplatte, also würde ich das Ding als -hdb /dev/sdX an qemu ankleben. Wichtig ist, daß Du als user in der Gruppe disk bist. Vielleicht habe ich auch wieder nicht kapiert, was Du vorhast.
lula
 
Beiträge: 644
Registriert: Feb 10th, '12, 20:13

Re: efi - virtuell

Beitragvon unklar » Mai 20th, '15, 21:24

lula hat geschrieben:würde ich das Ding als -hdb /dev/sdX an qemu ankleben.
BINGO!
Danke Lutz, das war der Hinweis und die Dinger habe ich in der efi-shell am Start. :D
Code: Alles auswählen
qemu-kvm -enable-kvm -k de -smp 2 -m 2048 -usbdevice tablet -pflash /home/unklar/Downloads/efi/OVMF-X64/OVMF.fd -monitor stdio -snapshot -hdb /dev/sdd -boot d

Und, ich habe hier stundenlang mit VendorID und ProductID gebastelt. :roll:
El Conkystador (el conquistador = der Sieger) ein Markenzeichen für @Sector11 8-)
unklar
 
Beiträge: 1468
Registriert: Jun 1st, '11, 15:06

Re: efi - virtuell

Beitragvon lula » Mai 20th, '15, 22:32

Und da /dev/sdX ja auch nur eine Datei ist, kann man sich das ganze langsame Gedöns mit DVDs, USB-Sticks, etc. auch gleich schenken und das ganze auf Dateien (sprich Iso-/Festplatten-images) machen. Macht m. E. keinen Unterschied, außer daß es schneller geht :) .
lula
 
Beiträge: 644
Registriert: Feb 10th, '12, 20:13

Re: efi - virtuell

Beitragvon lula » Mai 21st, '15, 00:06

Ich habe Deinen Ansatz einmal verfolgt; versuchen das USB-Gerät an qemu durchzureichen und davon zu booten:
Folgende Ausgangslage: USB-Stick als /dev/sdb mit Mageia5RC als Kopie auf /dev/sdb1 (Dateisystem vfat, Label MGALIVE):
Code: Alles auswählen
fdisk -l /dev/sdb/

Festplatte /dev/sdb: 3,8 GiB, 4048551936 Bytes, 7907328 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0xfadf8ede

Gerät      Boot Anfang    Ende Sektoren Größe Kn Typ
/dev/sdb1         2048 7907327  7905280  3,8G  c W95 FAT32 (LBA)
dosfslabel /dev/sdb1
MGALIVE

lsusb
...
Bus 003 Device 002: ID 8564:1000 Transcend Information, Inc. JetFlash

Also versucht zu starten mit:
Code: Alles auswählen
qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -soundhw hda -vga std -monitor stdio -net nic -net bridge,br=xenbr0 -usbdevice tablet -pflash ovmf/OVMF.fd -usb -usbdevice host:8564:1000

Fehlermeldung:
Code: Alles auswählen
(qemu) libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/003/002: Permission denied
ls -l /dev/bus/usb/003/002
crw-rw-r-- 1 root root 189, 257 20. Mai 21:41 /dev/bus/usb/003/002
Also erst einmal nicht weiter verwunderlich, ich darf da als user nur lesen, was bei Festplatten ja eher ungewöhlich ist.
Also werde ich als nächstes eine udev-Regel schreiben, die mir den vollen Zugriff auf das Gerät erlaubt und dann schauen wir mal weiter...
lula
 
Beiträge: 644
Registriert: Feb 10th, '12, 20:13

Re: efi - virtuell

Beitragvon lula » Mai 23rd, '15, 08:26

So, nun der Test mit dem Usb-Stick als usb-device, folgende Regel im Host:
Code: Alles auswählen
[root@lenovo:~]# cat /etc/udev/rules.d/90-test.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="8564", ATTR{idProduct}=="1000", MODE="0666" GROUP="disk"

Starten von qemu im Bios-Modus mit:
Code: Alles auswählen
qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -soundhw hda -vga std -monitor stdio -net nic -net bridge,br=xenbr0    -usb -usbdevice host:8564:1000 -vga std -boot menu=on

Ergebnis: Das Gerät wird offensichtlich durchgereicht, ich lande in der grub-rescue-Shell (offensichtlich noch Reste vom grub auf dem Stick :) ) . Aber der ls zeigt, daß dort eine Platte vorhanden ist.

2. Test: Booten von einer anderen Platte im efi-Modus mit angehängter USB-Platte.
Ausgaben im Gast:
Code: Alles auswählen
[root@localhost ~]# dmesg
...
[    5.158047] scsi 2:0:0:0: Direct-Access     JetFlash Transcend 4GB    1100 PQ: 0 ANSI: 4
[    5.163246] sd 2:0:0:0: [sdb] 7907328 512-byte logical blocks: (4.04 GB/3.77 GiB)
[    5.166319] sd 2:0:0:0: [sdb] Write Protect is off
[    5.166337] sd 2:0:0:0: [sdb] Mode Sense: 43 00 00 00
[    5.169421] sd 2:0:0:0: [sdb] No Caching mode page found
[    5.169428] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[    5.192216]  sdb: sdb1
[    5.209513] sd 2:0:0:0: [sdb] Attached SCSI removable disk

[root@localhost ~]# fdisk -l
...
Festplatte /dev/sdb: 3,8 GiB, 4048551936 Bytes, 7907328 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0xfadf8ede

Device     Boot Start     End Sectors  Size Id Type
/dev/sdb1        2048 7907327 7905280  3,8G  c W95 FAT32 (LBA)


3. Test: Booten von der angehängten USB-Platte im efi-Modus.
Ergebnis: keine Platte im BIOS sichtbar, also gleiches Verhalten wie bei unklar.

Also ist das möglicherweise (noch) nicht in der EFI-Firmware realisiert oder man muß dem qemu noch irgendwie beibringen, daß es sich dabei um eine Festplatte handelt.
Dateianhänge
boot.png
grub-rescue-Shell
boot.png (10.09 KiB) 3403-mal betrachtet
lula
 
Beiträge: 644
Registriert: Feb 10th, '12, 20:13

Re: efi - virtuell

Beitragvon unklar » Mai 23rd, '15, 10:57

lula hat geschrieben:Also ist das möglicherweise (noch) nicht in der EFI-Firmware realisiert...
genau darauf tippe ich auch.
El Conkystador (el conquistador = der Sieger) ein Markenzeichen für @Sector11 8-)
unklar
 
Beiträge: 1468
Registriert: Jun 1st, '11, 15:06

Re: efi - virtuell

Beitragvon unklar » Mai 25th, '15, 15:09

Hallo Lutz,
wie kopierst Du eigentlich zwischen Gast und Host?

Ich frage deshalb, weil ich hauptsächlich KDE nutze und das hier mit dem Konqueror oder auch Dolphin wunderbar mit sftp geht.
Code: Alles auswählen
sftp://unklar@192.168.178.45
und ich bin im Host.

Hast Du noch andere Varianten?
El Conkystador (el conquistador = der Sieger) ein Markenzeichen für @Sector11 8-)
unklar
 
Beiträge: 1468
Registriert: Jun 1st, '11, 15:06

Re: efi - virtuell

Beitragvon lula » Mai 25th, '15, 15:37

Ich benutze eigentlich nur die shell, also per ssh bzw. scp oder rsync über ssh
lula
 
Beiträge: 644
Registriert: Feb 10th, '12, 20:13

VorherigeNächste

Zurück zu Andere

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron