Bug#643953: Copy of the problematic grub config file?
On 07/09/2012 10:44 PM, Ian Campbell wrote: Do you by any chance have a copy of the problematic configuration file? Unfortunately not. Best I can tell, older versions of Debian's update-grub would output that divider, but I can't find anything in my current install that would generate it. Best I can do is find some unrelated examples from other people, like this one: http://old.nabble.com/Re:-Grub2---windows-p25735425.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677424: lsb-base: status_of_proc returns 4 (unknown) when pid file is specified and does not exist
On 06/18/2012 12:21 PM, Didier 'OdyX' Raboud wrote: As you reported this bug against the Debian stable release, lsb-base has seen many updates since then and I suspect that your bug above has been fixed by the resolution of bug #597628 in lsb 3.2-25. Can you verify that any of a) the attached init-functions-a (to be put as /lib/lsb/init-functions) file solves your bug (it's a file from stable + patches up to 3.2-25); b) the attached init-functions-b (to be put as /lib/lsb/init-functions) file solves your bug (it's a file from stable + all patches concerning pidofproc in the current unstable); c) the lsb-base package from the current testing or unstable do so; Â… solves your issue. It looks like both init-functions-a and init-functions-b solve my issue. I did not test the package from testing or unstable. I would say as a minor point that the change introduced in init-functions-a is correct in my particular case, but maybe not in others. For example, what if the pid file exists, but is not readable? The service could very well be running, but init-functions-a will return not running, if I'm reading it correctly. I don't see anything in the specification that says what to do in this case, but unknown seems like a better answer than not running to me. I suppose a case could also be made to attempt a guess as if no pidfile were available, though personally I'd regard that as DWIM and avoid it. The deeply nested logic in init-functions-b is hard to read and understand, but seems to partially address this. As I read it, it will return unknown if the pid file exists but is not readable. However, I wonder under what conditions the last conditional could be true: if [ $specified ]; then return 3 # almost certain it's not running fi I think the answer is only weird edge cases. Like, if $pidfile='', or if the pidfile didn't contain a PID. Under these conditions, pidofproc returns unknown if the pidfile is unspecified; I don't know if explicitly specifying an invalid pidfile makes things any less unknown. From my perspective (cluster management) unknown is the only correct answer here, since in either case something is seriously wrong, and the right thing to do is fence the troublesome node. Of course, if you pretend nothing is wrong, then the cluster manager can't do that. The other possibility (saying the service isn't running, which actually you aren't sure) leads to a situation where actually two mutually exclusive resources could be started by the cluster manager. For example, the same filesystem on a SAN could be mounted twice, or two DRBD nodes could be made primary. Again, these are minor points. Since I don't actually use LSB init scripts for mounting my filesystems or promoting my DRBD nodes, the horrible data corruption scenarios I give can't actually exist. Probably this is true of most clusters in practice, but still, the possibility exists that someone will be surprised by this overly-optimistic behavior someday. If you wanted to close this bug I wouldn't object, and I'll open another one when I can think of a real-world use case. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677424: lsb-base: status_of_proc returns 4 (unknown) when pid file is specified and does not exist
Package: lsb-base
Version: 3.2-23.2squeeze1
Severity: normal
Tags: patch
The specific problem I'm experiencing is with /etc/init.d/portmap, which
returns 4 when portmap isn't running. I can't find sufficient documentation on
correct behavior to be sure if init-functions is incorrect, or if portmap is
using it incorrectly, but I think it's the former.
This actually causes serious problems at least in managing portmap with
pacemaker, which requires init scripts to comply strictly with the LSB
specification [2]. Pacemaker will call the status action periodically to
monitor the service, and if the response is unknown, the monitor action is
considered to have failed, which might get the node ejected from the cluster,
or at least prevent other things from running as they should.
I think the crux of the issue is the implementation of pidofproc. The LSB
specification [1] says about pidofproc:
If the -p pidfile option is specified and the named pidfile does not
exist, the functions shall assume that the daemon is not running.
At the end of pidofproc is this:
if [ -x /bin/pidof -a ! $specified ]; then
status=0
/bin/pidof -o %PPID -x $1 || status=$?
if [ $status = 1 ]; then
return 3 # program is not running
fi
return 0
fi
return 4 # Unable to determine status
The way I read this, pidofproc can't return 3 if a pidfile is specified, which
I think is wrong according to the LSB specification. As I read the spec [1], if
the pidfile doesn't exist, and it was explicitly specified, then pidofproc
should return 3. No process table grepping or anything else allowed. In that
spirit, I propose this patch, which at least solves my problem:
--- init-functions.orig 2012-06-13 16:55:02.0 -0400
+++ init-functions 2012-06-13 17:02:58.0 -0400
@@ -77,6 +77,9 @@
pidfile=/var/run/$base.pid
fi
+if [ $specified -a -n ${pidfile:-} -a ! -e $pidfile ]; then
+return 3 # explicitly specified pidfile does not exist; must assume
not running
+fi
if [ -n ${pidfile:-} -a -r $pidfile ]; then
read pid $pidfile
if [ -n ${pid:-} ]; then
-- System Information:
Debian Release: 6.0.5
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages lsb-base depends on:
ii ncurses-bin 5.7+20100313-5 terminal-related programs and man
ii sed 4.2.1-7The GNU sed stream editor
lsb-base recommends no packages.
lsb-base suggests no packages.
-- no debconf information
[1]
http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html
[2]
http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/ap-lsb.html
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648448: Duplicate packages with different checksums in squeeze and squeeze-security
Bump? This seems like a very annoying problem with a trivial solution. Every time I run apt-get update, the version from squeeze is installed, but then my monitoring detects unapplied security updates and alarms go off. If I force installing the version from squeeze-security, then different alarms go off for unapplied squeeze updates. If I'm wrong about the trivial solution part, is there any reasonable workaround? Maybe there's some pinning magic that can be done? I've looked, but I can't think of a way to construct a rule that doesn't ignore more than necessary, like ignoring all security updates or all updates to the Xen packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650300: xen-tools: xt-guess-suite-and-mirror fails when using sources.list.d
Package: xen-tools Version: 4.2-1 Severity: normal If apt is configured with sources.list.d (and not sources.list), then xt-guess-suite-and-mirror won't guess anything. It looks like it makes no attempt at all to parse sources.list.d. This means that xen-create-image, with the default xen-tools.conf with reasonable modifications, will fail because it can't find any directory named /usr/lib/xen-tools/.d, because the dist option is empty, because xt-guess-suite-and-mirror doesn't write anything to stdout. Further, it exits with zero status so the real problem is masked. Setting the dist and mirror options to not use xt-guess-suite-and-mirror seems to work around the problem, but given the silent failure of xt-guess-suite-and-mirror, realizing this takes a bit of work. -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xen-tools depends on: ii debootstrap1.0.26+squeeze1 Bootstrap a basic Debian system ii libconfig-inifiles-per 2.52-1Read .ini-style configuration file ii libfile-slurp-perl .13-1 single call read write file rout ii libtext-template-perl 1.45-1Text::Template perl module ii perl-modules 5.10.1-17squeeze2 Core Perl modules Versions of packages xen-tools recommends: ii libexpect-perl1.20-2 Expect.pm - Perl Expect interface ii rinse 1.7-1 RPM installation environment ii xen-hypervisor-4.0-amd64 [xen 4.0.1-4The Xen Hypervisor on AMD64 pn xen-shell none (no description available) Versions of packages xen-tools suggests: pn btrfs-tools none (no description available) pn cfengine2 none (no description available) pn evms-cli none (no description available) pn reiserfsprogs none (no description available) ii xen-utils-4.0 [xen-utils] 4.0.1-4XEN administrative tools pn xfsprogs none (no description available) -- Configuration Files: /etc/xen-tools/xen-tools.conf changed: lvm = vmimages install-method = debootstrap size = 2Gb # Disk image size. memory = 128Mb# Memory size swap = 1Gb # Swap size fs = ext3 # use the EXT3 filesystem for the disk image. dist = `xt-guess-suite-and-mirror --suite` # Default distribution to install. image = sparse # Specify sparse vs. full disk images. gateway= 172.20.20.1 netmask= 255.255.255.0 broadcast = 172.20.20.255 passwd = 1 kernel = /boot/vmlinuz-`uname -r` initrd = /boot/initrd.img-`uname -r` mirror = `xt-guess-suite-and-mirror --mirror` ext3_options = noatime,nodiratime,errors=remount-ro ext2_options = noatime,nodiratime,errors=remount-ro xfs_options = defaults reiserfs_options = defaults btrfs_options= defaults pygrub = 1 vcpus = 1 role = macpros_puppet -- 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#643953: xen-utils-4.0: pygrub can not parse empty root statement in menu.lst
Package: xen-utils-4.0 Version: 4.0.1-2 Severity: normal Trying to get a system that I've long had runing on the bare metal to boot as a VM, I discovered that pygrub would not parse my menu.lst. The problematic entry is this: # This is a divider, added to separate the menu items below from the Debian # ones. title Other operating systems: root pygrub's parser seems to expect that root will be followed by a disk specification. I get this traceback: File ./pygrub, line 669, in module chosencfg = run_grub(file, entry, fs, incfg[args]) File ./pygrub, line 549, in run_grub g = Grub(file, fs) File ./pygrub, line 205, in __init__ self.read_config(file, fs) File ./pygrub, line 413, in read_config self.cf.parse(buf) File /usr/lib/xen-4.0/bin/../lib/python/grub/GrubConf.py, line 284, in parse self.add_image(GrubImage(title, img)) File /usr/lib/xen-4.0/bin/../lib/python/grub/GrubConf.py, line 134, in __init__ _GrubImage.__init__(self, title, lines) File /usr/lib/xen-4.0/bin/../lib/python/grub/GrubConf.py, line 87, in __init__ self.reset(lines) File /usr/lib/xen-4.0/bin/../lib/python/grub/GrubConf.py, line 103, in reset self._parse(lines) File /usr/lib/xen-4.0/bin/../lib/python/grub/GrubConf.py, line 98, in _parse map(self.set_from_line, lines) File /usr/lib/xen-4.0/bin/../lib/python/grub/GrubConf.py, line 141, in set_from_line setattr(self, self.commands[com], arg.strip()) File /usr/lib/xen-4.0/bin/../lib/python/grub/GrubConf.py, line 106, in set_root self._root = GrubDiskPart(val) File /usr/lib/xen-4.0/bin/../lib/python/grub/GrubConf.py, line 57, in __init__ self.disk = str File /usr/lib/xen-4.0/bin/../lib/python/grub/GrubConf.py, line 70, in set_disk self._disk = int(val[2:]) ValueError: invalid literal for int() with base 10: '' -- System Information: Debian Release: 6.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xen-utils-4.0 depends on: ii e2fslibs1.41.12-4stable1 ext2/ext3/ext4 file system librari ii iproute 20100519-3 networking and traffic control too ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libncurses5 5.7+20100313-5 shared libraries for terminal hand ii libxenstore3.0 4.0.1-2 Xenstore communications library fo ii python-support 1.0.10 automated rebuilding support for P ii python2.5 2.5.5-11 An interactive high-level object-o ii udev164-3/dev/ and hotplug management daemo ii xen-utils-common4.0.0-1 XEN administrative tools - common ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages xen-utils-4.0 recommends: ii bridge-utils 1.4-5 Utilities for configuring the Linu ii xen-hypervisor-4.0-amd64 [xen 4.0.1-2The Xen Hypervisor on AMD64 Versions of packages xen-utils-4.0 suggests: pn xen-docs-4.0 none (no description available) -- 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
