On 24 Feb 2024 17:12, kaliderus wrote:
Retour final pour ceux qui seraient confrontés aux mêmes embêtements  :

[snip]
- penser à passer suffisamment de RAM à la machine virtuelle pour
décompresser et utiliser le noyau et le initramfs, pourtant testé à -m
256 (bloquage) le processus passe normalement à -m  size=4G (sans
doute trop)

Essaie de regen l'initramfs avec "dep" au lieu de "most" dans "/etc/initramfs-tools/initramfs.conf", tu économiseras un peu. J'ai plusieurs VMs (Xen) Debian qui bootent à 256M, elles sont light mais pas über custom non plus (128M passe pas).

- qemu n'est pas capable (à ma connaissance) d'utiliser le BIOS natif
de la machine, et le SeaBios par défaut ne convient pas, il faut donc
lui indiquer d'utiliser OVMF.fd

Vois le BIOS comme une sorte de "driver bas niveau du matériel" (à la louche). Le BIOS de la carte mère gère ton "vrai" hardware, mais dans une machine virtuelle, il y a du hardware émulé, donc il faut un BIOS émulé :) Ton BIOS ne saurait de toutes façons pas gérer le matériel émulé par QEMU (plateformes i440fx ou q35 pour x86).

Seabios -> virtual BIOS
OVMF    -> virtual UEFI
(y'en a d'autres, comme rombios)

A mon avis tu avais installé ton système original en UEFI, d'où le problème avec Seabios quand émulé. Une machine installée depuis le BIOS ne bootera pas sans modifs depuis l'UEFI, et vice-versa.

En revanche, tu peux avoir des machines virtuelles qui n'ont pas de BIOS du tout (Xen PV, PVH).

- un montage automatique des partitions paramétré dans PCmanFM-QT
(environnement LXQT), qui fait que quand qemu voulait accéder à
/dev/sdb (ancien système) il lançait un fsck systématique des
partitions, et plantait, pour se retrouver en shell de secours. Ne pas
lancer qemu sur une partition déjà montée (ou c'est PCman le problème
?)

QEMU refusera de se lancer sur une partition montée de la manière que les softs genre fsck refusent : ils veulent l'accès exclusif.

Pour éviter toutes manipulations sur des disques qui finissent dans une machine virtuelle (dans mon cas des partitions ZFS), j'utilise des règles udev.
Créer un fichier "/etc/udev/rules.d/99-hide-partitions.rules", avec :

SUBSYSTEM=="block", ENV{ID_PART_ENTRY_UUID}=="hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh", ENV{UDISKS_IGNORE}="1"

Remplacer les "h" par un UUID, répéter pour chaque partition.
C'est ptêt possible d'ignorer un disque, j'ai pas cherché, ce serait mieux !

- les partitions spécifiées par /dev/sdb et /dev/sdb1 etc. (sans doute
des restes de version précédentes de Debian) sont sujettes à être
confondues avec le nouveau système au niveau de grub.cfg (qui ne peut
accéder ensuite à /home), il est donc nécessaire de les spécifier par
le UUID (modifier /etc/default/grub pour décommenter
#GRUB_DISABLE_LINUX_UUID=true) et relancer update-grub (et modifier
/boot/grub/grub.cfg à la main est assez pénible quand on a pas le bon
clavier, mais étape nécessaire avant l'update du grub)

[.]_DISABLE_[.]_UUID=true, ça veut dire disable=true, donc ne -pas- utiliser les UUID ;) Foutues doubles négations ...

[snip]

ps : en investiguant un peu j'ai remarqué que AMI propose leur bios
sous licence BSD-2, peut-être est-ce une autre solution ?

T'as des liens stp ?

PS: trop tard pour cette fois, mais y'a des utilitaires pour transformer une machine physique en machine virtuelle, virt-p2v par exemple.

--
++
zithro / Cyril

Répondre à