[SOLVED ]Bullseye KVM/QEMU

[k829king]

I downloaded Bullseye Alpha3 iso (ran checksum aok) and tried to install into KVM/QEMU using virt-manager (choosing OS type as Debian testing) but it fails with

Code: Select all

Select and install software
installation step failed
An installation step failed. You can try to run the failing item again from the menu, or skip it and choose something else. The failing step is: Select and install software

I've written the same iso to a USB and have installed on same metal unit with a new additional drive without issue.
How can I check what the KVM/QEMU issue is?

[Head_on_a_Stick]

How can I check what the KVM/QEMU issue is?

Switch to TTY4 to see the actual error messages.

Is the VM connected to the internet?

[k829king]

Is the VM connected to the internet?

Yes

Switch to TTY4 to see the actual error messages.

Thank you! Tried to upload screenshot but got a "board quota has been met" message ...
so the I could see

Code: Select all

Jan 23 11:57:10 in-target:  qtspeech5-speechd-plugin:amd64
Jan 23 11:57:10 in-target:  llibqt5opengl5:amd64
Jan 23 11:57:10 in-target:  qt5-style-plugin-cleanlooks:amd64
Jan 23 11:57:10 in-target:  libqt5dbus5:amd64
Jan 23 11:57:10 in-target:  libreoffice-qt5
Jan 23 11:57:10 in-target:  lxqt-session
Jan 23 11:57:10 in-target:  xml-core
Jan 23 11:57:10 in-target: Processing was halted because there were too many errors.
Jan 23 11:57:10 kernel: [ 799.799778] ISO 9660 Extensions: Microsoft Joliet Level 3
Jan 23 11:57:10 kernel: [ 799.801071] ISO 9660 Extensions: RRIP_1991A

then multiple of these

Code: Select all

Jan 23 11:57:10 main-menu[468]: (process:29861): dpkg-divert: warning diverting file '/sbin/start-stop-daemon' from an Essential package with rename is dangerous, use --no-rename

and then

Code: Select all

Jan 23 11:57:10 main-menu[468]: (process:29861): cat: write error: No space left on device
Jan 23 11:57:10 main-menu[468]: WARNING ***: Configuring 'pkgsel' failed with error code 1
Jan 23 11:57:10 main-menu[468]: WARNING ***: menu item 'pkgsel' failed.


So I grew the qcow2 image form 20G to 40G and it installed aok. slightly bemused that after finalisation the amount of disk usage still seems minimal but it is now installed.

[CwF]

Holy overfed cows! The king prefers grass fed!

I have never started off a vm with more than 8.4GB! I ran through a bullseye install, a min cli only and a 'full' desktop that left 3 GB free?!
Of course deleted it since my pride is maintaining upgraded only...They have gigs free still after 2 generations of upgrades.
My i686 bullseye (was i386 Jessie) now sits at 5.9GB free! That one with XFCE 4.16 and FF-ESR is a 822MB cow! Its had all its shots! My almost done bullseye hypervisor sits at 1.6GB, fully built amd64's at 1.5GB. I guess I like it tight. I do have some fat ones, but they are expanded, not created fat.

[Head_on_a_Stick]

Yes, I always use a 10G disk image and I've never had a problem with the Debian installer.

I would hazard a guess that the OP gave the VM a large amount of RAM and just accepted the default partitioning so an equally large swap partition took up most of the image.

[CwF]

a large amount of RAM

Good point!
OP doesn't consider, I'd assume no swap, and we'd go in circles not recognizing that potential large variable!

I did notice the installer allowed no swap, was clear about root option, and had a non-free option built in...Very easy installer IMO.

I almost always limit 'allocated' RAM and set 'maximum' to 2 or 4x. On my mentioned install I did notice it did max out 2GB of ram a few times and rarely used both given cores. After I installed my preferred zramswap (got it that time p.H.) I noticed it calibrates off of 'maximum' RAM, that's the 2x or 4x amount and not the 'current'! Could be an issue! So my 2g vm had a 971MB swap! I wonder what the partitioner sees? 2 or 8GB in my case?

[k829king]

Thanks and yes, I was setting up this VM pre metal install and was looking to run some fairly hefty graphic and OCR functions so I gave it 32Gb...
So apologies for not thinking about consequences or mentioning it ....
I've not got my head around (or been able to spend much time contemplating) noswap or zramswap or other possibilities.

[CwF]

Read through some of these comments;
viewtopic.php?f=17&t=148615

pre metal install

I this means you are setting it up in a vm only to move it to a real machine, then you're on the right track!

As I was trying to point out in that other thread, the image can morph into anything you want and very few initial conditions are permanent, actually maybe NONE! So you do need to out think the installer in a few cases. I think you are figuring that out,

So I'll type it again, ALL images (installs and/or existing systems) should be able to be virtualized, some virtualized systems can be whatever you want...After a bit of that experience you can jump to making the image run on all hardware, or many examples maybe not all, but images can be loaded with the info for all machines it may run on - so on failure a backup machine can run it right away with zero mods.

I don't know, but I'm going to guess the installer will see 'maximum' ram and gauge it's decision on that and not the 'current allocation'.

[CwF]

Oh, I'll add..

If you have the ram to give a VM 32GB, the you have the ram to create/update/fix an image in ram without a disk storage footprint of any kind! For that trick keep the images partition size within the ram constraint. The image may have un-partitioned space beyond this, but if the active partition(s) is smaller it's safe.
So it's common for me to run a 120GB disk image with the 8.4GB active partition, initialized at maybe a few gigs may grow to slightly above 8.4GB when virtualized, This is why I've mention leaving all that wasted space - a system blows up for example with all that space used, but is partitioned, then you can pull out the extra partition to get back to a small OS image. Also, you can just pass the whole disk of a damaged system you'd like to temporarily virtualize.

So apposite of common sense, the hypervisor image itself can realistically be one of the smallest images you have!

Just thinking ahead...