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.
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 …
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.
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
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.
Letzte Frage - und vielleicht schreibt ja auch mal jemand - 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 …
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 …
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/”
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.
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.
