Bug#1010026: qemu-system-x86: fails to start VM with "host" cpu missing features

[Adrian Davey]

uot;:"/usr/share/OVMF/OVMF_CODE_4M.ms.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}'
\
-blockdev
'{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/REPLACED_VM_NAME_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}'
\
-machine
pc-q35-5.2,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format,memory-backend=pc.ram
\
-accel kvm \
-cpu
Opteron_G3,vme=on,x2apic=on,tsc-deadline=on,hypervisor=on,arat=on,mmxext=on,fxsr-opt=on,pdpe1gb=on,3dnowext=on,3dnow=on,cmp-legacy=on,cr8legacy=on,3dnowprefetch=on,osvw=on,amd-no-ssb=on,npt=on,nrip-save=on,svme-addr-chk=on,monitor=off
\
-m 512 \
-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":536870912}' \
-overcommit mem-lock=off \
-smp 2,sockets=2,cores=1,threads=1 \
-uuid f7722398-98ca-020a-13e7-93de4f798282 \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=33,server=on,wait=off \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc,driftfix=slew \
-global kvm-pit.lost_tick_policy=delay \
-no-hpet \
-no-shutdown \
-global ICH9-LPC.disable_s3=1 \
-global ICH9-LPC.disable_s4=1 \
-boot menu=off,strict=on \
-device
'{"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"}'
\
-device
'{"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"}'
\
-device
'{"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"}'
\
-device
'{"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"}'
\
-device
'{"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"}'
\
-device
'{"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"}'
\
-device
'{"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"}'
\
-device
'{"driver":"qemu-xhci","p2":15,"p3":15,"id":"usb","bus":"pci.2","addr":"0x0"}'
\
-device
'{"driver":"virtio-scsi-pci","id":"scsi0","bus":"pci.1","addr":"0x0"}' \
-device
'{"driver":"virtio-serial-pci","id":"virtio-serial0","bus":"pci.3","addr":"0x0"}'
\
-blockdev
'{"driver":"file","filename":"/opt/vm/images/REPLACED_VHOSTNAME/default/REPLACED_VM_NAME.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}'
\
-device
'{"driver":"virtio-blk-pci","bus":"pci.4","addr":"0x0","drive":"libvirt-1-format","id":"virtio-disk0","bootindex":1}'
\
-netdev tap,fd=34,id=hostnet0,vhost=on,vhostfd=37 \
-device
'{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:a7:24:12","bus":"pcie.0","addr":"0x3"}'
\
-netdev tap,fd=38,id=hostnet1,vhost=on,vhostfd=36 \
-device
'{"driver":"virtio-net-pci","netdev":"hostnet1","id":"net1","mac":"52:54:00:97:27:bf","bus":"pcie.0","addr":"0x6"}'
\
-chardev socket,id=charchannel0,fd=32,server=on,wait=off \
-device
'{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}'
\
-audiodev '{"id":"audio1","driver":"none"}' \
-vnc 127.0.0.1:0,audiodev=audio1 \
-device
'{"driver":"virtio-vga","id":"video0","max_outputs":1,"bus":"pcie.0","addr":"0x1"}'
\
-device
'{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.5","addr":"0x0"}'
\
-object
'{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \
-device
'{"driver":"virtio-rng-pci","rng":"objrng0","id":"rng0","bus":"pci.6","addr":"0x0"}'
\
-sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
2022-04-21T17:49:47.230945Z qemu-system-x86_64: warning: This feature
depends on other features that were not requested: CPUID.800AH:EDX.npt
[bit 0]
2022-04-21T17:49:47.231093Z qemu-system-x86_64: warning: This feature
depends on other features that were not requested:
CPUID.800AH:EDX.nrip-save [bit 3]
2022-04-21T17:49:47.231103Z qemu-system-x86_64: warning: This feature
depends on other features that were not requested:
CPUID.800AH:EDX.svme-addr-chk [bit 28]
2022-04-21T17:49:47.232675Z qemu-system-x86_64: warning: This feature
depends on other features that were not requested: CPUID.800AH:EDX.npt
[bit 0]
2022-04-21T17:49:47.232713Z qemu-system-x86_64: warning: This feature
depends on other features that were not requested:
CPUID.800AH:EDX.nrip-save [bit 3]
2022-04-21T17:49:47.232722Z qemu-system-x86_64: warning: This feature
depends on other features that were not requested:
CPUID.800AH:EDX.svme-addr-chk [bit 28]
2022-04-21T17:49:47.488753Z qemu-system-x86_64: error: failed to set MSR
0xc104 to 0x1
qemu-system-x86_64: ../../target/i386/kvm/kvm.c:2996: kvm_buf_set_msrs:
Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.


the difference between the two is the extra 2 lines (I assume 1 per vCPU)
in 5.17, but then the -cpu entry in the command line also adds
vmcb-clean=on, even though the xml file has "host" cpu and never changes
between the two invocations with different kernels.
qemu-system-x86_64: warning: This feature depends on other features that
were not requested: CPUID.800AH:EDX.vmcb-clean [bit 5]
qemu-system-x86_64: warning: This feature depends on other features that
were not requested: CPUID.800AH:EDX.vmcb-clean [bit 5]

I will try to find a 5.15 kernel on snapshot.debian to try shortly.

Cheers,

Adrian



On Fri, 22 Apr 2022 at 17:50, Michael Tokarev  wrote:

> 22.04.2022 19:01, Adrian Davey wrote:
> > HI Michael,
> >
> > Apologies the reportbug package is installed on a laptop, the issue is
> on a headless system [..]
>
> That's okay, that happens.
>
> > This headless server has both Kernel: Linux 5.16.0-6-amd64 as well as
> Linux 5.17.0-1-amd64 #1 SMP PREEMPT Debian 5.17.3-1 (2022-04-18) x86_64
> GNU/Linux
> > same result as above.
>
> The fix went into 5.17.0-rc3 kernel so it is included in your 5.17 kernel.
>
> Now, 5.16.0-6-amd64 - this one is based on 5.16.18 which includes the fix.
> While 5.16.0-5-amd64 is based on 5.16.14, which does not have it.
>
> Are you sure the assertion failure problem occur with any of these *fixed*
> kernels - either with  5.16.0-6-amd64 or with 5.17.3-1?
>
> Please post the qemu error message(s) from any ofthe "fixed" kernels.
>
> Also you can try the _older_ kernel, such as 5.15, - that one should work
> too.
>
> >
> > libvirt full log (modified for anonymity) :
>
> um. Where's the errors in there? I see full qemu command line (for which
> I asked initially, before discovering the bad and the good commits).  Now
> it seems the command line isn't really necessary (but we do have it anyway
> which is good).
>
> Thanks!
>
> /mjt
>

Bug#1010026: qemu-system-x86: fails to start VM with "host" cpu missing features

[Adrian Davey]

addr":"0x0"}'
\
-device
'{"driver":"virtio-scsi-pci","id":"scsi0","bus":"pci.1","addr":"0x0"}' \
-device
'{"driver":"virtio-serial-pci","id":"virtio-serial0","bus":"pci.3","addr":"0x0"}'
\
-blockdev
'{"driver":"file","filename":"/opt/vm/images/REPLACED_VHOSTNAME/default/REPLACED_VM_NAME.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}'
\
-device
'{"driver":"virtio-blk-pci","bus":"pci.4","addr":"0x0","drive":"libvirt-1-format","id":"virtio-disk0","bootindex":1}'
\
-netdev tap,fd=32,id=hostnet0,vhost=on,vhostfd=34 \
-device
'{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:a7:24:12","bus":"pcie.0","addr":"0x3"}'
\
-netdev tap,fd=35,id=hostnet1,vhost=on,vhostfd=36 \
-device
'{"driver":"virtio-net-pci","netdev":"hostnet1","id":"net1","mac":"52:54:00:97:27:bf","bus":"pcie.0","addr":"0x6"}'
\
-chardev socket,id=charchannel0,fd=30,server=on,wait=off \
-device
'{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}'
\
-audiodev '{"id":"audio1","driver":"none"}' \
-vnc 127.0.0.1:0,audiodev=audio1 \
-device
'{"driver":"virtio-vga","id":"video0","max_outputs":1,"bus":"pcie.0","addr":"0x1"}'
\
-device
'{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.5","addr":"0x0"}'
\
-object
'{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \
-device
'{"driver":"virtio-rng-pci","rng":"objrng0","id":"rng0","bus":"pci.6","addr":"0x0"}'
\
-sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on


On Fri, 22 Apr 2022 at 15:54, Michael Tokarev  wrote:

> 22.04.2022 17:10, Adrian Davey wrote:
> > Package: qemu-system-x86
> > Version: 1:7.0+dfsg-1
> > Severity: normal
> >
> > 2022-04-21T17:07:40.354354Z qemu-system-x86_64: warning: This feature
> depends
> > on other features that were not requested: CPUID.800AH:EDX.npt [bit
> 0]
>
> As I said, this is unrelated.
>
> > 2022-04-21T17:07:40.419616Z qemu-system-x86_64: error: failed to set MSR
> > 0xc104 to 0x1
> > qemu-system-x86_64: ../../target/i386/kvm/kvm.c:2996: kvm_buf_set_msrs:
> > Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.
>
> And this is the actual issue in the.. KERNEL.
>
> The commit in the kernel which introduce it is this one:
>
> commit 880993138396f8f0be620c425d08f84490c35251
> Author: Maxim Levitsky 
> Date:   Tue Mar 22 19:24:48 2022 +0200
>
>  KVM: x86: SVM: fix tsc scaling when the host doesn't support it
>
> which is part of 5.16.0 kernel.  And the commit which fixed this is
>
> commit e910a53fb4f20aa012e46371ffb4c32c8da259b4
> Author: Maxim Levitsky 
> Date:   Wed Feb 23 13:56:49 2022 +0200
>
>  KVM: x86: nSVM: disallow userspace setting of MSR_AMD64_TSC_RATIO to
> non default value when tsc scaling disabled
>
> which is a part of 5.16.12 kernel.
>
> I don't know which is 5.16.0-5-amd64, - but it looks like 5.16.18 is
> in Debian now. Is it your current kernel? What does `uname -a' say?
>
> It looks like the only thing you need is to upgrade the kernel.
>
> > Reverting to qemu-system-x86 6.2+dfsg-3 and the VMs start-up perfectly
> fine
> > using the same libvirt xml.
>
> It is because new qemu started using the MSRs it didn't use previously,
> and hit this very issue. It is all in the kernel, -- it is the kernel
> who reports the list of MSRs it supports, and qemu sets only those MSRs
> which the kernel reports are supported. And out of the sudden one of
> the reported-as-supported MSRs turned out to be unsupported by the kernel -
> that's the meaining of this assert().
>
> Please verify your kernel is at least 5.16.18.
>
> Thanks,
>
> /mjt
>
> > Kernel: Linux 5.16.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
>

Bug#1010026: qemu-system-x86: fails to start VM with "host" cpu missing features

[Adrian Davey]

Package: qemu-system-x86
Version: 1:7.0+dfsg-1
Severity: normal

Dear Maintainer,

VMs controlled by libvirt failed to start when using "host" cpu type with kvm
acceleration

libvirt log gives:

2022-04-21T17:07:40.354354Z qemu-system-x86_64: warning: This feature depends
on other features that were not requested: CPUID.800AH:EDX.npt [bit 0]
2022-04-21T17:07:40.354467Z qemu-system-x86_64: warning: This feature depends
on other features that were not requested: CPUID.800AH:EDX.nrip-save [bit
3]
2022-04-21T17:07:40.354476Z qemu-system-x86_64: warning: This feature depends
on other features that were not requested: CPUID.800AH:EDX.vmcb-clean [bit
5]
2022-04-21T17:07:40.354482Z qemu-system-x86_64: warning: This feature depends
on other features that were not requested: CPUID.800AH:EDX.svme-addr-chk
[bit 28]
2022-04-21T17:07:40.355818Z qemu-system-x86_64: warning: This feature depends
on other features that were not requested: CPUID.800AH:EDX.npt [bit 0]
2022-04-21T17:07:40.355850Z qemu-system-x86_64: warning: This feature depends
on other features that were not requested: CPUID.800AH:EDX.nrip-save [bit
3]
2022-04-21T17:07:40.355857Z qemu-system-x86_64: warning: This feature depends
on other features that were not requested: CPUID.800AH:EDX.vmcb-clean [bit
5]
2022-04-21T17:07:40.355864Z qemu-system-x86_64: warning: This feature depends
on other features that were not requested: CPUID.800AH:EDX.svme-addr-chk
[bit 28]
2022-04-21T17:07:40.419616Z qemu-system-x86_64: error: failed to set MSR
0xc104 to 0x1
qemu-system-x86_64: ../../target/i386/kvm/kvm.c:2996: kvm_buf_set_msrs:
Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.

Reverting to qemu-system-x86 6.2+dfsg-3 and the VMs start-up perfectly fine
using the same libvirt xml.

host cpu flags from /proc/cpuinfo :

flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid
extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy
abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate
vmmcall npt lbrv svm_lock nrip_save

Cheers,

Adrian


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu 1.0.0+git-20190125.36a4c85-5.1
ii  libaio1   0.3.113-2
ii  libbpf0   1:0.7.0-2
ii  libc6 2.33-7
ii  libcapstone4  4.0.2-5
ii  libfdt1   1.6.1-1
ii  libfuse3-33.10.5-1
ii  libgcc-s1 12-20220319-1
ii  libglib2.0-0  2.72.1-1
ii  libgnutls30   3.7.4-2
ii  libibverbs1   39.0-1+b1
ii  libjpeg62-turbo   1:2.1.2-1
ii  libnettle83.7.3-1
ii  libnuma1  2.0.14-3
ii  libpixman-1-0 0.40.0-1
ii  libpmem1  1.11.1-3
ii  libpng16-16   1.6.37-3
ii  librdmacm139.0-1+b1
ii  libsasl2-22.1.28+dfsg-4
ii  libseccomp2   2.5.3-2
ii  libslirp0 4.6.1-1
ii  libudev1  250.4-1
ii  liburing2 2.1-2
ii  libvdeplug2   4.0.1-3
ii  libxendevicemodel14.16.0+51-g0941d6cb-1+b1
ii  libxenevtchn1 4.16.0+51-g0941d6cb-1+b1
ii  libxenforeignmemory1  4.16.0+51-g0941d6cb-1+b1
ii  libxengnttab1 4.16.0+51-g0941d6cb-1+b1
ii  libxenmisc4.164.16.0+51-g0941d6cb-1+b1
ii  libxenstore4  4.16.0+51-g0941d6cb-1+b1
ii  libxentoolcore1   4.16.0+51-g0941d6cb-1+b1
ii  libzstd1  1.5.2+dfsg-1
ii  qemu-system-common1:7.0+dfsg-1
ii  qemu-system-data  1:7.0+dfsg-1
ii  seabios   1.15.0-1
ii  zlib1g1:1.2.11.dfsg-4

Versions of packages qemu-system-x86 recommends:
ii  ovmf  2022.02-3
pn  qemu-block-extra  
pn  qemu-system-gui   
ii  qemu-utils1:7.0+dfsg-1

Versions of packages qemu-system-x86 suggests:
ii  samba  2:4.16.0+dfsg-6
pn  vde2   

-- no debconf information

Bug#911833: 911833 retitle

[Adrian Davey]

Control: retitle -1 iptables-persistent: upable to cope with iptables 
moving to /usr/sbin/

Bug#911833: iptables-persistent

[Adrian Davey]

Package: iptables-persistent
Version: 1.0.9
Severity: normal

Dear Maintainer,

Since iptables 1.6.2-1.1 was uploaded to unstable on 07 Aug 2018 
ip{,6}tables-* have been placed in /usr/sbin/ and not /sbin/ , 
iptables-persistent uses hardcoded "/sbin/ip{,6}tables-restore" in the 
netfilter-persistent plugins.d directory which causes 
netfilter-persistent to fail upgrade to 1.0.9 as systemd reports failed 
jobs.
Please consider using a `which` for ip{,6}tables-* and use those to run 
jobs instead, so that the package can cope with current Buster and lower 
"/sbin/ip{,6}tables-*" and Sid's "/usr/sbin/ip{,6}tables-*".


Many thanks,

Adrian

Bug#906048: linux-image-4.17.0-1-amd64: BT_HCIUART_BCM missing

[Adrian Davey]

Forgot to mention BT_HCIUART_BCM is enabled in 4.9 default config on 
debian, so I think this is a regression rather than a wishlist bug for 
enabling.


Cheers,

Adrian

Bug#906048: linux-image-4.17.0-1-amd64: BT_HCIUART_BCM missing

[Adrian Davey]

Package: src:linux
Version: 4.17.8-1
Severity: normal

Dear Maintainer,


   * What led up to the situation?
unable to use built-in Bluetooth (SDIO BCM) adaptor, missing BCM HCIUART

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
btattach --bredr /dev/ttyS1 -P bcm

   * What was the outcome of this action?
no Bluetooth: HCI UART protocol BCM registered

   * What outcome did you expect instead?
Bluetooth: HCI UART protocol BCM registered

I think CONFIG_BT_HCIUART_BCM=y is required, but in 4.17 it has a load of 
depends:-

config BT_HCIUART_BCM
bool "Broadcom protocol support"
depends on BT_HCIUART
depends on BT_HCIUART_SERDEV
depends on (!ACPI || SERIAL_DEV_CTRL_TTYPORT)
depends on GPIOLIB
select BT_HCIUART_H4
select BT_BCM

Cheers,

Adrian


-- Package-specific info:
** Version:
Linux version 4.17.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-26)) #1 SMP Debian 4.17.8-1 (2018-07-20)

** Command line:
BOOT_IMAGE=/vmlinuz-4.17.0-1-amd64 
root=UUID=be897614-1dfd-4a34-af4a-5d230fafff5b ro rootflags=subvol=rootvol quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
LANGUAGE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-4.17.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.132
ii  kmod25-1
ii  linux-base  4.5

Versions of packages linux-image-4.17.0-1-amd64 recommends:
pn  apparmor 
ii  firmware-linux-free  3.4
pn  irqbalance   

Versions of packages linux-image-4.17.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-efi-amd64  2.02+dfsg1-5
pn  linux-doc-4.17  

Versions of packages linux-image-4.17.0-1-amd64 is related to:
ii  firmware-amd-graphics 20180518-1
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20180518-1
pn  firmware-libertas 
ii  firmware-linux-nonfree20180518-1
ii  firmware-misc-nonfree 20180518-1
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#857195: libvirt-clients

[Adrian Davey]

Package: libvirt-clients
Version: 3.0.0-3
Severity: normal

Dear Maintainer,

`virsh capabilities` does not report  section for some non-native 
qemu-system-$arch.


libvirt api (https://libvirt.org/drvqemu.html#prereq) describes that

"
Deployment pre-requisites
QEMU emulators: The driver will probe /usr/bin for the presence of qemu, 
qemu-system-x86_64, qemu-system-microblaze, qemu-system-microblazeel, 
qemu-system-mips,qemu-system-mipsel, qemu-system-sparc,qemu-system-ppc. 
The results of this can be seen from the capabilities XML output "


However, qemu-system-sparc nor qemu-system-mips are not reported.
qemu-system-x86, qemu-system-arm, qemu-system-ppc are reported however.
(Host is x86_64 debian sid)

This makes creating guest domain from XML impossible for sparc* and 
mips* guests:


virsh -c qemu:///system define debian-sid-sparc64.xml
error: Failed to define domain from debian-sid-sparc64.xml
error: invalid argument: could not find capabilities for arch=sparc64

Regards,

Adrian

Bug#833461: roundcube-core

[Adrian Davey]

Package: roundcube-core
Version: 1.2.1+dfsg.1-1
Severity: normal

Dear Maintainer,

roundcube-core cannot be upgraded nor installed from unstable due to a 
dependency on an unknown package


dep: php-pear-core-minimal (>= 1.10.1)
Package not available

Should there be a dependency on a virtual package that either php-pear 
or some new package named php-pear-core-minimal can meet?


Regards,

Adrian

Bug#827456: qemu-system-sparc: missing links to ROM files

[Adrian Davey]

Package: qemu-system-sparc
Version: 1:2.6+dfsg-3
Severity: normal

Dear Maintainer,

qemu is not able to use option -vga cg3 for qemu-system-sparc as the ROM 
is missing. openbios-sparc now has the files generated and the package 
ships the ROM files in /usr/share/openbios/


Please include links for the QEMU,cgthree.bin QEMU,VGA.bin QEMU,tcx.bin 
files in /usr/share/qemu/ as is currently done for openbios-sparc32 and 
openbios-sparc64 ROMs, as this seems to be the default location for qemu 
to pick up the sparc display ROMs.


Many thanks,

Adrian

Bug#824665: openbios-sparc: missing QEMU,cgthree.bin file

[Adrian Davey]

Package: openbios-sparc
Version: 1.1+svn1353-1
Severity: normal

Dear Maintainer,

qemu is not able to use option -vga cg3 for qemu-system-sparc as the ROM 
is missing.


Please include the generated from source QEMU,cgthree.bin, similar to 
your current rules for QEMU,tcx.bin ROM. I did a test debuild of 
openbios and the file is indeed created but not popped into the 
distributed .deb file.


So in debian/rules

install -m644 obj-sparc32/QEMU,tcx.bin 
$(CURDIR)/debian/openbios-sparc/usr/share/openbios/QEMU,tcx.bin


please consider adding

install -m644 obj-sparc32/QEMU,cgthree.bin 
$(CURDIR)/debian/openbios-sparc/usr/share/openbios/QEMU,cgthree.bin


Once this is included hopefully we can get the qemu-system-sparc package 
to add symlinks to the openbios directory as it does for the sparc32/64 
ROMs but updated to have symlinks also for the tcx and cgthree ROMs too.


Many thanks,

Adrian

Bug#822106: libvirt-daemon-system: fails to start libvirt-lxc guest

[Adrian Davey]

Package: libvirt-daemon-system
Version: 1.3.3-2
Severity: normal

Dear Maintainer,

Starting an libvirt-lxc guest in virsh fails.

virsh # start testvm
error: failed to get domain 'testvm'
error: Domain not found: No domain with matching name 'testvm'

log file issues this:

~# cat /var/log/libvirt/lxc/testvm.log

2016-04-19 13:33:47.547+: starting up
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
LIBVIRT_DEBUG=3 LIBVIRT_LOG_OUTPUTS=3:stderr 
/usr/lib/libvirt/libvirt_lxc --name testvm --console 23 --security=none 
--handshake 26 --veth vnet1
PATH=/bin:/sbin TERM=linux container=lxc-libvirt HOME=/ 
container_uuid= LIBVIRT_LXC_UUID= LIBVIRT_LXC_NAME=testvm 
/bin/systemd
2016-04-19 13:33:47.698+: 1: info : libvirt version: 1.3.3, package: 
2 (Guido Günther  Fri, 15 Apr 2016 08:44:14 +0200)

2016-04-19 13:33:47.698+: 1: info : hostname: 
2016-04-19 13:33:47.698+: 1: warning : 
lxcContainerUnmountSubtree:614 : Failed to unmount 
'/.oldroot/sys/kernel/security', trying to detach subtree '/.oldroot': 
Invalid argument



Reverting to 1.3.1-2 and I can start same the libvirt-lxc guest.


Kernel: Linux 4.5.0-1-amd64

Bug#794095: dnsmasq-base: 100% cpu when using default libvirtd --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper

[Adrian Davey]

Package: dnsmasq-base
Version: 2.74-1
Severity: normal

Dear Maintainer,

libvirtd starts dnsmasq 
/usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf 
--leasefile-ro --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
this pegs the cpu to 100%.

If run as 
/usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf 
--leasefile-ro
then the cpu is normal.

Downgrading to 2.73-2 and using libvirtd default dhcp helper keeps the cpu at 
normal rate

libvirt-daemon package has not been updated in the last ~2 months, but dnsmasq 
has in the last couple of days, so whatever changed in dnsmasq either needs 
investigation or libvirtd needs its dhcp helper updating to match.

Cheers,

Adrian

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dnsmasq-base depends on:
ii  adduser  3.113+nmu3
ii  libc62.19-19
ii  libdbus-1-3  1.8.20-1
ii  libgmp10 2:6.0.0+dfsg-7
ii  libhogweed4  3.1.1-3
ii  libidn11 1.31-1
ii  libnetfilter-conntrack3  1.0.4-1
ii  libnettle6   3.1.1-3
ii  libnfnetlink01.0.1-3

Versions of packages dnsmasq-base recommends:
pn  dns-root-data  none

dnsmasq-base suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#766390: [Pkg-libvirt-maintainers] Bug#766390: libvirt0: fails unprivileged lxc domain with /proc/sys re-mount error

[Adrian Davey]

Hi,

To further the bug report, I installed fedora 20, tried the container 
again, it fails with not understanding how to deal with sys or proc 
mount points, libvirt version was too low. I then updated the system to 
latest virt repo which is the same version number as debian's 1.2.9. 
tried again, fails in the same way as it does on debian, so thats good / 
bad news, at least we are consistent!


I have now installed a debian system at jessie level with kernel 3.14.2 
(from d-i usb install), got my test container working with idmap: good 
result!


Upgraded all packages to sid, container still starts: good result!

Updated to linux-image-amd64 (brings in linux-image-3.16.0-4-amd64 == 
3.16.7 , no idea why the kernel team has changed their package names 
recently), container fails to start.


Looking back at the fedora installation, it too is a 3.16 kernel. I am 
rather surprised the fedora folks haven't noticed, I doubt fedora 21 
will work with idmap libvirt_lxc either.


I posted on libvir mailing list [1] about possible issues with kernel / 
libvirt needing to be synced for mounting proc, but nobody replied.


So in conclusion, seems the kernel did break somewhere after 3.14.2.  I 
will try later kernels but fishing in the dark as to where to look for 
the relevant changes, git bisect is a little beyond me.


Do I open a bug with the kernel or should this bug just be re-assigned ?

Regards,

Adrian

[1] 
https://www.redhat.com/archives/libvir-list/2014-October/msg00483.html



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#766390: [Pkg-libvirt-maintainers] Bug#766390: libvirt0: fails unprivileged lxc domain with /proc/sys re-mount error

[Adrian Davey]

On 24/10/2014 08:09, Guido Günther wrote:

On Thu, Oct 23, 2014 at 08:34:50PM +0100, Adrian Davey wrote:
I tried without the unprivileged_userns_clone before doing the change 
as by

default the debian linux kernel doesn't set it


The only difference I can spot is, that I'm not using butterfs. I'm
also using systemd outside of the container. I'm not using selinux or
apparmor.
Cheers,
 -- Guido


Hi,

I pulled out an old HP N36L Microserver and did a fresh Jessie base 
install via d-i onto ext4. Then dist-upgraded to sid, installed the same 
packages to enable libvirt deployment, same result as before.


So it's not a btrfs vs ext4 issue :/

root@holly2:~# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs 
(rw,relatime,size=10240k,nr_inodes=248327,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

tmpfs on /run type tmpfs (rw,nosuid,relatime,size=398492k,mode=755)
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs 
(rw,nosuid,nodev,noexec,relatime)

tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs 
(rw,nosuid,nodev,noexec,relatime,size=5120k)

tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)

pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup 
(rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=21,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)

hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
tmpfs on /run/user/1000 type tmpfs 
(rw,nosuid,nodev,relatime,size=199248k,mode=700,uid=1000,gid=1000)

fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)

root@holly2:~# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.16-3-amd64 
root=UUID=32338814-6c6a-4329-96a1-6cea2e4f8f4d ro cgroup_enable=memory 
quiet


List of installed packages and versions on the host uploaded at a text 
file rather than make this bug report too long.


Regards,

Adrian

acl 2.2.52-2
acpi 1.7-1
acpi-support-base 0.142-5
acpid 1:2.0.23-1
adduser 3.113+nmu3
amd64-microcode 2.20131007.1+really20130710.1
apt 1.0.9.3
apt-utils 1.0.9.3
augeas-lenses 1.2.0-0.2
base-files 7.8
base-passwd 3.5.36
bash 4.3-11
binutils 2.24.90.20141023-1
bridge-utils 1.5-9
bsdmainutils 9.0.6
bsdutils 1:2.25.1-5
busybox 1:1.22.0-9
bzip2 1.0.6-7
console-setup 1.113
console-setup-linux 1.113
coreutils 8.23-2
cpio 2.11+dfsg-2
cron 3.0pl1-124.2
dash 0.5.7-4
dbus 1.8.8-2
debconf 1.5.53
debconf-i18n 1.5.53
debian-archive-keyring 2014.1
debianutils 4.4
debootstrap 1.0.64
dictionaries-common 1.23.14
diffutils 1:3.3-1
discover 2.1.2-7
discover-data 2.2013.01.11
dmidecode 2.12-3
dmsetup 2:1.02.90-2
dnsmasq-base 2.72-2
dpkg 1.17.20
dpkg-dev 1.17.20
e2fslibs:amd64 1.42.12-1
e2fsprogs 1.42.12-1
e3 1:2.71-1
eatmydata 82-2
ebtables 2.0.10.4-3
emacsen-common 2.0.8
findutils 4.4.2-9
firmware-linux 0.43
firmware-linux-free 3.3
firmware-linux-nonfree 0.43
gcc-4.7-base:amd64 4.7.4-3
gcc-4.8-base:amd64 4.8.3-13
gcc-4.9-base:amd64 4.9.1-18
gettext-base 0.19.3-1
gnupg 1.4.18-4
gpgv 1.4.18-4
grep 2.20-4
groff-base 1.22.2-8
grub-common 2.02~beta2-15
grub-pc 2.02~beta2-15
grub-pc-bin 2.02~beta2-15
grub2-common 2.02~beta2-15
gzip 1.6-4
hostname 3.15
iamerican 3.3.02-6
ibritish 3.3.02-6
ienglish-common 3.3.02-6
ifupdown 0.7.49
init 1.21
init-system-helpers 1.21
initramfs-tools 0.118
initscripts 2.88dsf-53.4
insserv 1.14.0-5
installation-report 2.57
iproute2 3.16.0-2
iptables 1.4.21-2
iputils-ping 3:20121221-5+b1
isc-dhcp-client 4.3.1-5
isc-dhcp-common 4.3.1-5
ispell 3.3.02-6
kbd 1.15.5-1
keyboard-configuration 1.113
klibc-utils 2.0.4-2
kmod 18-3
less 458-3
laptop-detect 0.13.7
libacl1:amd64 2.2.52-2
libapparmor1:amd64 2.9.0-1
libapt-inst1.5:amd64 1.0.9.3
libapt-pkg4.12:amd64 1.0.9.3
libasprintf0c2:amd64 0.19.3-1
libattr1:amd64 1:2.4.47-2
libaudit-common 1:2.4-1
libaudit1:amd64 1:2.4-1
libaugeas0 1.2.0-0.2
libavahi-client3

Bug#766390: [Pkg-libvirt-maintainers] Bug#766390: libvirt0: fails unprivileged lxc domain with /proc/sys re-mount error

[Adrian Davey]

On 23/10/2014 13:03, Guido Günther wrote:

On Wed, Oct 22, 2014 at 07:42:04PM +0100, Adrian Davey wrote:

Package: libvirt0
Version: 1.2.9-3
Severity: normal

Dear Maintainer,

Launching a libvirt_lxc domain with idmap enabled using virsh fails:

virsh # start testvm
error: Failed to start domain testvm
error: internal error: guest failed to start: Failed to re-mount
/proc/sys on /proc/sys flags=1021: Operation not permitted


I tried to reproduce and used the attached config, did a

 sudo  ./uidmapshift -b /my/lxc/containers/lxc-test2 0 10 1000

(from nsexec, currently not packaged in Debian) and could happily
start the container. The bash process also shows the uid mapping. Note
that I did not set:

   echo 1  /proc/sys/kernel/unprivileged_userns_clone

since my kernel doesn't have it. Can you check if this works for you 
too?

Cheers,
 -- Guido


I tried without the unprivileged_userns_clone before doing the change as 
by default the debian linux kernel doesn't set it


I have just tried again without it set, exactly the same issue.

I have tried a debootstrap installation then using uidmapshift, same 
result.
I have tried an LXC download template for sid/amd64 that does the id 
shift, same result. (echo 1  
/proc/sys/kernel/unprivileged_userns_clone, is required to make sure the 
download template operation finishes)


If it works for you then there must be something different between our 
setups, I guess it's a case of trying to identify what is different 
easily.


Which kernel are you using ? Do you have anything in libvirt conf that 
is not the default that could be related ? Do normal LXC unprivileged 
domains work for you? I find that LXC doesn't work either as cgroups 
have issues as described in [1] and then /dev/.lxc/ errors [2].  These 
rootfs live on btrfs filesystem with default mount options.
I was hoping systemd with libvirt would sort out my original cgroups 
issue and just work to compliment my qemu side of libvirt.


Cheers,

Adrian

[1] 
https://lists.linuxcontainers.org/pipermail/lxc-users/2014-September/007776.html
[2] 
https://lists.linuxcontainers.org/pipermail/lxc-users/2014-September/007860.html



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#766390: Info received ([Pkg-libvirt-maintainers] Bug#766390: libvirt0: fails unprivileged lxc domain with /proc/sys re-mount error)

[Adrian Davey]

Hi,

I have just created a new qemu domain of sid and installed libvirt 
there.


steps were:

install base sid from d-i
then libvirt-daemon-system, libvirt0, libvirt-clients, dnsmasq-base, 
bridge-utils, ebtables, debootstrap

(let the deps get pulled in)

add cgroup_enable=memory to kernel cmdline (reboot vm)

use virsh to
net-edit default (change from 192.168.122.0 to 192.168.123.0 as we are 
already in a libvirt defined network)

define testvm.xml

use debootstrap to
debootstrap sid /opt/vm/containers/testvm/ 
http://ftp.uk.debian.org/debian


grab uidmapshift and run
./uidmapshift -b /opt/vm/containers/testvm 0 1 1000

virsh # connect lxc:///

virsh # start testvm
error: Failed to start domain testvm
error: internal error: guest failed to start: Failed to re-mount 
/proc/sys on /proc/sys flags=1021: Operation not permitted



virsh #

same as before.

So I must be missing something. Hopefully you can reproduce this within 
a qemu vm and compare to your working setup.

I did not install any LXC packages.

Regards,

Adrian


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#766390: libvirt0: fails unprivileged lxc domain with /proc/sys re-mount error

[Adrian Davey]

Package: libvirt0
Version: 1.2.9-3
Severity: normal

Dear Maintainer,

Launching a libvirt_lxc domain with idmap enabled using virsh fails:

virsh # start testvm
error: Failed to start domain testvm
error: internal error: guest failed to start: Failed to re-mount /proc/sys on 
/proc/sys flags=1021: Operation not permitted

virsh # dumpxml testvm
domain type='lxc'
  nametestvm/name
  uuidefdb0924-d538-461e-98c4-b46eabd7ec13/uuid
  memory unit='KiB'262144/memory
  currentMemory unit='KiB'262144/currentMemory
  vcpu placement='static'1/vcpu
  resource
partition/machine/partition
  /resource
  os
type arch='x86_64'exe/type
init/bin/bash/init
  /os
  idmap
uid start='0' target='1' count='1000'/
gid start='0' target='1' count='1000'/
  /idmap
  features
privnet/
  /features
  clock offset='utc'/
  on_poweroffdestroy/on_poweroff
  on_rebootrestart/on_reboot
  on_crashrestart/on_crash
  devices
emulator/usr/lib/libvirt/libvirt_lxc/emulator
filesystem type='mount' accessmode='passthrough'
  source dir='/opt/vm/containers/testvm'/
  target dir='/'/
/filesystem
interface type='network'
  mac address='00:16:3e:03:90:ee'/
  source network='default'/
  guest dev='eth0' actual='vnet1'/
/interface
console type='pty'
  target type='lxc' port='0'/
/console
  /devices
/domain

This is a systemd controlled system with systemd responsible for /proc 

I have these additional settings as recommended for normal LXC operation

echo 1  /sys/fs/cgroup/cpuset/cgroup.clone_children
echo 1  /proc/sys/kernel/unprivileged_userns_clone

/etc/sub{u/g}id:

systemd-timesync:10:65536
systemd-network:165536:65536
systemd-resolve:231072:65536
systemd-bus-proxy:296608:65536
mylxcuser:1:10001


The same error happens if mapping id 0 == 0 or 0 == 1

mount | grep proc
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

Without idmap enabled the domain starts a debian sid amd64 container perfectly.

Regards,

Adrian

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libvirt0 depends on:
ii  libapparmor12.9.0-1
ii  libaudit1   1:2.4-1
ii  libavahi-client30.6.31-4
ii  libavahi-common30.6.31-4
ii  libc6   2.19-11
ii  libcap-ng0  0.7.4-2
ii  libdbus-1-3 1.8.8-2
ii  libdevmapper1.02.1  2:1.02.90-2
ii  libgnutls-deb0-28   3.3.8-3
ii  libnl-3-200 3.2.24-2
ii  libnl-route-3-200   3.2.24-2
ii  libnuma12.0.10~rc2-3
ii  libsasl2-2  2.1.26.dfsg1-12
ii  libselinux1 2.3-2
ii  libssh2-1   1.4.3-4
ii  libsystemd0 215-5+b1
ii  libxml2 2.9.1+dfsg1-4
ii  libyajl22.1.0-2

Versions of packages libvirt0 recommends:
pn  lvm2  none

libvirt0 suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765045: [libvirt-clients]

[Adrian Davey]

policykit-1 and libpolkit-agent-1-0 from sid work fine, you need to have 
configured libvirt to work with polkit correctly


/etc/polkit-1/localauthority/50-local.d/ with polkit config files eg;

org.libvirt.unix.manage.pkla contains (notice the filename ending 
(.pkla) as we have polkit 0.105 in sid currently, after 0.106 the ending 
is not required)


[Allow fred libvirt management permissions]
Identity=unix-user:fred
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes


as stated at http://libvirt.org/auth.html#ACL_server_polkit

then virsh and virt-manager work fine in sid without needing extras from 
experimental


so its less of a bug, more of an extra note needed for configuration 
with polkit.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765045: [Pkg-libvirt-maintainers] Bug#765045: [libvirt-clients]

[Adrian Davey]

On 14/10/2014 13:10, Guido Günther wrote:

On Tue, Oct 14, 2014 at 10:17:18AM +0100, Adrian Davey wrote:
policykit-1 and libpolkit-agent-1-0 from sid work fine, you need to 
have

configured libvirt to work with polkit correctly

/etc/polkit-1/localauthority/50-local.d/ with polkit config files eg;

org.libvirt.unix.manage.pkla contains (notice the filename ending 
(.pkla) as

we have polkit 0.105 in sid currently, after 0.106 the ending is not
required)

[Allow fred libvirt management permissions]
Identity=unix-user:fred
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes


This should not be necessary if your user is in the libvirt group. Can
you check?
Cheers,
 -- Guido


user is in the libvirt group but without the above it fails with

error: failed to connect to the hypervisor
error: authentication failed: no agent is available to authenticate

changing pkla file to

[Allow group libvirt management permissions]
Identity=unix-group:libvirt
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes


this works for all users in libvirt group

Regards,

Adrian


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765045: [Pkg-libvirt-maintainers] Bug#765045: Bug#765045: [libvirt-clients]

[Adrian Davey]

On 14/10/2014 13:45, Guido Günther wrote:

On Tue, Oct 14, 2014 at 01:38:23PM +0100, Adrian Davey wrote:

On 14/10/2014 13:10, Guido Günther wrote:
On Tue, Oct 14, 2014 at 10:17:18AM +0100, Adrian Davey wrote:
policykit-1 and libpolkit-agent-1-0 from sid work fine, you need to have
configured libvirt to work with polkit correctly

/etc/polkit-1/localauthority/50-local.d/ with polkit config files eg;

org.libvirt.unix.manage.pkla contains (notice the filename ending
(.pkla) as
we have polkit 0.105 in sid currently, after 0.106 the ending is not
required)

[Allow fred libvirt management permissions]
Identity=unix-user:fred
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes

This should not be necessary if your user is in the libvirt group. Can
you check?
Cheers,
 -- Guido

user is in the libvirt group but without the above it fails with

error: failed to connect to the hypervisor
error: authentication failed: no agent is available to authenticate

changing pkla file to

[Allow group libvirt management permissions]
Identity=unix-group:libvirt
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes


this works for all users in libvirt group


Is your /etc/libvirt/libvirtd.conf the default one?
 -- Guido



apart for the commented out lines there is nothing in 
/etc/libvirt/libvirtd.conf


cat /etc/libvirt/libvirt.conf
#
# This can be used to setup URI aliases for frequently
# used connection URIs. Aliases may contain only the
# characters  a-Z, 0-9, _, -.
#
# Following the '=' may be any valid libvirt connection
# URI, including arbitrary parameters

#uri_aliases = [
#  hail=qemu+ssh://r...@hail.cloud.example.com/system,
#  sleet=qemu+ssh://r...@sleet.cloud.example.com/system,
#]

#
# This can be used to prevent probing of the hypervisor
# driver when no URI is supplied by the application.

#uri_default = qemu:///system


Regards,

Adrian


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#564936: grub-pc: unexpectable reboot

[Adrian Davey]

Hi,

I too have the same issue, however, this version does work on all my
64bit systems and half of the 32bit systems.

Regards,

Adrian





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#565313: xserver-xorg-video-radeon: 16 bit colour on M64 gives green tinted screen

[Adrian Davey]

On 15/1/2010, Julien Cristau jcris...@debian.org wrote:

On Fri, Jan 15, 2010 at 08:59:22 -0500, Alex Deucher wrote:

 On Thu, Jan 14, 2010 at 1:53 PM, Adrian Davey adr...@beth2.org wrote:
  Package: xserver-xorg-video-radeon
  Version: 1:6.12.4-2
  Severity: important
 
  Version 6.12.4-2 16-bit colour gives a green tint to the screen, slight 
  fuzziness to the panel and overall very dim display. Tested on M64 with 
  both LCD panel on laptop and on external VGA LCD Panel, same result.
  Changing to the console from X keeps the green dim display, making reading 
  the text on a black background very hard indeed.
 
  There is no issue at 24-bit colour, however, at this depth I have don't 
  have enough video RAM to allow acceleration, making it painfully slow to 
  use, the main reason for using 16-bit.
 
  Version 6.12.3-1 16-bit colour works correctly.
 

 I think this is an X server issue.  Are you using both driver versions
 with the same xserver?

That would be the upgrade from server 1.6.x to 1.7.x then.

Cheers,
Julien

Sorry I should have said xserver 1.6 plus 6.12.3-1 is fine
xserver 1.7 plus 6.12.4-2 is not good for 16bit colour.

I have not tried 6.12.3-1 on server 1.7 as there are conflicts in
installing.

# dpkg -i xserver-xorg-video-radeon_1%3a6.12.3-1_amd64.deb
dpkg: warning: downgrading xserver-xorg-video-radeon from 1:6.12.4-2 to
1:6.12.3-1.
dpkg: regarding xserver-xorg-video-radeon_1%3a6.12.3-1_amd64.deb
containing xserver-xorg-video-radeon:
 xserver-xorg-core conflicts with xserver-xorg-video-5
  xserver-xorg-video-radeon provides xserver-xorg-video-5 and is to be
installed.
dpkg: error processing xserver-xorg-video-radeon_1%3a6.12.3-1_amd64.deb
(--install):
 conflicting packages - not installing xserver-xorg-video-radeon
Errors were encountered while processing:
 xserver-xorg-video-radeon_1%3a6.12.3-1_amd64.deb

Hope this helps,

Adrian





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#500590: mtx: New upstream release

[Adrian Davey]

Package: mtx
Version: 1.3.11-1
Severity: wishlist

Hi,

There is a new release 1.3.12 of mtx available [1].  Please consider updating 
your package.

Many thanks,

Regards, Adrian

[1] http://sourceforge.net/project/showfiles.php?group_id=4626

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686-bigmem (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages mtx depends on:
ii  libc6 2.7-13 GNU C Library: Shared libraries

mtx recommends no packages.

mtx suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#471317: [Pkg-utopia-maintainers] Bug#471317: Confirm amd64 and glib breakage

[Adrian Davey]

On 18/3/2008, Sjoerd Simons [EMAIL PROTECTED] wrote:

reassign 471317 network-manager

On Tue, Mar 18, 2008 at 03:12:59AM +0100, Michael Biebl wrote:
 reassign 471317 libglib2.0-0
 thanks

 Zitat von Neutron Soutmun [EMAIL PROTECTED]:

 Confirm, downgrading the libglib to 2.14.6-1 and also 2.16.1-1 fix this
 problem.


 Thanks for the confirmation. Seems like
 80_static-mutex-aliasing-warnings.patch breaks g_mutex_lock on amd64.
 Reassigning to libglib2.0-0.

That patch can't break locking for NM. As Sebastien mentioned earlier, the
changes can only ever have effect when you compile against the new glib. We
need to debug this more on network-manager's side before starting to blame
glib.

I've made some debs[0] which should fix the dbus errors we're seeing in the NM
logs. Which may or may not fix this issue, but it definately fixes some memory
corruption. (I couldn't test this because i don't have machines with kill
switches though...)

So please everyone who can reproduce it, try these debs.. And if it still fails
send in new NM logs :)

  Sjoerd
0: http://beast.luon.net/~sjoerd/NM/
--
Understanding is always the understanding of a smaller problem
in relation to a bigger problem.
   -- P. D. Ouspensky


I can confirm that network-manager_0.6.5-5.0.1_amd64.deb from
http://beast.luon.net/~sjoerd/NM/ works perfectly with the latest
libglib2

Regards

Adrian

Bug#471317: [Pkg-utopia-maintainers] Bug#471317: network-manager: no networks found when libglib2 2.16.1-2 is installed

[Adrian Davey]

Output of NetworkManager --no-daemon  and nm-tool as requested,

NetworkManager: info  starting...
NetworkManager: info  New VPN service 'openvpn'
(org.freedesktop.NetworkManager.openvpn).
NetworkManager: info  Found radio killswitch
/org/freedesktop/Hal/devices/ipw_wlan_switch
NetworkManager: info  wlan0: Device is fully-supported using driver
'iwl4965'.
NetworkManager: info  nm_device_init(): waiting for device's worker
thread to start
NetworkManager: info  nm_device_init(): device's worker thread
started, continuing.
NetworkManager: info  Now managing wireless (802.11) device 'wlan0'.
NetworkManager: info  Deactivating device wlan0.
NetworkManager: info  eth0: Device is fully-supported using driver
'e1000'.
NetworkManager: info  nm_device_init(): waiting for device's worker
thread to start
NetworkManager: info  nm_device_init(): device's worker thread
started, continuing.
NetworkManager: info  Now managing wired Ethernet (802.3) device
'eth0'.
NetworkManager: info  Deactivating device eth0.
NetworkManager: info  Will activate wired connection 'eth0' because
it now has a link.
NetworkManager: info  Updating allowed wireless network lists.
NetworkManager: info  SWITCH: no current connection, found better
connection 'eth0'.
NetworkManager: info  Will activate connection 'eth0'.
NetworkManager: info  Device eth0 activation scheduled...
NetworkManager: info  Activation (eth0) started...
NetworkManager: info  Activation (eth0) Stage 1 of 5 (Device Prepare)
scheduled...
NetworkManager: info  Activation (eth0) Stage 1 of 5 (Device Prepare)
started...
NetworkManager: info  Activation (eth0) Stage 2 of 5 (Device Configure)
scheduled...
NetworkManager: info  Activation (eth0) Stage 1 of 5 (Device Prepare)
complete.
NetworkManager: info  Activation (eth0) Stage 2 of 5 (Device Configure)
starting...
NetworkManager: info  Activation (eth0) Stage 2 of 5 (Device Configure)
successful.
NetworkManager: info  Activation (eth0) Stage 3 of 5 (IP Configure
Start) scheduled.
NetworkManager: info  Activation (eth0) Stage 2 of 5 (Device Configure)
complete.
NetworkManager: info  Activation (eth0) Stage 3 of 5 (IP Configure
Start) started...
NetworkManager: info  Updating VPN Connections...
process 23273: arguments to dbus_message_get_args() were incorrect,
assertion (error) == NULL || !dbus_error_is_set ((error)) failed in
file dbus-message.c line 1667.
This is normally a bug in some application using the D-Bus library.
NetworkManager: info  Error getting killswitch power arguments:  -

NetworkManager: info  Wireless now enabled by radio killswitch
Killed

/* killed after 5 mins of no activity, nm-applet was circling */



/* then when running it again and using nm-tool while running */

NetworkManager Tool

get_nm_state(): didn't get a reply from NetworkManager.


NetworkManager appears not to be running (could not get its state).

Regards,

Adrian

Bug#471317: [Pkg-utopia-maintainers] Bug#471317: network-manager: no networks found when libglib2 2.16.1-2 is installed

[Adrian Davey]

On 17/3/2008, Michael Biebl [EMAIL PROTECTED] wrote:

Adrian Davey wrote:
 Output of NetworkManager --no-daemon  and nm-tool as requested,
 
 NetworkManager: info  starting...
 NetworkManager: info  New VPN service 'openvpn'
 (org.freedesktop.NetworkManager.openvpn).

 Start) started...
 NetworkManager: info  Updating VPN Connections...
 process 23273: arguments to dbus_message_get_args() were incorrect,
 assertion (error) == NULL || !dbus_error_is_set ((error)) failed in
 file dbus-message.c line 1667.
 This is normally a bug in some application using the D-Bus library.


I can't reproduce this problem. NM is running just fine with the newer glib.
It seems to crash when tries to update the vpn connections. Could you
try to uninstall network-manager-openvpn* and test with a fresh account
without any vpn configuration?

Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


I have removed and purged network-manager-openvpn*, created a fresh
account and rerun as asked,


NetworkManager: info  starting...
NetworkManager: info  Found radio killswitch
/org/freedesktop/Hal/devices/ipw_wlan_switch
NetworkManager: info  wlan0: Device is fully-supported using driver
'iwl4965'.
NetworkManager: info  nm_device_init(): waiting for device's worker
thread to start
NetworkManager: info  nm_device_init(): device's worker thread
started, continuing.
NetworkManager: info  Now managing wireless (802.11) device 'wlan0'.
NetworkManager: info  Deactivating device wlan0.
NetworkManager: info  eth0: Device is fully-supported using driver
'e1000'.
NetworkManager: info  nm_device_init(): waiting for device's worker
thread to start
NetworkManager: info  nm_device_init(): device's worker thread
started, continuing.
NetworkManager: info  Now managing wired Ethernet (802.3) device
'eth0'.
NetworkManager: info  Deactivating device eth0.
NetworkManager: info  Will activate wired connection 'eth0' because
it now has a link.
NetworkManager: info  Updating allowed wireless network lists.
NetworkManager: info  SWITCH: no current connection, found better
connection 'eth0'.
NetworkManager: info  Will activate connection 'eth0'.
NetworkManager: info  Device eth0 activation scheduled...
NetworkManager: info  Activation (eth0) started...
NetworkManager: info  Activation (eth0) Stage 1 of 5 (Device Prepare)
scheduled...
NetworkManager: info  Activation (eth0) Stage 1 of 5 (Device Prepare)
started...
NetworkManager: info  Activation (eth0) Stage 2 of 5 (Device Configure)
scheduled...
NetworkManager: info  Activation (eth0) Stage 1 of 5 (Device Prepare)
complete.
NetworkManager: info  Activation (eth0) Stage 2 of 5 (Device Configure)
starting...
NetworkManager: info  Activation (eth0) Stage 2 of 5 (Device Configure)
successful.
NetworkManager: info  Activation (eth0) Stage 3 of 5 (IP Configure
Start) scheduled.
NetworkManager: info  Activation (eth0) Stage 2 of 5 (Device Configure)
complete.
NetworkManager: info  Activation (eth0) Stage 3 of 5 (IP Configure
Start) started...
NetworkManager: info  Updating VPN Connections...
process 26217: arguments to dbus_message_get_args() were incorrect,
assertion (error) == NULL || !dbus_error_is_set ((error)) failed in
file dbus-message.c line 1667.
This is normally a bug in some application using the D-Bus library.
NetworkManager: info  Error getting killswitch power arguments:  -

NetworkManager: info  Wireless now enabled by radio killswitch

eventually killed

and again with nm-tool,


NetworkManager Tool

get_nm_state(): didn't get a reply from NetworkManager.


NetworkManager appears not to be running (could not get its state).




Regards,

Adrian

Bug#471317: network-manager: no networks found when libglib2 2.16.1-2 is installed

[Adrian Davey]

Package: network-manager
Version: 0.6.5-5
Severity: grave
Justification: renders package unusable

When upgrading from libglib2 2.14.6-1 to 2.16.1-2 network manager
reports that there are no network found, the hardware devices are
working though.
Downgrading to 2.14.6-1 fixes the problem, but I am not sure if this is
an issue with libglib2 or network-manager working with later libglib2
versions.

Adrian

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages network-manager depends on:
ii adduser 3.106 add and remove users and
groups
ii dbus 1.1.20-1 simple interprocess
messaging syst
ii dhcdbd 3.0-2 D-Bus interface to the ISC
DHCP cl
ii hal 0.5.10+git20080301-1 Hardware Abstraction Layer
ii ifupdown 0.6.8 high level tools to
configure netw
ii iproute 20080108-1 Professional tools to
control the
ii iputils-arping 3:20071127-1 Tool to send ICMP echo
requests to
ii libc6 2.7-9 GNU C Library: Shared
libraries
ii libdbus-1-3 1.1.20-1 simple interprocess
messaging syst
ii libdbus-glib-1-2 0.74-1 simple interprocess
messaging syst
ii libgcrypt11 1.4.0-3 LGPL Crypto library -
runtime libr
ii libglib2.0-0 2.16.1-2 The GLib library of C
routines
ii libgpg-error0 1.4-2 library for common error
values an
ii libhal1 0.5.10+git20080301-1 Hardware Abstraction Layer -
share
ii libiw29 29-1 Wireless tools - library
ii libnl1 1.1-2 library for dealing with
netlink s
ii libnm-util0 0.6.5-5 network management framework
(shar
ii lsb-base 3.2-4 Linux Standard Base 3.2 init
scrip
ii wpasupplicant 0.6.3-1 Client support for WPA and
WPA2 (I

Versions of packages network-manager recommends:
ii network-manager-gnome 0.6.5-3 network management framework
(GNOM

-- no debconf information)

Bug#452278: hplip: depends on python-qt3

[Adrian Davey]

Package: hplip
Version: 2.7.10-2
Severity: normal


This package now has python-qt3 dependency which should only be
installed if hplip-gui is used.
The ubuntu version does not have this dependancy, nor does 2.7.10-1 in
experimental.


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Bug#332414: package kicks out xserver-xfree86 and leaves system without any xserver

[Adrian Davey]

Package: xserver-common
Version: 6.8.2.dfsg.1-8
Severity: Normal

When upgrading xserver-common to 6.8.2.dfsg.1-8 it conflicts with
xserver-xfree86, introduced as a result of bug #318425, which is all
fine but it does leave /etc/X11/X linking to /bin/true and no xserver on
the system.  I don't think this is quite the expected behavior, if the
xserver-xfree86 is to be removed from the system surely the package
should be replaced with an xserver package, most likely xserver-xorg?

Kind regards,

Adrian