similar to: xen-utils-common buggy in squeeze: The script hotplugpath.sh is missing in /etc/xen/scripts

Is there a fix for this in the works/coming for squeeze or do I have to patch the package myself? If so, how? Thanks, a grateful Debian user that hasn't patched packages yet! Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20101122/8433308c/attachment.htm>

FYI: This bug also breaks user supplied scripts (/etc/xen/scripts/block-*) that are needed to handle block device mounting other than "phy:" and "file:" disks. See attached email from debian-user mailing list. cheers -henrik -------------- next part -------------- An embedded message was scrubbed... From: Henrik Langos <hlangos-debian at innominate.com> Subject: Re:

Package: xen-utils-common Version: 4.0.0-1 Severity: important When Xen is configured in routed mode, restarting xend fails because the script hotplugpath.sh is missing. Please see below for more information. *** root at eliott:~# /etc/init.d/xend restart Restarting Xen daemons: xend/etc/xen/scripts/network-route: line 20: /etc/xen/scripts/hotplugpath.sh: No such file or directory

Package: xen-utils-common Version: 4.1.4-3 Severity: important Dear Maintainer, While updating my xen package today, I was prompted with a config file conflict. --- /etc/xen/scripts/hotplugpath.sh 2013-04-28 01:51:20.899778510 +0800 +++ /etc/xen/scripts/hotplugpath.sh.dpkg-new 2013-04-19 19:39:55.000000000 +0800 @@ -1,12 +1,10 @@ SBINDIR="/usr/sbin" BINDIR="/usr/bin"

Hi, I was thinking about a common (I hope!) use case of Glusterfs geo-replication. Imagine 3 different facility having their own glusterfs deployment: * central-office * remote-office1 * remote-office2 Every client mount their local glusterfs deployment and write files (i.e.: user A deposit a PDF document on remote-office2), and it get replicated to the central-office glusterfs volume as soon

Hello List, why is the Bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591456 not fixed yet? It was already reported back in 2010 and a patch was already supplied, too. Is this a bigger deal? Thanks, Mario

Hi, I've got troubles after few minutes of glusterfs operations. I setup a 4-node replica 4 storage, with 2 bricks on every server: # gluster volume create vms replica 4 transport tcp 192.168.7.1:/srv/vol1 192.168.7.2:/srv/vol1 192.168.7.3:/srv/vol1 192.168.7.4:/srv/vol1 192.168.7.1:/srv/vol2 192.168.7.2:/srv/vol2 192.168.7.3:/srv/vol2 192.168.7.4:/srv/vol2 I started copying files with

-----Original message----- From: Paul Muster paul@muster.dyndns.info Date: Thu, 13 Oct 2011 08:29:37 -0500 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] The script hotplugpath.sh ismissing in/etc/xen/scripts > On 13.10.2011 01:52, Barry Kolts wrote: > > > What I did, following the instructions on the last page > > Paul referred to, is add "deb

Processing commands for control at bugs.debian.org: > severity 588406 important Bug #588406 [xen-utils-common] xen-utils-common: /etc/xen/scripts/block not driving helper scripts; XEN_SCRIPT_DIR not properly set Severity set to 'important' from 'normal' > tags 588406 patch Bug #588406 [xen-utils-common] xen-utils-common: /etc/xen/scripts/block not driving helper scripts;

Hey everyone, I have a question about vif-common.sh. I run multiple bridges attached on dummy interfaces, which allow me to put guests in seperate subnets (routed through the dom0). As you might expect I already have quite extensive iptables scripts to accomidate this kind of routing. I was just hoping someone on this list can confirm, that I understand what the iptables lines in vif-common.sh

When start a domU through xl create. The domU associated ip in the configuration file is not recorded in the xenstore. For this reason vif-common.sh antispoof scripts fails. *xl create * /usr/bin/xenstore-ls /local/domain/0/backend/vif/5/0 frontend = "/local/domain/5/device/vif/0" frontend-id = "5" online = "1" state = "4" script =

Package: xen-utils-common Version: 4.1.4-3 Severity: important Dear Maintainer, Executive summary: dist-upgrade - squeeze to wheezy. Rebooted machine; no default route on network interface eth0. Commented 'transfer_addrs' function in network-bridge produced a machine which worked after reboot. We're using network-bridge as our xen networking configuration. After rebooting the

I changed the suggested line in /etc/xen/xend-config.sxp configuration file, but the errors about the file hotplugpath.sh are still present. root at eliott:~# /etc/init.d/xend start Starting Xen daemons: xenstored xenconsoled xend/etc/xen/scripts/network-route: line 20: /etc/xen/scripts/hotplugpath.sh: No such file or directory /etc/xen/scripts/network-route: line 20:

Package: xen-utils-common Version: 4.8.3+comet2+shim4.10.0+comet3-1+deb9u5 Severity: important Tags: patch security -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),

I am using Debian 6.0 "Squeeze", I applied that patch (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591456) to xen-common because of lack of hotplugpath.sh. network-route netdev=eth1 now does work, but vif-route gives me this error: root at xen-dom0:~# xm create /srv/xen/profiles/ca.cfg Using config file "/srv/xen/profiles/ca.cfg". Error: Device 0 (vif) could not be

I am using Debian 6.0 "Squeeze", I applied that patch (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591456) to xen-common because of lack of hotplugpath.sh. network-route netdev=eth1 now does work, but vif-route gives me this error: root at xen-dom0:~# xm create /srv/xen/profiles/ca.cfg Using config file "/srv/xen/profiles/ca.cfg". Error: Device 0 (vif) could not be

Package: xen-utils-common Version: 4.4.1-5 Severity: important Dear Maintainer, I tried to upgrade xen-utils-4.4 depending on xen-utils-common. Here is aptitude answer: ... Param?trage de xen-utils-common (4.4.1-5) ... insserv: Service xenstored has to be enabled to start service xendomains insserv: Service xenconsoled has to be enabled to start service xendomains insserv: exiting now!

I had some problems getting Xen to work on my machine. I tracked down the problem to the function dom0_ip in vif-common.sh which shall retrieve the ip address of the main network device of dom0. This function, however, fails in some admittedly unusual configurations. The machine in question is a rented server. The LAN adapter is configured with a /32 netmask. I have debian, and this is an excerpt

I am brand new to vpim, so I tried to use the example cmd-itip.sh. But it fails on the code: if e.comments with the error message: ./cmd-itip.txt.sh:113: undefined method `comment'' for #<Vpim::Icalendar::Vevent:0x101899c> (NoMethodError) In the rdoc it says there should be Icalendar::Get::Common#comment But there is no module Get in Vpim:Icalendar. There is the module

On 9/13/18 11:09 AM, Richard W.M. Jones wrote: > This resurrects the unused tests/functions.sh file (although now we > need to generate it from tests/functions.sh.in). Put the common code > for running a test against every plugin here. > > Because of the previous commits we can now use the plugins list > directly from configure.ac instead of needing to use weird shell >