summary refs log tree commit diff stats
path: root/results/classifier/108/debug/1018530
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-07-03 19:39:53 +0200
committerChristian Krinitsin <mail@krinitsin.com>2025-07-03 19:39:53 +0200
commitdee4dcba78baf712cab403d47d9db319ab7f95d6 (patch)
tree418478faf06786701a56268672f73d6b0b4eb239 /results/classifier/108/debug/1018530
parent4d9e26c0333abd39bdbd039dcdb30ed429c475ba (diff)
downloademulator-bug-study-dee4dcba78baf712cab403d47d9db319ab7f95d6.tar.gz
emulator-bug-study-dee4dcba78baf712cab403d47d9db319ab7f95d6.zip
restructure results
Diffstat (limited to 'results/classifier/108/debug/1018530')
-rw-r--r--results/classifier/108/debug/1018530123
1 files changed, 0 insertions, 123 deletions
diff --git a/results/classifier/108/debug/1018530 b/results/classifier/108/debug/1018530
deleted file mode 100644
index b35c774b..00000000
--- a/results/classifier/108/debug/1018530
+++ /dev/null
@@ -1,123 +0,0 @@
-debug: 0.956
-permissions: 0.945
-other: 0.945
-device: 0.936
-boot: 0.933
-PID: 0.931
-network: 0.926
-socket: 0.925
-performance: 0.919
-semantic: 0.918
-files: 0.914
-KVM: 0.912
-graphic: 0.908
-vnc: 0.871
-
-No write access in a 9p/virtfs shared folder
-
-Ubuntu version:  Ubuntu 12.04 LTS
-Kernel: 3.2.0-25-generic
-Version of qemu-kvm: 1.0+noroms-0ubuntu13
-
-I have created an shared folder for an virtual machine which is managed by libvirt.
-
-<filesystem type='mount' accessmode='passthrough'>
-<source dir='/storage/data'/>
-<target dir='data'/>
-<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
-</filesystem>
-
-I mounted it in the virtual machine with this command:  mount -t 9p -o trans=virtio,version=9p2000.L data /data
-The filesystem permissions of all files an folders in the shared folder are set to 777. I expected that I have the full permissions also in the virtual machine.
-
-Regardless of the permissions on the filesystem I cannot write or create files and folders in the virtual machine. The original filesystem (/storage) is XFS.
-In another shared folder (similar config in libvirt) which is originally NTFS I have no problems.
-
-ProblemType: Bug
-DistroRelease: Ubuntu 12.04
-Package: qemu-kvm 1.0+noroms-0ubuntu13
-ProcVersionSignature: Ubuntu 3.2.0-25.40-generic 3.2.18
-Uname: Linux 3.2.0-25-generic x86_64
-ApportVersion: 2.0.1-0ubuntu8
-Architecture: amd64
-Date: Wed Jun 27 20:15:20 2012
-InstallationMedia: Ubuntu-Server 12.04 LTS "Precise Pangolin" - Beta amd64 (20120409)
-MachineType: To be filled by O.E.M. To be filled by O.E.M.
-ProcEnviron:
- TERM=xterm
- LANG=de_DE.UTF-8
- SHELL=/bin/bash
-ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.2.0-25-generic root=/dev/mapper/system-root ro
-SourcePackage: qemu-kvm
-UpgradeStatus: No upgrade log present (probably fresh install)
-dmi.bios.date: 04/18/2012
-dmi.bios.vendor: American Megatrends Inc.
-dmi.bios.version: 1208
-dmi.board.asset.tag: To be filled by O.E.M.
-dmi.board.name: M5A99X EVO
-dmi.board.vendor: ASUSTeK COMPUTER INC.
-dmi.board.version: Rev 1.xx
-dmi.chassis.asset.tag: To Be Filled By O.E.M.
-dmi.chassis.type: 3
-dmi.chassis.vendor: To Be Filled By O.E.M.
-dmi.chassis.version: To Be Filled By O.E.M.
-dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1208:bd04/18/2012:svnTobefilledbyO.E.M.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnASUSTeKCOMPUTERINC.:rnM5A99XEVO:rvrRev1.xx:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
-dmi.product.name: To be filled by O.E.M.
-dmi.product.version: To be filled by O.E.M.
-dmi.sys.vendor: To be filled by O.E.M.
-
-
-
-Thanks for reporting this bug.  Could you check your /var/log/syslog for apparmor messages relating to libvirt accessing /data?  The command
-
-   sudo grep DENIED /var/log/syslog | grep libvirt
-
-should return interesting results.
-
-No, there are no results relating /data. I would have wondered about it, because I already configured apparmor to allow access to /data. The current rules in the profile of the virtual machine are
-  "/storage/data/" rw,
-  "/storage/data/**" rw,
-
-I also disabled the apparmor profile but it didn't help either.
-
-I can confirm this does not work in precise, however it looks like creating files (and directories etc) was not implemented in qemu-kvm 1.0.  File creation was added with commit daf0b9aca9f67323266af1a92e8ea06f9d7bf408 .
-
-This should work in quantal - if it does not, then that is a new bug.  However adding a new feature in an SRU (especially to LTS) would be hard to justify.
-
-
-No, commit  daf0b9aca9f67323266af1a92e8ea06f9d7bf408 added create support proxy FS driver model. Local FS had support for creating files much before.
-
-Georg, is qemu running with root user privileges?
-
-qemu is running with user libvirt-qemu, not root.
-
-Quoting M. Mohan Kumar (<email address hidden>):
-> No, commit  daf0b9aca9f67323266af1a92e8ea06f9d7bf408 added create
-> support proxy FS driver model. Local FS had support for creating files
-> much before.
-
-Yes, but that commit is not in v1.0 (according to qemu-kvm git
-history at least)
-
-
-Georg,
-
-pass-through security model needs root privilege, if you want to run qemu as non-root user either you have to use mapped security model or proxy fs driver. But libvirt does not have support for proxy FS driver. I posted a patch few months ago to libvirt for enabling the same. I will do the followup with libvirt list to enable proxy FS in libvirt.
-
-So could you please try mapped security model or run  qemu as root user and update the results?
-
-Okay, it is working now. I am using the mapped security model but I wanted to avoid it at first.
-I hope proxy FS will be supported in quantal.
-
-But I am still wondering why passthrough security is working smoothly with NTFS-3G.
-
-With passthrough security model creation files in guest still doesn't work in Raring. 
-
-QEMU version is 1.4.0,
-AppArmor folder rules added to libvirt profile of tested VM,
-Permissions on testing folder is 777.
-
-Please file a new bug using 'ubuntu-bug libvirt-bin', providing details on the setup and how it is failing.
-
-Sounds like this was an Ubuntu- or libvirt-specific bug ... so closing this in the upstream QEMU bug tracker.
-