• Re: qemu et lancer un system " reel "

    From =?utf-8?Q?=C3=89tienne?= Mollier@21:1/5 to All on Thu Feb 22 22:00:02 2024
    Bonjour kaliderus,

    kaliderus, on 2024-02-22:
    J'ai bien accès au Grub, mais une fois passé cette étape le grub de " ancien système " me dit :
    Loading Linux...blabla
    et tout de suite
    erreur : mémoire épuisée
    Loading initial ramdisk ...
    erreur : le noyau doit d'abord être chargé

    La ligne de commande de j'utilise actuellement :

    qemu-system-x86_64 \
    -enable-kvm \
    -bios /usr/share/ovmf/OVMF.fd \
    -rtc base=localtime \
    -m 128 \
    ^^^^^^
    Sans précision sur l'unité utilisée, ce devraient être des
    megaoctets.

    -name jessie-base \
    -boot menu=on \
    -drive format=raw,file=/dev/sdb

    Si vous avez une idée pour avancer je vous remercie par avance.

    L'initramfs doit être décompressé en mémoire lors du démarrage
    du système. Chez moi, il excède les 128Mio décompressé :

    $ unmkinitramfs /boot/initrd.img-6.6.15-amd64 initramfs
    $ du -sh initramfs
    168M initramfs

    Il faut également compter l'occupation du noyau en mémoire. En
    allouant 256M ou plus, la séquence de démarrage devrait pouvoir
    passer à la suite.

    En espérant que ça clarifie effectivment la situation,
    --
    Étienne Mollier <[email protected]>
    Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
    Sent from /dev/pts/4, please excuse my verbosity.
    On air: Riverside - The Place Where I Belong

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAmXXs8UACgkQeTz2fo8N EdpR+A//aNVXFKuceOEdj4lSPLIqAji0PdL6+5W0e+a+QTx0l58mnOGQ77tLDleL L/bSF/Vno5QMwNc7pM0lc+bERufBpftclu1qWY8AEOHtHiOtDW0Wyn+zM+BB+J3v oOd8+Is9wW2OyTelctGSc2QYcwO+lsYE+7Q3vr23WpndRs10xNttmuC+ZTUimLJt NIBLWTuylYqY/ytEpu6yRSYIEbLctk6KianFIp4B/olctCkDs2zt1H2YBaQbMHFX DM+rKiVhfxl/iKZJJ6+DLiy0XMAWrS6f3VtDYAplLwvVpSwU2kISIRLDyqb21Ilz rLlpwAGWbpgxxgdRPFROgjwsSthUAI27sCvVvqlSUKofWWQ+drG3qrIbD3Ajsc7E ekChLfacjMyx2djyEUiqZbhZzCCUokLVkX7V+i1UgxoXYSWdT89IT1aGd8lo9P3x AAGdeLVURM5ejGD1A0vO/pKMlUDk0tRRxn+5SC5QFYBoXAXHo7jW7vm1DtYdoCTA bX1TuRXGwM+dL8Ssv9WkT48Rym+aj/FmJQpLBxIa4tAYoGJ1U3mDtWJUTvj3U10h vrFBfcJ2OyFVs07HYnnur1mliVns56ZXF6qm1N7tThCaTCdUssa2WUfNBmPSsS5V Bps2ZZiZ5BG1npjIeROGbAsiZuONvk1m8icez7bdSylgZWGIzro=
  • From Jean Bernon@21:1/5 to All on Thu Feb 22 21:20:01 2024
    Si tu utilises Gnome, as-tu essayé gnome-boxes ?


    ----- Mail original -----

    De: "kaliderus" <[email protected]>
    À: "debian" <[email protected]>
    Envoyé: Jeudi 22 Février 2024 20:24:56
    Objet: qemu et lancer un system " reel "

    Bonjour la liste,

    J'ai changé de disque dur ssd récemment (je suis donc passé de "
    ancien disque " à " nouveau disque" ), et réinstallation de Debian
    sur
    le nouveau disque.

    Je voudrais avoir accès à l'ancien système, que j'ai mis dans un
    boîtier USB.

    Et je voudrais avoir accès à cet ancien système, en bootant à partir
    du nouveau via qemu (donc pas uniquement accès au système de
    fichiers).

    Petit détail : " ancien disque " est partitionné avec la partition d'initialisation accessible directement, les autres sont chiffrées.

    J'ai lu pas mal sur le sujet, la théorie me semble assez simple, mais
    la suite est un peu mystérieuse, même avec l'aide de quelques moteurs
    de recherche.

    J'ai bien accès au Grub, mais une fois passé cette étape le grub de " ancien système " me dit :
    Loading Linux...blabla
    et tout de suite
    erreur : mémoire épuisée
    Loading initial ramdisk ...
    erreur : le noyau doit d'abord être chargé

    La ligne de commande de j'utilise actuellement :

    qemu-system-x86_64 \
    -enable-kvm \
    -bios /usr/share/ovmf/OVMF.fd \
    -rtc base=localtime \
    -m 128 \
    -name jessie-base \
    -boot menu=on \
    -drive format=raw,file=/dev/sdb

    Si vous avez une idée pour avancer je vous remercie par avance.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From zithro@21:1/5 to kaliderus on Sat Mar 16 19:20:01 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)