Bug#766195: [PATCH] ipv6: reuse ip6_frag_id from ip6_ufo_append_data
On 30.10.2014 20:00, Ben Hutchings wrote: [...] Yes, I can see how this (disabling virtio features) would prevent live migration from old to new host kernels. You will probably need a one-time reboot of the guest when migrating to the new host kernel. We could either mention this in the DSA text, or keep UFO enabled even though it doesn't work correctly (in practice, we sort of have to do that as the tap device's feature flags aren't respected by guests - which I think is a QEMU bug). Please let us know whether live migration between two hosts running the new kernel version does work (I think it will). I confirm that. Although I did not exactly test this because of some constraints. I tested with virsh save/restore which uses the same codepaths as virsh migrate I think. This cold migration spewed out the same error messages as written earlier when migrating from old to new. And it went fine from new to new. BTW I use a patched qemu-kvm because of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724758. So maybe there are only a few wheezy users doing live migrations. Cheers Harry -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766195: [PATCH] ipv6: reuse ip6_frag_id from ip6_ufo_append_data
I can confirm that linux-image-3.2.0-4-amd64_3.2.63-2+deb7u1_amd64.deb fixes this regression for me. Cheers Harry -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766195: [PATCH] ipv6: reuse ip6_frag_id from ip6_ufo_append_data
On 30.10.2014 11:17, Harald Staub wrote: I can confirm that linux-image-3.2.0-4-amd64_3.2.63-2+deb7u1_amd64.deb fixes this regression for me. But it breaks live migration, probably when the source host runs an older kernel. When libvirt tries to complete the migration, it aborts with: error: Domain not found: no domain with matching name 'VMNAME' On the destination host, in /var/log/libvirt/qemu/VMNAME.log: kvm: Features 0x300fffe3 unsupported. Allowed features: 0x711fbbe3 qemu: warning: error while loading state for instance 0x0 of device ':00:03.0/virtio-net' load of migration failed I tried again with the older 3.2.60-1+deb7u3 on the destination host, this works fine. Cheers Harry -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629852: openjdk-6?
The security tracker still shows openjdk-6 as needs to be checked, e.g.: http://security-tracker.debian.org/tracker/CVE-2011-0872 OTOH, Ubuntu has issued a Security Notice for openjdk-6 on June 17: http://www.ubuntu.com/usn/usn-1154-1/ So I should assume the Debian stable package to be vulnerable? Cheers Harry -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627448: CVE-2011-1751 squeeze fix: VM stop/start required?
When patching KVM hosts, our preferred way is to live migrate the VMs to another host temporarily. I see that the fix for squeeze needed some backporting work. In particular, it introduces a no_hotplug property. I wonder if there are precautions to consider in this case. Live migration looks fine both ways: start a VM on unpatched host and migrate to patched host, and also the other way round. (Tried with just one VM.) Is there still a security hole through a migrated (from unpatched to patched host) VM? Is it necessary to stop and start the VMs? Cheers Harry -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597517: qemu-kvm: save is very slow
Package: qemu-kvm Version: 0.12.5+dfsg-3 Severity: grave I started some testing of the version of qemu-kvm of squeeze. I do this on a lenny box, with a sid kernel (linux-image-2.6.32-5-amd64 2.6.32-23) and backports of qemu-kvm and libvirt (0.8.3-1). I found that to save a VM (through virsh save) is really slow. A VM with 128MB RAM took 40 to 50 seconds. This makes it unusable not only for me (see launchpad bug link below, comment #3). With the following patch applied, it looks ok (save takes about 1 second): http://lists.nongnu.org/archive/html/qemu-devel/2010-07/msg00431.html The patch applies cleanly after having replaced DPRINTF with dprintf. I found this patch through https://bugs.launchpad.net/qemu/+bug/524447 I wonder why this was not included in upstream 0.12.5 ... -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597517: qemu-kvm: save is very slow
Hello Michael On 20.09.2010 15:20, Michael Tokarev wrote: [...] Thank you Harald for the bugreport that includes patch. I missed that change when it were committed. The problem with slow migration bothered me for quite some time, I've seen this thread on LP too, I argued with Anthony Liguori against his dd buffer size suggestion. But it was several months ago, while the fix is relatively recent. You just connected all the ends together - thank you for this. You are welcome! I verified the change (it's commit 5e77aaa0d7d2f4ceaa4fcaf50f3a26d5150f34a6 upstream) and it appears to be correct for 0.12 branch too. I already included it for the next debian release, if such a release will happen for squeeze (due to feature freeze). Thanks a lot! Now, I'm questioning the severity you've choosen for this bug. Grave is release-critical, when a package breaks for most users. I don't think many users uses migration, and no kvm package in any stable debian series included working migration code. It might be important if you really think it _is_ important, but grave? Why? I also wonder how many people use KVM on Debian in bigger environments. There, you certainly need save/restore and migrate. Maybe it is more often used on Ubuntu, see the already mentioned https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/524447/comments/3 So this bug is a blocker for bigger environments. In my opinion it would be a pity if squeeze released without this 8 lines fix. Also, libvirt/KVM is the preferred virtualization environment for Red Hat and Ubuntu, so I think it is important for Debian as well. But feel free to adjust the severity level to something more accurate, especially in the light of the current situation with the freeze. I wonder why this was not included in upstream 0.12.5 ... Very few people cares about 0.12 as a whole. Speaking of 0.12.5 -- well, there were a few changes that probably should be there too, but aren't. Some of them are in debian package. I very much appreciate this work, of Debian generally and in this case of you in particular! Cheers Harry -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#348604: new endianness problem?
Upstream has released 0.9.6, which includes several endianness issues. Can you please check whether the packages from deb-src http://zg.debian.zugschlus.de/zg/pool/main/mhash/ / Sorry, no powerpc binary packages at this time - I am trying to get the package built on some big endian machines. I built and installed libmhash2_0.9.6-1_powerpc.deb and libmhash-dev_0.9.6-1_powerpc.deb. Then, I rebuilt and installed libgringotts1_1.2.1-9_powerpc.deb. gringotts (1.2.8+1.2.9pre1-11) now gives a Segmentation Fault (after having asked for the password). Do you think it is necessary to rebuild gringotts as well? Should I send some sort of a trace? Thank you and greetings Harry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348604: new endianness problem?
Do you think it is necessary to rebuild gringotts as well? I'd give that a try. So I installed the rebuilt libgringotts-dev_1.2.1-9_powerpc.deb and rebuilt and installed gringotts. It still throws a Segmentation Fault :-( Cheers Harry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348604: new endianness problem?
In my case, the new versions (gringotts 1.2.8+1.2.9pre1-11, libgringotts1 1.2.1-9, libmhash2 0.9.4a-1) throw a segmentation fault. It looks the same as with the previous gringotts-versions with libmhash2 0.9.4a-1. Since this is on powerpc, I guess there might be an endianness problem in the new mhash code? Cheers Harry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299572: [debian-ntp] Bug#299572: ntp-server: strace log
Matthias Urlichs wrote: Hi, Harald Staub: I tried on one of the servers that has problems, and there, I still have segfaults, while the mentioned cvs version works fine. I attach an strace. Gah. Can you send me - the output of ifconfig - the contents of your ntp.conf Thanks. As mentioned earlier, the last dist-upgrade of this server was several months back. Today, I had the opportunity to dist-upgrade to current sarge (ntp from sid: 4.2.0a+stable-8). And ntp looks fine now :-) I am sorry I could not do this earlier :-/ Cheers Harry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299572: [debian-ntp] Bug#299572: ntp-server: strace log
Matthias Urlichs wrote:
Hi,
Beat Bolli:
Package: ntp-server
Version: 1:4.2.0a+stable-4
Followup-For: Bug #299572
Thanks. Please test whether -6 fixes this problem.
People: If you're stracing a server, use strace -f -s 300 -o FILE PROGRAM,
then send FILE as a (possibly gzipped) attachment unless you're very
sure that your mail client doesn't word-wrap.
Otherwise (a) the fork() call will make your trace useless, (b) any
syslog strings or other important information the server writes will be
truncated, and/or (c) program output will be interspersed with strace
output, which makes analysis harder than necessary.
On my PowerBook it looks fine now!
I tried on one of the servers that has problems, and there, I still have
segfaults, while the mentioned cvs version works fine. I attach an strace.
Thinking again of this, I want to point out two things. First, this might
be a different story, namely the mentioned bug #272511. Second, this server
runs sarge with the last dist-upgrade probably several months back, because
it is difficult to take it down. So I am not sure of how much use this is
to you, because perhaps a dist-upgrade would fix the ntpd segfault.
Anyway, thanks a lot!
Harald Staub
2138 execve(/usr/sbin/ntpd, [/usr/sbin/ntpd, -n], [/* 28 vars */]) = 0
2138 uname({sys=Linux, node=ezmp1, ...}) = 0
2138 brk(0)= 0x8b3f000
2138 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2004
2138 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
2138 open(/etc/ld.so.preload, O_RDONLY) = -1 ENOENT (No such file or
directory)
2138 open(/etc/ld.so.cache, O_RDONLY) = 3
2138 fstat64(3, {st_mode=S_IFREG|0644, st_size=25318, ...}) = 0
2138 old_mmap(NULL, 25318, PROT_READ, MAP_PRIVATE, 3, 0) = 0x20039000
2138 close(3) = 0
2138 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
2138 open(/lib/libm.so.6, O_RDONLY) = 3
2138 read(3, [EMAIL PROTECTED]
\0\7\0(\0\35\0\34\0\6\0\0\0004\0\0\0004\0\0\0004\0\0\0\340\0\0\0\340\0\0\0\5\0\0\0\4\0\0\0\3\0\0\0\30\5\2\0\30\5\2\0\30\5\2\0\23\0\0\0\23\0\0\0\4\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0+\5\2\0+\5\2\0\5\0\0\0\0\20\0\0\1\0\0\\5\2\\25\2\\25\2\0|\1\0\0\300\1\0\0\6\0\0\0\0\20\0\0\2\0\0\0`\5\2\0`\25\2\0`\25\2\0\340\0\0\0\340\0\0\0\6\0\0\0\4\0\0\0\4\0\0\0\24\1\0\0\24\1\0\0\24\1\0\0
\0\0\0
\0\0\0\4\0\0\0\4\0\0\0Q\345td\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\4\0\0\0\4\0\0\0\20\0\0...,
512) = 512
2138 fstat64(3, {st_mode=S_IFREG|0644, st_size=134464, ...}) = 0
2138 old_mmap(NULL, 136944, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xdc1000
2138 old_mmap(0xde2000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x2) = 0xde2000
2138 close(3) = 0
2138 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
2138 open(/usr/lib/i686/cmov/libcrypto.so.0.9.7, O_RDONLY) = 3
2138 read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\300\2\0004\0\0\0\220\262\17\0\0\0\0\0004\0
\0\5\0(\0\27\0\26\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\f\231\16\0\f\231\16\0\5\0\0\0\0\20\0\0\1\0\0\0\0\240\16\0\0\240\16\0\0\240\16\0\340\21\1\0\230L\1\0\6\0\0\0\0\20\0\0\2\0\0\0\30\254\17\0\30\254\17\0\30\254\17\0\330\0\0\0\330\0\0\0\6\0\0\0\4\0\0\0P\345td\360\230\16\0\360\230\16\0\360\230\16\0\34\0\0\0\34\0\0\0\4\0\0\0\4\0\0\0Q\345td\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0\5\10\0\0\346\n\0\0\0\0\0\0\253\n\0\0\0\0\0\0;\7\0\0\0\0\0\0\0\0\0\0E\7\0\0\221\n\0\0\0\0\0\0\0\0\0\0\363\6...,
512) = 512
2138 fstat64(3, {st_mode=S_IFREG|0644, st_size=1029672, ...}) = 0
2138 old_mmap(NULL, 1043608, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x111000
2138 old_mmap(0x1fb000, 73728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0xea000) = 0x1fb000
2138 old_mmap(0x20d000, 11416, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x20d000
2138 close(3) = 0
2138 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
2138 open(/lib/libcap.so.1, O_RDONLY) = 3
2138 read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\r\0\0004\0\0\0\240\'\0\0\0\0\0\0004\0
\0\4\0(\0\26\0\25\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\17%\0\0\17%\0\0\5\0\0\0\0\20\0\0\1\0\0\0
%\0\0 5\0\0
5\0\0\334\1\0\0004\4\0\0\6\0\0\0\0\20\0\0\2\0\0\0\270%\0\0\2705\0\0\2705\0\0\310\0\0\0\310\0\0\0\6\0\0\0\4\0\0\0Q\345td\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\4\0\0\0C\0\0\0F\0\0\0\0\0\0\0B\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0E\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0#\0\0\0\0\0\0\0\0\0\0\0\0\0\0006\0\0\0007\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0001\0\0\0009\0\0\0\0\0\000...,
512) = 512
2138 fstat64(3, {st_mode=S_IFREG|0644, st_size=11024, ...}) = 0
2138 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x20038000
2138 old_mmap(NULL, 14676, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x55b000
2138
Bug#299572: [debian-ntp] Bug#299572: ntp-server: strace log
Matthias Urlichs wrote: Hi, Harald Staub: I tried on one of the servers that has problems, and there, I still have segfaults, while the mentioned cvs version works fine. I attach an strace. Gah. Can you send me - the output of ifconfig - the contents of your ntp.conf Thanks. Cheers Harry eth0 Link encap:Ethernet HWaddr 00:08:02:F1:1F:40 inet addr:130.59.35.2 Bcast:130.59.35.3 Mask:255.255.255.252 inet6 addr: 2001:620:0:101:208:2ff:fef1:1f40/64 Scope:Global inet6 addr: fe80::208:2ff:fef1:1f40/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:4470 Metric:1 RX packets:2755516149 errors:0 dropped:0 overruns:0 frame:0 TX packets:4184415013 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:20518437 (19.5 MiB) TX bytes:2902994749 (2.7 GiB) Interrupt:30 eth1 Link encap:Ethernet HWaddr 00:08:02:F1:1F:8C inet addr:130.59.35.6 Bcast:130.59.35.7 Mask:255.255.255.252 inet6 addr: 2001:620:0:100:208:2ff:fef1:1f8c/64 Scope:Global inet6 addr: fe80::208:2ff:fef1:1f8c/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:234912636 errors:0 dropped:0 overruns:0 frame:0 TX packets:4582874 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3169016135 (2.9 GiB) TX bytes:737836491 (703.6 MiB) Interrupt:29 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host inet6 addr: 2001:620:0:ff::2/128 Scope:Global UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2883897546 errors:0 dropped:0 overruns:0 frame:0 TX packets:2883897546 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:872317027 (831.9 MiB) TX bytes:872317027 (831.9 MiB) lo:0 Link encap:Local Loopback inet addr:130.59.31.251 Mask:255.255.255.255 UP LOOPBACK RUNNING MTU:16436 Metric:1 lo:1 Link encap:Local Loopback inet addr:130.59.31.70 Mask:255.255.255.255 UP LOOPBACK RUNNING MTU:16436 Metric:1 logfile /var/log/ntpd driftfile /var/lib/ntp/ntp.drift keys /etc/ntp.keys trustedkey 12 server 130.59.35.1 maxpoll 6 server 130.59.35.5 maxpoll 6 peer 130.59.35.10 peer 130.59.35.130 peer 130.59.35.30 peer 130.59.35.22
Bug#299572: ntp-server: Fails to start after upgrade.
Same here. I bet we are bitten by bug 220 Segmentation fault: http://bugzilla.ntp.org/show_bug.cgi?id=220 It is marked as verified fixed since 2004-11-05. To switch to a cvs version is maybe not what you want at this time. On the other hand, this bug is really grave. I have to admit that I had segmentation faults (you can see them by running ntpd -n) already back in December and I missed to file a bug report. It was only on 2 experimental servers. I made a quick fix by using cvs version ntp-dev-4.2.0a-20041207, which just worked. This time, the segmentation fault is on my main workstation (current sid PowerBook), which otherwise runs very reliably. BTW, this Debian bug is probably related: #272511 ntp-server: Restart sometimes fails http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272511 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
