Return to Level1Techs.com

The small linux problem thread

linux
helpdesk

#2184

My last problem with the upgrade to Fedora 29 is solved by the comments in this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1625674

Seems the dnf bash completion hanging is due to permissions on some gpg files for certain repos, and dnf not handling it elegantly.


#2185

So more of a query than a problem:

Running VMware Workstation on Fedora 29 as a host OS? Any major issues to report?

Currently running CentOS at work but the performance is much slower than my home machine with Fedora, software stack is older, i am seeing stability issues with the RX550 i just popped into it for basic video acceleration, etc. (which given the age of the kernel, i am not entirely surprised).

I’m considering switching to Fedora 29 at work, VM workstation is the only commercial product i need to work on the box - anyone running it care to comment on any issues they’ve observed? I could maybe switch to KVM, but i just find VM workstation’s virtual network support WAY better (and i have a test environment with a whole heap of pre-existing VMware VMs that i’d preferably like to keep).


#2186

Normally when you access a VFIO device as a normal user, you would get a permission denied, like so:

(qemu) qemu-system-x86_64: -device vfio-pci,sysfsdev=/sys/bus/pci/devices/0000:00:02.0/fff6f017-3417-4ad3-b05e-17ae3e1a4615,display=on,x-igd-opregion=on,romfile=vbios_gvt_uefi.rom: vfio error: fff6f017-3417-4ad3-b05e-17ae3e1a4615: failed to open /dev/vfio/17: Permission denied

I was wondering if there is a way to the mdev GVT-g device without needing to be root.

Edit: To be clear, this is for plain qemu, not libvirt. I am able to get it working fine for libvirt.

Edit2: Here are the commands if you want to look at it.

MY_OPTIONS="+pcid,+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check"

qemu-system-x86_64 -enable-kvm -m 3072 -cpu Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on,$MY_OPTIONS\
	  -machine pc-q35-2.11 \
	  -smp 4,cores=2 \
	  -usb -device usb-kbd -device usb-tablet \
	  -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \
	  -drive if=pflash,format=raw,readonly,file='OVMF_CODE.fd' \
	  -drive if=pflash,format=raw,file='OVMF_VARS-1024x768.fd' \
	  -smbios type=2 \
	  -device ide-drive,bus=ide.2,drive=Clover \
	  -drive id=Clover,if=none,snapshot=on,format=qcow2,file='/home/user/Documents/Virtual Machine/shared/harddrives/MacOS/uefi_mojave_clover.qcow2' \
	  -device ide-drive,bus=ide.1,drive=MacHDD \
	  -drive id=MacHDD,if=none,file='/home/user/Documents/Virtual Machine/shared/harddrives/MacOS/uefi-mojave.qcow2',format=qcow2 \
	  -vga none \
	  -device vfio-pci,sysfsdev='/sys/bus/pci/devices/0000:00:02.0/fff6f017-3417-4ad3-b05e-17ae3e1a4615',display=on,x-igd-opregion=on,romfile='vbios_gvt_uefi.rom' \
	  -monitor stdio

#2187

Have you tried adding your user to the libvirt group?


#2188

I realized that I should have been more clear, I am using a plain qemu script to pull this off, not libvirt. Sorry about that!

With that being said I did try your suggestion, but I still got the same error.


#2189

There is also a qemu group, did you try that?


#2190

I added qemu to myself but it still doesn’t seem to work:

$ ./boot-macOS-Mojave.sh 
QEMU 3.0.0 monitor - type 'help' for more information
(qemu) qemu-system-x86_64: -device vfio-pci,sysfsdev=/sys/bus/pci/devices/0000:00:02.0/fff6f017-3417-4ad3-b05e-17ae3e1a4615,display=on,x-igd-opregion=on,romfile=vbios_gvt_uefi.rom: vfio error: fff6f017-3417-4ad3-b05e-17ae3e1a4615: failed to open /dev/vfio/17: Permission denied

I can verify that I am part of the group:

$ groups user
user : user wheel qemu libvirt

#2191

Are any of these suggestions helpful?


#2192

Quick couple of questions, I have separate partitions for /var & /tmp, If I unmount them and remove them from fstab will the OS use space on /root in their absence after reboot?

I also have /swap that I need to move, can I use swapoff and boot without swap until I finish rearranging the disk?

This will be temporary until I wipe and re-partition the disk they are currently on.

Thanks


#2193

Yep.

OS will use space on / as soon as you unmount them.

You’ll want to copy the contents of the /var partition to your /var dir on the root partition though. Lots of applications rely on data in /var.

yep. swapoff and remove it from fstab, just the same.


#2194

Excellent, thank you.

Hmm, I didn’t think of that, I thought /var was kind of similar to /tmp and used when doing updates and such. I’ll make sure to copy it and copy it back when I re-create the /var partition later.


#2195

Not at all. There is important data in there.