[OpenBSD :: Virtualisation] Pas d'écran de connexion ; pas de login !

Article publié, le et modifié le
5 minutes de lecture

Cet article contient 983 mots.
Source brute de l'article : MD

Description

Pour rappel, l’hyperviseur vmm(4) sous OpenBSD n’a pas de support vidéo pour les VM invités. Seule la console série est prise en charge.

Quand vous faites de la virtualisation sous OpenBSD amd64 ou i386, OpenBSD gère tout ce qu’il faut, comme de nécessaire. Ainsi la console série est configurée au sein du fichier de configuration /etc/boot.conf et le dispositif tty00 est configuré correctement pour utiliser ladite console série.


Le problème est quand vous avez l’idée de créer votre VM, sous Linux par exemple, à moins de spécifiquement répondre yes lorsqu’est demandé le paramétrage de com0, il est possible de se retrouver avec le problème suivant :

Pas d’écran de connexion == pas de login possible !

(où il y en a des malchanceux, et d’autres où ça roule sans soucis… je suis souvent de la première catégorie)


Pour illustrer le propos, une fois la VM OpenBSD copiée sur un hôte OpenBSD, voici le démarrage :

$ vmctl start -c vm-test
Using drive 0, partition 3.
Loading......
probing: pc0 com0 mem[638K 1022M a20=on]
disk: hd0+
>> OpenBSD/amd64 BOOT 3.52
boot>
booting hd0a:/bsd: 14329128+3191816+337072+0+872448 [999468+128+1135344+859361]=0x14ba488
entry point at 0xffffffff81001000
[ using 2995336 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2020 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.8 (GENERIC) #4: Mon Jan 11 10:34:36 MST 2021
    root@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 1056956416 (1007MB)
avail mem = 1010040832 (963MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf3f40 (10 entries)
bios0: vendor SeaBIOS version "1.11.0p3-OpenBSD-vmm" date 01/01/2011
bios0: OpenBSD VMM
acpi at bios0 not configured
cpu0 at mainbus0: (uniprocessor)
cpu0: AMD FX-8320E Eight-Core Processor, 3211.59 MHz, 15-02-00
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,CX8,SEP,PGE,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,HV,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1
cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache
cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: smt 0, core 0, package 0
pvbus0 at mainbus0: OpenBSD
pvclock0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "OpenBSD VMM Host" rev 0x00
virtio0 at pci0 dev 1 function 0 "Qumranet Virtio RNG" rev 0x00
viornd0 at virtio0
virtio0: irq 3
virtio1 at pci0 dev 2 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio1: address fe:e1:bb:d1:a9:7b
virtio1: irq 5
virtio2 at pci0 dev 3 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk0 at virtio2
scsibus1 at vioblk0: 1 targets
sd0 at scsibus1 targ 0 lun 0: <VirtIO, Block Device, >
sd0: 51200MB, 512 bytes/sector, 104857600 sectors
virtio2: irq 6
virtio3 at pci0 dev 4 function 0 "OpenBSD VMM Control" rev 0x00
vmmci0 at virtio3
virtio3: irq 7
isa0 at mainbus0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns8250, no fifo
com0: console
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (6dc570f70e2c7991.a) swap on sd0b dump on sd0b
Automatic boot in progress: starting file system checks.
/dev/sd0a (6dc570f70e2c7991.a): file system is clean; not checking
/dev/sd0m (6dc570f70e2c7991.m): file system is clean; not checking
/dev/sd0d (6dc570f70e2c7991.d): file system is clean; not checking
/dev/sd0f (6dc570f70e2c7991.f): file system is clean; not checking
/dev/sd0g (6dc570f70e2c7991.g): file system is clean; not checking
/dev/sd0h (6dc570f70e2c7991.h): file system is clean; not checking
/dev/sd0j (6dc570f70e2c7991.j): file system is clean; not checking
/dev/sd0i (6dc570f70e2c7991.i): file system is clean; not checking
/dev/sd0e (6dc570f70e2c7991.e): file system is clean; not checking
/dev/sd0k (6dc570f70e2c7991.k): file system is clean; not checking
/dev/sd0l (6dc570f70e2c7991.l): file system is clean; not checking
pf enabled
kern.seminfo.semmni: 10 -> 60
kern.seminfo.semmns: 60 -> 1024
starting network
reordering libraries: done.
starting early daemons: syslogd pflogd nsd ntpd.
starting RPC daemons:.
savecore: no core dump
checking quotas: done.
clearing /tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sshd smtpd.
starting local daemons: cron.
Thu Feb 18 12:25:45 CET 2021

Et, voilà cela s’arrête à l’affichage de l’heure… et vous allez pouvoir attendre longtemps l’écran de connexion de session qui ne viendra jamais !


Et, au cas où tu te le demandes, toi lecteur, non cela ne vient pas d’une corruption de la VM lors de la copie/synchronisation, des tests à base de somme de contrôle sha256 ont été faits avant la copie et après celle-ci, tel que :

Sur la station Linux :

$ cat vm-test.qcow2.sha256
73054a89bb2e0b13d78e8cb446424baa01f7761099d8681a59137655b28c979c  vm-test.qcow2

Puis sur l’hôte OpenBSD :

$ sha256 vm-test.qcow2                                                                                                                                                                    
SHA256 (vm-test.qcow2) = 73054a89bb2e0b13d78e8cb446424baa01f7761099d8681a59137655b28c979c

$ sha256 -C vm-test.qcow2.sha256 vm-test.qcow2
(SHA256) vm-test.qcow2: OK

Mais alors que faire ?!

Sur ton OS source, par exemple le Linux où la VM a été créée, avec qemu et les différents outils virt*, connectes-toi à ta VM, et fais les deux petites modifications suivantes nécessaires :

Configuration

boot.conf

Le fichier de configuration /etc/boot.conf n’a pas été créé - s’il l’est, vérifies l’écriture. Il doit absolument contenir à minima ceci :

set tty com0

Par défaut, le taux de connexion est ainsi de 9200 baups.


Or, étant donné que le futur hôte est OpenBSD, faisons ça bien :

stty com0 115200
set tty com0

Ainsi nous configurons le taux de débit au maximum supporté, soit de 115200.

ttys

L’autre modification nécessaire à faire est de reparamétrer les informations d’initialisation du Terminal tty00.

Le fichier est /etc/ttys, et il faut commenter/supprimer la ligne correspondante à tty00 pour ajouter la déclaration correcte suivante :

tty00   "/usr/libexec/getty std.115200" vt220    on secure

Si vous déclarez le fichier boot.conf ci-dessus a sa valeur par défaut, configurez cette déclaration ainsi :

tty00   "/usr/libexec/getty std.9600"   vt220   on secure

Et, voilà !

Une fois la VM recopiée sous OpenBSD, vous aurez à nouveau l’écran de connexion.

Documentations

Remerciements

@jggimi