KVM problem to start virtual machines

I am also having the same problem and also have multiple vm's running on current state Ubuntu, or Deb distro's. This is limited to Garuda and the patch process on or about Sept 26th. No fix found to date but both old (existing vms) and new fail to run. You can create but nothing will run from the GUI or CLI.

While I 100% understand that working on a rolling distro has its challenges I have not seen something break like this via update and take this long to work into the support threads and get addressed. This is an issue with Garuda and needs to be worked out within the community even if someone who starts the process bails out.

How can you possibly make such a statement with any degree of certainty. This is pure speculation on your part. Always remember, whenever you point the finger at someone else, there's three fingers pointing back at you. Have you even checked the bug trackers on the related upstream projects (and Arch itself)? Have you tested numerous other kernels including linux-mainline and linux-next=git? Have you reported fully on your attempted fixes (as detailed in the help request template)? We are simply left guessing as to which fixes you have attempted. The required information you have provided is woefully inadequate. In addition your expectations of entitlement are way out of line for a free distro with a small dev team and an equally small group of forum support volunteers.

Neither of you have provided your system specs with an inxi -Faz output as requested multiple times. This is also explicitly spelled out as a requirement for help requests in the help request template. The help request template also explains explicitly that:

Without it, you will not receive any help from the Garuda team or your topic is likely to be closed without notice.

You ignore all the expectations on our forum, yet you expect the Garuda devs to come running to your rescue for software that has nothing to do with Garuda. Virtualization technologies are not our responsibility to maintain or bugfix. You should determine if this is a problem with your related virtualization packages by downgrading all their components to see if this corrects your issue. If the quemu or other related updates are at fault, then it is your responsibility to report this on the relevant projects upstream bug tracker.

Garuda expects users to perform their due diligence, and your performance has fallen far short in that department. Learn to do for yourselves before you expect others to do for you.

Sorry to be so blunt, but you need to put on your big boy boots and start doing more digging. There are posts out there on other forums similar to the errors you have received. Perhaps with a little more effort you can turn up something that may help.

2 Likes

The point I am making is the update broke a functional component of the distro you are maintaining. I am not assigning any blame its an observation of the painfully obvious. The issue very much appears to be reproducable across multiple systems all running Garuda, all failing with the same error after an update.

I am not asking for anyone to run, nor for you to fix it, simply saying that to close the ticket seems like the exact opposite of what is needed.

Its broke on your distro over more then one PC running in more then one environment. If you would like to engage to address let me know. If you simply want to stand on your soap box have at it.

1 Like

I already did address finding a solution:

Check your pacman log for the list of upgraded packages when the breakage occurred.

Downgrade all packages affecting virtualization selectively one at a time.

BTW one more post without an inxi -Faz and the thread will be locked.

The forum is not a one way street. You expect assistance, yet you do not provide requested outputs or requested information, and refuse to answer any questions put to you.

Have you performed the step I suggested to identify the cause?

So to sum things up @ atkatana:

No requested outputs provided.
No requests for information supplied.
No answers to any questions put to you.
No feedback to suggested solutions provided.

By demonstrating this type of behavior you come off as simply trolling our forum. If you actually want assistance you have a very funny way of showing it. Keep this lack of cooperation up with forum assistants and you will be burning your bridges here pretty soon with no one to blame but yourself.

3 Likes

If you chose to dual/multi-boot, that's all on you. Garuda does not support it, as stated in multi-places.

1 Like

Not a troll just found the thread after you had closed it.

Not a dual boot or multi-boot system.

Output pasted below as this is the first request I have seen so it is the first time I can respond.

System:
  Kernel: 5.14.9-zen2-1-zen x86_64 bits: 64 compiler: gcc v: 11.1.0
  parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
  root=UUID=78efd0c8-0b1e-4f14-aea1-c5b26ccc73e8 rw [email protected] quiet
  splash rd.udev.log_priority=3 vt.global_cursor_default=0
  systemd.unified_cgroup_hierarchy=1 loglevel=3
  Console: tty pts/1 DM: SDDM Distro: Garuda Linux base: Arch Linux
Machine:
  Type: Desktop System: Hewlett-Packard product: HP Z640 Workstation v: N/A
  serial: <filter> Chassis: type: 6 serial: <filter>
  Mobo: Hewlett-Packard model: 212A v: 1.01 serial: <filter>
  UEFI: Hewlett-Packard v: M60 v02.56 date: 11/04/2020
Battery:
  Device-1: hidpp_battery_0 model: Logitech K350 serial: <filter>
  charge: 50% (should be ignored) rechargeable: yes status: N/A
CPU:
  Info: 2x 12-Core model: Intel Xeon E5-2690 v3 bits: 64 type: MT MCP SMP
  arch: Haswell family: 6 model-id: 3F (63) stepping: 2 microcode: 46 cache:
  L2: 60 MiB
  flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  bogomips: 249210
  Speed: 1198 MHz min/max: 1200/3500 MHz Core speeds (MHz): 1: 1198 2: 1640
  3: 2910 4: 2047 5: 2120 6: 3394 7: 2194 8: 3375 9: 2242 10: 1555 11: 1198
  12: 2805 13: 1378 14: 2233 15: 2191 16: 1197 17: 1738 18: 1602 19: 2348
  20: 2154 21: 2275 22: 2264 23: 2515 24: 1474 25: 2358 26: 1568 27: 3023
  28: 1854 29: 1761 30: 2020 31: 3418 32: 3176 33: 3189 34: 1343 35: 1757
  36: 3496 37: 2270 38: 1576 39: 2567 40: 1505 41: 3490 42: 2292 43: 1852
  44: 1198 45: 1198 46: 2576 47: 1196 48: 2227
  Vulnerabilities: Type: itlb_multihit status: KVM: VMX disabled
  Type: l1tf
  mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
  Type: mds mitigation: Clear CPU buffers; SMT vulnerable
  Type: meltdown mitigation: PTI
  Type: spec_store_bypass
  mitigation: Speculative Store Bypass disabled via prctl and seccomp
  Type: spectre_v1
  mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional,
  IBRS_FW, STIBP: conditional, RSB filling
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: NVIDIA GK110GL [Quadro K5200] driver: nvidia v: 470.74
  alternate: nouveau,nvidia_drm bus-ID: 04:00.0 chip-ID: 10de:103c
  class-ID: 0300
  Display: server: X.org 1.20.13 compositor: kwin_x11 driver: loaded: nvidia
  tty: 80x24
  Message: Advanced graphics data unavailable in console. Try -G --display
Audio:
  Device-1: Intel C610/X99 series HD Audio vendor: Hewlett-Packard
  driver: snd_hda_intel v: kernel bus-ID: 00:1b.0 chip-ID: 8086:8d20
  class-ID: 0403
  Device-2: NVIDIA GK110 High Definition Audio driver: snd_hda_intel
  v: kernel bus-ID: 04:00.1 chip-ID: 10de:0e1a class-ID: 0403
  Device-3: JMTek LLC. TKGOU PnP USB Microphone type: USB
  driver: hid-generic,snd-usb-audio,usbhid bus-ID: 3-5.4:6
  chip-ID: 0c76:1467 class-ID: 0300 serial: <filter>
  Device-4: Texas Instruments PCM2704C stereo audio DAC type: USB
  driver: hid-generic,snd-usb-audio,usbhid bus-ID: 3-6:3 chip-ID: 08bb:27c4
  class-ID: 0300
  Sound Server-1: ALSA v: k5.14.9-zen2-1-zen running: yes
  Sound Server-2: JACK v: 1.9.19 running: no
  Sound Server-3: PulseAudio v: 15.0 running: no
  Sound Server-4: PipeWire v: 0.3.38 running: yes
Network:
  Device-1: Intel Ethernet I218-LM vendor: Hewlett-Packard driver: e1000e
  v: kernel port: 3040 bus-ID: 00:19.0 chip-ID: 8086:15a0 class-ID: 0200
  IF: eno1 state: up speed: 1000 Mbps duplex: full mac: <filter>
  Device-2: Intel Ethernet 10-Gigabit X540-AT2
  vendor: Hewlett-Packard 10Gb 2-port 561T driver: ixgbe v: kernel
  port: 3000 bus-ID: 01:00.0 chip-ID: 8086:1528 class-ID: 0200
  IF: ens4f0 state: up speed: 10000 Mbps duplex: full mac: <filter>
  Device-3: Intel Ethernet 10-Gigabit X540-AT2
  vendor: Hewlett-Packard 10Gb 2-port 561T driver: ixgbe v: kernel
  port: 3000 bus-ID: 01:00.1 chip-ID: 8086:1528 class-ID: 0200
  IF: ens4f1 state: down mac: <filter>
Bluetooth:
  Device-1: ASUSTek ASUS USB-BT500 type: USB driver: btusb v: 0.8
  bus-ID: 3-11.4:11 chip-ID: 0b05:190e class-ID: e001 serial: <filter>
  Report: bt-adapter ID: hci0 rfk-id: 0 state: up address: <filter>
RAID:
  Hardware-1: Intel C610/X99 series sSATA Controller [RAID mode]
  driver: ahci v: 3.0 port: 3060 bus-ID: 00:11.4 chip-ID: 8086.2827 rev: 05
  class-ID: 0104
  Hardware-2: Intel C600/X79 series SATA RAID Controller driver: ahci v: 3.0
  port: 3020 bus-ID: 00:1f.2 chip-ID: 8086.2826 rev: 05 class-ID: 0104
Drives:
  Local Storage: total: 3.87 TiB used: 1.21 TiB (31.4%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Samsung
  model: SSD 970 EVO Plus 500GB size: 465.76 GiB block-size: physical: 512 B
  logical: 512 B speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter>
  rev: 2B2QEXM7 temp: 47.9 C scheme: GPT
  ID-2: /dev/sda maj-min: 8:0 vendor: Hitachi model: HUA723030ALA641
  size: 2.73 TiB block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s
  type: HDD rpm: 7200 serial: <filter> rev: A840 scheme: GPT
  SMART Message: Unknown smartctl error. Unable to generate data.
  ID-3: /dev/sdb maj-min: 8:16 vendor: Samsung model: SSD 840 EVO 750GB
  size: 698.64 GiB block-size: physical: 512 B logical: 512 B
  speed: 6.0 Gb/s type: SSD serial: <filter> rev: BB6Q scheme: GPT
  SMART Message: Unknown smartctl error. Unable to generate data.
Partition:
  ID-1: / raw-size: 465.51 GiB size: 465.51 GiB (100.00%)
  used: 100.15 GiB (21.5%) fs: btrfs block-size: 4096 B dev: /dev/nvme0n1p2
  maj-min: 259:2
  ID-2: /boot/efi raw-size: 256 MiB size: 252 MiB (98.46%)
  used: 554 KiB (0.2%) fs: vfat block-size: 512 B dev: /dev/nvme0n1p1
  maj-min: 259:1
Swap:
  Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: zram size: 62.81 GiB used: 30.8 MiB (0.0%)
  priority: 100 dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 35.0 C mobo: N/A gpu: nvidia temp: 50 C
  Fan Speeds (RPM): N/A gpu: nvidia fan: 31%
Info:
  Processes: 705 Uptime: 1d 2h 55m wakeups: 13 Memory: 62.81 GiB
  used: 10.48 GiB (16.7%) Init: systemd v: 249 tool: systemctl Compilers:
  gcc: 11.1.0 clang: 12.0.1 Packages: pacman: 1680 lib: 386 Shell: fish
  v: 3.3.1 running-in: tty pts/1 (SSH) inxi: 3.3.06

If you actually ask I am happy to assist.

Thank you for posting your inxi output @atkatana.

Perhaps to you it seems I'm going out of my way to be a dick, but you are making this an excercize in frustration for forum assistants. You still have not answered any of the questions I put to you.

If you really want to make progress on this issue you need to sift your pacman log for the list of which updates broke your virtualized environments. As you more or less know the date this happened, it hopefully won't be too hard to narrow down the package(s) responsible for the breakage.

Please post the list of package updates that took place when your breakage occurred.

You can then start selectively downgrading any packages related to virtualization. You are the one that needs to put in the work if you wish to see a resolution to this issue. I only ever install systems to bare metal, so I can not troubleshoot this problem for you. You will likely need to do the detective work required if you expect progress to be made with this issue.


To the OP:

You have still not provided an inxi -Faz output. Perhaps there is a commonality between your systems that can be identified as a factor with this information. I have read posts on the Arch forum where specific hardware was the cause of virtualization breakages in the past. We can't possibly determine if hardware could be a factor without your hardware specs.


I have asked several times now:

Neither of you have seen fit to answer to this query. You seriously can't expect us to help find a solution if we need to keep guessing at everything. Getting answers from both of you is akin to pulling teeth.

I ask again:

Have you tested numerous other kernels including linux-mainline and linux-next-git?

Please start responding to questions put to you if you wish to receive assistance.

1 Like

I have not to date tried any kernel updates, role backs etc. In my experience so far if something I have not touched breaks it will generally resolve via the patch process. I had a GRUB issue that had to be fixed and a couple of file system issues that were self inflicted so in general I try to support the patch/update process. My VM's are not in general critical on a day to day, but they are needed at times and there is data or work effort on those vms so I need to get this resolved to support my work.

I do know the date range ~25-9-21 to 27-9-21 and will go get the logs and post them. I do understand the process and want to support getting this fixed for all.

Some other options for you to consider/test:

Go through your BIOS settings to see if there are any settings that affect virtualization that can be changed.

Check if your BIOS has an update available.

There is another option rather than downgrading all packages related to virtualization that were upgraded at the breakage. Look to see if the affected packages have a newer developmental git version that can be installed in preference to downgrading.

1 Like

Ok so the most likely transactions that I can find are the linux kernel and the linux firmware. Both update on 27-9-21. The only other transaction that day that would be in the mix is the linux-zen kernel and the linux-zen headers. All the kernels go from 5.14.7 to 5.14.8

Nothing else in the mix looks like it would have anyhitng to do with KVM, Virtualization ect. The update to openssh for instance is not imho likely to be a problem here.

On the BIOS question I am up to date with HP BIOS for the box. The VTx settings are more or less on/off and are set to on. No other updates or changes have been made to the system or BIOS and as noted to date I have not changed the Kernel or any other external settings.

Do you have virt-manager-meta installed? :eyes:

1 Like

virt-manager-meta v5.1 is installed

I've been experiencing the exact same issues for about a week or so (I hadn't tried to start any VMs for about 2 weeks before that).

This does coincide with the release of libvirt 7.8.0, I did see somewhere on their mailing lists about improvements when cleaning up cgroups on shutdown. But tbh I definitely don't know enough about cgroups (let alone how libvirt wants/needs to manage them).

I tried downgrading libvirt to 7.7.0, as its the only thing I can see that has had updates in the last few weeks.
But that didn't change anything.

I installed the git versions of the following:

yay -S virtkvm-git libvirt-git qemu-arch-extra-git

Also didn't really fix anything:

virsh # start win10 
error: Failed to start domain 'win10'
error: Unable to read from '/sys/fs/cgroup/machine.slice/machine-qemu\x2d5\x2dwin10.scope/libvirt/cgroup.controllers': No such file or directory

It should be noted that I usually run the xanmod kernel, but switched to mainline to test and do the git and previous version installs. So no difference as far as I can tell there.

inxi -Fax :point_down:

System:    Kernel: 5.10.72-1-lts x86_64 bits: 64 compiler: gcc v: 11.1.0 
           parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-lts root=UUID=8c7d91ae-0b18-49bd-8870-4486aa0989d2 rw 
           [email protected] quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0 
           systemd.unified_cgroup_hierarchy=1 resume=UUID=536234d6-6610-4a6d-a58d-1c4fdcb7fc90 loglevel=3 
           Desktop: GNOME 40.5 tk: GTK 3.24.30 wm: gnome-shell dm: GDM 40.1 Distro: Garuda Linux base: Arch Linux 
Machine:   Type: Desktop Mobo: ASUSTeK model: SABERTOOTH Z170 S v: Rev 1.xx serial: <filter> UEFI: American Megatrends v: 3801 
           date: 03/14/2018 
Battery:   Device-1: hidpp_battery_0 model: Logitech Wireless Mouse MX Master 2S serial: <filter> 
           charge: 55% (should be ignored) rechargeable: yes status: Discharging 
CPU:       Info: Quad Core model: Intel Core i7-6700K bits: 64 type: MT MCP arch: Skylake-S family: 6 model-id: 5E (94) 
           stepping: 3 microcode: EA cache: L2: 8 MiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 63999 
           Speed: 4109 MHz min/max: 800/4200 MHz Core speeds (MHz): 1: 4109 2: 4086 3: 4001 4: 4056 5: 4110 6: 4125 7: 4001 
           8: 4155 
           Vulnerabilities: Type: itlb_multihit status: KVM: VMX disabled 
           Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable 
           Type: mds mitigation: Clear CPU buffers; SMT vulnerable 
           Type: meltdown mitigation: PTI 
           Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling 
           Type: srbds mitigation: Microcode 
           Type: tsx_async_abort mitigation: Clear CPU buffers; SMT vulnerable 
Graphics:  Device-1: NVIDIA GP104 [GeForce GTX 1070] vendor: Micro-Star MSI driver: nvidia v: 470.74 
           alternate: nouveau,nvidia_drm bus-ID: 01:00.0 chip-ID: 10de:1b81 class-ID: 0300 
           Device-2: Microsoft LifeCam Cinema type: USB driver: snd-usb-audio,uvcvideo bus-ID: 1-10:6 chip-ID: 045e:075d 
           class-ID: 0102 
           Display: x11 server: X.Org 1.20.13 compositor: gnome-shell driver: loaded: nvidia display-ID: :1 screens: 1 
           Screen-1: 0 s-res: 3840x2160 s-dpi: 96 s-size: 1016x572mm (40.0x22.5") s-diag: 1166mm (45.9") 
           Monitor-1: DP-0 res: 3840x2160 hz: 60 dpi: 140 size: 697x392mm (27.4x15.4") diag: 800mm (31.5") 
           OpenGL: renderer: NVIDIA GeForce GTX 1070/PCIe/SSE2 v: 4.6.0 NVIDIA 470.74 direct render: Yes 
Audio:     Device-1: Intel 100 Series/C230 Series Family HD Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel 
           bus-ID: 00:1f.3 chip-ID: 8086:a170 class-ID: 0403 
           Device-2: NVIDIA GP104 High Definition Audio vendor: Micro-Star MSI driver: snd_hda_intel v: kernel bus-ID: 01:00.1 
           chip-ID: 10de:10f0 class-ID: 0403 
           Device-3: Microsoft LifeCam Cinema type: USB driver: snd-usb-audio,uvcvideo bus-ID: 1-10:6 chip-ID: 045e:075d 
           class-ID: 0102 
           Device-4: C-Media Im Fulla Schiit type: USB driver: hid-generic,snd-usb-audio,usbhid bus-ID: 1-6:2 
           chip-ID: 0d8c:1066 class-ID: 0300 
           Sound Server-1: ALSA v: k5.10.72-1-lts running: yes 
           Sound Server-2: JACK v: 1.9.19 running: no 
           Sound Server-3: PulseAudio v: 15.0 running: no 
           Sound Server-4: PipeWire v: 0.3.38 running: yes 
Network:   Device-1: Intel Ethernet I219-V vendor: ASUSTeK driver: e1000e v: kernel port: f000 bus-ID: 00:1f.6 
           chip-ID: 8086:15b8 class-ID: 0200 
           IF: enp0s31f6 state: down mac: <filter> 
           Device-2: Broadcom BCM4360 802.11ac Wireless Network Adapter vendor: ASUSTeK driver: wl v: kernel modules: bcma 
           port: e000 bus-ID: 02:00.0 chip-ID: 14e4:43a0 class-ID: 0280 
           IF: wlp2s0 state: up mac: <filter> 
           IF-ID-1: virbr0 state: down mac: <filter> 
Drives:    Local Storage: total: 3.85 TiB used: 186.48 GiB (4.7%) 
           SMART Message: Required tool smartctl not installed. Check --recommends 
           ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Seagate model: BarraCuda 510 SSD ZP512CM30011 size: 476.94 GiB 
           block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter> rev: STCS1024 
           temp: 33.9 C scheme: GPT 
           ID-2: /dev/sda maj-min: 8:0 vendor: Crucial model: CT480BX500SSD1 size: 447.13 GiB block-size: physical: 512 B 
           logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> rev: R013 scheme: GPT 
           ID-3: /dev/sdb maj-min: 8:16 vendor: Western Digital model: WD30EFRX-68EUZN0 size: 2.73 TiB block-size: 
           physical: 4096 B logical: 512 B speed: 6.0 Gb/s type: HDD rpm: 5400 serial: <filter> rev: 0A82 scheme: GPT 
           ID-4: /dev/sdc maj-min: 8:32 vendor: Crucial model: CT240M500SSD1 size: 223.57 GiB block-size: physical: 4096 B 
           logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> rev: MU05 
Partition: ID-1: / raw-size: 459.56 GiB size: 459.56 GiB (100.00%) used: 186.47 GiB (40.6%) fs: btrfs dev: /dev/nvme0n1p2 
           maj-min: 259:2 
           ID-2: /boot/efi raw-size: 260 MiB size: 256 MiB (98.46%) used: 562 KiB (0.2%) fs: vfat dev: /dev/nvme0n1p1 
           maj-min: 259:1 
           ID-3: /home raw-size: 459.56 GiB size: 459.56 GiB (100.00%) used: 186.47 GiB (40.6%) fs: btrfs dev: /dev/nvme0n1p2 
           maj-min: 259:2 
           ID-4: /var/log raw-size: 459.56 GiB size: 459.56 GiB (100.00%) used: 186.47 GiB (40.6%) fs: btrfs 
           dev: /dev/nvme0n1p2 maj-min: 259:2 
           ID-5: /var/tmp raw-size: 459.56 GiB size: 459.56 GiB (100.00%) used: 186.47 GiB (40.6%) fs: btrfs 
           dev: /dev/nvme0n1p2 maj-min: 259:2 
Swap:      Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default) 
           ID-1: swap-1 type: partition size: 17.12 GiB used: 0 KiB (0.0%) priority: -2 dev: /dev/nvme0n1p3 maj-min: 259:3 
           ID-2: swap-2 type: zram size: 15.57 GiB used: 0 KiB (0.0%) priority: 100 dev: /dev/zram0 
Sensors:   System Temperatures: cpu: 31.0 C mobo: N/A gpu: nvidia temp: 51 C 
           Fan Speeds (RPM): N/A gpu: nvidia fan: 0% 
Info:      Processes: 304 Uptime: 36m wakeups: 2 Memory: 15.57 GiB used: 4.12 GiB (26.5%) Init: systemd v: 249 tool: systemctl 
           Compilers: gcc: 11.1.0 Packages: pacman: 1577 lib: 383 Shell: Zsh v: 5.8 running-in: tilix inxi: 3.3.06
2 Likes

Very useful information @stuartc .

Thank you for posting your findings and welcome to the forum.

1 Like

This thread is 6 months old and is probably totally unrelated:

However, it does have some ideas not proposed before. One is to add this line to the kernel boot parameters:

systemd.unified_cgroup_hierarchy=0

Then:

grub-mkconfig -o /boot/grub/grub.cfg

or:

update-grub

Then reboot.

The Garuda default is:

systemd.unified_cgroup_hierarchy=1

Just thought I'd mention this post as it was preventing the startup of the VM's. VM's are not my thing, so I'm just throwing this out there on the remote chance it might help. I guess it could be a possibility that something recently has become incompatible with the change to cgroup v2.

https://wiki.archlinux.org/title/cgroups

Edit:

My suggestion to change to the cgroups load line GRUB_CMDLINE_LINUX_DEFAULT= in /etc/default/grub did solve a freezing issue when running VM's for a user just now. So, it may very well be worth a try.

8 Likes

That solved it! I also saw this same recommendation elsewhere, but I assumed that Garuda and many others default to the new unified cgroups stuff - perhaps it's less common than I thought?

The there is also a compile flag I see mentioned here on the gentoo bug tracker: 691310 – sys-apps/systemd-243_rc1: libvirtd-lxc (and others) breaks because legacy cgroupv1 hierarchy is unavailable.

I don't fully understand what the difference between hybrid and unified, and given these kinds of tidbits of info are mostly like 3-4 years old - again assuming :sweat_smile: - that it wouldn't be an issue today.

Do you know when the systemd.unified_cgroup_hierarchy=1 was introduced.

Oh btw, I rolled back to the standard/current libvirt-7.8.0-1 and also testing on xanmod 5.14.10 (also 5.10 mainline), all works. Thanks again.

1 Like

Damn @tbg, great find :partying_face:

5 Likes

Ubuntu is/was one of the last holdouts to switch to cgroups version 2. I read a post from this Aug saying that they were just about to switch. They were apparently waiting until they had full compatibility with snaps before switching. Most distros are using version 2 now I believe.

Garuda has been using it for quite some time, a dev would know the exact date of implementation.

Glad to hear that fixed some of you with this issue up.

2 Likes

Confirmed this will solve the problem with VM's not booting. I would point out that for those that want or need the help, the setting can be found in the Garuda assistant under boot options. There you can edit the value of systemd.unified_cgroup_hierarchy=1 (i.e. change it to 0 and save)

I would then uncheck the cgroup v2 compatibility option on the same page. Save all changed, and reboot.

There is no need to use the UI, but given this is one of the best looking distro out there for those that use the GUI you have the option to address quickly .

Thanks to all .... always good to find a solution that helps everyone

4 Likes

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.