similar to: Bug#458502: xen-utils-common: Slight problem with LSB header in init.d script

Package: xen-utils-common Version: 3.0+hg11292-2 Tags: patch User: initscripts-ng-devel at lists.alioth.debian.org Usertags: incorrect-dependency When testing dependency based boot sequencing, I discovered a bug in the init.d script for xen-utils-common. It is set to stop in the boot "runlevel" (S), but no script should stop there. Also, xend only depend on $local_fs, but

Package: xen-utils-common Version: 3.0.3-0-2 Severity: important patch I ran into this problem when using xen on Debian/Etch. I have several virtual xen instanses, and I name them using their fully qualified DNS domain name. These machines have failed to start automatically when I booted the host machine, and I just recently found out why. During shutdown, I was messages like this: Error:

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal There should be a clean and clearly defined way to restart all the Xen daemons in the case of error. If the file /var/lib/xenstored/tdb is corrupt then you must stop xenstored, rm the file, and then restart it. Currently there is no defined way of doing this so the solution is to kill -9 the process, rm the file, and then reboot. --

Package: xen-utils-common Version: 4.0.0-1 Severity: important When xen domUs are saved by running /etc/init.d/xendomains stop the memory images are saved world readable, so that every user on the system can read the memory dumps. The default mode of /var/lib/xen/save is 755, vm images are saved with mode 755. At least the save directory shoudn't be world readable. -- System Information:

I had to apply this patch to configure.in to get configure to run on Tru64 Unix on Alpha. The RSA test forgot to reset $LIBS. (The compile stopped with missing "zlib.h". I'll send more patches if required. :-) diff -ur src-2.9p1/configure.in src-2.9p1-local/configure.in --- src-2.9p1/configure.in Wed Jun 6 17:15:09 2001 +++ src-2.9p1-local/configure.in Wed Jun 6

Package: xen-utils-common Version: 4.0.0-1 Severity: important After running modules_setup you need to have the following line: [ -x /sbin/restorecon ] && /sbin/restorecon -R /dev/xen The reason is that the module load causes the kernel to create device nodes in the devtmpfs. This bypasses the udev code for labelling the device node and results in xenstored being unable to access

Subject: xen-utils-common: /etc/init.d/xen restart fails when using network-bridge if netdev does not match eth[0-9+] Package: xen-utils-common Version: 3.1.0-1 Severity: normal *** Please type your report below this line *** On a machine where the NICs are named something other than ethN, and using (network-script 'network-bridge netdev=XXX') (where XXX is the name of one of these

Package: xen-utils-common Version: 4.3.0-3 Severity: normal Dear Maintainer, * What led up to the situation? I upgraded my server from squeeze to wheezy and then to jessie. Server is Intel S3200SHV m/b with Intel(R) Core(TM)2 Quad CPU. I'm pretty sure that before that it was running whatever came before squeeze, I forget the name. I was trying to get xen_pciback to work, so I

Package: xen-utils-common Version: 3.0.3-0-2 I discovered this the hard way, trying to follow the instructions from the manual page and failing to get it to work. The xm(1) manual page include this text: BLOCK DEVICES block-attach domain-id be-dev fe-dev mode [bedomain-id] [...] mode The access mode for the device from the guest domain.

Package: xen-utils-common Version: 3.0.3-0-2 Severity: minor Tags: patch Hi ! /etc/init.d/xendomains and /etc/init.d/xend complain about xen-utils-version not existing any more instead of failing silently. The following patch fix this problem. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1,

Package: xen-utils-common Version: 4.6.0-1+nmu2 Severity: important Dear Maintainer, xen-init-name is a Python script which parses output of the following command: xen create --quiet --dryrun --defconfig /etc/xen/test1.cfg But there is no 'config' key in JSON output of the command above. The following patch fixes this error. Please apply. Thank you very much, LH ---

Package: xen-utils-common Version: 4.0.0-1 Severity: normal A strange issue, when deploying Xen using Puppet, /etc/udev/rules.d/xend.rules and /etc/udev/rules.d/xen-backend.rules files are empty. Specifically, the symlinks point to ../xend.rules and ../xen-backend.rules respectively in /etc/udev, but neither of those files exist. Manually copying those files from another host that was not

https://bugs.freedesktop.org/show_bug.cgi?id=108783 Bug ID: 108783 Summary: Nouveau crash in X server / display system with PAGE_NOT_PRESENT/NULL_DMAOBJ running Minecraft Feed The Beast Continuum Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All)

Package: xen-utils-common Version: 4.0.0-1 Severity: normal This is an offshoot of Bug#588888, but is really a separate issue. It appears that with hvmloader, the disk device names presented to the vm must by from a specific set that hvmloader knows how to emulate. Names like hd[a-c] and sd[a-c] work, but sr0 does not. While this makes sense, when you think about what hvmloader is doing, it is

Package: xen-utils-common Version: 4.4.1-9 Severity: important This bug was already reported as #763102 and was brushed off because maintainer says it implicates xend which is not there in 4.4 anymore. However, this problem is present during upgrade from wheezy to jessie and means that reboots are not possible without physical interventions. As noted in #763102, during shutdown, we can see this

Package: xen-utils-common Version: 4.4.1-9+deb8u1 Severity: normal With SE Linux it's desirable to give utilities and daemons the minimum privileges. That includes not permitting general utilities to create directories under /var/run. I think it would be best if /var/run/xen-hotplug was created by an init script such as /etc/init.d/xen (or by systemd-tmpfiles when using systemd units).

Package: xen-utils-common Version: 3.0.3-0-2 Severity: minor Here's an excerpt from /etc/init.d/xend: *) N=/etc/init.d/xen-utils echo "Usage: $N {start|stop|restart|force-reload}" >&2 exit 1 ;; This will obviously display a wrong path when the script is called with unknown arguments. Regards, -- J?r?my -------------- next part

Package: xen-utils-common Version: 4.4.0-5 Severity: important Tags: patch Hello, xen-init-list fails to parse output of xen list -l when using XM toolstack. Therefore, /etc/init.d/xendomains stop fails to shutdown any guests still running on shutdown. xen-init-list fails with the following message: /usr/lib/xen-common/bin/xen-init-list Traceback (most recent call last): File

Package: xen-utils-common Version: 4.4.1-3 I use xen, and I start some domains using symlinks in /etc/xen/auto. On startup, the file /etc/init.d/xendomains is supposed to start them. It does start the domains, but it also throws out a bunch of errors: /etc/init.d/xendomains: line 135: domains: bad array subscript The culprit is this line in /etc/init.d/xendomains:

> This bug was already reported as #763102 and was brushed off because maintainer > says it implicates xend which is not there in 4.4 anymore. Quoting the explanation sent when closing #763102: If you think a bug has been associated with xend in error please check if it still reproduces with the packages in Jessie (currently 4.4.1-3) and reopen. I'm sorry you felt this was