PXE-UEFI-Boot eines virt. Clients in proxmox/kvm (linbo2)

Clientpflege Linuxclient
1

Hi zusammen,

ich kriege proxmox zwar dazu einen Client von PXE zu booten (bzw. einfach Netzwerk ganz vorne in die Bootreihenfolge zu stellen ist nicht schwer).
Allerdings bootet das System nicht, wenn ich auf UEFI stelle. Dagegen klappt es mit BIOS super.

image
image714×330 3.2 KB

und dann landet der Client in einer UEFI-Shell. Da weiß ich nicht weiter.
Auf Serverseite sieht das ungefähr so aus:

Mar 30 18:25:31 server dhcpd[8895]: DHCPOFFER on 10.16.16.58 to 4e:aa:05:ff:d1:47 via 10.16.16.254
Mar 30 18:25:34 server dhcpd[8895]: DHCPDISCOVER from 4e:aa:05:ff:d1:47 via 10.16.16.254
Mar 30 18:25:34 server dhcpd[8895]: DHCPOFFER on 10.16.16.58 to 4e:aa:05:ff:d1:47 via 10.16.16.254
Mar 30 18:25:38 server dhcpd[8895]: execute_statement argv[0] = /usr/lib/linuxmuster/dhcpd-update-samba-dns.py
Mar 30 18:25:38 server dhcpd[8895]: execute_statement argv[1] = add
Mar 30 18:25:38 server dhcpd[8895]: execute_statement argv[2] = 10.16.16.58
Mar 30 18:25:38 server dhcpd[8895]: execute_statement argv[3] = r20x-virt02
Mar 30 18:25:39 server dhcpd[8895]: DHCPREQUEST for 10.16.16.58 (10.16.1.1) from 4e:aa:05:ff:d1:47 via 10.16.16.254
Mar 30 18:25:39 server dhcpd[8895]: DHCPACK on 10.16.16.58 to 4e:aa:05:ff:d1:47 via 10.16.16.254
Mar 30 18:25:39 server in.tftpd[9272]: tftp: client does not accept options
Mar 30 18:25:39 server dhcpd[8895]: DHCPDISCOVER from 4e:aa:05:ff:d1:47 via 10.16.16.254
Mar 30 18:25:39 server dhcpd[8895]: DHCPOFFER on 10.16.16.58 to 4e:aa:05:ff:d1:47 via 10.16.16.254

usw… mehr passiert da nicht mehr.

Bei einem auf-dem-Blech Client sieht das so aus:

Mar 30 18:40:36 server dhcpd[8895]: DHCPDISCOVER from 50:81:40:20:2b:06 via 10.16.17.254
Mar 30 18:40:36 server dhcpd[8895]: DHCPOFFER on 10.16.17.9 to 50:81:40:20:2b:06 via 10.16.17.254
Mar 30 18:40:36 server dhcpd[8895]: uid lease 10.16.17.145 for client 50:81:40:20:2b:06 is duplicate on 10.16.17.0/24
Mar 30 18:40:36 server dhcpd[8895]: execute_statement argv[0] = /usr/lib/linuxmuster/dhcpd-update-samba-dns.py
Mar 30 18:40:36 server dhcpd[8895]: execute_statement argv[1] = add
Mar 30 18:40:36 server dhcpd[8895]: execute_statement argv[2] = 10.16.17.9
Mar 30 18:40:36 server dhcpd[8895]: execute_statement argv[3] = r219-pc09n
Mar 30 18:40:37 server dhcpd[8895]: DHCPREQUEST for 10.16.17.9 (10.16.1.1) from 50:81:40:20:2b:06 via 10.16.17.254
Mar 30 18:40:37 server dhcpd[8895]: DHCPACK on 10.16.17.9 to 50:81:40:20:2b:06 via 10.16.17.254
Mar 30 18:40:37 server dhcpd[8895]: BOOTREQUEST from 00:17:c8:89:71:59 via 10.16.14.254: BOOTP from dynamic client and no dynamic leases
Mar 30 18:40:37 server rsyncd[11578]: connect from r219-pc09n.xxx (10.16.17.9)
Mar 30 18:40:37 server rsyncd[11579]: rsync on linbo/start.conf-50:81:40:20:2b:06 from r219-pc09n.xxx (10.16.17.9)
Mar 30 18:40:37 server rsyncd[11579]: building file list

Weiß jemand wie ich weiterkomme?

Vielen Dank und viele Grüße, Tobias

2

Hallo Tobias,

hast du in der start.conf auf uefi gestellt? Hast du eine uefi
start.conf Vorlage aus srv/linbo/examples/ genommen?

LG

Holger

3

Hallo Holger,

ja, sorry, vergessen zu sagen: Ich habe einen Hardware-client mit UEFI-boot und dementsprechend eine start.conf mit uefi drin stehen — das war das Beispiel darunter, das funktioniert und dieselbe start.conf für den kvm/proxmox-client, der dann nicht weitermacht.
Aber da ich das wirklich das allererste Mal in virtuell gesehen habe, hat mich auch nicht gewundert, dass das nicht funktioniert.

Wäre halt interessant zu wissen, ob jemand einen UEFI-Boot virtuellen Client funktionsfähig booten kann.

äh, funktioniert!

NAch dem ich diese Seite fand: OVMF/UEFI Boot Entries - Proxmox VE habe ich mit ESC tatsächlich das boot-ende UEFI Bios erstmal so konfiguriert, dass Secure Boot ausgeschalten wird…

übrigens: wenn LINBO mit Secure Boot mal funktionieren soll, kann man das damit wunderbar testen…

Also: Problem hat sich von selbst gelöst.

Kleines (nicht bis zum Booten funktionierendes) Schmankerl am Rande: Weil proxmox von sich aus keine Simulation einer NVMe vorsieht, habe ich ausgegraben, dass man hier: nano /etc/pve/qemu-server/201.conf seinen Client manuell so konfiguriert:

args: -drive file=/dev/rpool/data/vm-201-disk-2,if=none,id=NVME1 -device nvme,drive=NVME1,serial=abcd
bios: ovmf

Dabei ist /dev/rpool/data/vm-201-disk-2 ein Device, könnte auch eine .img-Datei sein, oder ein LVM volume oder ähnliches (bei mir ein ZFS volume).

Und dann findet LINBO tatsächlich ein NVMe Device vor…

image

:frowning:
Leider funktioniert es dann Linbo nicht, das EFI so fertig zu konfigurieren, dass beim neustart die ubuntu-Partition bootet.
ICh kann zwar kurz vor dem Boot mit „efibootmgr“ feststellen, dass in EFI die ubuntu-Partition als next-bootend markiert wird. Beim Restart ist das allerdings wieder weg.

Das ganze zeigt sich dann auch dadurch, dass in der GUI keines der Symbole: start, sync, new angezeigt wird.

Das Problem zeigt sich aber nur beim Versuch mit einer NVMe extra-platte.

Mit UEFI-Booten und SCSI0 (sdaX) funktioniert auch das Booten von der Platte…

VG, Tobias