Installation im bhyve Hypervisor (UEFI)?

UCS - Univention Corporate Server
,
#1

Hallo, zusammen,

ich versuche gerade, einen UCS (4.1 vom Standard 64bit-Installationsmedium) in einem FreeNAS Corral (FreeNAS 10) zu installieren. Ich erwarte jetzt keine detaillierte Hilfe bezgl. bhyve - das ist der FreeBSD Hypervisor - aber mein Problem ist, dass die Installation völlig anstandslos durchläuft, die Festplatte danach aber nicht bootet.

Zu den Details:

Die VM hat eine CD, verbunden mit dem ISO-Image, eine Festplatte, Typ Block-Device, AHCI für den Gast, und eine Virtio-Netzwerkkarte. Und natürlich eine VGA - das ist auch der Grund, weshalb beim derzeitigen Stand von bhyve zwingend UEFI statt BIOS/MBR/Grub zum Booten verwendet werden muss. Grafische Konsole nur mit UEFI.

Prinzipiell ist der Hypervisor natürlich so voll funktionsfähig. Ich habe 2 FreeBSD und eine Windows 7 VM in genau dieser Umgebung am Laufen.

So sieht die von UCS vorgeschlagene Partitionierung aus:

Dabei fällt mir die “riesige” EFIboot-Partition auf. In meinen FreeBSD-Systemem mit EFI Boot, sei es VM oder phys. Server mit z.B. NVME-Disks ist die EFI Boot-Partition kleiner als 1 MB und enthält ein FAT-Filesystem mit den Bootloader-Dateien.

#2

Ich muss den Beitrag leider aufteilen, weil ich als neuer Benutzer nur ein Bild pro Beitrag einstellen darf. Sorry.

Naja, weiter im Text, die Installation läuft erst mal völlig problemlos durch:

#3

Wenn ich dann anschließend die CD entferne und die HDD als Boot-Device setze, dann sieht das Ganze aber leider so aus:

#4

Und nach einer kleinen Gedenkpause dann so:

Gucke ich mir das Festplatten-Abbild “von außen” also auf dem Hypervisor/FreeNAS an, bin ich überrascht, dass dort offensichtlich kein GPT-Partitionsschema angelegt wurde:

gpart: No such geom: /dev/zvol/zfs/vm/ox/hd.

Stattdessen finde ich eine einzelne MBR-Partition:

fdisk /dev/zvol/zfs/vm/ox/hd
******* Working on device /dev/zvol/zfs/vm/ox/hd *******
parameters extracted from in-core disklabel are:
cylinders=7832 heads=255 sectors/track=63 (16065 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=7832 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 238 (0xee),(EFI GPT)
    start 1, size 125829119 (61439 Meg), flag 0
	beg: cyl 0/ head 0/ sector 1;
	end: cyl 1023/ head 254/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

Ist das so gedacht? Irgendwelche Vorschläge, wie ich das Teil zum Booten bekomme?

Ein FreeNAS-System mit einer VM mit UCS/Open-Xchange und einer weiteren mit einer pfsense-Firewall wäre eine absolut geniale Komplettlösung für eine kleine Firma …

Gruß und danke vorab,
Patrick

#5

Ich hab einen Teil der Fragestellung mal ins FreeNAS-Forum getragen:
https://forums.freenas.org/index.php?threads/bhyve-zvols-on-disk-format.52756/

Gruß
Patrick

1 Like
#6

Das Problem mit der nicht sichtbaren Partitionstabelle war in der Tat hausgemacht, also byhve/FreeBSD-spezifisch. Nachdem ich die virtuelle Festplatte in eine lauffähige VM geklont hatte, war die GPT-Partitionstabelle da und ein Mount der EFI-Boot-Partition problemlos möglich.

Inhalt:

root@dhcp:~ # cd /mnt
root@dhcp:/mnt # ls -lR
total 4
drwxr-xr-x  1 root  wheel  4096 Mar 29 21:25 EFI

./EFI:
total 4
drwxr-xr-x  1 root  wheel  4096 Mar 29 21:25 univention

./EFI/univention:
total 3196
-rwxr-xr-x  1 root  wheel      154 Mar 29 21:26 grub.cfg
-rwxr-xr-x  1 root  wheel   935760 Mar 29 21:26 grub.efi
-rwxr-xr-x  1 root  wheel   935760 Mar 29 21:26 grubx64.efi
-rwxr-xr-x  1 root  wheel  1390392 Mar 29 21:26 shimx64.efi

Und nun wird’s wieder UCS-spezifisch … bhyve sucht (wie meine phys. Server übrigens auch) nach einer Datei in C:\EFI\BOOT\BOOTX64.EFI - weshalb legt UCS die Bootloader nach ...\univention?

Was kann ich dort manuell installieren, damit ich das System booten kann? Kenne mich als FreeBSD-Spezialist nicht so super mit Grub & Co. aus.

Gruß
Patrick

#7

So - gelöst. Was ich gelernt habe, ist, dass EFI Bootloader wohl nicht zwangsläufig in C:\EFI\BOOT\BOOTX64.EFI abgelegt werden müssen sondern man in einer EFI-Firmware einstellen kann, was genau gebootet werden soll. Praktisch Bootmanager im BIOS-Setup.

Ob bhyve das nicht unterstützt oder nur FreeNAS die Einstellung nicht bietet, weiß ich nicht, ist aber wurst :wink:

Ich hab rEFInd manuell nach C:\EFI\BOOT\BOOTX64.EFI gelegt und, oh Wunder - UCS läuft.

Jetzt muss ich mal gucken, was der Update-Prozess dieses Debian mit der Boot-Partition macht und ob das alles überlebt, was ich da manuell abgelegt habe.

http://www.rodsbooks.com/refind/

Gruß
Patrick

1 Like
#8

Letzte Frage - und vielleicht schreibt ja auch mal jemand :wink: - hat 4.1.4 bekannte Probleme mit Virtio-Blockstorage? Wenn ich die Installation auf einer Virtio- statt AHCI-Platte versuche, bleibt sie kurz nach der Partitionierung hängen. Wenn ich nach der Installation von AHCI auf Virtio schalte, hagelt’s eine Kernel-Panic …

Gruß
Patrick

#9

Hallo Patrick,

zumindest für virtio kann ich Entwarnung geben. Bei mir laufen mehrere Instanzen unter KVM mit virtio-Platten problemlos.

Viele Grüße
Ulf

#10

Nö, weder 4.1.4 noch 4.2-RC - beide frieren in bhyve mit virtio-blk ein. 4.2 sogar mit AHCI. Schade, aber 4.1.4 läuft und ich hab eine Menge über EFI gelernt … :slight_smile:

Patrick

#11

Hi.

I’m not sure if this has a solution yet. I’m trying to install a UCS 4.3 server in a FreeNas 11.1 U5 virtual machine. I can only post 2 links as a new user, so I will list the images at this site “itcmsfl dot com/ucs43freenaserr/”

I understand the issue: https://forums.freenas.org/index.php?threads/howto-how-to-boot-linux-vms-using-uefi.54039/, https://forums.freenas.org/index.php?threads/howto-how-to-boot-linux-vms-using-uefi.54039/page-3#post-389907.

After following the steps to copy the needed files from /boot/efi/EFI/univention to /boot/efi/EFI/BOOT, as per the post, the server gets to the main grub screen. freenasvm-bootingucs43err1.png

Then there is a problem with the signature and then with booting the kernel. freenasvm-bootingucs43err2.png

If I boot from the ucs43 iso freenasvm-bootingucs43err0.png and run the repair console freenasvm-bootingucs43err00.png and run the uefi grub repair freenasvm-bootingucs43err000.png, I can boot the server, only once, if I leave the image loaded on the vm. As soon as I remove the cd, I get back to the loop above.

I have also tried to use the refined boot to boot the vmlinuz, but that gets stuck during boot. freenasvm-bootingucs43err3.png, freenasvm-bootingucs43err4.png.

Any more ideas? I’m not a linux guru, but have many years of working with bsd/linux. I can follow and read instructions as much as needed.

Thanks,

p.s. Forgot to mention that I can not disable secure boot with the FreeNas vm webgui.

#12

I am far away from providing a solution.
The only thing I can see is, that there are some open bugs related to the installation on UEFI-Systems.
It might need someone with a valid subscription running against this error to open a ticket.

Mastodon