On Wed, Aug 16, 2017 at 11:44 AM, ChristianEhrhardt
<email address hidden> wrote:
> On Wed, Aug 16, 2017 at 6:48 PM, dann frazier <email address hidden>
> wrote:
>
>> I confirmed that adding these lines to the libvirt profile allows me to
>> start the guest (I assume the first two are already covered by the other
>> bug).
>>
>> "/home/ubuntu/vm-start-stop/vms/7936-0.img" rwk,
>> "/home/ubuntu/vm-start-stop/zesty-server-cloudimg-arm64.img" rk,
>>
>
> Those are the two already fixed in latest libvirt, thanks for checking.
>
>
>> "/home/ubuntu/vm-start-stop/vms/7936-0_CODE.fd" rk,
>> "/home/ubuntu/vm-start-stop/vms/7936-0_VARS.fd" rk,
>>
>
> Those two are the new ones - thanks.
> With that I can dev a patch tmrw that fixes that.
Great!
> One thing thou - you added the k to both.
> But the Denies were only about the _CODE.
> Would with only one getting the k permission the other one be the one
> failing?
Correct. I tried adding 'k' only to _CODE, but subsequent start
attempts started reporting errors with _VARS:
ubuntu@grotrian:~$ sudo virsh start 7936-0
error: Failed to start domain 7936-0
error: internal error: process exited while connecting to monitor:
2017-08-16T16:44:36.708278Z qemu-system-aarch64: -drive
file=/home/ubuntu/vm-start-stop/vms/7936-0_VARS.fd,if=pflash,format=raw,unit=1:
Failed to unlock byte 100
2017-08-16T16:44:36.708431Z qemu-system-aarch64: -drive
file=/home/ubuntu/vm-start-stop/vms/7936-0_VARS.fd,if=pflash,format=raw,unit=1:
Failed to unlock byte 100
2017-08-16T16:44:36.708662Z qemu-system-aarch64: -drive
file=/home/ubuntu/vm-start-stop/vms/7936-0_VARS.fd,if=pflash,format=raw,unit=1:
Failed to lock byte 100
I gather QEMU only attempts to lock _VARS once it has successfully
acquired a lock on _CODE.
On Wed, Aug 16, 2017 at 11:44 AM, ChristianEhrhardt ubuntu/ vm-start- stop/vms/ 7936-0. img" rwk, ubuntu/ vm-start- stop/zesty- server- cloudimg- arm64.img" rk, ubuntu/ vm-start- stop/vms/ 7936-0_ CODE.fd" rk, ubuntu/ vm-start- stop/vms/ 7936-0_ VARS.fd" rk,
<email address hidden> wrote:
> On Wed, Aug 16, 2017 at 6:48 PM, dann frazier <email address hidden>
> wrote:
>
>> I confirmed that adding these lines to the libvirt profile allows me to
>> start the guest (I assume the first two are already covered by the other
>> bug).
>>
>> "/home/
>> "/home/
>>
>
> Those are the two already fixed in latest libvirt, thanks for checking.
>
>
>> "/home/
>> "/home/
>>
>
> Those two are the new ones - thanks.
> With that I can dev a patch tmrw that fixes that.
Great!
> One thing thou - you added the k to both.
> But the Denies were only about the _CODE.
> Would with only one getting the k permission the other one be the one
> failing?
Correct. I tried adding 'k' only to _CODE, but subsequent start
attempts started reporting errors with _VARS:
ubuntu@grotrian:~$ sudo virsh start 7936-0 16T16:44: 36.708278Z qemu-system- aarch64: -drive ubuntu/ vm-start- stop/vms/ 7936-0_ VARS.fd, if=pflash, format= raw,unit= 1: 16T16:44: 36.708431Z qemu-system- aarch64: -drive ubuntu/ vm-start- stop/vms/ 7936-0_ VARS.fd, if=pflash, format= raw,unit= 1: 16T16:44: 36.708662Z qemu-system- aarch64: -drive ubuntu/ vm-start- stop/vms/ 7936-0_ VARS.fd, if=pflash, format= raw,unit= 1:
error: Failed to start domain 7936-0
error: internal error: process exited while connecting to monitor:
2017-08-
file=/home/
Failed to unlock byte 100
2017-08-
file=/home/
Failed to unlock byte 100
2017-08-
file=/home/
Failed to lock byte 100
I gather QEMU only attempts to lock _VARS once it has successfully
acquired a lock on _CODE.
-dann