similar to: Bug#589357: xen-hypervisor-4.0-i386: balloon driver crash

Package: xen-hypervisor-4.0-amd64 Version: 4.0.1~rc3-1 Severity: normal Hi, I upgrade one server from lenny to squeeze, to start testing xen-hypervisor-3.4 and xen-hypervisor-4.0, but it seems to don't work. The error : xm create -c /etc/xen/slhoka.cfg Using config file "/etc/xen/slhoka.cfg". Error: Device 0 (vif) could not be connected. Hotplug scripts not working. The error

Package: xen-hypervisor-4.0-amd64 Version: 4.0.1-1 Severity: normal Hello, I've this message in dmesg that I can't understand: [ 4.032472] ------------[ cut here ]------------ [ 4.032521] WARNING: at /build/buildd-linux-2.6_2.6.32-26-amd64-KkHF2p/linux-2.6-2.6.32/debian/build/source_amd64_xen/mm/page_alloc.c:1833 __alloc_pages_nodemask+0x177/0x5f5() [ 4.032590] Hardware name:

Package: xen-hypervisor-4.0-i386 Version: 4.0.1-4 Severity: normal Tags: squeeze -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-xen-686 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash xen-hypervisor-4.0-i386 depends on

Package: xen-utils-3.2-1 Version: 3.2.1-2 Severity: important Hi, I set the severity to important as it seems that current xen tools does not allow to load amd64 Debian kernel in DomU. I also put the debian-kernel ML in CC as I'm not sure the problem comes from xen tools or the kernel itself. Here is my configuration: Hypervisor: xen-hypervisor-3.2-1-amd64 3.2.1-2

Package: xen-hypervisor-3.0.3-1-i386-pae Version: 3.0.3-0-2 Followup-For: Bug #423006 FYI, I experience the very same problem here. The machine reboots immediately after the error... I had to reboot outside xen to standard Linux kernel, and then it works... Hope this helps -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500,

Package: xen-hypervisor-3.2-1-i386 Version: 3.2.1-2 Severity: minor Instead of running GRUB configuration directly, the package should use a trigger for that, to avoid doing it more than once when multiple hypervisor packages are installed (not speaking about other kernels). -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (502,

Package: xen-hypervisor-4.2-amd64 Version: 4.2.1-2 Severity: critical Tags: upstream Justification: breaks the whole system Dear Maintainer, After migration from Xen 4.1 to 4.2 all VMs have disapeared and I am unable to "re-create" my VM from the configfiles. When I try "xm new com-web" i get a python message : Using config file "./com-web". Error:

Package: xen-hypervisor-3.0.3-1-i386 Version: 3.0.3-0-1 Severity: normal -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, When you have a HVM domain running, if you try to boot a regular paravirtualized domain, dom0 (or maybe the hypervisor) crashes immediately (reboot). The opposite (trying to boot a HVM domain while a regular paravirtualized domain is running) crashes the system as well. I

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal I'm not an expert in networking but I think that the current setup when using network-nat for domains is insecure. I've configured : (network-script 'network-nat netdev=eth1') (vif-script vif-nat) So when only domain 0 is started, I get the following : # iptables -L -n Chain INPUT (policy ACCEPT) target prot

Hi all, I've been looking at the next steps to try to get Xen running fully on top of pv_ops. To that end, I've (just) started looking at one of the next major jobs --- i686 dom0 on pv_ops. There are still a number of things needing done to reach parity with xen-unstable: x86_64 xen on pv_ops Paravirt framebuffer/keyboard CPU hotplug Balloon kexec driver domains but it

Hi all, I've been looking at the next steps to try to get Xen running fully on top of pv_ops. To that end, I've (just) started looking at one of the next major jobs --- i686 dom0 on pv_ops. There are still a number of things needing done to reach parity with xen-unstable: x86_64 xen on pv_ops Paravirt framebuffer/keyboard CPU hotplug Balloon kexec driver domains but it

Hi all, I've been looking at the next steps to try to get Xen running fully on top of pv_ops. To that end, I've (just) started looking at one of the next major jobs --- i686 dom0 on pv_ops. There are still a number of things needing done to reach parity with xen-unstable: x86_64 xen on pv_ops Paravirt framebuffer/keyboard CPU hotplug Balloon kexec driver domains but it

Package: xen-hypervisor-4.1-amd64 Version: 4.1.1-3 Severity: important Whenever I try to start a domU, xm create failed for 'Boot loader didn't return any data!'. % sudo xm create -c squeeze.cfg Using config file "/etc/xen/squeeze.cfg". Error: Boot loader didn't return any data! It seems related to the following error in dmesg [1440.163935] pygrub[3654] trap invalid

Package: xen-utils-common Version: 3.4.2-1 Severity: important File: /etc/init.d/xend Tags: patch Hello, /etc/init.d/xend assume xenfs is present and doesn't start xend if not. This dirty patch makes xend start and XEN being operationnal with old flavour xen kernels. I use 2.6.31.5 with forwarded ported Xen 2.6.18 dom0 kernel patch but it should work with debian's 2.6.26 ---

After the last round of patches to febootstrap, the image-based test in libguestfs still failed. It turned out that this happens because Debian started replacing /var/run and /var/lock with symlinks that point to a tmpfs mounted to /run. The symlinks were copied to the appliance but /run/lock did not exist, so pvcreate refused to run (script 'images/guest-aux/make-debian-img.sh'). After I

Hi Ghislain, I think you might be comparing two versions of R with different BLAS implementations, one that is single threaded (is your 3.3.2 used with reference blas?) and one that is multi threaded (3.4.1 with openblas). Could you check with "perf"? E.g. run your benchmark with "perf record" in both cases and you should see the names of the hot BLAS functions and this

Dear all, As the object of this mail suggests, the methods package is not loaded by default in R2.13 when using Rscript whereas it is loaded when using an interactive session. An example with the metafor package : library(metafor) example(addpoly.rma) this works in an interaction R shell, but put it in a .R file and use it with Rscript, it won't work until you added library(methods)

Package: xen-utils-unstable Version: 3.3-unstable+hg17192-1 Severity: important Tags: patch In tools/firmware/Makefile, INST_DIR is $(DESTDIR)/usr/$(PREFIX)/boot but $(PREFIX) is empty. hvmloader doesn't get installed. diff -ru xen-unstable-3.3-unstable+hg17192.orig/debian/patches/tools-prefix.diff xen-unstable-3.3-unstable+hg17192/debian/patches/tools-prefix.diff ---

Hi Ghislain, The documentation at https://cran.r-project.org/doc/manuals/r-release/R-admin.html#BLAS provides a fair bit of information. What specifically would you like to see added? Best, Ista On Mon, Aug 21, 2017 at 10:13 AM, Ghislain Durif <ghislain.durif at inria.fr> wrote: > Hi Tomas, > > Thanks for your answer. > > Indeed, I checked and my R-3.4.1 installed from the

Package: xen-utils-common Version: 4.1.2-7 Severity: grave Tags: patch Justification: renders package unusable Dear Maintainer, The script /usr/lib/xen-common/bin/xen-toolstack improperly aborts if *either* `xm` or `xl` cannot be found in the xen-dir (/usr/lib/xen-4.0/bin). This means that a default installation (e.g. following Debian wiki on the subject, namely installing xen-linux-system and