xen xen-kernel doesn't start at all

I have a i7 ivy-bridge put to CSM compatibility with BIOS first. My settings for the dom0 are:


set vfs.root.mountfrom.options=rw
xen_cmdline="dom0_mem=4048M dom0_max_vcpus=4 dom0pvh=1 com1=115200,8n1 guest_loglvl=all loglvl=all"

and followed the guide for installing the XEN-kernel. My /etc/ttys is:

xc0     "/usr/libexec/getty Pc"         vt100   on  secure
ttyu0   "/usr/libexec/getty std.115200" dialup  on  secure

First of all, it is unable to find the root device (ada1p6), even when copying it to /boot/defaults and secondly when activating the xen-kernel it doesn't boot at all, loading the modules but no xen-kernel showing up.

what do I making wrong?

which you mean? my typos are famous as legastenic! tried with "brackets", doesn't help. and AFAIK it isn't ada1p6. /etc/fstab is alright!

not with vfs.root.mountfrom="ufs:ad1p6" (copied and pasted and modified) nor with with other versions of it.

/dev/ada1p6             /           ufs       rw      0       1
/dev/ada1p7             swap    none    sw      0       0

[5 mins. later]

works now! with
but this was not the main issue! what to do with the xen-kernel!
virsh -c "xen://":
Failed to connect socket to '/var/run/libvirt/virtxend-sock': No such file or directory
I guess it is for a running xen-kernel! I had it on this PC very early and it worked great! Now I really don't know, why this damn thing doesn't boot!
Did you make an XML file for Xen? libvirt must be configured. I have no idea if this is related to your problem but libvirt should be setup and running for Xen.


Staff member
Is this a typo?
xc0     "/usr/libexec/getty Pc"         vt100   on  secure
ttyu0   "/usr/libexec/getty std.115200" dialup  on  secure
That xencommons_enable="YES" doesn't belong in /etc/ttys.
Looking at the instructions here:

I see no mention of libvirt. So maybe that is just one method of using Xen.
The page is 5 years old so take that into account.

Please note the banner on the above page. Legacy BIOS support only.
So make sure your host BIOS is set to legacy. Also note IOMMU CPU required.
SirDice: yup, was a typok, corrected it to /etc/rc.conf!
Phishfry: what I did now was to write bootcode to /dev/ada1 with gpart; I had big problems to get other systems back and had to delete the /dev/ada1p1 and reconnect it to systems like coping the .efi-file from the rescue image to the partition. I do not know how often I had the wiki-page for FreeBSD open in the last 72 hours!

I think it has to do with the (U)EFI bootmode; I set to CSM in BIOS, MBR first, but FreeBSD is booting .EFI. How to change that?
My FreeBSD 13.0-RELEASE with xen-kernel/xen-tools (4.15) work fine via UEFI boot. All XEN-related settings:

1) /boot/loader.conf (hint: vmm_load="YES" should be absent):
xen_cmdline="dom0_mem=2048M dom0_max_vcpus=2 dom0=pvh com1=115200,8n1 guest_loglvl=all loglvl=all"

2) /etc/sysctl.conf:

3) /etc/ttys:
xc0     /usr/libexec/getty Pc           xterm   onifconsole     secure

4) /etc/rc.conf:
devel/libvirt from packages does not include Xen support.
Xen needs libvirt.
You are wrong, XEN does not require libvirt. This package may be required, for example, for virt-manager to manage XEN. In addition to the virt-manager, you can manage XEN (in addition to xl ) via CBSD ( at least I manage a small XEN cluster with CBSD ;-)
Sorry for course in advance: shit!

No change at all, xen_kernel doesn't boot and FreeBSD 14 is only bootable with key 6 for the built kernel change and the 3 for command line with "unset xen_kernel" and "boot" afterwards.

Installed CBSD and set it up to the home directory but take care, with sudo it is too less on permissions for setting up! But I think that it is a question for controlling the hypervisor after kernel successfully booted, what definitely is not doing how it should!

My thoughts go back to the MBR in PCB mode first before UEFI boots, but this is with this installation probably impossible.

I installed FreeBSD_CURRENT from the mini-memstick and ftp'd the sets because of mismatch of checksum in the installation program. So there were no inodes made after installation but a "tar xfv set*"; I configured /etc/rc.conf and network manually and keep on working on a splash screen, but the bitmap doesn't work, I guess because of the colours (should be the same as my avatar here). Any other ideas?

At the moment I'm working on a Hackintosh Monterey, but getting no sound with the Voodoo driver as well as with LILO.kext and ALC.kext. To listen to music I had to install windoze with a cracked parallels with the apple hypervisor and connect my bluetooth stick (rtl8761b) in the VM, so I can listen now to YT or Kodi or whatever! There's linux driver for this device but nothing for Mac and the HDMI output doesn't work. With linux there's a dkms config and it does what it should; working like a charm! is what I learned there. I never forget that the mach-kernel is the double of our CURRENT, so I don't forget the base, that made the OC-loader for Mac possible. Ok, enough from this point of view, it was a month of work!


So, last change, I guess, if someone knows anything how to get the XEN work, please help!

ahhh! with the 13-RELEASE it is tired and available for everybody, but 14 for specialists! All I can do, is making a Virtual Machine with OsX or linux and boot it from there on (this works, I tried it out!) or making a Virtual Machine in the 14_CURRENT release with 13-RELEASE with qemu or virtualbox-ose!

Gonna write in the forums, I already did ant freebsd-current@freebsd.org mailing list, but got no answer, maybe your proposal is good like this; we discuss it in the mailing list and bring the result here for others!

to let a intermed behind: we're making a virtual console on a plain FreeBSD14 machine "greatgrandma" Dell on the receiving end, and on the other end we connect it to the port but with problems, as the 9-pin don't match the cable. It *needs* to be a 0-modem-cable. we'll update with output of the serial console.

It *needs* to be a 0-modem-cable. we'll update with output of the serial console.
Yes commonly referred to as null modem cable.

Most older APC UPS used the null modem cable. So easy to scape those.

The advice about FreeBSD 13 is valid.
FreeBSD 14 is a development version right now. It can be broke by design.
Under construction. Danger Zone.
not all warnings given are exectely included permanently, I think. And for me it's the moment of updating to latest source when system has been built after make buildworld -j9 and install buildworld -j9, what takes "great-grandma" a temperature of 80° on mainboard and something useful to do for 27 hours.

for me it always has been the "newest version" and "latest" and "current" what did it's fascination and when success it's motivation for bad times enough, no need to go around and earn something with it. there's still enough pressure and I guess the "CURRENT" and brandnew thing is for forgetting how damn fast the time has been. What today is modern and in, is out tomorrow and people tend to suffer on the sickness of being empty with one reasen: the capitalism and wellfare everywhere. and: the sensorical (en-)privation - neologism?.

speak with elder people and they will all tell you the same: that the system will accellerate so fast that it's getting a mary-go-around seen as charts for breaking down completely. the covide was just a warning by nature.
hi guys,

now I finally had time to occupy me with the serial console output on the old
Dell Vostro 134, sorry for late reply, wasn't this easy to get the adapters and the cable.

As things are at the moment:

a) I'm not sure about the 0-modem-cable if pin 2 and 3 are crossed, but I can
get a connection at the dell with 'cu -s 9600 -c /dev/cuaU0' telling me
connect, I type ATX, answer is OK.

b) on the Xen-kernel side I changed my settings for the sio0 in /boot/
devices.hints with flag 0x100. I changed /boot.config to "-h -D". When
rebooting dell doesn't write anything at all.

The system is slow when booting, probably because of the 9600 baud given in
the devices.hints. I use "serialconsole,efi" in /boot/loader.conf. But thats
all I have at the moment but a cable accross my room! With the adapter from
board to serial output it wasn't the problem. On dell side I use an USB-
Adapter for the other side of the cable.

So, my specialists, what's wrong with it, why does dell not write anything. I
read in Dutch, German and English, some sides wanted to sell me a rebuild of
kernel but others say it's to be done dynamically on the devices.hint file.
Anyway, trying to add "device sio(0) at isa? ...." gives me just a syntax
error when trying to compile. I guess it is ok with /devices.hints".

could someone help me please?

buhu.... it just takes a while to get a special card and an adapter and a cable and now noone, not in the fora, not in here is ready to help me further.

ok, let's ask it this way: what did I do false this time, beastie? maybe turn it off, but tried, not difference.

so, please answer now or I forget about this issue!

Ole seemed to have a valid Xen recipe. Start there.
As for point a)
but I can
get a connection at the dell with 'cu -s 9600 -c /dev/cuaU0' telling me
connect, I type ATX, answer is OK.
This sounds wrong to me.

I have no idea about ATX. That sounds like a modem AT command. Especially if answered with an OK.
Something is amiss.
You are trying to connect to a VM. For that FreeBSD has a virtual serial console called nmdm(4).
That is what I use with bhyve. I pass thru virtual serial ports to my VM's. That is my management port.
I have not experimented with Xen for 3 years and took no notes. Performance was lacking I do remember.
I did use Virt Machine Manager/libvirt for a nice GUI setup.
I'm not sure about the 0-modem-cable if pin 2 and 3 are crossed
Two ways to find out. First, with a computer with a serial port built-in (which is likely /dev/cuau1) and a usb-to-serial adapter (/dev/cuau3). Then open a minicom/cu/putty session in one terminal to /dev/cuau1 and a second terminal session to /dev/cuau3. What you type in the first terminal will show up in the second one, and the other way around. Then it's indeed a cross (null modem) cable.
Second way to find out is with a multimeter. Check if pin 2 at one end is connected to pin 3 at the other end. Measure passage (will beep if yes) or measure resistance, should be close to zero. You'll find the pin numbers on the connector.
I was looking at this earlier and I don't think you can use nmdm like I suggested.
So you have to use another machine and connect to com1 of the host machine.

So I have a funny feeling you may be connecting to the wrong USB port.
(Due to OK command probably from cellular modem)
Check to see what your USB ports are.
ls /dev/cuaU*
I have a suspicion that you have something wrong.
Tieks: thx for friendly support, as a missing instrument of the multimeter (how long will it takes until our mobiles will recognize turned phases)!
OT: On this cable I got from Am* broke my relationship that dured back to 1998 apart, now I'm looking for alternatives. This is a good sign that I got the right one, as we consequently avoid any monopolization. whatta do with google and fb? gonna check this /dev/cuau3 (putty is working here?) thing out later at night, doing the beta 7 update on dev. for IoS at the moment. Time became somethines a much to precious good and resource! This is why Hackintosh and not Macintosh!

Phishfry , my veteran in this thread! As far as I can remember from yesterday, the old dell pc has just a /dev/cuaU0, no cuaUx then the zero. on xen-side, I'll answer later, it's early here 21:00 at evening and nightcleur works in an good mood.

/proc - 3 -hours as such a procedure of starting, btw, take serial console or both, serial first at the menu? I have disabled the kernel debugger in latest built, problem?