Retour final pour ceux qui seraient confrontés aux mêmes embêtements : - passer l'utilisateur qui doit utiliser qemu dans le group " disk " pour accéder aux partitions racine - 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) - 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 - 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 ?) - 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) - Note : utiliser l'aide de -device pour voir tous les composants disponible (pas nécessairement super clairs) - les paramètres (proscrire -drive car stabilité non-garantie) -blockdev node-name=diskdebase,driver=raw,file.driver=host_device,file.filename=/dev/sdb \ -device virtio-blk,drive=diskdebase sont suffisants dans l'immédiat pour utiliser l'ancien système
ps : en investiguant un peu j'ai remarqué que AMI propose leur bios sous licence BSD-2, peut-être est-ce une autre solution ?
