Bug#991586: unbound systemd service should use network-online.target instead of network.target
Package: unbound Version: 1.9.0-2+deb10u2 When starting unbound and binding to a specific interface using the `interface` keyword, unbound can fail if the interface is not configured correctly on boot. Changing the systemd unit to use the `network-online.target` instead of the `network.target` remedies the situation. Once the interface is online, unbound succeeds in binding to the interface and starts correctly. There is also another bug report (for the Ubuntu package) where another reason for switching to using `network-online.target` is given: https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1923733 That bug report suggests reporting the bug against the Debian package as they use the Debian package unmodified, but I cannot find a corresponding bug report. -- Marcus Furlong
Bug#946852:
Removing `,rsa1` in /usr/share/perl5/Smokeping/probes/SSH.pm fixes the issue. -- Marcus Furlong
Bug#932838:
This leads to people disabling functionality. See e,g,: https://gerrit.wikimedia.org/r/#/c/operations/docker-images/docker-pkg/+/487849/3/docker_pkg/image.py -- Marcus Furlong
Bug#932838: python-apt package on pypi should be updated
Package: python-apt The python-apt package on pypi is outdated (seems to be from 2012) and fails to install when trying to pip install: # pip install python-apt || 51kB 12.8MB/s ERROR: Complete output from command python setup.py egg_info: ERROR: Traceback (most recent call last): File "", line 1, in File "/tmp/pip-install-nvaql1yl/python-apt/setup.py", line 6, in from DistUtilsExtra.command import * ModuleNotFoundError: No module named 'DistUtilsExtra' ERROR: Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-install-nvaql1yl/python-apt/ See https://pypi.org/project/python-apt/#history Would it be possible to update this package to the most recent version? -- Marcus Furlong
Bug#913274: Incorrectly parsing whitespace in Sources.iter_paragraphs
> > Passing the contents does the correct thing in all other cases, so not
> > sure why it would be having an issue with this?
>
> Ahah!
>
> TagFile only accepts filehandles, not static data:
>
> https://salsa.debian.org/apt-team/python-apt/blob/master/python/tag.cc#L750
>
> In deb822.py there is a function _is_real_file() and that is used so that
> python-apt's TagFile is only invoked on filehandles and not on text data,
> diverting to the in-built parser when TagFile cannot be used.
So in my case, the in-built parser is being used and it is stricter
than python-apt's parser?
> BTW if you are read()ing so that you can deal with the compressed Pacakges.gz,
> TagFile can handle on-the-fly decompression.
>
> In [1]: from debian.deb822 import Packages
>
> In [2]: with open('Packages.gz') as fh:
>...: for p in Packages.iter_paragraphs(fh):
>...: if 'version' not in p:
>...: print(p)
>
> (wild guess as to why you might be doing this!)
One reason I'm doing it is for decompression, but a second reason is
to provide feedback to the user via a progress bar. To do that, the
Packages is downloaded, decompressed, packages counted via regex, then
parsed.
I have tried to do this in a generic way, as the code also handles yum
and yast repos. These mostly follow the same logic; download package
list, decompress package list, count occurrences, parse.
https://github.com/furlongm/patchman/blob/master/patchman/repos/utils.py#L296-L334
Looking at the git blame, most of that code has been working fine for
6+ years. This is the first time I've ever come across a repo with
whitespace in that section.
> I've been thinking that in cases where iter_paragraphs was called with
> use_apt_pkg=True and then apt_pkg is not used contrary to what was requested,
> iter_paragraphs should generate a warning. That risks becoming noisy in a way
> that is not desirable, but also perhaps gets us away from this ambiguous
> behaviour where the use_apt_pkg setting has been ignored.
>
> I wonder what the likelihood is that introducing a warning would break someone
> else's code? (It would break an autopkgtest, for instance, by writing to
> stderr)
If other tools/libraries are more tolerant, including python-apt,
would it make sense for python-debian to be more tolerant when using
the in-built parser? In that case, the two parser implementations
would be more consistent.
--
Marcus Furlong
Bug#913274: Incorrectly parsing whitespace in Sources.iter_paragraphs
Control: retitle -1 Incorrectly parsing whitespace in Deb822.iter_paragraphs
On Tue, 13 Nov 2018 at 23:42, Marcus Furlong wrote:
>
> > > I have come across a case where whitespace is added in
> > > Packages{.gz,.bz2} and I am not sure how it should be parsed.
> > [...]
> > > Should this whitespace be parsed as a paragraph delimiter?
> >
> > For a Packages file, each paragraph is defined as a set of DEBIAN/control
> > paragraphs; the Description field is not allowed to contain lines that are
> > whitespace-only.
> >
> > https://wiki.debian.org/DebianRepository/Format#A.22Packages.22_Indices
> >
> > https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-description
> >
> > So the strict answer is yes, it should be a paragraph delimiter but most
> > implementations seem to be more forgiving in what they accept.
> >
> > Note that for debian/control files in source packages, whitespace-only lines
> > are treated as paragraph separators so that whitespace errors in an editor
> > don't accidentally make packages disappear from the archive.
> >
> >
> > > Currently, the whitespace is being treated as a paragraph delimiter,
> > > in python-debian, but not by apt-get, etc.
> >
> > Could you expand on this with an example, perhaps?
> >
> > python-debian actually uses python-apt for dealing with Sources and Packages
>
> I was incorrect. As you have shown, python-apt works correctly.
>
> > files (i.e. the exact same code as apt) and already does treat
> > whitespace-only
> > lines as being part of a paragraph rather than breaking them:
> >
> >
> > $ ipython3
> > Python 3.6.7 (default, Oct 21 2018, 08:08:16)
> > Type "copyright", "credits" or "license" for more information.
> >
> > In [1]: from debian.deb822 import Packages
> >
> > In [2]: with open('Packages') as fh:
> > ...: for p in Packages.iter_paragraphs(fh):
> > ...: if p['Version'] == '1.25.0-1529904044':
> > ...: print(p)
>
> I've narrowed down where the issue occurs. It happens when passing the
> contents rather than the file handle to iter_paragraphs:
>
> ~# ipython3
> Python 3.5.3 (default, Jan 19 2017, 14:11:04)
> Type "copyright", "credits" or "license" for more information.
>
> IPython 5.1.0 -- An enhanced Interactive Python.
> ? -> Introduction and overview of IPython's features.
> %quickref -> Quick reference.
> help -> Python's own help system.
> object? -> Details about 'object', use 'object??' for extra details.
>
> In [1]: from debian.deb822 import Packages
>
> In [2]: with open('Packages') as fh:
> ...:for p in Packages.iter_paragraphs(fh.read()):
> ...:if 'version' not in p:
> ...:print(p)
> ...:
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
>
> In [3]:
>
> Passing the contents does the correct thing in all other cases, so not
> sure why it would be having an issue with this?
>
> --
> Marcus Furlong
--
Marcus Furlong
Bug#913274: Incorrectly parsing whitespace in Sources.iter_paragraphs
> > I have come across a case where whitespace is added in
> > Packages{.gz,.bz2} and I am not sure how it should be parsed.
> [...]
> > Should this whitespace be parsed as a paragraph delimiter?
>
> For a Packages file, each paragraph is defined as a set of DEBIAN/control
> paragraphs; the Description field is not allowed to contain lines that are
> whitespace-only.
>
> https://wiki.debian.org/DebianRepository/Format#A.22Packages.22_Indices
>
> https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-description
>
> So the strict answer is yes, it should be a paragraph delimiter but most
> implementations seem to be more forgiving in what they accept.
>
> Note that for debian/control files in source packages, whitespace-only lines
> are treated as paragraph separators so that whitespace errors in an editor
> don't accidentally make packages disappear from the archive.
>
>
> > Currently, the whitespace is being treated as a paragraph delimiter,
> > in python-debian, but not by apt-get, etc.
>
> Could you expand on this with an example, perhaps?
>
> python-debian actually uses python-apt for dealing with Sources and Packages
I was incorrect. As you have shown, python-apt works correctly.
> files (i.e. the exact same code as apt) and already does treat whitespace-only
> lines as being part of a paragraph rather than breaking them:
>
>
> $ ipython3
> Python 3.6.7 (default, Oct 21 2018, 08:08:16)
> Type "copyright", "credits" or "license" for more information.
>
> In [1]: from debian.deb822 import Packages
>
> In [2]: with open('Packages') as fh:
> ...: for p in Packages.iter_paragraphs(fh):
> ...: if p['Version'] == '1.25.0-1529904044':
> ...: print(p)
I've narrowed down where the issue occurs. It happens when passing the
contents rather than the file handle to iter_paragraphs:
~# ipython3
Python 3.5.3 (default, Jan 19 2017, 14:11:04)
Type "copyright", "credits" or "license" for more information.
IPython 5.1.0 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object', use 'object??' for extra details.
In [1]: from debian.deb822 import Packages
In [2]: with open('Packages') as fh:
...:for p in Packages.iter_paragraphs(fh.read()):
...:if 'version' not in p:
...:print(p)
...:
Homepage: https://code.visualstudio.com/
Homepage: https://code.visualstudio.com/
Homepage: https://code.visualstudio.com/
Homepage: https://code.visualstudio.com/
Homepage: https://code.visualstudio.com/
Homepage: https://code.visualstudio.com/
Homepage: https://code.visualstudio.com/
Homepage: https://code.visualstudio.com/
Homepage: https://code.visualstudio.com/
Homepage: https://code.visualstudio.com/
Homepage: https://code.visualstudio.com/
Homepage: https://code.visualstudio.com/
In [3]:
Passing the contents does the correct thing in all other cases, so not
sure why it would be having an issue with this?
--
Marcus Furlong
Bug#913274:
Example to find the stanzas with extra whitespace: # curl -s http://packages.microsoft.com/repos/vscode/dists/stable/main/binary-amd64/Packages | grep -n -H "^ $" (standard input):3485: (standard input):3780: (standard input):3802: (standard input):3824: (standard input):3846: (standard input):3868: (standard input):3890: (standard input):3912: (standard input):3934: (standard input):3956: (standard input):3978: (standard input):4000: -- Marcus Furlong
Bug#913274: Incorrectly parsing whitespace in Sources.iter_paragraphs
Package: python-debian
Version: 0.1.33
I have come across a case where whitespace is added in
Packages{.gz,.bz2} and I am not sure how it should be parsed.
Currently, the whitespace is being treated as a paragraph delimiter,
in python-debian, but not by apt-get, etc.
See, for example, line 3780 of
http://packages.microsoft.com/repos/vscode/dists/stable/main/binary-amd64/Packages
Should this whitespace be parsed as a paragraph delimiter?
--
Marcus Furlong
Bug#738199:
It would be great to get this feature working again. Is there anything in particular holding it up? Do the patchsets still apply cleanly? -- Marcus Furlong
Bug#748055:
Also seeing the same issue with debian-goodies 0.63
# checkrestart -v
Found 1 processes using old versions of upgraded files
(1 distinct programs)
Process /sbin/multipathd (PID: 17158)
List of deleted files in use:
/[aio]
/[aio]
/[aio]
/[aio]
Running:['dpkg-query', '--search', '/sbin/multipathd']
Reading line: multipath-tools: /sbin/multipathd
(1 distinct packages)
Of these, 1 seem to contain init scripts which can be used to restart them:
The following packages seem to have init scripts that could be used
to restart them:
multipath-tools:
17158 /sbin/multipathd
These are the init scripts:
service multipath-tools-boot restart
service multipath-tools restart
Example of lsof output:
# lsof | grep aio
multipath 17158 root DEL REG 0,11
12681615 /[aio]
multipath 17158 root DEL REG 0,11
12681613 /[aio]
multipath 17158 root DEL REG 0,11
12681611 /[aio]
multipath 17158 root DEL REG 0,11
12681609 /[aio]
-blacklist = []
+blacklist = [re.compile('/\[aio\]')]
works as per previous comment.
Marcus.
--
Marcus Furlong
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514197:
Issue also exists in wheezy. The one line patch fixes it there. Any chance this can be applied before wheezy is released? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660818: rpm support for checkrestart
2012/2/23 Javier Fernández-Sanguino Peña j...@computer.org:
On Wed, Feb 22, 2012 at 06:33:19PM +1100, Marcus Furlong wrote:
If rpm support would be acceptable, I'd be happy to re-work the above
patch so that it checks for the existence of dpkg-query and/or rpm
and proceeds accordingly.
I'm open to supporting rpm in checkrestart but to do so it would be best to
separate the dpkg and rpm calls into different functions and call one (or the
other) based not on the existance of the dpkg-query or rpm binaries
themselves (you can install the rpm software in Debian) but on wether you are
running in an rpm or deb-based distribution.
We have debian installations that have rpm installed (due to hardware
RAID software that IBM distributes only as rpms). The attached patch
checks for the existence of both dpkg-query and rpm. If it finds
either it runs the corresponding checks. On our systems, this is the
correct thing to do, as it finds both deb-based packages and rpm-based
packages that require restarts. If either rpm or dpkg-query is not
found, those codepaths are not executed.
Tested on lenny, squeeze, opensuse, centos/sl/redhat 5/6.
Regards,
Marcus.
--
Marcus Furlong
--- checkrestart.orig 2012-02-29 13:37:30.788710631 +1100
+++ checkrestart 2012-03-05 17:28:40.875381912 +1100
@@ -114,6 +114,11 @@
# TODO - This does not work yet:
#toRestart = psdelcheck()
+global dpkgQueryBin, rpmBin
+
+dpkgQueryBin = find_cmd('dpkg-query')
+rpmBin = find_cmd('rpm')
+
toRestart = lsofcheck()
print Found %d processes using old versions of upgraded files % len(toRestart)
@@ -138,33 +143,13 @@
process.listDeleted()
packages = {}
-diverted = None
-dpkgQuery = [dpkg-query, --search] + programs.keys()
-dpkgProc = subprocess.Popen(dpkgQuery, stdout=subprocess.PIPE, stderr=None,
-env = lc_all_c_env)
-for line in dpkgProc.stdout.readlines():
-if line.startswith('local diversion'):
-continue
+
+if dpkgQueryBin != 1:
+deb_packages(programs, packages)
-m = re.match('^diversion by (\S+) (from|to): (.*)$', line)
-if m:
-if m.group(2) == 'from':
-diverted = m.group(3)
-continue
-if not diverted:
-raise Exception('Weird error while handling diversion')
-packagename, program = m.group(1), diverted
-else:
-packagename, program = line[:-1].split(': ')
-if program == diverted:
-# dpkg prints a summary line after the diversion, name both
-# packages of the diversion, so ignore this line
-# mutt-patched, mutt: /usr/bin/mutt
-continue
-
-packages.setdefault(packagename,Package(packagename))
-packages[packagename].processes.extend(programs[program])
-
+if rpmBin != 1:
+rpm_packages(programs, packages)
+
print (%d distinct packages) % len(packages)
if len(packages) == 0:
@@ -172,18 +157,31 @@
print (please read checkrestart(1))
sys.exit(0)
+
for package in packages.values():
+output = ''
if package == 'util-linux':
continue
-dpkgQuery = [dpkg-query, --listfiles, package.name]
-dpkgProc = subprocess.Popen(dpkgQuery, stdout=subprocess.PIPE, stderr=None,
+
+if dpkgQueryBin != 1:
+dpkgQuery = [dpkgQueryBin, --listfiles, package.name]
+dpkgProc = subprocess.Popen(dpkgQuery, stdout=subprocess.PIPE, stderr=subprocess.PIPE,
+env = lc_all_c_env)
+for line in dpkgProc.stdout.readlines():
+output = output + %s\n % line
+
+if rpmBin != 1:
+rpmQuery = [rpmBin, -q, -l, package.name]
+rpmProc = subprocess.Popen(rpmQuery, stdout=subprocess.PIPE, stderr=None,
env = lc_all_c_env)
-for line in dpkgProc.stdout.readlines():
-path = line[:-1]
-if path.startswith('/etc/init.d/'):
-if path.endswith('.sh'):
+for line in rpmProc.stdout.readlines():
+output = output + %s \n % line
+
+for line in output.splitlines():
+if line.startswith('/etc/init.d/') or line.startswith('/etc/rc.d/init.d/'):
+if line.endswith('.sh'):
continue
-package.initscripts.add(path)
+package.initscripts.add(line)
# Alternatively, find init.d scripts that match the process name
if len(package.initscripts) == 0:
for process in package.processes:
@@ -265,6 +263,7 @@
def isdeletedFile (f):
global lc_all_c_env
+global dpkgQueryBin, rpmBin
if allFiles:
return 1
@@ -284,7 +283,7 @@
if f.startswith('/run/'):
return 0
# Or about files under /drm
Bug#660818: rpm support for checkrestart
Package: debian-goodies
Attached is a simple patch for checkrestart which gives rpm support. I
use checkrestart extensively on debian servers and it would be great
to have it on rpm-based machines as well.
There also exist gentoo patches for checkrestart here -
http://arcdraco.net/checkrestart
If rpm support would be acceptable, I'd be happy to re-work the above
patch so that it checks for the existence of dpkg-query and/or rpm
and proceeds accordingly.
Regards,
Marcus.
--
Marcus Furlong
--- checkrestart.orig 2012-02-22 15:54:38.0 +1100
+++ checkrestart2012-02-22 16:10:19.0 +1100
@@ -139,10 +139,15 @@
packages = {}
diverted = None
-dpkgQuery = [dpkg-query, --search] + programs.keys()
-dpkgProc = subprocess.Popen(dpkgQuery, stdout=subprocess.PIPE, stderr=None,
+output = ''
+for key in programs.keys():
+dpkgQuery = [rpm, -q, -f, --queryformat=%{NAME}] + [key]
+dpkgProc = subprocess.Popen(dpkgQuery, stdout=subprocess.PIPE, stderr=None,
env = lc_all_c_env)
-for line in dpkgProc.stdout.readlines():
+for line in dpkgProc.stdout.readlines():
+output = output + %s: %s \n % (line, key)
+
+for line in output.splitlines():
if line.startswith('local diversion'):
continue
@@ -175,12 +180,12 @@
for package in packages.values():
if package == 'util-linux':
continue
-dpkgQuery = [dpkg-query, --listfiles, package.name]
+dpkgQuery = [rpm, -q, -l, package.name]
dpkgProc = subprocess.Popen(dpkgQuery, stdout=subprocess.PIPE, stderr=None,
env = lc_all_c_env)
for line in dpkgProc.stdout.readlines():
path = line[:-1]
-if path.startswith('/etc/init.d/'):
+if path.startswith('/etc/init.d/') or path.startswith('/etc/rc.d/init.d'):
if path.endswith('.sh'):
continue
package.initscripts.add(path)
Bug#649141: closed by Bastian Blank wa...@debian.org (no bug)
On Sun, Dec 11, 2011 at 06:03, Debian Bug Tracking System ow...@bugs.debian.org -- Forwarded message -- From: Bastian Blank wa...@debian.org This is no bug, but actually documented. You can't migrate systems to a cpu with lower capabilities. Out of interest, where is this documented? The debian examples would seem to indicate you can, by limiting the guest CPU features: Try zgrep cpuid /usr/share/doc/xen-utils-common/examples/* It should also be possible to do so by masking features on the host CPU, via kernel boot options ( see http://zhigang.org/wiki/XenCPUID ) However in 'xm dmesg' I get the following: (XEN) Cannot set CPU feature mask on CPU#0 (XEN) Cannot set CPU feature mask on CPU#1 (XEN) Cannot set CPU feature mask on CPU#2 (XEN) Cannot set CPU feature mask on CPU#3 (XEN) Cannot set CPU feature mask on CPU#4 (XEN) Cannot set CPU feature mask on CPU#5 (XEN) Cannot set CPU feature mask on CPU#6 (XEN) Cannot set CPU feature mask on CPU#7 (XEN) Cannot set CPU feature mask on CPU#8 (XEN) Cannot set CPU feature mask on CPU#9 (XEN) Cannot set CPU feature mask on CPU#10 (XEN) Cannot set CPU feature mask on CPU#11 (XEN) Cannot set CPU feature mask on CPU#12 (XEN) Cannot set CPU feature mask on CPU#13 (XEN) Cannot set CPU feature mask on CPU#14 (XEN) Cannot set CPU feature mask on CPU#15 when trying to boot with the following options: cpuid_mask_ecx=0x0008E3FD cpuid_mask_edx=0xBFEBFBFF It accepts and tries to act on the mask, but does not succeed. Also does not give indication as to why. -- Marcus Furlong -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649141: xen-hypervisor-4.0-amd64: live migration fails with invalid opcode due to nonstop_tsc
Package: xen-hypervisor-4.0-amd64Version: 4.0.1-4Severity: graveTags: squeezeJustification: causes data loss, migrations fail When migrating from a machine that has nonstop_tsc in /proc/cpuinfo (A) to a machine that does not have this flag (B), guests VM either get a kernel panic or most/all running processes report invalid opcodes in dmesg and crash. When migrating in the opposite direction (B - A), there seems to be no issues. The solution would seem to involve masking out cpu features, but I'm not sure entirely how to do this. There are red hat specific patches here for the same issue: https://bugzilla.redhat.com/show_bug.cgi?id=526862 and the issue is discussed here as well: https://bugzilla.redhat.com/show_bug.cgi?id=711322 https://bugzilla.redhat.com/show_bug.cgi?id=694492 xm dmesg doesn't show anything strange, but the guests need to be destroyed, or sometimes you can type reboot and it'll get a kernel panic and reboot itself. This link has some info on cpu masking but I'm not sure how to apply it my hosts for this flag (or whether it should be applied to guests or host?): http://zhigang.org/wiki/XenCPUID#cpuid-boot-options-definition A # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 44 model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz stepping: 2 cpu MHz : 2400.178 cache size : 12288 KB fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc up rep_good nonstop_tsc aperfmperf pni pclmulqdq est ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat bogomips: 4800.35 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: A # xm info | grep hw_caps hw_caps: bfebfbff:2c100800::1f40:029ee3ff::0001: B # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU X3350 @ 2.66GHz stepping: 7 cpu MHz : 2660.054 cache size : 6144 KB fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc up rep_good aperfmperf pni est ssse3 cx16 sse4_1 hypervisor lahf_lm bogomips: 5320.10 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: B # xm info | grep hw_caps hw_caps: bfebfbff:20100800::0940:0008e3fd::0001: -- Marcus Furlong -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584881:
] ? retint_restore_args+0x5/0x6 [5410976.055803] [81012ba0] ? child_rip+0x0/0x20 # free total used free sharedbuffers cached Mem: 10453401026512 18828 0 61688 401856 -/+ buffers/cache: 562968 482372 Swap: 3161640 290723132568 # mount /dev/md0 on / type ext4 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) xenfs on /proc/xen type xenfs (rw) fusectl on /sys/fs/fuse/connections type fusectl (rw) # fdisk -l Disk /dev/sda: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000600d9 Device Boot Start End Blocks Id System /dev/sda1 11216 9764864 fd Linux raid autodetect /dev/sda212161347 1053889+ 82 Linux swap / Solaris /dev/sda31348 121601 965940255 fd Linux raid autodetect Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0007482c Device Boot Start End Blocks Id System /dev/sdc1 11216 9764864 fd Linux raid autodetect /dev/sdc212161347 1053889+ 82 Linux swap / Solaris /dev/sdc31348 121601 965940255 fd Linux raid autodetect Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0006adc2 Device Boot Start End Blocks Id System /dev/sdb1 11216 9764864 fd Linux raid autodetect /dev/sdb212161347 1053889+ 82 Linux swap / Solaris /dev/sdb31348 121601 965940255 fd Linux raid autodetect # uname -a Linux barwon 2.6.32-5-xen-amd64 #1 SMP Thu May 19 01:16:47 UTC 2011 x86_64 GNU/Linux -- Marcus Furlong - VPAC Systems Administrator http://www.vpac.org +61 3 9925 4574 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599615:
Also seeing the exact same thing on two newly installed squeeze boxes. Both hit this bug on reboot. (raid10 md+xen+drbd backends) -- Marcus Furlong -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565187:
2010/1/13 Marco d'Itri m...@linux.it: However, what is the solution??? Manually bringing down/up the interfaces which you need need It's not possible to do this remotely without killing your ssh session (assuming the ssh session is on that interface). So a possible workaround is to write a script with ifdown/ifup for each interface that you want to restart. But is this not what the networking init-script is for? Regards, Marcus. -- Marcus Furlong -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587702:
Same issue here. Downgrading tar on the remote machine to the snapshot version fixes the issue. This bug was introduced into stable through a security update, has been fixed in unstable/testing, but is not fixed in stable. Are there any plans to fix it in stable? I still have a number of servers that require the above snapshot version installed, otherwise remote backups do not work (they worked before the security update). Thanks, -- Marcus Furlong -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595490:
I have the same issue. Apparently there are patches for this error, which only affects intel: http://www.gossamer-threads.com/lists/xen/devel/185593 For logging the output is the same as in the above thread: Xen call trace == xsave_init + 0x6d/0x1f0 init_intel + 0x13d/0x380 generic_identity + 0x39/0x190 identify_cpu + 0xe2/0x250 __start_xen + 0x2ec6/0x3340 __high_start + 0xa1/0xa3 Error message: === Panic on CPU 0: Xen BUG at i387.c:159 For more info: http://wiki.xensource.com/xenwiki/Xen4.0 In Xen 4.0.1 there's a bug in HVM guest save/restore/livemigration on Intel CPUs, related to XSAVE feature. As a workaround you can add no-xsave as an option to Xen command line in grub.conf. This issue is fixed in Xen 4.0.2-rc1-pre with this patch: http://xenbits.xen.org/xen-4.0-testing.hg?rev/16867267ac12 . -- Marcus Furlong -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587702:
Same issue here. Downgrading tar on the remote machine to the snapshot version fixes the issue. -- Marcus Furlong -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
