Re: qemu et lancer un system " reel "
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}=="----",
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
Re: apt pas content
Le Sat, 16 Mar 2024 14:06:14 +0100, Gaëtan Perrier a �crit : C'est très certainement dû à ça : https://lists.debian.org/debian-devel-announce/2024/02/msg0.html j'ai le même type d'erreur, cf: # apt-get upgrade . 0 mis à jour, 0 nouvellement installés, 0 à enlever et 1469 non mis à jour Cordialement Bonjour, > > Depuis quelques jours je rencontre un problème de mise à jour avec > apt. > > # apt dist-upgrade > Lecture des listes de paquets... Fait > Construction de l'arbre des dépendances... Fait > Lecture des informations d'état... Fait > Calcul de la mise à jour... Erreur ! > Certains paquets ne peuvent être installés. Ceci peut signifier > que vous avez demandé l'impossible, ou bien, si vous utilisez > la distribution unstable, que certains paquets n'ont pas encore > été créés ou ne sont pas sortis d'Incoming. > L'information suivante devrait vous aider à résoudre la situation : > > Les paquets suivants contiennent des dépendances non satisfaites : > libgnutls-dane0 : Dépend: libgnutls30 (= 3.8.3-1) > E: Erreur, pkgProblem::Resolve a généré des ruptures, ce qui a pu > être causé par les paquets devant être gardés en l'état. > > Le problème de dépendance est étrange car ces deux paquets sont > installés dans la bonne version: > > # apt-show-versions | grep libgnutls > libgnutls-dane0:amd64/testing 3.8.3-1 uptodate > libgnutls-dane0:i386/testing 3.8.3-1 uptodate > libgnutls-openssl27:amd64/testing 3.8.3-1 uptodate > libgnutls-openssl27:i386/testing 3.8.3-1 uptodate > libgnutls28-dev:amd64/testing 3.8.3-1 uptodate > libgnutls28-dev:i386 not installed > libgnutls30:amd64/testing 3.8.3-1 uptodate > libgnutls30:i386/testing 3.8.3-1 uptodate > > Et le problème de paquet garder en l'état est lui aussi étrange car > il n'y en a pas : > > # apt-mark showhold > # > > Je suis un peu perdu là ... > > Gaëtan > > -- Lumière de tous les chakras ! ⚡⚡⚡藍 藍藍
Re: apt pas content
Bonjour, Il y a un gros problème avec gnutls mais je pensais que ça se limitais à testing. J'ai réussi à m'en sortir hier en forçant l'installation de la mise à jour de gnutls et de ses dépendances et en _réinstallant_ le reste qui a été viré par un dist-upgrade. Seul cups est toujours cassé. JB signature.asc Description: OpenPGP digital signature
apt pas content
Bonjour, Depuis quelques jours je rencontre un problème de mise à jour avec apt. # apt dist-upgrade Lecture des listes de paquets... Fait Construction de l'arbre des dépendances... Fait Lecture des informations d'état... Fait Calcul de la mise à jour... Erreur ! Certains paquets ne peuvent être installés. Ceci peut signifier que vous avez demandé l'impossible, ou bien, si vous utilisez la distribution unstable, que certains paquets n'ont pas encore été créés ou ne sont pas sortis d'Incoming. L'information suivante devrait vous aider à résoudre la situation : Les paquets suivants contiennent des dépendances non satisfaites : libgnutls-dane0 : Dépend: libgnutls30 (= 3.8.3-1) E: Erreur, pkgProblem::Resolve a généré des ruptures, ce qui a pu être causé par les paquets devant être gardés en l'état. Le problème de dépendance est étrange car ces deux paquets sont installés dans la bonne version: # apt-show-versions | grep libgnutls libgnutls-dane0:amd64/testing 3.8.3-1 uptodate libgnutls-dane0:i386/testing 3.8.3-1 uptodate libgnutls-openssl27:amd64/testing 3.8.3-1 uptodate libgnutls-openssl27:i386/testing 3.8.3-1 uptodate libgnutls28-dev:amd64/testing 3.8.3-1 uptodate libgnutls28-dev:i386 not installed libgnutls30:amd64/testing 3.8.3-1 uptodate libgnutls30:i386/testing 3.8.3-1 uptodate Et le problème de paquet garder en l'état est lui aussi étrange car il n'y en a pas : # apt-mark showhold # Je suis un peu perdu là ... Gaëtan signature.asc Description: This is a digitally signed message part
