VM Guest: OS Type: FreeBSD

[scorc]

Id like to suggest creation/addition of OS Type: FreeBSD.
The only real setting I'm aware of, and my therefore make this irrelevant, is:

FreeBSD supports UEFI.
FreeBSD does NOT support Secure Boot. ...Yet.

Suggestion being:
Adding a selection item for OS Type = FreeBSD. This would set a default in the TianoCore/EDKII UEFI firmware to disable Secure Boot by default.

This may not be specific enough to FreeBSD; other OS's can be in the same boat.
In theory, however, this would work for any FreeBSD derived OS: OPNsense, pfSense, GhostBSD, etc.
And also work for anything with the same "issue" that is NOT FreeBSD.
Yes, one COULD just know the limitation up-front, and go in and disable Secure Boot on every VM they spin up.

 

[noel.]

Is there a reason you are not just using seaBIOS instead of UEFI? That would eliminate the secureboot problem.

Yes, one COULD just know the limitation up-front, and go in and disable Secure Boot on every VM they spin up.

This is a valid point, there is a wiki article on FreeBSD guests but disabling secureboot is not mentioned (and is also very out-of-date with bsd 10.3). This should probably be added and updated...

 

[scorc]

Is there a reason you are not just using seaBIOS instead of UEFI? That would eliminate the secureboot problem.


This is a valid point, there is a wiki article on FreeBSD guests but disabling secureboot is not mentioned (and is also very out-of-date with bsd 10.3). This sould probably be added and updated...

The font and screen are bigger?

Joking aside: no, no specific reason to NOT use seabios. Just been doing some labbing for different FreeBSD based OS's and kept running into this. In theory, seabios is fine.

One of my goals is to build a system and configure, then install on a physical machine and do the same config tasks (lab vs prod).

The seabios vs edkII really doesn't matter, its just more like what will be faced in those instances. Presumably. Different manufacturers can do w/e they want with their efi implementation as long as it hits the required basics for their target audience.

If I have access, guess i can contribute to the wiki. Saw it before and forgot about that page.

Again, just a suggestion. Would be cool to see, but im also a bit of a FreeBSD fan who is aware this is a relatively trivial action to take each time.

 

[scorc]

Here is my wiki proposal. I was unsuccessful in getting an account or login into the wiki. ???I made a MediaWiki Account??? It didn't allow me to login to the Proxmox wiki and i couldn't find a 'sign-up' page. I cant demo my work that I'm aware of, so, some formatting could be off once pasted.

 

[Dunuin]

I was unsuccessful in getting an account or login into the wiki. ???I made a MediaWiki Account??? It didn't allow me to login to the Proxmox wiki and i couldn't find a 'sign-up' page

You need to write a email to the Proxmox office to get an account, as wiki registration was disabled because of spammers.

One thing that maybe also should be mentioned is, that the FreeBSD QEMU guest agent doesn't support all features. For example no fsfreze, so no data integrity with snapshot backups, as write caches won't be flushed first:

WARNING!!!​

This port provides "as is". Some commands is not working, for example "fsfreeze". We try to make a patches for vcpu and fs features at FreeBSD. Command reference and current command support status in FreeBSD can be found here Be Careful. Port builds without any docs.

From this github repo and the official repo is using the same.

 

[mr44er]

Is there a reason you are not just using seaBIOS instead of UEFI?

SCFB gives a slightly better experience and acceleration.

More in-depth:
https://www.freebsd.org/cgi/man.cgi?scfb
https://wiki.freebsd.org/GraphicsOld/SCFB
https://tips.graphica.com.au/freebsd-gnome-on-qemu/
tldr; If you want to use xorg with UEFI you have to use scfb, with seabios you have to use VESA. It is still that way, tried it yesterday. novnc works on both, but only on console.

On my FreeBSD-workstation I have passthroughed my nvidia and use the actual nvidia-driver and also UEFI.

In theory, however, this would work for any FreeBSD derived OS: OPNsense, pfSense, GhostBSD, etc.

That's correct, but on OPNsense or pfSense you don't need/want xorg. Another story with GhostBSD

 

[scorc]

SCFB gives a slightly better experience and acceleration.

More in-depth:
https://www.freebsd.org/cgi/man.cgi?scfb
https://wiki.freebsd.org/GraphicsOld/SCFB
https://tips.graphica.com.au/freebsd-gnome-on-qemu/
tldr; If you want to use xorg with UEFI you have to use scfb, with seabios you have to use VESA. It is still that way, tried it yesterday. novnc works on both, but only on console.

I just want to say thank you for this. My 'freebsd desktop' attempts on Proxmox have been kinda ugly. This seems to have been the fix.

You need to write a email to the Proxmox office to get an account, as wiki registration was disabled because of spammers.

One thing that maybe also should be mentioned is, that the FreeBSD QEMU guest agent doesn't support all features. For example no fsfreze, so no data integrity with snapshot backups, as write caches won't be flushed first:

From this github repo and the official repo is using the same.

1. Ill see about who to email unless noel is watching and doesnt mind dropping a line so i can ensure i get the right email.
2. And fair point, i really hadnt looked past 'can i see my IP in the Proxmox GUI' post qemu-guest-agent install.

 

[Neobin]

1. Ill see about who to email unless noel is watching and doesnt mind dropping a line so i can ensure i get the right email.

https://forum.proxmox.com/threads/proxmox-wiki-contributions-how.118942/#post-516298

 

[mr44er]

I just want to say thank you for this. My 'freebsd desktop' attempts on Proxmox have been kinda ugly. This seems to have been the fix.

I ran lumina and mate with a quick test on 13.1-RELEASE-p5. I didn't need a second .conf for input.
Here my notes/steps (no hald!):

ee /usr/local/etc/X11/xorg.conf.d/98-qemu-video.conf
->
Section "Device"
        Identifier  "Card0"
        Driver      "scfb"
        BusID       "PCI:0:1:0"
EndSection


pkg install utouch-kmod xf86-input-evdev

rc.conf
->
kld_list="utouch"
dbus_enable="YES"


.xinitrc
->
exec dbus-launch --exit-with-session mate-session

startx

 

[noel.]

Hi @scorc, did you ever get access to the wiki?

 

[mr44er]

For even better experience, I want to recommend net/xrdp
With it you can connect via any RDP-client (mstsc/remmina etc.) to your desktop, but you need the latest commit.

It is easy to setup, but read my journey here: https://github.com/neutrinolabs/xrdp/issues/2477

 

[scorc]

@noel I just sent the email for access.
Thank you Neobin

I ran lumina and mate with a quick test on 13.1-RELEASE-p5. I didn't need a second .conf for input.
Here my notes/steps (no hald!):

Im not sure i follow? A second .conf? And the hald?

For even better experience, I want to recommend net/xrdp
With it you can connect via any RDP-client (mstsc/remmina etc.) to your desktop, but you need the latest commit.

It is easy to setup, but read my journey here: https://github.com/neutrinolabs/xrdp/issues/2477

I think this goes beyond setup for a host in Proxmox? I like it however, and will look to add a link to it if im allowed into the wiki.

 

[mr44er]

Im not sure i follow?

Just my notes will work 1:1 and 100%

A second .conf?

https://tips.graphica.com.au/freebsd-gnome-on-qemu/ speaks about /usr/local/etc/X11/xorg.conf.d/98-qemu-video.conf and /usr/local/etc/X11/xorg.conf.d/99-qemu-input.conf, but you need only the first one. Also you could name it how you want, /usr/local/etc/X11/xorg.conf.d/myproxmoxvideo.conf would be also ok.

And the hald?

Some time ago dbus and hald daemon, both were needed. For now, you don't.

I think this goes beyond setup for a host in Proxmox?

Yeah, more or less.

I like it however, and will look to add a link to it if im allowed into the wiki.

Sure, go ahead.