Debian on OpenBSD vmd

[CiotBSD]

Hi.

I attempt to run an install a Debian Buster into a VM on OpenBSD 6.5.
This OpenBSD run on a server, without X, only SSH connection.

Ago 8 months, I installed with success a Debian Stretch on other VM, and previously on OpenBSD 6.4, segun this tutorial:
http://www.netzbasis.de/openbsd/vmd-debian/

I understand the process to connect on VM is by serial console... no X!

Now, just i use the same tuto to install Buster; after sames modifications with new files, when i start the VM, i've this error: undefined video mode number: 314.

- boot.img: http://ftp.debian.org/debian/dists/b...ia/boot.img.gz
- initrd: http://ftp.debian.org/debian/dists/b.../xen/initrd.gz
- virtio module: http://ftp.debian.org/debian/pool/ma...9-3_amd64.udeb

The preparation of boot.img:

gzip -d initrd.gz
mkdir buster
cd buster
ar -x ../virtio-modules-4.9.0-11-amd64-di_4.9.189-3_amd64.udeb data.tar.xz
xz -d data.tar.xz
tar xf data.tar
rm data.tar
find . | cpio -o -A -H sv4cpio -O ../initrd
cd ..
gzip -9 initrd
gzip -d boot.img.gz
doas vnconfig vnd1 ~/vm/debian/boot.img
doas mount /dev/vnd1i /mnt
doas cp initrd.gz /mnt/INITRD.GZ
doas vi /mnt/TXT.CFG
	-	append vga=788 initrd=initrd.gz --- quiet ^M
	+	append vga=off initrd=initrd.gz --- quiet console=ttyS0,115200n8 ^M
doas umount /mnt
doas vnconfig -u vnd1

Thoses steps seem run correctly. No error!

I start the vm:

vmctl start install -c

('install' is the name of the VM)

And after few seconds, the result is:

[IdOp]

It looks like an error message generated by the Linux kernel.

Presumably the video mode it (Linux) has been configured to use is not one that is supplied by the virtual machine.

Did you try hitting Enter and if so did you get a list of available video modes? If so you can try one out and see how it works.

If you find a suitable video mode that way from those that are available, you could then look at changing the Linux boot time configuration to use that mode. This may involve setting "vga=..." somewhere; sorry I'm not familiar with Debian or grub.

ADDED: Welcome to the forum!

[jggimi]

Hello and welcome!


Virtual video hardware is NOT made available to vmm(4) guests. Only serial consoles are supported. IdOp's assumption that the Linux kernel is producing the message is likely to be correct.


Guests can support graphical applications, such as webservers or X clients. But they do not have access to any type of graphic "cards" in their virtual machines.

[CiotBSD]

Yes, I understand the video process.

But, the customized TXT.CFG (into boot.img file) is to set vga=off and console=...

After the error message, no input is possible!

On OpenBSD 6.4, for Debian Stretch, this run correctly.

[fvgit]

Originally Posted by CiotBSD

But, the customized TXT.CFG (into boot.img file) is to set vga=off and console=...

After the error message, no input is possible!

On OpenBSD 6.4, for Debian Stretch, this run correctly.

Can you install Debian Stretch successfully on an OpenBSD 6.5 VM (instead of 6.4)?

[CiotBSD]

Originally Posted by fvgit

Can you install Debian Stretch successfully on an OpenBSD 6.5 VM (instead of 6.4)?

No, it's same problem!

----

I restart vmd.
- delete file of vm
- recreate new file qcow2
- download file boot.img.gz shared by netbazis... (this boot.img.gz
- and restart install, with same problem!

$ doas rcctl restart vmd
$ rm -fP buster.qcow2
$ vmctl create buster.qcow2 -s 60G
$ ftp http://www.netzbasis.de/openbsd/vmd-debian/boot.img.gz
$ gunzip -d boot.img.gz
$ vmctl start install -c

My '/etc/vm.conf':

ROOT="/home/myid/vm"

switch "sw" {
    interface bridge0
}

# VM to attempt an install img OS
vm "install" {
    disable
    disk $ROOT/debian/boot.img
    disk $ROOT/debian/buster.qcow2
    interface { switch "sw" }
    memory 1G
    owner myid
}

@jggimi: yes, I known by qemu is possible, but slowly... and after, download on my server a file (where size is 60 Go), by ADSL, is "impossible"!
And qemu is not the solution!
(only with vmd, please)

[jggimi]

Originally Posted by CiotBSD

No, it's same problem!

I'm using -current, and have downloaded and tested the prepared image from the "how to" site. It will start the install process without attempting to use a video card.


From what I can determine, your problem is not an OpenBSD problem. Instead, it is a problem with how your newer version of Debian is provisioned.

[jggimi]

This is apparently a Debian issue, since Debian is looking for a video card that does not exist. Perhaps provisioning requirements have changed in this version?

Run your guest where video is supported, such as with emulators/qemu on OpenBSD, then provision this guest to ensure it uses a serial console and does not attempt to use a video card.

[CiotBSD]

Originally Posted by jggimi

(...)
Run your guest where video is supported, such as with emulators/qemu on OpenBSD, then provision this guest to ensure it uses a serial console and does not attempt to use a video card.

It seems to be not possible. Because, this server have not X server. (no set x* installation...)
I'm connecting by SSH session.

The purpose is run a server Debian Buster on VM into an OpenBSD server (without X).

[PapaParrot]

First off , Welcome to the forum,... It is normal for servers to not use Xorg or any X windows.

CiotBSD>>I attempt to run an install a Debian Buster into a VM on OpenBSD 6.5.
This OpenBSD run on a server, without X, only SSH connection.

I am assuming you mean a web server, ? There are many kinds of servers, if it is not a web server, you should clarify.
You should be able to use QEMU, and install Debian on ir, but on your PC, with a QEMU VM, where video is supported (as jggimi said). I will say though, from experience, it is not worth the trouble, of course that might depend on your reasons for wanting to do this, I have a very low opinion of what Debian has become, and that would be another topic, in off topic, Just saying, The current stable Debian 10, did not work well at all on a VM, and it is not much better on bare metal, real hardware.
Any way , I think if you can explain more about why you want to do this it might help. It does not make sense to me why someone would want to put Debian, or any OS on a VM , on a webserver (if it is a web server), ..?
=== edited ===
For help with installing Debian, on VM or bare metal, you would be better off asking on a forum that is dedicated to Debian, of course, if the host system is OpenBsd, installing the VM software, etc, would be a OpenBsd issue, my suggestion is start with a simple QEMU VM, and try installing FreeDos to a QEMU VM, then try another, install OpenBsd to it, the the 3rd one, try Debian, you will see what I mean, it just plain does not work well. Ahh, another one that runs really well on a VM, and is fun, My favorite: Minix3

[jggimi]

Originally Posted by CiotBSD

It seems to be not possible. Because, this server have not X server. (no set x* installation...)
I'm connecting by SSH session.

The purpose is run a server Debian Buster on VM into an OpenBSD server (without X).

To fix this problem, you must have a Debian guest that does not require a video card. I recommend:

• Copy your Debian system to -- or recreate it on -- a system with a video card.
• Provision the system so that a) it uses a serial console, and b) does not attempt to use video card hardware.
• Copy the repaired image back to the OpenBSD host system.

Originally Posted by PapaParrot

...You should be able to use QEMU...

Qemu is possible, but is a very cumbersome solution for this use-case.

• The server is remote, headless, and does not have the X filesets installed.
• Qemu can run guests with the no-graphics option but the Debian guest will fail with the same error, as it currently requires video.
• Qemu guests can transmit virtual video card output over a network with Qemu's built-in VNC server. But it will be far easier to fix the Debian issue locally, on a workstation with a graphics card.

.

[CiotBSD]

OK.
I reboot my laptop with HD OpenBSD 6.5 to attempt SSH connections on the server (too, on 6.5).
And, it's run correctly!
(But, the installer not found the ISO to continue the install... it's other problem, not result to this issue; i think)

Surprising: With my HD Debian Sid, connecting by SSH on the same server, I've this issue. But with HD OpenBSD, it's OK!

@jggimi: thank!

[jggimi]

Originally Posted by CiotBSD

With my HD Debian Sid, connecting by SSH on the same server, I've this issue. But with HD OpenBSD, it's OK!

This is likely to be a difference in how the two different ssh(1) clients are provisioned.

[CiotBSD]

Originally Posted by jggimi

This is likely to be a difference in how the two different ssh(1) clients are provisioned.

Not by my file ".ssh/config". It's exactly the same file, rsynced on both systems!

On OpenBSD, ssh client is:

$ ssh -V 
OpenSSH_8.0, LibreSSL 2.9.1

But, even on Debian Sid, if SSH is v8.0 too, is based on OpenSSL 1.1.x!
- https://packages.debian.org/sid/ssh
- https://packages.debian.org/sid/openssh-client
- https://packages.debian.org/sid/libssl1.1

or, perhaps, the DE?
On OpenBSD is Xfce 4.12; On Debian Sid is 4.14!

[jggimi]

OpenSSH uses two configuration files when the ssh(1) -F option is not present: ~/.ssh/config, and /etc/ssh/ssh_config. You might see differences if you compare the output of $ ssh -G <host> from your two client systems.

[CiotBSD]

Hi.

For OpenBSD:

user myid
hostname ip_server
port ***
addkeystoagent true
addressfamily any
batchmode no
canonicalizefallbacklocal yes
canonicalizehostname false
challengeresponseauthentication no
checkhostip yes
compression yes
controlmaster auto
enablesshkeysign no
clearallforwardings no
exitonforwardfailure no
fingerprinthash SHA256
forwardagent no
forwardx11 no
forwardx11trusted yes
gatewayports no
hashknownhosts yes
hostbasedauthentication no
identitiesonly no
kbdinteractiveauthentication yes
nohostauthenticationforlocalhost no
passwordauthentication yes
permitlocalcommand no
proxyusefdpass no
pubkeyauthentication yes
requesttty auto
streamlocalbindunlink no
stricthostkeychecking ask
tcpkeepalive yes
tunnel false
verifyhostkeydns true
visualhostkey yes
updatehostkeys false
canonicalizemaxdots 1
connectionattempts 1
forwardx11timeout 1200
numberofpasswordprompts 3
serveralivecountmax 7
serveraliveinterval 30
ciphers chacha20-poly1305@openssh.com,aes256-ctr
controlpath ~/.ssh/socket-myid@ip_server:***
hostkeyalgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,ssh-rsa-cert-v01@openssh.com,ssh-rsa,ssh-dss-cert-v01@openssh.com,ssh-dss
hostbasedkeytypes ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
kexalgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
casignaturealgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
loglevel INFO
macs hmac-sha2-512-etm@openssh.com,hmac-sha2-512
pubkeyacceptedkeytypes ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
xauthlocation /usr/X11R6/bin/xauth
identityfile ~/.ssh/id_rsa
identityfile ~/.ssh/id_dsa
identityfile ~/.ssh/id_ecdsa
identityfile ~/.ssh/id_ed25519
identityfile ~/.ssh/id_xmss
canonicaldomains
globalknownhostsfile /etc/ssh/ssh_known_hosts /etc/ssh/ssh_known_hosts2
userknownhostsfile ~/.ssh/known_hosts ~/.ssh/known_hosts2
connecttimeout none
tunneldevice any:any
controlpersist yes
escapechar ~
ipqos af21 cs1
rekeylimit 0 0
streamlocalbindmask 0177
syslogfacility USER

For Debian Sid:

user myid
hostname ip_server
port ***
addkeystoagent true
addressfamily any
batchmode no
canonicalizefallbacklocal yes
canonicalizehostname false
challengeresponseauthentication no
checkhostip yes
compression yes
controlmaster auto
enablesshkeysign no
clearallforwardings no
exitonforwardfailure no
fingerprinthash SHA256
forwardagent no
forwardx11 no
forwardx11trusted yes
gatewayports no
gssapiauthentication yes
gssapikeyexchange no
gssapidelegatecredentials no
gssapitrustdns no
gssapirenewalforcesrekey no
gssapikexalgorithms gss-gex-sha1-,gss-group14-sha1-
hashknownhosts yes
hostbasedauthentication no
identitiesonly no
kbdinteractiveauthentication yes
nohostauthenticationforlocalhost no
passwordauthentication yes
permitlocalcommand no
proxyusefdpass no
pubkeyauthentication yes
requesttty auto
streamlocalbindunlink no
stricthostkeychecking ask
tcpkeepalive yes
tunnel false
verifyhostkeydns true
visualhostkey yes
updatehostkeys false
canonicalizemaxdots 1
connectionattempts 1
forwardx11timeout 1200
numberofpasswordprompts 3
serveralivecountmax 7
serveraliveinterval 30
ciphers chacha20-poly1305@openssh.com,aes256-ctr
controlpath ~/.ssh/socket-1a12c584cabe32e54d63767c556a9bbe86455c90
hostkeyalgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,ssh-rsa-cert-v01@openssh.com,ssh-rsa,ssh-dss-cert-v01@openssh.com,ssh-dss
hostbasedkeytypes ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
kexalgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
casignaturealgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
loglevel INFO
macs hmac-sha2-512-etm@openssh.com,hmac-sha2-512
pubkeyacceptedkeytypes ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
xauthlocation /usr/bin/xauth
identityfile ~/.ssh/id_rsa
identityfile ~/.ssh/id_dsa
identityfile ~/.ssh/id_ecdsa
identityfile ~/.ssh/id_ed25519
identityfile ~/.ssh/id_xmss
canonicaldomains
globalknownhostsfile /etc/ssh/ssh_known_hosts /etc/ssh/ssh_known_hosts2
userknownhostsfile ~/.ssh/known_hosts ~/.ssh/known_hosts2
sendenv LANG
sendenv LC_*
connecttimeout none
tunneldevice any:any
controlpersist yes
escapechar ~
ipqos lowdelay throughput
rekeylimit 0 0
streamlocalbindmask 0177
syslogfacility USER

A diff result:

$ diff Debian-ssh-G-server OpenBSD-ssh-G-server 
21,26d20
< gssapiauthentication yes
< gssapikeyexchange no
< gssapidelegatecredentials no
< gssapitrustdns no
< gssapirenewalforcesrekey no
< gssapikexalgorithms gss-gex-sha1-,gss-group14-sha1-
51c45
< controlpath ~/.ssh/socket-1a12c584cabe32e54d63767c556a9bbe86455c90
---
> controlpath ~/.ssh/socket-myid@ip_server:***
59c53
< xauthlocation /usr/bin/xauth
---
> xauthlocation /usr/X11R6/bin/xauth
68,69d61
< sendenv LANG
< sendenv LC_*
74c66
< ipqos lowdelay throughput
---
> ipqos af21 cs1

[jggimi]

Hmmm. I don't see anything obvious in these differences. OpenBSD does not use GSS-API for authentication, a ControlPath is only used with multiplexed sessions (ssh -O), XAuthLocation is only used with X11 Forwarding (ssh -X/-Y), I don't perceive anything significant in the locale differences sent to the servier, and and the IPQoS values are actually identical: lowdelay = af21, throughput = cs1.

[fvgit]

Maybe it's just me, but I think this discussion is getting a bit confusing.

Perhaps the SSH issue could be separated into a topic of its own? Just a thought.

[jggimi]

I perceive two related problems: A Debian-specific serial console / video card provisioning issue of some kind, and an ssh(1) issue that presents on a Debian workstation. I'm not sure I can help any further with either, and both appear to me to be Debian problems.

[CiotBSD]

We have identified the reason: a Debian-specific serial console!

Thanks for your help!