bhyve Arch Linux VM emulated with BHYVE : considerations.

It's not me that I have told that bhyve does not support the efi variables. Has been a bhyve developer. He is helping me to make work the pass thru of my graphic card. I haven't the knowledge to tell something like this. I'm not so experienced. I'm an humble man who like to experiment and to learn. I say what it is. Why shouldn't I believe in the words of a developer ? I think that your solution does not make what he told not true. We can configure EFI,but using only the default location. This is what he said. Despite this,for me it's not a reason to stop learning it. Is when a feature is missing that I like more to find alternative solutions. There is nothing that I should stop. Don't be so rude with me. If I were a critical and destructive person I would have stopped to become crazy here.
 
I think that me and that bhyve developer that's helping me (I think that the FreeBSD community is very helpful and friendly) we made some progress trying to pass thru the 2080 ti. And also arch linux is helping,I think. Anyway,now when I do "startx" from the ssh shell of the arch linux VM I see a more friendly messages and Xorg does not crash,though,the monitor attached to the HDMI port of the graphic card still does not turn on. There is still something that's broken,maybe inside the Arch Linux. This is the xorg.conf file that I'm using :

Code: 
Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0"
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
EndSection

Section "Files"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Unknown"
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"

EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

This is the log file of Xorg :


Code: 
X.Org X Server 1.20.13
X Protocol Version 11, Revision 0
[   252.614] Build Operating System: Linux Archlinux
[   252.614] Current Operating System: Linux arch-efi-kvm-bhyve 5.14.2-arch1-2 #1 SMP PREEMPT Thu, 09 Sep 2021 09:42:35 +0000 x86_64
[   252.614] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=955227a2-49c7-400b-a74a-f45a123b8b49 rw text
[   252.614] Build Date: 04 August 2021  08:13:54AM
[   252.614]
[   252.614] Current version of pixman: 0.40.0
[   252.614]    Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
[   252.614] Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   252.614] (==) Log file: "/var/log/Xorg.2.log", Time: Sat Sep 11 20:20:05 2021
[   252.614] (==) Using config file: "/etc/X11/xorg.conf"
[   252.614] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   252.614] (==) ServerLayout "Layout0"
[   252.614] (**) |-->Screen "Screen0" (0)
[   252.614] (**) |   |-->Monitor "Monitor0"
[   252.614] (**) |   |-->Device "Device0"
[   252.614] (**) |-->Input Device "Keyboard0"
[   252.614] (**) |-->Input Device "Mouse0"
[   252.614] (==) Automatically adding devices
[   252.614] (==) Automatically enabling devices
[   252.614] (==) Automatically adding GPU devices
[   252.614] (==) Automatically binding GPU devices
[   252.614] (==) Max clients allowed: 256, resource mask: 0x1fffff
[   252.614] (WW) The directory "/usr/share/fonts/misc" does not exist.
[   252.614]    Entry deleted from font path.
[   252.614] (WW) The directory "/usr/share/fonts/TTF" does not exist.
[   252.614]    Entry deleted from font path.
[   252.614] (WW) The directory "/usr/share/fonts/OTF" does not exist.
[   252.614]    Entry deleted from font path.
[   252.614] (WW) The directory "/usr/share/fonts/Type1" does not exist.
[   252.614]    Entry deleted from font path.
[   252.614] (WW) The directory "/usr/share/fonts/100dpi" does not exist.
[   252.614]    Entry deleted from font path.
[   252.614] (WW) The directory "/usr/share/fonts/75dpi" does not exist.
[   252.614]    Entry deleted from font path.
[   252.614] (==) FontPath set to:

[   252.614] (==) ModulePath set to "/usr/lib/xorg/modules"
[   252.614] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[   252.614] (WW) Disabling Keyboard0
[   252.614] (WW) Disabling Mouse0
[   252.614] (II) Module ABI versions:
[   252.614]    X.Org ANSI C Emulation: 0.4
[   252.614]    X.Org Video Driver: 24.1
[   252.614]    X.Org XInput driver : 24.1
[   252.614]    X.Org Server Extension : 10.0
[   252.615] (--) using VT number 2

[   252.615] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration
[   252.615] (II) xfree86: Adding drm device (/dev/dri/card0)
[   252.615] (**) OutputClass "nvidia" ModulePath extended to "/usr/lib/nvidia/xorg,/usr/lib/xorg/modules,/usr/lib/xorg/modules"
[   252.617] (--) PCI:*(0@0:2:0) 10de:1e04:19da:2503 rev 161, Mem @ 0xd2000000/16777216, 0xc0000000/268435456, 0xd0000000/33554432, I/O @ 0x0000c000/128, BIOS @ 0x????????/>
[   252.617] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
[   252.617] (II) LoadModule: "glx"
[   252.617] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[   252.618] (II) Module glx: vendor="X.Org Foundation"
[   252.618]    compiled for 1.20.13, module version = 1.0.0
[   252.618]    ABI class: X.Org Server Extension, version 10.0
[   252.618] (II) LoadModule: "nvidia"
[   252.618] (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so
[   252.618] (II) Module nvidia: vendor="NVIDIA Corporation"
[   252.618]    compiled for 1.6.99.901, module version = 1.0.0
[   252.618]    Module class: X.Org Video Driver
[   252.618] (II) NVIDIA dlloader X Driver  470.63.01  Tue Aug  3 20:37:27 UTC 2021
[   252.618] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs

I don't see errors....
 
Why on earth do you want to pass through a GPU using bhyve to a Linux guest when FreeBSD can use the same GPU directly? It's just adding a massive layer of complexity which is not necessary to use it in most cases at all.
 
Can you explain what do you understand by "efi variables" ?
What is this "default location" that you speaking for?
Because the heading of the topic "Arch Linux VM does not boot with BHYVE." is actually not true as I already show you that you can boot Arch Linux under Bhyve with UEFI.
 
hardworkingnewbie said:
Why on earth do you want to pass through a GPU using bhyve to a Linux guest when FreeBSD can use the same GPU directly? It's just adding a massive layer of complexity which is not necessary to use it in most cases at all.
Click to expand...

I can't talk about this on this topic because it concerns bhyve and arch linux,not the gpu passing thru. And I've explained why in a different post. There are so many people that are ready to blame me because I want to talk only about gpu pass thru. I hope that they can understand that inside that topic there could be a lot of sub topics not directly correlated to that.
 
VladiBG said:
Can you explain what you understand by "efi variables" ?
What is this "default location" that you speaking for?
Because the heading of the topic "Arch Linux VM does not boot with BHYVE." is actually not true as I already show you that you can boot Arch Linux under Bhyve with UEFI.
Click to expand...

I'm not able to explain it because I didn't understand it well. I can only guess what it means. I mean,I vaguely understand it. When I started this topic I haven't been able to boot Arch with Bhyve even If I had applied the Sipek workaround. I made some mistake for sure. Only later I've been able to solve the problem. Do u think that I should change the title of the topic now ?

UPDATE 1 : I have changed the title of this post.
UPDATE 2 : I have found the explanation that you are looking for here :

github.com

Not able to boot Debian (UEFI) · Issue #336 · churchers/vm-bhyve

I was able to install it, and the first reboot went well (still running under "vm install ...") But as soon as I try to start it "vm start..." it's not able to boot with UEF...
github.com github.com

churchers commented on Jan 13, 2020​


This sounds like it's related to efi variables. Many Linux distributions don't use the default filename for the EFI filename (for perfectly good reasons), and use EFI variables to store the correct path. Unfortunately bhyve loses this on restart as it doesn't store the efivars anywhere. Hopefully bhyve will fix this some day. It's been known for at least 18 months.

I really appreciate your apologies for telling me that I blame bhyve. You have been rude with me. But I said only the truth,that bhyve is missing some features. Yes,we can find good workarounds,but this doesn't change the fact. Anyway,As I told,I like to play with bhyve.
 
VladiBG said:
Until then you can rename grubx64.efi to bootx64.efi and place it under esp\EFI\BOOT\bootx64.efi
Click to expand...
This applies for quite many OS installation media, particularly Linux distro ISOs, that won't boot on bhyve via EFI. Even the final installed OS itself. I've encountered Linux distros that install a "branded" efi file, which then won't boot - unless you rename the EFI file.

The bootx64.efi is the one official location that UEFI looks at if there isn't any pre-existing NVRAM boot settings. If you have a boot problem, rename the EFI file to bootx64.efi and voila, it works.

Apologies if this seems off-topic to the PCI passthrough; it's just so easy to miss and hate bhyve for this otherwise small and easy to fix detail. I figured that merits spotlighting it more explicitly.
 
cmoerz said:
This applies for quite many OS installation media, particularly Linux distro ISOs, that won't boot on bhyve via EFI. Even the final installed OS itself. I've encountered Linux distros that install a "branded" efi file, which then won't boot - unless you rename the EFI file.

The bootx64.efi is the one official location that UEFI looks at if there isn't any pre-existing NVRAM boot settings. If you have a boot problem, rename the EFI file to bootx64.efi and voila, it works.

Apologies if this seems off-topic to the PCI passthrough; it's just so easy to miss and hate bhyve for this otherwise small and easy to fix detail. I figured that merits spotlighting it more explicitly.
Click to expand...

Bhyve is work in progress,even if slow. So there is no reason to hate it,at least for me. What bothered my nerves is that someone did not admit that bhyve misses some functionalities, thinking that the workaround found might be enough to say that bhyve had no problem at all. That developer said also that actually it misses a LOT of (minor ?) funcionalities. The question that I ask myself now and which makes me curious is why its development proceeds so slowly...
 
Alain De Vos said:
You can try a textual login. And then do X forwarding over ssh. In that way the desktop manager is not blocking.
Click to expand...

marietto@marietto:~ $ ssh marietto@192.168.1.3 startlxde

Password:
** Message: 16:39:46.561: main.vala:102: Session is LXDE
** Message: 16:39:46.562: main.vala:103: DE is LXDE

(lxsession:1368): Gtk-WARNING **: 16:39:46.583: cannot open display:

I did the same on Linux + qemu + kvm with the same Arch image and I've been able to forward correcty lxde over SSH on the desktop manager that I was using. In other words,there lxde overlapped over xfce4.
 
Thanks. I suspect that I haven't configured the X11 authentication on the Arch Linux. Let's see.
 
I have fixed the first problem,using the parameter ssh -X :

Code: 
marietto@marietto:~ $ ssh -X -p 50505 192.168.1.3

Password:

Last login: Sun Sep 12 17:03:15 2021 from 192.168.1.6

Environment:

  USER=marietto
  LOGNAME=marietto
  HOME=/home/marietto
  PATH=/usr/local/sbin:/usr/local/bin:/usr/bin
  SHELL=/bin/bash
  TERM=xterm-256color
  DISPLAY=localhost:10.0
  MOTD_SHOWN=pam
  MAIL=/var/spool/mail/marietto
  SSH_CLIENT=192.168.1.6 60424 50505
  SSH_CONNECTION=192.168.1.6 60424 192.168.1.3 50505
  SSH_TTY=/dev/pts/1

Running /usr/bin/xauth remove unix:10.0
/usr/bin/xauth add unix:10.0 MIT-MAGIC-COOKIE-1 6357f49300263a

With the Display configured correctly I tried to start lxde :

Code: 
[marietto@arch-efi-kvm-bhyve ~]$ startlxde

** Message: 17:42:32.161: main.vala:102: Session is LXDE
** Message: 17:42:32.161: main.vala:103: DE is LXDE
Xlib:  extension "RANDR" missing on display "localhost:10.0".
** Message: 17:42:32.632: main.vala:134: log directory: /home/marietto/.cache/lxsession/LXDE
** Message: 17:42:32.632: main.vala:135: log path: /home/marietto/.cache/lxsession/LXDE/run.log

another problem came up,fortunately. Otherwise I would have been bored :D
 
the solution is to use : ssh -Y -p 50505 192.168.1.3
startxfce4
or lxpanel &

-Y instead of -X did the trick. But now,the lxde desktop manager of arch linux overlaps totally xfce4 on FreeBSD...
 
Last edited:
VladiBG said:
Grub with EFI/GPT is working just fine under bhyve. Following the installation from https://wiki.archlinux.org/title/installation_guide
Click to expand...
Agreed, no problem with the installation........however I got problems when I try to reboot from the disk
Code: 
BdsDxe: failed to load Boot0001 "UEFI BHYVE SATA DVD ROM BHYVE-9D6E-0680-8540" from PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0xFFFF,0x0): Not Found
BdsDxe: failed to load Boot0002 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x4,0x0): Not Found

I'm using vm-bhyve for managing al my VM's, and probably It's necessary to provide device.map an grub.cfg files in the folder as other Linux distro as Alpine or CentOS.

Could you run it from the disk?
Thanks in advance
 
ziomario said:
I really appreciate your apologies for telling me that I blame bhyve. You have been rude with me. But I said only the truth,that bhyve is missing some features. Yes,we can find good workarounds,but this doesn't change the fact. Anyway,As I told,I like to play with bhyve.
Click to expand...
Sorry to come back about the "rudeness" you mention a couple of times in the chat ;) However following all messages I would like to highlight a lot of mistakes you've done here and hopefully it might be useful in the future:
  1. Arch Linux VM emulated with BHYVE : considerations --> You should have kept focus in your problems using bhyve (via script vm-bhyve) all the time instead of fanny about mixing subjects.
  2. Don't criticize Bbyve software just because your configuration setup is wrong.
  3. Stop blame developer, or talking about bugs when your configuration is wrong
  4. Passing through graphic card --> it's a different subject not cover for the thread --> Open a new Thread!
  5. Configuration Xorg.conf --> again mixing things --> Open a new Thread!
  6. ssh X11 remote server --> Open a new Thread!
  7. Linux + qemu + kvm --> This is FreeBSD (no Linux) --> Open a new Thread! or go Linux forums
FreeBSD community is probably one the the most helpful, professional and kind , I've ever seen, so please be more straight in the future :)

PD: I would close this post if I were you
 
diego : Don't you mean Thread rather than Post? Technical precision and correct use of terminology are usually pretty helpful when problem solving. You do have a good point about staying on topic, though.
 
You must log in or register to reply here.
Back
Top