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: Quid du support nvidia en mars 2024
On 12 Mar 2024 20:14, kaliderus wrote:
Bonsoir,
Qu'en est-il actuellement du support nvidia ?
Il y a super longtemps (15-20 ans), j'ai galéré comme pas possible à
utiliser des drivers proprio (" fuck nvidia " dixit un certain Linus).
Actuellement mon ordi fonctionne avec une carte intel, impeccable.
J'envisage d'investir dans du matériel neuf et récent, chose qui ne
m'est pas arrivée depuis plus de 10 ans.
Mon besoin final :
- via qemu, virtualiser un Win$ 10/11/ou autre car pour un
logiciel spécifique (vraiment pas le choix).
- avoir un support multi-écrans (6 sorties) du système susnommé
(éventuellement avec plusieurs cartes graphiques si nécessaire)
toujours à travers qemu.
Voyez-vous des limitations matérielles ou logicielles, à priori, pour
ce genre de configuration ?
A priori, globalement, non ^^
Difficile de répondre exactement. Tu demandes en gros "est-ce que
j'aurais des problèmes avec ma citadine à la campagne ?".
Tant que tu restes sur des chemins pépères c'est pas pire, mais la
moindre ornière et c'est la galère !
Pas mal de gens font ça avec succès, dont moi, et c'est le matos le plus
problématique: c'est "plus dur" à patcher du hardware que du logiciel.
Il y a aussi des combinaisons qui marchent mieux que d'autres, au bon
gré des fabricants (générations, firmware, microcode, drivers, etc), le
mieux c'est d'essorer le web, il y a pas mal de forums à ce sujet (VFIO,
passthrough, etc).
A mon avis, l'élément le plus important c'est le couple CPU/Carte Mère,
surtout pour du PCI PassThrough.
Le CPU pour les fonctions de virtualisation, et bien sûr le nombre de
"coeurs" dispos pour les machines hébergées, et la CM pour partager les
périphériques sans encombres. Un des mots clé est IOMMU.
Comme Basile, je recommande AMD, pour des raisons autant philosophiques
que pragmatiques ou techniques.
Pense aussi à une carte mère avec assez de ports PCIe !
La plupart des CM grand public sont "gamers", et n'ont que 2-3 ports
PCIe x16 et peu de x1, ça peut ne pas te suffire. Au pire il existe des
"PCIe expanders/splitters", mais ça n'augmentera pas magiquement la
bande passante avec le CPU.
Faire gaffe au dimensionnement de l'alim aussi, c'est bien beau de
consolider un réseau dans une seule boîte, mais faut nourrir tout ce
beau monde ! Viser la certif "gold", sans tomber dans les excès en
Watts. L'efficacité max est à 50 ou 80% de charge, me souviens plus.
Le refroidissement aussi peut être un problème, surtout avec plusieurs
GPUs (beaucoup châleur, mauvais "air flow"), et penser aux canicules
estivales ...
Finalement t'as deux choix:
- soit tu choisis le matos d'abord (disponibilité, choix persos, etc),
et ensuite tu valides/peaufines en fonction des avis positifs et
négatifs sur les zinterwebs
- soit tu "copies" carrément les configs d'autres qui marchent !
Sinon quand je dois choisir du matos, je me base toujours sur les
conseils de Canard PC Hardware, pour connaître le meilleur rapport
qualité/prix. Même s'ils considèrent aussi un peu l'aspect bureautique,
leurs configs sont plutôt orientées "gaming", mais qui peut le plus peut
le moins !
Ca fait plus de 20 ans, et j'ai jamais été déçu. Ils vont pas te faire
claquer 100 balles de plus pour 2% de gains en perf, mais les configs
sont durables.
Et puis ils prêchent contre les LEDs partout, rien que pour ça il faut
les soutenir !
Logiciellement c'est l'inverse, pas de prob.
Je ne sais pas si le PCI-PT marche nativement sur QEMU "solo", mais Xen
fait ça très bien (avec ou sans QEMU, au choix).
Au pire y'a KVM, mais comme je fais partie de la team debian-xen, je
prêche pour ma paroisse ... :)
Merci par avance.
k.
--
++
zithro / Cyril
Re: utilisation de nis et nfs pour un réseau de 32 postes
On 24 Feb 2024 23:23, BERTRAND Joël wrote: Un gros serveur sous NetBSD et toutes les stations sont diskless et bootent sur le réseau. Les disques sont en NFS et les swaps en iSCSI. Peux-tu expliquer ce choix (NFS vs iSCSI) stp ? Si je dis pas de conneries, tu pourrais boot root (/) en iSCSI. Note que je suis autant interessé par ton raisonnement (ton choix pratique) que par le débat NFS vs iSCSI (la théorie) ! (Y'a pas de solutions toutes faites, le forum de FreeNAS est un bon exemple). La qualité du switch est primordiale. Passer d'un TPLink à un Cisco m'a changé la vie. Entièrement d'accord avec toi. J'en profite pour un coup de gueule, c'est le problème avec le matos "grand public". Un switch 1Gb/s "grand public" veut dire que tu auras ce débit entre DEUX stations ! (Comprendre entre 2 ports physiques). Un "vrai" switch 1Gb/s 10 ports devrait tenir au moins 5Gb/s (sans uplink) : deux stations à 1Gpbs, fois 5. J'ai découvert ce problème par la pratique, chercher "switch backplane" sur le net. Même certains switch soit-disant d'entreprise (SOHO) sont incapables de tels débits. (Mais YMMV comme disent les ricains). Le goulot d'étranglement n'est pas le réseau, mais le système de fichier sur les disques exportés. J'ai fait la bêtise d'utiliser FFSv2 sur lequel il n'est pas possible de mettre un cache. Lorsque j'aurai le temps, je remplacerai cela par un ZFS+cache. AFAIK, le problème de tous réseaux c'est la latence, pas le débit. (Toutes proportions gardées). Donc améliorer les accès disque(s) n'améliorent pas forcément la "réactivité". Peux-tu éclairer ma lanterne stp ? PS: j'ai travaillé dans la VoIP, où j'ai -finalement- compris que latence et débit n'ont rien à voir. Sans même parler de jitter (la variation de latence en bon céfran). -- ++ zithro / Cyril
Re: Erreur nvidia suite upgrade noyau 6.1.0-18
Rilax les gens (: A mon avis c'est juste une incompréhension. En caricaturant : - Michel a compris qu'André disait "je laisse tomber, ça montre bien qu'il y a que des noobs/gens inutiles ici". - Alors qu'André voulait dire "je laisse tomber car ça me saoûle, dommage car ça aurait pu profiter à d'autres". J'ai bon ? PS: je t'ai envoyé quelques pistes, mais bon si t'es saoûlé je comprends. On est tous tombé sur des problèmes "qui piquent" où tout le monde s'arrache les cheveux, au bout d'un moment tu te dis, "et merde", et tu fais avec/sans ! -- ++ zithro / Cyril
Re: Erreur nvidia suite upgrade noyau 6.1.0-18
On 13 Feb 2024 18:22, ajh-valmer wrote: Errors were encountered while processing: linux-image-6.1.0-18-amd64 linux-image-amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) Sans logs, c'est "ma voiture a un bruit, c'est quoi ?" ;) Télécharge manuellement le nouveau kernel et installe-le en mode debug : (DL en user, install en root) $ apt-get download linux-image-6.1.0-18-amd64 # dpkg -D13 -i linux-image-6.1.0-18-amd64.deb Augmenter "D" augmente les détails. Voir "man dpkg" ou "dpkg --debug=help" pour les chiffres utiles. Quelques autres pistes: - dkms - apt pinning - vérifier l'état des paquets (dpkg --audit, etc). (- espace disque dans /boot ou /lib) -- ++ zithro / Cyril
Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
On 13 Feb 2024 10:31, Hugues MORIN-TRENEULE wrote:
@zithro / Cyril: je me suis trompé en écrivant, j'upgrade de bien de
Stretch à Buster ;-)
Tant mieux ;)
C'est toujours bon de préciser pour les futurs lecteurs !
Donc je récapitule pour voir si j'ai bien compris: - ps pour trouver
le PID d'apt - killall -9 "PID d'apt" - dpkg-reconfigure - apt
upgrade --without-new-pkgs (=> Cette commande met à niveau les
paquets qui peuvent l'être sans entraîner l'installation ou la
suppression d'autres paquets. ) - apt full-upgrade
Ça vous semble correct ?
Oui ça devrait aller, lis bien les docs officiels de MàJ, à chaque
update majeur de version il y a des particularités (paquets obsolètes, etc).
Quand tu changes les sources, pense à enlever les backports, si tu les
utilises.
Si c'est une install avec GUI, essaie de faire l'update depuis
tty1/tty6, pas depuis X (vt7). Le serveur X -peut- redémarrer et te
perdre la fenêtre d'upgrade (donc le stopper en plein milieu).
Il est aussi recommandé d'utiliser "screen", pour parer à ce genre de
problèmes (lancer avec "screen -R upgrade", et récup avec la même
commande si ça coupe. Tu peux changer "upgrade" en hugues ou w/e).
La commande "script" est aussi recommandée, pour tout enregistrer.
J'ajoute quelques commandes qui peuvent être utiles avant de lancer
l'upgrade. Elles sont aussi recommandées dans les "Release Notes", afin
de partir sur une base saine avant l'upgrade.
Certaines commandes sont équivalentes et donneront le même résultat.
Quant à quoi faire du résultat ... ça dépend ! Pas de recette miracle.
Mais ce n'est ni parce que tu n'as rien, ni parce que tu as des
résultats que c'est un gage de réussite (:
# lister les paquets obsolètes et "not-from-Debian"
apt list '~o'
# les purger - ATTENTION, purge=remove conf files
apt purge '~o'
apt list '?narrow(?installed, ?not(?origin(Debian)))'
apt-forktracer | sort
# vérif les paquets, surtout ceux en "hold"
dpkg --audit
dpkg --get-selections | grep 'hold$'
apt-mark showhold
# liens symboliques dans /etc qui pointent nulle part
symlinks -r /etc | grep dangling
# trouver les anciens fichiers config (ie. de paquets supprimés ou
d'anciennes versions de paquets mis à jour)
# (cette commande est affichée sur 2 lignes dans ce mail)
find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'
-o -name '*.old*'
# equivalent
dpkg -l | grep ^rc
# les purger - ATTENTION, perte de données
apt purge $(dpkg -l | awk '/^rc/ { print $2 }')
Sinon, quelques paquets à installer avant l'upgrade si t'aimes bien tout
check :
deborphan
apt-forktracer
apt-listbugs
apt-listchanges
Bref, tu as presque toutes les armes, "pick your poison" comme disent
les ricains !
Perso, je préfère mettre toutes les chances de mon côté donc je lance
toutes les commandes sur toutes les machines.
Certains risquent de dire que c'est too much. A toi de voir ;)
--
++
zithro / Cyril
Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
On 12 Feb 2024 08:00, Hugues MORIN-TRENEULE wrote: Bonjour a tous Je reviens vers vous car je ne sais pas comment m'y prendre pour réparer un crash lors d'un apt full-upgrade lors d'un passage de Stretch a Bullseye. Ca fonctionne peut-être, mais ce n'est pas la manière recommandée ! Seulement l'update de "version" à "version +1" l'est. Donc tu devrais faire : 1. stretch -> buster 2. buster -> bullseye Pour l'avoir fait récemment, les étapes sont quasi les mêmes donc c'est pas trop chiant, et c'est plus sûr (ie. tu risques moins d'erreurs). Fais un doc avec juste les commandes pour aller plus vite. Si tu veux les miens je peux te les filer. -- ++ zithro / Cyril
Re: Debian 12 - Blocage IPv4 sans fail2ban & co
On 07 Sep 2023 12:55, Romain wrote: Les erreurs étaient bien (et sont encore, même si moins nombreuses) sur le serveur chez OVH. Pour le moment je n'arrive plus à reproduire. Comme j'échange avec OVH en même temps, peut-être une correction de leur côté. A suivre. Rah ce top posting ... Pour info, si OVH utilise des IP privées sur son réseau interne, c'est normal qu'elles apparaissent dans les mtr. Comme ton DNS local (ou avahi, etc) connait cette adresse, il te l'affiche comme étant une machine locale. Les routeurs internes de certains FAIs et hébergeurs ont parfois des IPs RFC1918, voire APIPA (pour CG-NAT), afin d'économiser les IPv4 publiques. T'as une IPv4 full stack des deux côtés (chez toi et chez eux) ? D'après mes souvenirs ça peut poser des problèmes si ce n'est pas le cas. Autre piste, tu peux essayer des traceroutes avec les 3 protocoles : ICMP, UDP, TCP. Il y a parfois des différences. -- ++ zithro / Cyril
Re: Lenteur au boot : résolu
On 20 Aug 2023 16:14, ajh-valmer wrote: Hello, J'ai retrouvé une vitesse de boot plus digne. /etc/default/grub : GRUB_DISABLE_OS_PROBER=false (retirer le #) Pour info, "GRUB_DISABLE_OS_PROBER" n'a rien à voir avec le boot proprement dit. Ca ne sert qu'à détecter les autres OS installés sur ta machine, et uniquement lorsque "update-grub" se lance (penser dual boot), par exemple lors d'un update du kernel. D'ailleurs, c'est couillon mais c'est une double négation : disable + false = true, donc tu viens d'activer le prober. Si tu n'as pas d'autres OS installés sur ta machine, ou *surtout* si tu utilises un hyperviseur (virtualisation) avec des disques "passthrough-ed", je te conseille de le mettre à TRUE (l'autre option étant de carrément virer le paquet "os-prober"). Bonus, tu gagneras quelques secondes lors des prochains lancements de "update-grub", car il n'aura pas à parcourir tous tes disques à la recherche d'autres OS. PS: il faut lancer "update-grub" à chaque modif de "/etc/default/grub". /etc/boot/grub.cfg : /dev/sda5 indiquait msdos6 puis update-initramfs -u a remédié au problème. Je pense que tu voulais dire "/boot/grub.cfg". Bon dimanche. https://xkcd.com/386 ;) -- ++ zithro / Cyril
