similar to: Bug#744160: xl.conf ambiguity

Package: xen-utils-4.1 Version: 4.1.4-3+deb7u1 Switching to the xl toolstack I expected my configuration to work unmodified, but it doesn't, and I couldn't find any documentation regarding this, since xl.cfg(5) is missing. Original version, used with xm: vfb = ['type=vnc,vnclisten=0.0.0.0:6369,vncdisplay=6369,vncpasswd=x'] Working xl version: vnclisten="0.0.0.0:6369"

Package: xen-utils-4.1 Version: 4.1.4-3+deb7u1 Severity: normal It seems to be impossible to save or migrate HVM guest using the xl toolstack. Trying to do so hangs the process initiating the action, and the domU can't be shut down with the 'xl shutdown' command after this. 'xl destroy' works. The domain keeps running during the save operation, doesn't get paused for any

Package: xen-utils-4.1 Version: 4.1.4-3+deb7u1 Severity: important Tags: security patch When you use xl toolstack, you can't reboot domUs. When you switch back to xm toolstack, than reboot works again. I think the problem with the debian packaged version is the same as in this thread: http://lists.xen.org/archives/html/xen-devel/2011-09/msg01289.html I also think it's a security issue,

Package: xen-utils-common Version: 4.1.4-2 Severity: minor The syntax that the scripts use prevents one from creating a vif named "dev", for example. Attached is a patch for one script, but the syntax that skips using the "dev" keyword is present in other scripts, like vif-bridge. -------------- next part -------------- A non-text attachment was scrubbed... Name:

Package: xen-utils-4.1 Version: 4.1.3-7 Severity: normal pygrub looks for extlinux config files "/boot/isolinux/isolinux.cfg" and "/boot/extlinux.conf", but the default Debian installation uses the config file "/boot/extlinux/extlinux.conf". (See /usr/lib/xen-4.1/bin/pygrub lines 405-407.) ...Marvin -- System Information: Debian Release: 7.0 APT prefers testing

Package: xen Version: 4.0.1-5.11 Severity: important Tags: security, patch, fixed-upstream http://www.openwall.com/lists/oss-security/2013/11/21/2 Description: An inverted boolean parameter resulted in TLB flushes not happening upon clearing of a present translation table entry. Retaining stale TLB entries could allow guests access to memory that ought to have been revoked, or grant greater

I'm afraid this still doesn't work even after upgrading to jessie (xen-utils-4.3 4.3.0-3+b1). Should I open a new bug against xen-utils-4.3 or can this bug somehow be applied to that package as well?

Package: xen-utils-4.1 Version: 4.1.3-7 Severity: normal The function is_disk_image in /usr/lib/xen-4.1/bin/pygrub at line 45 distinguishes a partitioned disk from a partition by looking for 0xaa55 at offset 0x1fe in the image, but this is the bootsector signature, not the partition table signature. extlinux and other bootloaders put this signature there on bootable partitions (which don't

Package: xen-utils-4.1 Version: 4.1.3-7 Severity: normal The grub.cfg created by a default Debian installation uses many configuration statements that pygrub does not recognize, and pygrub is unable to find any kernel to load. ...Marvin -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500,

Package: xen-utils-4.1 Version: 4.1.3-7 Severity: normal pygrub does not recognize the include statement in extlinux.conf. The default Debian installation of extlinux creates a stub extlinux.conf which includes linux.cfg, where all the linux image entries are. This means that even if bugs 697407 and 697409 are fixed, pygrub still can't find the right kernel on a default Debian installation

Package: xen-utils-common Version: 4.1.4-3+deb7u1 Severity: normal Dear Maintainer, i changed toolkit to xl, after that i observe that my domU started as HVM domains. I found same problem here: http://mail-index.netbsd.org/port-xen/2012/04/11/msg007216.html When i manualy setup loop devices and specify it as disks in my VM conf file, domU started as PV. -- System Information: Debian Release: 7.1

Package: xen-utils-4.3 Version: 4.3.0-3 Severity: important Tags: upstream patch When using Xen compiled with seabios-1.7.4-1 (now in unstable/testing), HVMs fail immediately upon starting with a VCPU triple fault: (XEN) HVM1: Loading SeaBIOS ... (XEN) hvm.c:1253:d1 Triple fault on VCPU0 - invoking HVM shutdown action 1. This is because SeaBIOS can now be greater than 128k, which breaks an

Based on Waldi''s RFC at http://lists.xen.org/archives/html/xen-devel/2012-09/msg00943.html To use it set vif.default.script="vif-openvswitch" in /etc/xen/xl.conf or use script=vif-openvswitch in the vif configuration. Appears to do the right thing for PV and HVM guests (including tap devices) and with stubdomains. In order to support VLAN tagging and trunking the

Package: xen-utils-4.3 Version: 4.3.0-3+b1 Using the xl toolstack there's no information about the networks of the domUs in xentop. I have a PV and a HVM domU and both are shown as having 0 network interfaces, while in fact they have functioning interfaces. Here's one of the interfaces that should be shown, from xenstore: 29 = "" 0 = "" frontend =

Hallo Mailinglist:), i used xen 4.1 with xend xm a while. I compiled the unstable 4.2 today and most thinks run fine :). I have only one big problem, the network for my guestsystems. It don't want to work. Hopefully somebody can help me. In Xen 4.1 i only wrote the following line in my questconfig: vif = [ "bridge=eth0,script=vif-bridge" ] And everything works fine. This does not

Processing commands for control at bugs.debian.org: > tags 744157 +fixed-upstream Bug #744157 [xen-utils-4.1] VNC parameters can be set only globally using xl Added tag(s) fixed-upstream. > tags 744159 +fixed-upstream Bug #744159 [xen-utils-4.1] HVM guest can't be saved/migrated with xl Added tag(s) fixed-upstream. > tags 744160 +fixed-upstream Bug #744160 [xen-utils-common] xl.conf

Your message dated Sun, 10 Aug 2014 12:00:17 +0000 with message-id <E1XGRnN-0007ak-6G at franck.debian.org> and subject line Bug#718898: fixed in xen 4.4.0-1 has caused the Debian Bug report #718898, regarding coreutils: cut no longer works with newline as delimiter to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your

Hi All, I am confused by a type conversion happening against my intent. In an R script I allocate a matrix X, and I pass it to a C function by using tmp -< .C(..., as.double(X),...). I use as.double() because I read that it makes sure that the parameter passing is correct. I return the matrix from the R script using: return (list(..., X = tmp$X, ...)) The returned value is not a matrix

https://bugs.freedesktop.org/show_bug.cgi?id=82255 Priority: medium Bug ID: 82255 Assignee: nouveau at lists.freedesktop.org Summary: [VP2] Chroma planes are vertically stretched during VDPAU playback Severity: normal Classification: Unclassified OS: All Reporter: emil.l.velikov at gmail.com

2010/1/25 Edmund Grimley Evans <Edmund.Grimley-Evans at arm.com>: > I just got this error message from the GNU assembler: > > Error: alignment too large: 15 assumed > > Which made me laugh at first. The corresponding input line was: > >        .align  16 > > Apparently what's going on here is that ".align 16" is ambiguous: on > some architectures