Bug#714273: qemu-system-x86: manpage claims it would use bochsbios, etc.
Control: tag -1 + confirmed upstream patch pending 27.06.2013 17:13, Christoph Anton Mitterer wrote: The manpage claims it would use Bochs bios, but we use seabios: QEMU uses the PC BIOS from the Bochs project and the Plex86/Bochs LGPL VGA BIOS. The VGA BIOS seems also to be another one? I just sent a patch to upstream fixing this -- http://thread.gmane.org/gmane.comp.emulators.qemu/219366 Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710822: qemu: cve-2013-2016
Please excuse me for this really long delay with the answer. 16.06.2013 23:29, Michael Gilbert wrote: On Wed, Jun 5, 2013 at 1:12 PM, Michael Tokarev wrote: 02.06.2013 22:53, Michael Gilbert wrote: Package: qemu Severity: serious version: 1.5.0+dfsg-1 Tags: security Hi, An out-of-bounds issue in virtio was published for qemu: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-2016 Hmm. Now I'm really confused. Upstream version 1.5.0 includes the fix for this issue, so filing the bug against 1.5.0+dfsg-1 package is kind of wrong. The fix is commit 5f5a1318653c08e435cfa52f60b6a712815b659d which was applied past 1.5.0~rc0. Is that a complete fix? The suggested patch in the redhat bug [0] also adds checks to virtio-pci.c, which is what I had used for reference when checking whether this was fixed or not, and that is not applied in the debian package yet. The fix referred to from that redhat bugreport (which is here -- https://lists.gnu.org/archive/html/qemu-devel/2013-04/msg05254.html or http://thread.gmane.org/gmane.comp.emulators.qemu/208677 ) was a suggested patch. After which some discussion emerged (see the thread on gmane), and another, V2 version of the same patch were sent, which is here -- http://patchwork.ozlabs.org/patch/241991/ or http://thread.gmane.org/gmane.comp.emulators.qemu/210292 -- which has been applied as 5f5a1318653c08e, which is included in 1.5.0-rc1 and up. Thanks, /mjt [0] https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-2016 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669184: qemu-kvm: Virtio network drops in case of a heavy load
On 18.04.2012 04:14, Vugar Dzhamalov wrote: Package: qemu-kvm Version: 1.0+dfsg-9 Severity: important It seems that I am getting into something very similar to these bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=554078 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576838 At the same time while running it with e1000 I don't get any similar issues. Please provide actual data from your systems. Both bugreports you references are old and fixed long ago, so something very similar needs quite a bit of details since it is a new bug. Describe what you do, what actually happens, what messages from host and guest you're getting etc. I've never done any bug reporting prior to this one so if you would like me to provide you with any further info I'll try to do my best. Thanks You're welcome. Let's try the above first... Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625716: kvm: cannot boot from USB
On 18.04.2012 18:51, intrigeri wrote: Hi, Michal Suchanek wrote (05 May 2011 13:41:01 GMT) : Booting this way from an Ubuntu USB install media is also very slow but at least I can confirm the media is bootable. I'm going to file a wishlist bug about USB2 redirection soon, that will be about performance matters. Doesn't usb2 redirection work already? #625716, though, is purely about ability to boot from USB at all, which apparently works, so it should be closed, shouldn't it? Note that #625716 is tagged with squeeze, as in, 0.12 (squeeze) version of qemu-kvm does not boot from an usb device, because the bios it uses does not have proper usb support. It is fixed in more recent versions of qemu/bios, but it wont be fixed in squeeze. So it shouldn't be closed. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669184: qemu-kvm: Virtio network drops in case of a heavy load - Follow-up on virtio_net drop
On 23.04.2012 11:54, Vugar Dzhamalov wrote: [] I'll take a look. For the next time, please don't send me content of your /usr/bin or any other directories. Just _versions_ of the software affected, and, most important, the steps you did to (re)produce the issue. This includes the way you start your guests too - this is your kvm command line. Is there anything else I can do here to help with this? Thank you. Yes. What's the guest kernel details please? What is your kvm command line? Also, does it happen with regular bridge networking too, or only vde? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669184: qemu-kvm: Virtio network drops in case of a heavy load - Follow-up on virtio_net drop
Okay, I re-created your configuration with vde_switch, and I found the kvm command lines you used in one of the files -- you sent just too much information so really important bits got lost in the noize initially. I'm doing a copy test from one guest /dev/zero to another guest /dev/null. It copied 120 Gigs of data so far, and counting. Should it stop somewhere as per your bugreport? How can I make it stop/stall? Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669184: qemu-kvm: Virtio network drops in case of a heavy load - Follow-up on virtio_net drop
On 26.04.2012 12:24, Vugar Dzhamalov wrote: Thank you for doing this. I am very appreciate and sorry for wasting your time with this. Lets be honest here I've reported it more than a week ago and so far no one else joined the discussion. I guess it is quite obvious that there is something wrong with my setup rather than anything else... I'm not sure I understand. You have a problem which looks very much like a bug. The fact that no one else joined this discussion tell exactly nothing, since at this state, bugs are much more difficult to hit, since most obvious bugs which are hit by all users are fixed ages ago. Again, the fact I can't reproduce it does not mean it does not exist, but it most likely means my setup is (slightly) different than yours and something which we overlooked does not let me to hit this bug. Lack of other users hitting this bug does not mean the bug does not exist. We should actually find what is going on - either a real bug in the code or something wrong in your setup or something else, before deciding what to do next. I've launched 64 bit CentOS 6.2 as two guests in the same manner as I did with two 64bit Debian testing (wheezy) guests in the previous attempt and got the same issues with the virtio NIC. There is something wrong with my setup... I've found following in my /var/log/syslog kernel: [201326.063213] kvm: 17363: cpu0 unhandled rdmsr: 0xc001100d kernel: [201326.063226] kvm: 17363: cpu0 unhandled rdmsr: 0xc0010112 kernel: [201326.193885] kvm: 17363: cpu0 unhandled rdmsr: 0xc0010001 These are accesses by the guest to model-specific CPU registers (MSRs). Qemu must emulate these but it does not emulate all of them (and we can't even know all of them since CPUs are different). What you see here are: 0xC001100d CPU_ID_HYPER_EXT_FEATURES (information about extended features of hypervisor) 0xc0010112 MSR_K8_TSEG_ADDR (some AMD K8-specific register) 0xC0010001 MSR_K7_EVNTSEL1 (some AMD K7-specific register) Guest just probes various features of the CPU to know what a CPU can do, poking around what it knows. Qemu merely reports it didn't know what to do with these, and returned some sort of failure to the guest, which, at this stage, was fully prepared to handle. So these are all harmless. I can't see anything else I can do at this stage. I can use e1000 - it is more than sufficient for my current needs. Thank you. This is very good that you have a workaround - it means I can do some more urgent work before I'll take a look at this again. But the probleb appears to be here and we need to find it and fix it or at least understand why and where it happens. (And yes I'd be very glad to close this bugreport so I'd have less bugs to deal with :) Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685353: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
On 30.08.2012 22:03, malc wrote: On Thu, 30 Aug 2012, Mike Gerber wrote: [] Vassily: Anything else you need when the hang happens again? Unfortunately I'll have to go into production with the guest, and I can't spend more weeks with this bug after this week end. Audio compiled without optimzations which should give meaningful backtrace and contents of local variables. Mike, are you able to do that? You can grab either the upstream qemu-kvm sources or debian sources, remove all -Oxx references or adding -O0, and recompile (`apt-get build-dep qemu-kvm' will install all necessary deps). Or I can compile it for you if you prefer. Indeed, with optimizations, while the stack trace is useful, it is not as useful as without... Michael: I noticed that this bug (#685353) is RC, so please rate it down if you think it is appropiate. I doubt that many people will hit it. It was you who marked this bug as grave, right? :) Yes it does not look like something many people will hit. Are you okay with downgrading it to normal or important ? Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686438: move_mount: failed to move mount
On 02.09.2012 03:55, Thomas Nilsson wrote: The problem is described with patch here: https://bugzilla.redhat.com/show_bug.cgi?id=745781 So the fix apparently is just to disable mount --move. And as usual, there's no documentation about what it is for and why it is here. Upstream included a patch which is mentioned in the redhat bugreport above (to implement mount --move disabling), and later removed that mount --move code entirely. Lovely. Thomas, can you verify that adding --disable-mount-move to the configure flags of the package and rebuilding it fixes the problem for you? If you want, I can prepare an already compiled version for you for testing. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686484: chowning pid directory and writing there as root may lead to security issue
Package: dnsmasq
Version: 2.55-2
Severity: serious
Tags: security
The initscript (and postinst script) of dnsmasq creates /var/run/dnsmasq
directory and chowns it to dnsmasq:nogroup. However, dnsmasq daemon writes
the pidfile (which apparently is the only file there) as root user. Here's
the code which does this (in src/dnsmasq.c):
FILE *pidfile;
/* only complain if started as root */
if ((pidfile = fopen(daemon-runfile, w)))
{
fprintf(pidfile, %d\n, (int) getpid());
fclose(pidfile);
}
So there's no checking for this file to exist, being a symlink etc.
This way, we effectively making dnsmasq user equal to root: dnsmasq
user can (sym)link /var/run/dnsmasq/dnsmasq.pid to, say, /etc/shadow,
and it will be overwitten the next time dnsmasq (re)starts. This is
obviously wrong.
The only good side of this is that dnsmasq writes only controlled data
to this file (its pid, as per above), so the damage is minimal, ie,
only a denial of service, not gain of service (hence Severity is only
serious).
Besides, documentation says the pid file is /var/run/dnsmasq.pid, not
/var/run/dnsmasq/dnsmasq.pid - it is the initscript which sets the option
behind the scenes. Also, there's no mentions in the changelog about
WHY pid file is in this location. And more, it one can change the user
dnsmasq runs as.
It looks like this pidfile stuff needs to be removed entirely (moving
it to a subdir silently and chowning that subdir to dnsmasq user).
Thanks,
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686438: move_mount: failed to move mount
On 02.09.2012 13:25, Thomas Nilsson wrote: 2012-09-02 09:18, Michael Tokarev skrev: Thomas, can you verify that adding --disable-mount-move to the configure flags of the package and rebuilding it fixes the problem for you? If you want, I can prepare an already compiled version for you for testing. Thank you! /mjt I don't know which is the quickest way... I can try to build it during the day but if you have the build environment set up already it would be nice if you could compile it, thanks! I built and uploaded into my temp dir, http://www.corpit.ru/mjt/tmp/autofs/ (both source and amd64 binary are signed with my regular debian GPG key). Please test whenever this fixes your issue, and I'll include it in the next upload. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686484: chowning pid directory and writing there as root may lead to security issue
On 02.09.2012 13:40, Simon Kelley wrote: [] The explanation for the current state of affairs is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508560 Oh. I tried to find why/when this subdir appeared, but failed. The changelog mentions PID in uppercase ;) I'm sorry about this, knowing that I'd have much more useful bugreport. /var/run/dnsmasq is owned by user dnsmasq so that dnsmasq can unlink the pid file when it shuts down, even though at that point it is running as user dnsmasq, not as user root. This is a very general issue with daemons dropping privileges and their pidfiles. Each package solves it in its own way. Some forks a worker process which does setuid(), with a root-owned babysitter waiting for it to exit and clean the pidfile. Some keeps the pidfile open and truncates (not unlinking) it on exit. And some merely ignores this issue. And I think this 3rd option is the best in this case. The daemon itself does not _use_ the pidfile, it merely writes the pidfile. And tools like start-stop-daemon usually check /proc/$PID/exe or equivalent for the right executable, so, even if we'll leave the stale pidfile, no harm will be done at all. #508560 has minor severity, and I think it is just cosmetic thing. Note: having user-writable /var/run/FOO subdir, or keeping /var/run/FOO.pid open after dropping privileges are both, well, risky, since in both cases the process in question gains more privileges than actually necessary. It only needs to REMOVE (or clear) one file, but it can fill whole /var/run, or write some garbage to the pid file to trick the startup script (run as root) to execute some evil code. So I think just stopping caring (and reintroducing #508560) is the best thing to do. And by moving the pidfile back to /var/run/ we're back to the documented place and to no need for extra args. (But such moving back, if choosen, should be done carefully -- the initscript may need to continue providing /var/run/dnsmasq/ dir, now without chowning it, since old config may need it. Sigh.) Answering to the other your email: O_EXCL exist, yes, but we still have more privs (with writable subdir in /var/run/) than necessary. Not as dangerous as current way, but still a bit too many. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686524: qemu-kvm: guests won't start until input to console is made
Control: tag 686524 + moreinfo On 02.09.2012 22:34, Timo Weingärtner wrote: Package: qemu-kvm Version: 1.1.1+dfsg-1 Severity: grave Justification: renders package unusable Well, it is usable for lots of people. After starting the guest with virsh start router the kvm process uses 100% CPU. In virsh console router nothing happens until I press enter, then the guest starts booting. echo /dev/pts/$number also works here. When bootet the guest's clock is behind by the time between the virsh start and the input to the guest's console. How this bug is different from #685314 and #680719 (which is the same thing)? Note both are fixed in the version you're reporting this bug against, and verified. I'm not saying it is the same bug and it is fixed, I'm trying to understand how your is different. kvm command (libvirt-generated): /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 128 -smp 1,sockets=1,cores=1,threads=1 -name router -uuid d24ccdfa-201a-eda6-65e7-43b0b29c94ba -nographic -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/router.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -kernel /boot/kvm-router/vmlinuz -append root=/dev/vda ro console=ttyS0 -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/dev/vg/vm_router_root,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/dev/vg/vm_router_swap,if=none,id=drive-virtio-disk1,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,ifname=vm_router,script=/bin/true,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=02:84:00:00:00:01,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-s e rial,chardev=charserial0,id=serial0 -device i6300esb,id=watchdog0,bus=pci.0,addr=0x7 -watchdog-action reset -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 Please try reproducing it without libvirt. Maybe removing -M pc-0.12 will help with that. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686524: qemu-kvm: guests won't start until input to console is made
Control: tag 686524 + unreproducible On 03.09.2012 01:58, Timo Weingärtner wrote: [] Please try reproducing it without libvirt. Maybe removing -M pc-0.12 will help with that. Without the libvirt magic it doesn't use 100% CPU but it won't boot either. I removed pc-0.12 from libvirt's config, now it uses pc-1.1 and still hangs until console input. I can't reproduce this problem here. For me, it always starts booting. I tried previous version (1.1.0) and there it works too. What's the minimal command line to trigger this? Will it happen with simple kvm -nodefaults -serial file:/tmp/serial -nographics -kernel .. -append console=ttyS0 ? Also, does it happen with different guest kernel (-kernel option) ? Marking as unreproducible for now... Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686146: purging autofs5 fails with ucfr: Association belongs to autofs, not autofs5
Control: tag 686146 + pending On 29.08.2012 20:42, Michael Tokarev wrote: [] ii autofs 5.0.6-2 amd64 kernel-based automounter for Linux pc autofs5 5.0.4-3.2+b1 amd64 kernel-based automounter for Linux, version 5 And here we go. autofs should conflict with older version of autofs5. For now, you can upgrade autofs5 _too_, after which you'll be able to remove/purge it. This should be reflected in the control file. That turned out to be not so simple, and there's no established way to deal with such a situation. Indeed, manually upgrading autofs5 will let you to purge it. But in order to allow this purging automatically in this situation, I had to remove autofs5's postrm script in autofs postinst. All Breaks/Replaces in the control file are already present, but they don't work for a package which isn't installed but with only config files left, like in this our case. I'll fix this in the next upload. Anyway, this is done now. Thank you for the report! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686524: qemu-kvm: guests won't start until input to console is made
Control: tag 686524 - moreinfo unreproducible + confirmed On 03.09.2012 21:49, Timo Weingärtner wrote: bad: kvm -nographic -nodefaults -kernel /boot/vmlinuz-3.2.0-3-amd64 -append console=ttyS0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 good: kvm -nographic -nodefaults -kernel /boot/vmlinuz-3.2.0-3-amd64 -append console=ttyS0 -serial file:/tmp/serial bad: kvm -nographic -nodefaults -kernel /boot/vmlinuz-3.2.0-3-amd64 -append 'console=ttyS0' -serial pty That should be minimal enough. So it is just the pty code. I reproduced it here. Thank you very much. Now I can work it out. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686524: qemu-kvm: guests won't start until input to console is made
Control: retitle 686524 qemu-kvm: guests with -nographic -serial pty won't start until input to console is made Control: forwarded 686524 http://thread.gmane.org/gmane.comp.emulators.qemu/168265 I'm retitling the bugreport to reflect our findings. As stated before, -serial pty works the same as the longer version with -chardev pty and -device isa-serial. The important points here is -nographic and pty. This shuld be rather popular config for headless guests such as routers (your case?), but it is still uncommon - people use either text console (maybe with screen) or regular graphics screen more often than running it headless with console on a serial port. This is why we haven't hit this issue before, and why I don't think this bug deserves to have grave severity. Do you not agree? It does not mean we should not fix it ofcourse. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686524: qemu-kvm: guests won't start until input to console is made
Control: tag 686524 + patch pending On 04.09.2012 01:28, Timo Weingärtner wrote: Hallo Michael Tokarev, 2012-09-03 um 20:25:25 schriebst Du: Control: retitle 686524 qemu-kvm: guests with -nographic -serial pty won't start until input to console is made Control: forwarded 686524 http://thread.gmane.org/gmane.comp.emulators.qemu/168265 I'm retitling the bugreport to reflect our findings. As stated before, -serial pty works the same as the longer version with -chardev pty and -device isa-serial. The important points here is -nographic and pty. also bad: kvm -vnc ::1 -nodefaults -kernel /boot/vmlinuz-3.2.0-3-amd64 -append console=ttyS0 -serial pty And there are a few other places when this hang occurs. Fixed by this commit: http://permalink.gmane.org/gmane.comp.emulators.qemu/168209 http://anonscm.debian.org/gitweb/?p=collab-maint/qemu-kvm.git;a=commitdiff;h=dcf33d71bfee4d9bb2107f70c76bd5cbb2af3f98 Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684775: qemu-kvm: cannot boot a wheezy guest with SMP and less than 927 MB of RAM
Control: tag 684775 + upstream confirmed Somehow this has been forgotten in the BTS. We talked with Uwe on IRC about this. As stated in the original bugreport, guest crashes, but only when HOST kernel is 32bits, switching to 64bits host kernel fixes the issue. Since 64bit kernel and 32bit userland is now quite safe to use, and arguable, running 32bit kernel on a machine capable of 64bits operations and having 8Gb memory isn't a good idea, this bug has been here for quite some time, it is the first time it is reported, and I don't consider it of high priority. It is still necessary to verify where the problem is (host kernel, qemu/kvm userspace), when it has been introduced, and finally to fix it. I'll try to do that when time permits. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686146: purging autofs5 fails with ucfr: Association belongs to autofs, not autofs5
On 04.09.2012 12:16, Harald Dunkel wrote: On 09/03/12 07:04, Michael Tokarev wrote: That turned out to be not so simple, and there's no established way to deal with such a situation. Indeed, manually upgrading autofs5 will let you to purge it. But in order to allow this purging automatically in this situation, I had to remove autofs5's postrm script in autofs postinst. I am pretty sure that one package should not mess with the maintainer scripts of another package. Please propose another solution. From the two solutions I know -- - removing old package's postrm - depending on the transitional package first works and is transparent for the user, while second is annoying - again, for the user. Note the another package is the actually same, just older/renamed. BTW, I can check for the version of autofs5 too, to ensure it is 5.0.6, before removing the postrm script. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686706: seabios: Could not open option rom 'kvmvapic.bin': No such file or directory
tag 686706 - upstream + pending reassign 686706 qemu 1.1.0+dfsg-1 severity 686706 important merge 678217 686706 thanks On 05.09.2012 02:07, bmorel wrote: Package: seabios Version: 1.7.0-1 Severity: normal Tags: upstream First, seabios package in debian does include this file, in /usr/share/seabios (dpkg -L seabios will tell you). Second, it is not upstream issue. More, this file is not shipped in seabios by upstream, it is part of qemu package. Dear Maintainer, Starting a virtual machine with qemu is fine, but shows a message on console about a file which can not be found. This is #678217. Reassigned and merged. For now, you can create /usr/share/qemu/kvmvapic.bin symlink pointing to /usr/share/seabios/vapic.bin. However, this file exists in '/usr/share/kvm/kvmvapic.bin' This is a symlink belonging to qemu-kvm package. It is the most screwed-up bugreport I've seen so far. But okay, we'll sort it out anyway. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686973: VT100 emulation vulnerability (CVE-2012-3515, XSA-17)
Source: qemu Version: 0.12.5+dfsg-3squeeze1 Severity: grave Tags: security upstream patch All versions of qemu (and qemu-kvm) since 2004 have a flaw in handling VT100 escape sequences when emulating some devices with a virtual console backend. More information can be found at redhat bugreport there: https://bugzilla.redhat.com/show_bug.cgi?id=851252 and Xen Security Advisory at http://seclists.org/oss-sec/2012/q3/381 . This issue has been fixed in upstream version 1.1.2 (and 1.2.0), and affects all current versions of Debian. I'll prepare the security fixes in the nearest future. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529314: QEMU 1.2.0
On 08.09.2012 00:35, folkert wrote: [] pSeries support is already present in 1.1. That said if it works well [] Are you sure? It doesn't work: folkert@nieuw:~$ qemu --version QEMU emulator version 1.1.0 (Debian 1.1.0+dfsg-1), Copyright (c) 2003-2008 Fabrice Bellard folkert@nieuw:~$ qemu-system-ppc64 -M pSeries Supported machines are: pseries pSeries Logical Partition (PAPR compliant) Maybe this one? /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686979: qemu: spapr-rtas.bin and slof.bin missing for pSeries
Control: severity 686979 wishlist thanks On 08.09.2012 01:03, folkert wrote: Package: qemu Version: 1.1.0+dfsg-1 Severity: normal For the 'pseries' machine type, the files mentioned in the subject are missing in the .deb-file. I did an apt-file search for them and it seems there are no packages for them. This is a known issue (see #684909) without a good solution due to difficulties with producing arch-all packages which should be built each on its own architecture, all from the same source. Or someone should package the firmware separately, since it is not really provided by qemu source (even if upstream includes relevant source as git submodules). Downgrading to wishlist (since pseries support hasn't been supported before), and retitling to include pSeries. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687040: qemu-kvm / libvirt* : PCI Passthough for Atheros WiFi card does not work
On 08.09.2012 20:55, michael chlon wrote:
Package: qemu-kvm
Version: 1.1.1+dfsg-1
Severity: normal
Dear Maintainer,
I try to bind my WiFi card - Atheros ( module ath5k) - with my VM
in dorder to present WiFi card to the VM.
I try this with PCi Passtrough.
I have read a lot on internet, and done this:
- Activate iommu with for my kernel:
[]
- Then, activate the kvm module parameter (as request in syslog and VM
log !):
options kvm allow_unsafe_assigned_interrupts=1
- Kernel: 3.2.0-3-amd64
- qmeu-kvm: 1.1.1+dfsg-1
But each time, impossible to boot, with this messsage in virt-manager:
Unable to read from monitor: Connection reset by peer
Traceback (most recent call last):
File /usr/share/virt-manager/virtManager/asyncjob.py, line 45, in
cb_wrapper
callback(asyncjob, *args, **kwargs)
File /usr/share/virt-manager/virtManager/asyncjob.py, line 66,
in tmpcb
callback(*args, **kwargs)
File /usr/share/virt-manager/virtManager/domain.py, line
1114, in startup
self._backend.create()
File /usr/lib/python2.7/dist-packages/libvirt.py,
line 620, in create
if ret == -1: raise libvirtError
('virDomainCreate() failed', dom=self)
libvirtError: Unable to read from monitor:
Connection reset by peer
The good new ... is that the VM boot with my ethernet NIC card !
Please show what _kvm_ process says. It might be somewhere in
libvirt logs. And please complain to libvirt for not showing
error messages.
Did this wifi card work before, with some previous version of
qemu-kvm? I mean, is it a regression of an old bug?
Please try running stuff without libvirt.
Thanks,
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687040: qemu-kvm / libvirt* : PCI Passthough for Atheros WiFi card does not work
On 09.09.2012 01:38, Chlon Michaël wrote: [] = And in the VM log (qemu log): 2012-09-08 21:27:35.632+: starting up LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/ QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-1.1 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name android_4 _0 -uuid 65471d1a-613d-9046-94ce-2d57e234033e -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/android_4_0.monitor,server,nowait -mon chardev=charmonitor,id=monitor ,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/etc/libvirt/qemu/android_4_0.img,if=none,id=drive-ide0-0-0,format=raw -device ide-hd,bus=id e.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -chardev pty,id=chars erial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -vga cirrus -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device pc i-assign,host=37:09.0,id=hostdev0,configfd=34,bus=pci.0,addr=0x3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 Domain id=2 is tainted: high-privileges char device redirected to /dev/pts/10 Failed to assign irq for hostdev0: Input/output error Perhaps you are assigning a device that shares an IRQ with another device? kvm: -device pci-assign,host=37:09.0,id=hostdev0,configfd=34,bus=pci.0,addr=0x3: Device 'pci-assign' could not be initialized 2012-09-08 21:27:36.845+: shutting down Here we go. This is the error/log which I asked you to provide (I wish libvirt gave these details right away without extra efforts from the user). So you have to investigate - the IRQ hint is a good hint to start with. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687257: libutempter0 is not multiarch-aware, embeds executable
Package: libutempter0 Version: 1.1.5-4 Severity: normal As $Subject says, libutempter0 is not Multi-Arch-able. I can guess this is because of /usr/lib/utempter/utempter executable which is shipped in this package. Due to this non-multi-arch-awareness, it isn't possible to install foreign packages depending on it. One trivial solution (to keep this package single as before) is to move /usr/lib/utempter/utempter to /usr/lib/$triplet/utempter, this way it will be co-installable with itself. Alternative is to split the binary into separate libutempter-bin package. I'm not sure which is preferred: while first way is less intrusive and is very simple, we're getting additional setgid binary for each arch, while second way minimizes number of setgid binaries to watch for. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539514: please enable DEBUG_BIOS
On 01.08.2009 20:22, Robert Millan wrote: Package: qemu Version: 0.10.5-1 Severity: wishlist Tags: patch Debug versions of vgabios.bin are provided, but they aren't useful because support for debug information is not enabled in qemu. Please enable DEBUG_BIOS so that the information that is sent out by vgabios will reach standard output. [Replying to an old bugreport] Current qemu has another debugging feature, which is enabled by a special chardev, like this: -chardev stdio,id=seabios \ -device isa-debugcon,iobase=0x402,chardev=seabios This is for seabios itself, but probably not for vgabios. Is that chardev not enough for your needs? Upstream is now in process of removing the code around this (parts in hw/pc.c which are enabled after #defining DEBUG_BIOS), and the next version of qemy most likely will use vgabios from the seabios sources, not from the bochs project -- and that one will most likely have different (and simpler) debugging provisions. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684355: unblock: autofs/5.0.6-3
Control: retitle -1 unblock: autofs/5.0.7-1 Please unblock package autofs There are a few relatively small changes fixing some bugs and making the package more accurate. Also, per request from the previous maintainer, debian/control is changed to list new maintainer address - this is important change by its own. I uploaded the package into unstable, adding a few more changes on the way - manpage hyphen fix and usage of hardening flags. The new debdiff is attached. We reviewed remaining upstream changes between 5.0.6 and 5.0.7 releases (debian 5.0.6-2+ package was based on a middle of 5.0.7 upstream release) and realized that all changes in 5.0.7 and even PAST 5.0.7 are bugfixes, and many are important as well. So we went on and packaged upstream release 5.0.7 plus almost all past-5.0.7 changes from upstream git. Since the amount of bugs in autofs is really huge, any bugfixing is important, that's why we decided to package 5.0.7 to start with. Complete debdiff between 5.0.6-2 which is currently in wheezy and proposed 5.0.7-1 is large: 72 files changed, 3611 insertions(+), 7322 deletions(-) but this is because we initially included half of the upstream git changes past 5.0.6, debian/patches/autofs-5.0.6-upstream-git.patch, which was 6015 lines long, and with all that now is within various files in orig.tar.gz. Actual differences between upstream 5.0.7 and debian 5.0.6+ is this: 31 files changed, 744 insertions(+), 574 deletions(-) this since commit 09d4edb2469f9415f6ca33760d83b3c85b517de7, autofs-5.0.6 - fix libtirpc name clash: http://git.kernel.org/?p=linux/storage/autofs/autofs.git;a=shortlog in there, basically, all changes between 2012-06-28 (by Leonardo Chiquitto) and up to release_5_0_7 tag. We also included 4 out of 5 fixes past 5.0.7 in there - omitting a larger, ipv6-related change fix ipv6 proximity calculation, which has some breaking potential. Here's the changelog since 5.0.6-2 (wheezy) version: autofs (5.0.7-1) unstable; urgency=low * new upstream (5.0.7) release. It brings the following changes: - fixed remount deadlock, and several other locking fixes - fixed umount recovery for busy direct mounts - removed old code (mount-move which was fixed in 5.0.6-4 #686438) - fix hosts lookup module to be more robust - implemented abilty to re-read indirect maps on the fly (sighup) - fixes for nfs handling to be more robust - several fixes for multi-mount entries - several fixes for NFSv4 mounts (Closes: #675798) and a few more small/misc fixes. This is all-bugfix changes, making the code more robust and less buggy. * removed --disable-mount-move configure option, not needed anymore. * removed autofs-5.0.6-upstream-git.patch. * refreshed manpages-hyphen.patch. * added selected fixes from upstream git, up to upstream/master commit 9872cdbf9f1588174121e6ffe6f7509cde2d98e9: - 0001-autofs-5.0.7-fix-nobind-sun-escaped-map-entries.patch (Closes: #678408) - 0002-autofs-5.0.7-fix-use-cache-entry-after-free-mistake.patch - 0004-autofs-5.0.7-fix-parse-buffer-initialization.patch - 0005-autofs-5.0.7-fix-typo-in-automount-8.patch * added remove-kernel-mount.nfs-version-check.patch to stop automount from checking for very old mount.nfs or kernel. The check isn't necessary (that's pre-squeeze versions, so not even versioned Breaks are needed anymore), but it is also harmful, since automount spawns mount.nfs at startup and confuses upstart and systemd who start tracking wrong process. The patch just removes these checks assuming we always use recent enough versions. (Closes: #678555) -- Michael Tokarev m...@tls.msk.ru Wed, 26 Sep 2012 21:15:05 +0400 autofs (5.0.6-4) unstable; urgency=low * configure with --disable-mount-move -- upstream even removed the code in question for 5.0.7 release (Closes: #686438) * remove autofs5.postrm in autofs.postinst to cope with old maintscript removing our configfiles. See comments in autofs.postinst for more details (Closes: #686146) * added allow-nsswitch.conf-to-not-contain-automount-lines.patch (submitted to upstream too) to stop automount from complaining when nsswitch.conf does not mention autofs (which is almost every install anyway). (Closes: #682266, #602090) -- Michael Tokarev m...@tls.msk.ru Sat, 22 Sep 2012 13:07:46 +0400 autofs (5.0.6-3) unstable; urgency=low [Michael Tokarev] * almost completely rewrote the startup script, make it cleaner, consistent and actually returning proper exit codes. Removed $ constructs too, dash apparently does not understand these. (Closes: #677520, #683936) * transfer ownership of ucf-conffiles forcibly only if they're owned by autofs5, not by any other package. * run ucf --purge in postrm only if it is installed, and in the right order too (Closes: #685468) * added filagdir.patch - fix a typo in configure.in which prevents from
Bug#684355: unblock: autofs/5.0.6-3
On 26.09.2012 23:49, Michael Tokarev wrote:
[]
Debdiff between wheezy and sid version will be sent in a separate
email, since it is large. The same but without upstream changes
(which are easily visible in the git tree referenced above) and
the removal of half-5.0.7 upstream diff from debian/patches is
below. The diffstat for this short version:
16 files changed, 489 insertions(+), 86 deletions(-)
And ofcource I forgot to add the debdiff. Attached now.
/mjt
diff -Nru autofs-5.0.6/debian/autofs.init autofs-5.0.7/debian/autofs.init
--- autofs-5.0.6/debian/autofs.init 2012-06-01 16:12:48.0 +0400
+++ autofs-5.0.7/debian/autofs.init 2012-06-07 23:41:38.0 +0400
@@ -1,7 +1,5 @@
#! /bin/sh
#
-# rc file for automount using a Sun-style master map.
-#
### BEGIN INIT INFO
# Provides: autofs
@@ -17,11 +15,10 @@
# Location of the automount daemon and the init directory
#
-DAEMON=/usr/sbin/automount
-prog=`basename $DAEMON`
-DEVICE=autofs
-NAME=autofs
-PIDFILE=/var/run/${NAME}.pid
+PROG=automount
+DAEMON=/usr/sbin/$PROG
+NAME=autofs
+PIDFILE=/run/$NAME.pid
test -e $DAEMON || exit 0
@@ -37,103 +34,78 @@
. /etc/default/autofs
fi
+start_stop_autofs() {
+ start-stop-daemon $@ --pidfile $PIDFILE --exec $DAEMON -- \
+ $OPTIONS --pid-file $PIDFILE
+}
+
start() {
- log_action_begin_msg Starting $prog $prog
+ log_action_begin_msg Starting $PROG
- # Make sure autofs4 module is loaded
- if ! grep -q autofs /proc/filesystems
+ if ! grep -qw autofs /proc/filesystems
then
- # Try load the autofs4 module fail if we can't
- modprobe autofs4 /dev/null 21
- if [ $? -eq 1 ]
+ if ! modprobe autofs4 /dev/null 21
then
log_action_end_msg 1 failed to load autofs4 module
return 1
fi
elif [ -f /proc/modules ] grep -q ^autofs[^4] /proc/modules
then
- # wrong autofs filesystem module loaded
log_action_end_msg 1 autofs kernel module is loaded, autofs4
required
return 1
fi
- start-stop-daemon --start --exec $DAEMON --oknodo -- $OPTIONS
--pid-file $PIDFILE
- RETVAL=$?
- if [ $RETVAL -eq 0 ] ; then
- log_end_msg 0
- else
+ if ! start_stop_autofs --start --oknodo --quiet ; then
log_action_end_msg 1 no valid automount entries defined.
+ return 1
fi
+ log_end_msg 0
return 0
}
stop() {
- log_action_begin_msg $Stopping $prog:
- count=0
- while [ -n `pidof $prog` -a $count -lt 15 ] ; do
- start-stop-daemon --stop --exec $DAEMON --oknodo
- [ -z `pidof $prog` ] || sleep 3
- count=`expr $count + 1`
- done
- if [ -z `pidof $prog` ] ; then
- RETVAL=0
- log_action_end_msg 0
- else
- RETVAL=1
+ log_action_begin_msg Stopping $PROG
+ if ! start_stop_autofs --stop --retry 5 --oknodo --quiet ; then
log_action_end_msg 1
+ return 1
fi
- return $RETVAL
-}
-
-restart() {
- stop
- start
+ log_end_msg 0
+ return 0
}
reload() {
- pid=`pidof $prog`
- if [ -z $pid ]; then
- log_action_msg $$prog not running
- RETVAL=1
- else
- kill -HUP $pid 2 /dev/null
- log_action_msg $Reloading maps
- RETVAL=0
+ log_action_begin_msg Reloading $PROG maps
+ if ! start_stop_autofs --stop --signal=HUP --quiet
+ then
+ log_action_end_msg 1 $PROG not running
+ return 1
fi
- return $RETVAL
+ log_action_end_msg 0
+ return 0
}
-RETVAL=0
+forcestart() {
+ OPTIONS=$OPTIONS --force
+ start
+}
case $1 in
- start)
- start
- ;;
- forcestart)
- OPTIONS=$OPTIONS --force
- start
- ;;
- stop)
- stop
+ start|forcestart|stop|reload)
+ $1
;;
restart|force-reload)
- restart
+ stop
+ start
;;
forcerestart)
- OPTIONS=$OPTIONS --force
- restart
- ;;
- reload)
- reload
+ stop
+ forcestart
;;
status)
- status_of_proc -p $PIDFILE $DAEMON $prog
+ status_of_proc -p $PIDFILE $DAEMON $PROG
;;
*)
- echo $Usage: $0
{start|forcestart|stop|restart|forcerestart|reload|force-reload|status}
- exit 1;
+ echo Usage: $0
{start|forcestart|stop|restart|forcerestart|reload|force-reload|status}
+ exit 1
Bug#688964: qemu-kvm: Fedora 17 guest hangs on boot with soft lockup in udevd
Control: tags -1 + moreinfo On 27.09.2012 18:27, Nikolai Kondrashov wrote: Package: qemu-kvm Version: 1.1.2+dfsg-2 Severity: important A fully-updated 64-bit Fedora 17 guest using the 3.5.4-1.fc17.x86_64 kernel hangs on boot with the following repeated messages on the console: BUG: soft lockup - CPU#0 stuck for 22s! [udevd:417] It boots at least with 1.1.0+dfsg-3. The 1.1.1+dfsg-1 breaks it. Ok, so this is a breakage in 1.1.x stable series. This update contains 30 commits -- http://git.qemu.org/?p=qemu-stable-1.1.git;a=shortlog between v1.1.1 and v1.1.0 tags. 2 of these commits are already in qemu-kvm 1.1.0, and 15 commits are completely irrelevant (touching different architectures, or are documentation fixes, or adding config-time checks etc. So that's definitely not too much. The qemu-kvm was being controlled by virt-manager. Please provide full command line which virt-manager uses. You can find it in virtmanager logs or in ps(1) output. Trying to bisect it with git, skipping merged commits, which don't have the debian directory, produced the following list of commits which could be breaking it: Bisecting these 13 commits is a bit, well, fun, but bisecting across merges is difficult. dbe4ac16bbab4c237ff54132968accad4f5a4757 f63e60327b8e239ae97fa71060940ca20a8bf38e 02fe741375d4993b3d6870ff6466cc775b409ba1 0ec39075710ae15acc2a5825cd21e0c229fa04af 1658e3cd893e3a35d89388fdd736a6d81cb405e8 ee7735fa639c43ccb3746d84609332e48e22479f 065436479b9164b51892dbd7a7e35a3f9f496894 0da4c073228c645a0366f3fe801df072cf268482 70d582074f0b9485ad9800f8e0126ef68608ba85 f6db26e4f8fe6d80e17aa62e6bcc465e323a7fee 4c45bf61d315316b5932051551c16b17cf9b3d85 c49dd1bf6450b7880972b2f176ec10e8a496073c b4fcb4b4995b292b6013600af78d37416c6ebb34 c9c2479289fd1faf4a1a40db54cc255fbf03af21 7672b714b28e3d49f73c605873404bf6f644c2b2 feba8ae20b372115bc15432d7c484171c25bee62 7d440f20bda8658fe16bdfe9c41c689764c50248 ca09717e8e0664801522781962a3c727d04eef33 0cc21de484d4f00c7b7cacb487bd343cc55effa5 845685265756467050859e2359acf1632352 08375616a0e24484f313900311e1748a2fe12f87 cd63a77e990f68a699ba220c8006386bd4379f81 b7093f294c330c4db789c077dac9d8611e4f8ee0 b993b863e78ae54c5e966f4e1626bc37c560e6aa 07ff37597bee726681c94c650568870bd4ff94d1 4082e889ee8aa43b303105180399bab14312231e e77326d99c938d78a06036b8529b669253baec59 f52d0d639e96f30b226b853d931881d034c57308 785adb09b9fd0d4df6707f00247ec519c42fcfc6 8b3ac661208c88b9d424ede176b99be6fff1283e 2eb4d314cef55749f7835f6338080895daed277e adda59173c976b8863d74b612fafa9212b9182f2 7fa12eb15f95c269f488fce4096093c96dbaffab b696aeab6ad6abe3b45fac96264a40a555ff64ce 6514fe50471ca277c461435b17771e91c115b010 6f82a5ea52302bab33287b0191538be6f9138637 dd48eac4f170fa78ada12df70573c0d757f8febf 37add8028a2872563e7c6efa598e439508eb9a53 398b87f4ef3426569bdda2da2c9c2b89f4ba906f c63c453889d0bfbd183da686bc076590220fd44a 94a6e73b39d7f9ad8ebebaa080932437690a7412 Wow. That's quite a bit more than 13 commits which are EVER possible to be the problem ;) I don't understand what did you bisect. Please give me some pointers about how to install this fedora version - download links, options you've choosen etc. I haven't used redhat-based distro for more than 10 years, so your help can greatly reduce time required to solve this. And please don't forget to provide the command line. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688964: qemu-kvm: Fedora 17 guest hangs on boot with soft lockup in udevd
On 27.09.2012 20:25, Nikolai Kondrashov wrote: On 09/27/2012 06:23 PM, Michael Tokarev wrote: Please provide full command line which virt-manager uses. You can find it in virtmanager logs or in ps(1) output. Here is the command line: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/root USER=root LOGNAME=root QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-1.1 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name fedora-hang-test -uuid d155797a-03fb-0181-8e71-8d38181a7158 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fedora-hang-test.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/fedora-hang-test.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/home/nkondras/tmp/Fedora-17-x86_64-Live-Desktop.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=20,id=hostnet0,vhost=on,vhostfd=22 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:5e:20:81,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:1 -vga cirrus -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 Simply booting from this Live CD hangs: http://download.fedoraproject.org/pub/fedora/linux/releases/17/Live/x86_64/Fedora-17-x86_64-Live-Desktop.iso Ok. I reproduced this, I _think_, and now I want some confirmation from you. This is my command line: QEMU_AUDIO_DRV=none qemu-kvm -nodefconfig -nodefaults -enable-kvm \ -monitor stdio -rtc base=utc \ -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ -m 512 -vga cirrus -cdrom Fedora-17-x86_64-Live-Desktop.iso \ -device intel-hda,id=sound0,bus=pci.0,addr=0x4 \ -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 leads to this in guest: ... Starting udev Wait for Complete Device Initialization... [4.123978] piix4_smbus :00:01.3: SMBus Host Controller at 0xb100, revision 0 [4.311473] microcode: AMD CPU family 0x6 not supported [4.355429] microcode: AMD CPU family 0x6 not supported [7.323032] ALSA sound/pci/hda/hda_intel.c:823 azx_get_response timeout, switching to polling mode: last cmd=0x000f [8.325018] ALSA sound/pci/hda/hda_intel.c:831 No response from codec, disabling MSI: last cmd=0x000f [ 36.055021] BUG: soft lockup - CPU#0 stuck for 22s! [udevd:385] [ 36.055026] Modules linked in: snd_hda_intel(+) snd_hda_codec snd_hwdep i2c_piix4 snd_pcm i2c_core snd_page_alloc snd_timer snd soundcore uinput squashfs [ 36.055026] CPU 0 [ 36.055026] Modules linked in: snd_hda_intel(+) snd_hda_codec snd_hwdep i2c_piix4 snd_pcm i2c_core snd_page_alloc snd_timer snd soundcore uinput squashfs [ 36.055026] [ 36.055026] [ 36.055026] Pid: 385, comm: udevd Not tainted 3.3.4-5.fc17.x86_64 #1 Bochs Bochs [ 36.055026] RIP: 0010:[8105dc40] [8105dc40] __do_softirq+0x70/0x1e0 [ 36.055026] RSP: 0018:88001f003ef0 EFLAGS: 0206 [ 36.055026] RAX: 88001f8a7fd8 RBX: 81a17240 RCX: 0001f0542108 [ 36.055026] RDX: RSI: 006f RDI: 0002 [ 36.055026] RBP: 88001f003f40 R08: R09: 81c64540 [ 36.055026] R10: 0400 R11: 0020 R12: 88001f003e68 [ 36.055026] R13: 815f439e R14: 88001f003f40 R15: 0046 [ 36.055026] FS: 7f14b7509840() GS:88001f00() knlGS: [ 36.055026] CS: 0010 DS: ES: CR0: 8005003b [ 36.055026] CR2: 7fa5e9e4 CR3: 1f80e000 CR4: 06f0 [ 36.055026] DR0: DR1: DR2: [ 36.055026] DR3: DR6: 0ff0 DR7: 0400 [ 36.055026] Process udevd (pid: 385, threadinfo 88001f8a6000, task 88001b218000) [ 36.055026] Stack: [ 36.055026] 8101ac19 88001f8a7fd8 88001f8a7fd8 880a [ 36.055026] 88001f014000 88001f8a7fd8 0046 0007 [ 36.055026] 0050 0001 88001f003f58 815f4d9c [ 36.055026] Call Trace: [ 36.055026] IRQ [ 36.055026] [815f4d9c] call_softirq+0x1c/0x30 [ 36.055026] [81015465] do_softirq+0x75/0xb0 [ 36.055026] [8105e055] irq_exit+0xb5/0xc0 [ 36.055026] [815f56ee] smp_apic_timer_interrupt+0x6e/0x99 [ 36.055026] [815f439e] apic_timer_interrupt+0x6e/0x80 [ 36.055026] EOI [ 36.055026] [810e22ac
Bug#688964: qemu-kvm: Fedora 17 guest hangs on boot with soft lockup in udevd
To clarify: 1. this only affects 1.1.x tree (which is a history for most developers already) 2. the same guest boots okay with 1.2 (with kvm and irqchip enabled). BTW, what is this hda-duplex device anyway? I never heard of it before now :). And I guess using QEMU_AUDIO_DRV=none with a guest sound device isn't very smart move ;) (But setting it to something else does not change things). Also note that 1.1.1 contained one more patch which added msi reset, this time for ahci. Thanks, /mjt QEMU_AUDIO_DRV=none qemu-kvm -nodefconfig -nodefaults -enable-kvm \ -monitor stdio -rtc base=utc \ -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ -m 512 -vga cirrus -cdrom Fedora-17-x86_64-Live-Desktop.iso \ -device intel-hda,id=sound0,bus=pci.0,addr=0x4 \ -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 leads to this in guest: ... Starting udev Wait for Complete Device Initialization... [4.123978] piix4_smbus :00:01.3: SMBus Host Controller at 0xb100, revision 0 [4.311473] microcode: AMD CPU family 0x6 not supported [4.355429] microcode: AMD CPU family 0x6 not supported [7.323032] ALSA sound/pci/hda/hda_intel.c:823 azx_get_response timeout, switching to polling mode: last cmd=0x000f [8.325018] ALSA sound/pci/hda/hda_intel.c:831 No response from codec, disabling MSI: last cmd=0x000f [ 36.055021] BUG: soft lockup - CPU#0 stuck for 22s! [udevd:385] [ 36.055026] Modules linked in: snd_hda_intel(+) snd_hda_codec snd_hwdep i2c_piix4 snd_pcm i2c_core snd_page_alloc snd_timer snd soundcore uinput squashfs commit 0ec39075710ae15acc2a5825cd21e0c229fa04af (8e729e3b521d9fcd87fc2e40b6322e684f58bb2e upstream) Author: Jan Kiszka jan.kis...@siemens.com Date: Fri May 11 11:42:35 2012 -0300 intel-hda: Fix reset of MSI function -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688964: qemu-kvm: Fedora 17 guest hangs on boot with soft lockup in udevd
On 27.09.2012 22:28, Jan Kiszka wrote:
[]
--- a/hw/intel-hda.c
+++ b/hw/intel-hda.c
@@ -1107,6 +1107,9 @@ static void intel_hda_reset(DeviceState *dev)
DeviceState *qdev;
HDACodecDevice *cdev;
+if (d-msi) {
+msi_reset(d-pci);
+}
intel_hda_regs_reset(d);
d-wall_base_ns = qemu_get_clock_ns(vm_clock);
which is exactly about this hda thing. I'm CC'ing relevant
people here.
I suppose we are resetting the MSI configuration also in cases here
where only the HDA internals are supposed to be reset (when called from
intel_hda_set_g_ctl).
Hmm. I was looking at this code already (but i don't know the machinery
anyway). Here it is (I addedd two printfs in obvious places):
in intel_hda_reset
calling intel_hda_reset from intel_hda_set_g_ctl
in intel_hda_reset
(at this time it hangs in guest).
The following patch fixes it. Is it correct? :)
/mjt
diff --git a/hw/intel-hda.c b/hw/intel-hda.c
index e38861e..fdd7eeb 100644
--- a/hw/intel-hda.c
+++ b/hw/intel-hda.c
@@ -199,7 +199,7 @@ struct IntelHDAReg {
void (*rhandler)(IntelHDAState *d, const IntelHDAReg *reg);
};
-static void intel_hda_reset(DeviceState *dev);
+static void intel_hda_reset_dev(DeviceState *dev);
/* - */
@@ -500,7 +500,7 @@ static void intel_hda_notify_codecs(IntelHDAState *d, uint32_t stream, bool runn
static void intel_hda_set_g_ctl(IntelHDAState *d, const IntelHDAReg *reg, uint32_t old)
{
if ((d-g_ctl ICH6_GCTL_RESET) == 0) {
-intel_hda_reset(d-pci.qdev);
+intel_hda_reset_dev(d-pci.qdev);
}
}
@@ -1101,15 +1101,12 @@ static const MemoryRegionOps intel_hda_mmio_ops = {
/* - */
-static void intel_hda_reset(DeviceState *dev)
+static void intel_hda_reset_dev(DeviceState *dev)
{
IntelHDAState *d = DO_UPCAST(IntelHDAState, pci.qdev, dev);
DeviceState *qdev;
HDACodecDevice *cdev;
-if (d-msi) {
-msi_reset(d-pci);
-}
intel_hda_regs_reset(d);
d-wall_base_ns = qemu_get_clock_ns(vm_clock);
@@ -1122,6 +1119,15 @@ static void intel_hda_reset(DeviceState *dev)
intel_hda_update_irq(d);
}
+static void intel_hda_reset(DeviceState *dev)
+{
+IntelHDAState *d = DO_UPCAST(IntelHDAState, pci.qdev, dev);
+if (d-msi) {
+msi_reset(d-pci);
+}
+intel_hda_reset_dev(dev);
+}
+
static int intel_hda_init(PCIDevice *pci)
{
IntelHDAState *d = DO_UPCAST(IntelHDAState, pci, pci);
Bug#688964: [PATCH] intel_hda: do not call msi_reset when only device state needs resetting
Commit 8e729e3b521d9 intel-hda: Fix reset of MSI function
(applied to 1.1.1 as 0ec39075710) added a call to msi_reset()
into intel_hda_reset() function. But this function is called
not only from PCI bus reset method, but also from device init
method (intel_hda_set_g_ctl()), and there, we should not reset
msi state. For this, split intel_hda_reset() into two halves,
one common part with device reset, and one with msi reset,
intel_hda_reset_msi(), which also calls the common part, for
the bus method.
This is only needed for 1.1.x series, since in 1.2+, MSI reset
is called in proper places by the PCI code already.
Signed-off-by: Michael Tokarev m...@tls.msk.ru
Cc: Jan Kiszka jan.kis...@siemens.com
Cc: 688...@bugs.debian.org
---
hw/intel-hda.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/hw/intel-hda.c b/hw/intel-hda.c
index e38861e..da61323 100644
--- a/hw/intel-hda.c
+++ b/hw/intel-hda.c
@@ -1107,9 +1107,6 @@ static void intel_hda_reset(DeviceState *dev)
DeviceState *qdev;
HDACodecDevice *cdev;
-if (d-msi) {
-msi_reset(d-pci);
-}
intel_hda_regs_reset(d);
d-wall_base_ns = qemu_get_clock_ns(vm_clock);
@@ -1122,6 +1119,15 @@ static void intel_hda_reset(DeviceState *dev)
intel_hda_update_irq(d);
}
+static void intel_hda_reset_msi(DeviceState *dev)
+{
+IntelHDAState *d = DO_UPCAST(IntelHDAState, pci.qdev, dev);
+if (d-msi) {
+msi_reset(d-pci);
+}
+intel_hda_reset(dev);
+}
+
static int intel_hda_init(PCIDevice *pci)
{
IntelHDAState *d = DO_UPCAST(IntelHDAState, pci, pci);
@@ -1261,7 +1267,7 @@ static void intel_hda_class_init(ObjectClass *klass, void
*data)
k-revision = 1;
k-class_id = PCI_CLASS_MULTIMEDIA_HD_AUDIO;
dc-desc = Intel HD Audio Controller;
-dc-reset = intel_hda_reset;
+dc-reset = intel_hda_reset_msi;
dc-vmsd = vmstate_intel_hda;
dc-props = intel_hda_properties;
}
--
1.7.10.4
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688964: qemu-kvm: Fedora 17 guest hangs on boot with soft lockup in udevd
On 27.09.2012 23:32, Michael S. Tsirkin wrote: [] Looks good to me. I just sent another patch, now with proper S-o-b and description, which does the same but touches 2 less lines (by renaming the other half of the function), -- his is to be more like the 1.2+ version. The functionality is exactly the same. ACK for stable branch. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688964: qemu-kvm: Fedora 17 guest hangs on boot with soft lockup in udevd
[Dropping the Cc list] On 27.09.2012 23:57, Nikolai Kondrashov wrote: On 09/27/2012 10:40 PM, Nikolai Kondrashov wrote: Nikolai, please verify if this is the issue you're seeing, and please try without sound device. If this is the case, let's downgrade this bug from important to normal, since emulated sound devices aren't really of high priority in this context, and there should be easy workaround (to disable sound). I wasn't able to get a backtrace, unfortunately. It just isn't printed. Could I be missing some trick? However, removing the sound device did help. Easiest way to get a backtrace is to add a serial console to guest (I used -serial file:out), set it up in grub (console=ttyS0), AND remove quiet parameter from kernel command line, together with rhgb. The quiet thing is the most frequently forgotten parameter. I'll try the patch you sent in another message next. I've just tried latest master of git://git.debian.org/git/collab-maint/qemu-kvm.git where you applied your patch and it works. Both with your command line and from virt-manager. OK, excellent! Thank you very much for fixing it this fast :)! It was really easy to find the stuff in between the 13 commits :) And Jan noted the right place as well, it is more his work than mine. Now, it isn't really clear when this fix will hit the debian archive (ie, will be released to debian). I understand it is annoying to have bugs like this, but I'm afraid to push even more work to the release team. Current freeze policy is to allow fixing only bugs with severity serious and up, and your does not qualify :) Could you please tag your last two dfsg releases, so it is easier to check them out next time? I tagged it the time when I uploaded them, but forgot to push. Note I changed the tag format to include package name too, since else the tags in qemu and qemu-kvm packages/repositories clashes with each other. Thanks for noticing this, and for verifying the fix! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688964: qemu-kvm: Fedora 17 guest hangs on boot with soft lockup in udevd
Control: retitle -1 emulated hda-intel does not work since 1.1.1 upstream release (linux guest hangs) Control: found -1 1.1.1+dfsg-1 Control: affects -1 qemu I tried a few other guests with the same command line, and all shows bad behavor. Debian wheezy kernel also hangs when loading hda-intel modules, and win7 guest BSODs at startup. Is intel-hda the default for libvirt now, or should it be explicitly enabled? If the former, we've a serious bug here, for sure. Retitling the bug accordingly, and trying to understand the defaults of libvirt... And sure thing, the same issue equally affects qemu too. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689239: qemu-system: rbd images (ceph) are not working any more
Control: severity -1 wishlist On 30.09.2012 21:51, Harald Roessler wrote: Package: qemu-system Version: 1.1.2+dfsg-2 Severity: important Dear Maintainer, After installatio of version 1.1.2+dfsg-2 rbd images does not working more. The testing after the installation results in: -- error: internal error process exited while connecting to monitor: char device redirected to /dev/pts/2 qemu-system-x86_64: -drive file=xxx:xxx/xxx-xxx-xx:mon_host=10.10.10.128\:6789\;10.10.10.129\:6789\;10.10.10.132\:6789,if=none,id=drive-virtio-disk0,format=raw,cache=none: could not open disk image rbd:xxx/xxx-xxx-xx:mon_host=10.10.10.128\:6789\;10.10.10.129\:6789\;10.10.10.132\:6789: No such file or directory -- After rollback to version 1.1.0+dfsg-1 via dpkg rbd images are woking fine again. Please add rbd support again. Thanks! rbd (ceph) will not work in wheezy. I'm sorry about that, but ceph weren't in shape for wheezy, and ceph support has been dropped from all dependent packages. Hopefully it will be back in jessie (wheezy+1). Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684708: mdadm: support external metadata arrays correctly
On 02.10.2012 17:20, Miquel van Smoorenburg wrote: Package: mdadm Version: 3.2.5-1 [version 2 of the patch] The initramfs hook supplied by mdadm doesn't install mdmon. Also, mdmon is not included in the .udeb for the installer. This means that if you have an array with external metadata (ddf or, more widely used, imsm - Intel Matrix Raid) that it will come up readonly. This causes the installer to hang or the system not being able to boot if root is on that array. The attached patch does the following: - it makes sure mdadm is included in the initramfs and the udeb package - it adds a mdadm-waitidle script that runs just before reboot/halt. For arrays that are still running, it calls mdadm --wait-clean to wait for the array to go idle. This is needed so that the array is marked clean, otherwise it will start to resync at the next boot. - it adds a few lines to /etc/init.d/mdadm for the start and stop actions: o start: if a mdmon pidfile is found in /run/mdadm, restart mdmon o stop: link pidfiles of mdmon processes into /run/sendsigs.omit.d, and make sure that happens before sendsigs runs. - RUNDIR in /etc/init.d/mdadm is set to /run. This is sure to be ok: mdadm itself is already compiled with rundir hardcoded to /run. Note that I've made sure that this actually doesn't do /anything/ if you do not have running MD arrays with external metadata. Iow, this should not break anything, or cause regressions. I have added support for installation on Intel Matrix raid (imsm) arrays using mdadm to d-i, and I'll be sending patches to the debian-boot list soon. Please consider this patch for inclusion in wheezy. I think this is much more reasonable now than the previous version. I'll give it a very quick try, but I don't have any hardware currently where I can test the Real Thing unfortunately, so I'll verify only if it does not break existing stuff :) But it already looks rather good. The next thing is to convince the release team that his is indeed a good thing, too :) Thank you very much! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689747: autofs won't install with old autofs5 installation
Control: tags -1 + moreinfo unreproducible On 06.10.2012 00:41, David Starner wrote: Package: autofs Version: 5.0.7-1 Severity: serious $ sudo apt-get install autofs udev Reading package lists... Done Building dependency tree Reading state information... Done udev is already the newest version. The following NEW packages will be installed: autofs 0 upgraded, 1 newly installed, 0 to remove and 7 not upgraded. Now this is interesting. autofs 5.0.7 is declared as breaking autofs5 5.0.6. Yes when you ask to install new autofs package, apt does not offer to update autofs5 at the same time. Yet you said you have old autofs5 install in the subject. However, later you mention that there's NO autofs5 package installed, according to the dpkg -l output -- I think it was installed in the past but not purged. Now, I wonder which version of old autofs5 did you have installed. Because when I do that (install+remove) with squeeze version of autofs5, I can install sid version of autofs just fine. Can it be that you had lenny version of autofs5 maybe, or even something older? Need to get 720 kB of archives. After this operation, 1,649 kB of additional disk space will be used. Do you want to continue [Y/n]? y Get:1 http://ftp.us.debian.org/debian/ unstable/main autofs amd64 5.0.7-1 [720 kB] Fetched 720 kB in 1s (494 kB/s) Selecting previously unselected package autofs. (Reading database ... 278805 files and directories currently installed.) Unpacking autofs (from .../autofs_5.0.7-1_amd64.deb) ... Processing triggers for man-db ... fopen: Permission denied Setting up autofs (5.0.7-1) ... Installing new version of config file /etc/init.d/autofs ... ucfr: Attempt from package autofs to take /etc/auto.master away from package autofs5 ucfr: Aborting. This is the following code: # transfer ownership from old autofs5 package case $(ucfq -w /etc/default/autofs) in *:autofs5:*) force=--force ;; *) force= ;; esac for map in master net misc smb; do ucfr $force autofs /etc/auto.$map ucf /usr/share/autofs/conffiles/auto.$map /etc/auto.$map done ucfr $force autofs /etc/default/autofs ucf /usr/share/autofs/conffiles/default/autofs /etc/default/autofs we force-transfer ownership only when it currently belongs to autofs5. When old autofs5 is installed, the first ucfq query above on my system returns this: $ ucfq -w /etc/default/autofs /etc/default/autofs:autofs5:Yes:No so it properly uses --force when default/autofs is registered to autofs5. But in your case, apparently, default/autofs is not registered to autofs5, but /etc/auto.master is, and it stays first on the list to transfer ownership. Do you know if there was a version of old autofs which did not register /etc/default/autofs but registered /etc/auto.master? Or maybe it had /etc/default/autofs5 instead of default/autofs? Please show me the output of grep autofs /var/lib/ucf/registry Meanwhile I'll try to make this code fragment more robust by querying ownership for every file it touches instead of just one. Thank you! /mjt dpkg: error processing autofs (--configure): subprocess installed post-installation script returned error exit status 4 Errors were encountered while processing: autofs E: Sub-process /usr/bin/dpkg returned an error code (1) $ dpkg -l autofs\* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++--=-=-= iF autofs 5.0.7-1 amd64 kernel-based automounter for Linux un autofs5 none (no description available) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684355: unblock: autofs/5.0.7-2
Control: retitle -1 unblock: autofs/5.0.7-2 Since the previous email, one more neat way to break ucf file ownership tansfer when renaming a package has been found, #689747, which I just fixed. Initially we queried just one file which is supposed to be owned by old autofs5 - default/autofs, but it turned out that each file has to be handled separately, which is now implemented. This all is a result of a bugfix in 5.0.6-3, when I stopped transferring ucf-ownership forcible but started doing it conditionally, only of previously ownership belonged to autofs5. That was a bugfix without a separate BTS entry. Initial issue is that I do not want to transfer ownership of these files if they currently belong to some other package, if that's _ever_ possible, so using --force unconditionally does not look sane. Maybe I'm wrong here and always using --force for ucf file registration is okay, but the current version look more or less robust anyway. The small debdiff between 5.0.7-1 and 5.0.7-2 follows. Please consider unblocking the package. unblock autofs/5.0.7-2 Thank you for your time! /mjt diff -Nru autofs-5.0.7/debian/autofs.postinst autofs-5.0.7/debian/autofs.postinst --- autofs-5.0.7/debian/autofs.postinst 2012-09-03 08:52:07.0 +0400 +++ autofs-5.0.7/debian/autofs.postinst 2012-10-06 13:00:26.0 +0400 @@ -2,17 +2,15 @@ set -e if [ $1 = configure ]; then - # transfer ownership from old autofs5 package - case $(ucfq -w /etc/default/autofs) in -*:autofs5:*) force=--force ;; -*) force= ;; - esac - for map in master net misc smb; do -ucfr $force autofs /etc/auto.$map -ucf /usr/share/autofs/conffiles/auto.$map /etc/auto.$map + for file in auto.master auto.net auto.misc auto.smb default/autofs; do +# transfer ownership from old autofs5 package +case `ucfq -w /etc/$file` in + *:autofs5:*) force=--force ;; + *) force= ;; +esac +ucfr $force autofs /etc/$file +ucf /usr/share/autofs/conffiles/$file /etc/$file done - ucfr $force autofs /etc/default/autofs - ucf /usr/share/autofs/conffiles/default/autofs /etc/default/autofs fi # In version 5.0.6 (wheezy), the package has been renamed diff -Nru autofs-5.0.7/debian/changelog autofs-5.0.7/debian/changelog --- autofs-5.0.7/debian/changelog 2012-09-26 21:15:05.0 +0400 +++ autofs-5.0.7/debian/changelog 2012-10-06 13:06:37.0 +0400 @@ -1,3 +1,10 @@ +autofs (5.0.7-2) unstable; urgency=low + + * force transfer ucf autofs5=autofs ownership for all ucf-managed +files (Closes: #689747) + + -- Michael Tokarev m...@tls.msk.ru Sat, 06 Oct 2012 13:06:37 +0400 + autofs (5.0.7-1) unstable; urgency=low * new upstream (5.0.7) release. It brings the following changes: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689956: qemu-kvm: W2K8 64b srv BSOD on boot accessing system drive (bus=ide)
Control: severity -1 normal Control: tags -1 + moreinfo 08.10.2012 15:20, Josquin DEHAENE wrote: Package: qemu-kvm Version: 1.1.2+dfsg-2~bpo60+1 Severity: important Hi, We have different kind of VMs running on this host. All of them boot normaly after update to 1.1.2 expect Win2k8 64b wich make BSOD on 0x00..07E error. Note that Win2k8 srv 32b boot normaly. Downgrade to 1.0.0 make VMs to boot normaly. I don't have access to Win2K8 installation media, so can't test it. See attach file for detail VM definition. This VM definition does not help me, unfortunately. Qemu/kvm does not understand xml. It will help if you can show the kvm command line used instead. However after a brief look at the provided .xml (with my limited understanding of it) I noticed that there's no particular qemu/kvm machine version specified in there, -- and as far as I understand, it means that when you upgrade, it is okay to present slightly different virtual devices configuration than was in previous versions, -- qemu defaults to current hardware version without any specific value. In particular, it might present slightly different variants of built-in devices, with slightly different properties. The option/argument in question is -machine (or -M), which is, by default, pc which means the latest PC, or it can be pc-1.0 for example, to mean the hardware which was emulated by qemu-kvm-1.0, etc. With this in mind, it is unrealistic for qemu to provide compatible virtual hardware across versions for every guest OS variant possible, and it is not realistic to ask qemu why a particular OS or driver version does not work with one variant of qemu hardware and does not work with another. We don't control windows drivers. Another thing to have in mind is that virtual ide controller, while works, is quite a bit slow, and is not recommended for production use. There is a native device, virtio-block, with corresponding guest driver for windows available, and that one will work across upgrades - at least this is something we can control. Having said that, I'm downgrading severity of this bugreport from important to normal while I'm waiting for the qemu/kvm command line I asked above - and if my suspicious is right, and you don't specify -M/-machine of any particular version, that will be a wontfix. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689956: RE : Bug#689956: qemu-kvm: W2K8 64b srv BSOD on boot accessing system drive (bus=ide)
08.10.2012 18:05, Josquin DEHAENE wrote: I forgot to specify that VMs are managed through libvirt. Thus, the xml file is in libvirt definition format. A virsh version gives Yes I understand it is libvirt. For various reasons I still can't use it locally on my development/test machine. Besides, different versions of libvirt may generate slightly different command lines anyway, and the qemu/kvm command line is the only thing which matters here. [] I note your advice on the virtio drivers, we have already notice the performance gap but we use ide for historical reasons, in the time we've installed those VMs the windows driver wasn't functional/stable enough for our windows version. According to our test and our windows sources the windows driver is functional since the july's stable release(virtio-win-0.1-30). I see. Well, for 2k8 64 the situation is indeed a bit more difficult than for all less advanced versions of windows. In particular, there are MUCH less people who have access to win2k8 than, say, win7. Anyway here is the command line. An extract from pstree -al | grep lpp-dc kvm -S -M pc-1.0 -cpu core2duo,+lahf_lm,+rdtscp,+popcnt,+sse4.2,+sse4.1,+dca,+pdcm,+xtpr,+cx16,+tm2,+est,+vmx,+ds_cpl,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds -enable-kvm -m 2000 -smp 4,sockets=1,cores=4,threads=2 -name lpp-dc -uuid 9adb3d97-de75-ef46-f77f-b2b4eace3c1e -smbios type=0,vendor=moka pilot,version=3.0 (cluster),date=05/20/2012 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/lpp-dc.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot order=cd,menu=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/dev/drbd/by-res/disk-system-dc-lpp,if=none,id=drive-ide0-0-0,format=raw -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/dev/drbd/by-res/disk-datas-dc-lpp,if=none,id=drive-ide0-0-1,format=raw -device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive file=/mnt/meta/src/6001.18000.080118-1840_amd64fre_Server_fr-fr-KRMSXFRE_FR_D VD.iso,i f =none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=18,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:ae:09:95,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 0.0.0.0:23 -k fr -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 This does not look like the same VM as produced by the .xml you sent initially, but I'm not sure. The most important part: your .xml has this: type arch='x86_64' machine='pc'hvm/type but the command line above has -M pc-1.0. Where this 1.0 comes from? This is the key question. If the command line really has -M pc-1.0 with the buggy version of qemu-kvm, it indeed is a bug in qemu-kvm. But if it has different version - say, pc-1.1, here, it is not a bug. This is very important. If it is run as pc-1.1 when qemu-kvm_1.1.x is installed, please change the .xml to specify pc-1.0 and check if your win8 boots with that. Please let me know if I can help in anything, I hope not to have mistaken something. There aren't many thnigs here. Yes It'd be nice to have this resolved _provided_ it is indeed a bug in qemu/kvm. In order to verify we need to see which args (-M pc*) gets passed to qemu. Note you can find the complete command line somewhere in the libvirt logs too. So the things we can check: 1) -M pc-foo - which one is used? If it is pc-1.1, change it to 1.0 and retry. 2) If pc-1.0 works, we're all set, there's no bug. If pc-1.0 does NOT work it IS a bug, and we can try to pinpoint it further, but in this case I really want your help, because I don't have access to w2k8. 3) please try virtio drivers regardless of 1) and 2). This will allow you to boot regardless of -M argument. In order to use virtio drivers, add a new empty/dummy drive to the VM, and connect it to virtio bus. On first boot, windows will ask for drivers - install them. After this is done, and you rebooted and can see that empty/dummy drive, remove it from the VM definition, and you can now switch OTHER drives to virtio, since virtio driver is now registered in windows properly and will be used during boot too. The same way can be done to re-install an IDE driver - switch to virtio, next create a dummy ide drive and let it to install drivers for that. But for ide, a shorter path can be used - in 1.0 (working) version, switch the IDE controller driver to Standard/generic IDE controller, reboot into 1.1, and let it redetect the controller. The first boot (before redetection) will be very slow, since no good storage driver is in use, but on next boot it should work. This all applies to winnt4.0-win7, but I dunno if that will work on win2k8 64bits. And last but not least, thank you very much for your good job.
Bug#696865: backported version does not provide some symbols provided by version in wheezy, and no soname/soversion given in dependencies
Package: libldns1 Version: 1.6.13-1~bpo60+1 Severity: grave Justification: breaks other package(s) After updating unbound, which is linked with libldns1, from the version in squeeze-backports to the one in wheezy, the daemon does not start: Starting recursive DNS server: unbound /usr/sbin/unbound: symbol lookup error: /usr/sbin/unbound: undefined symbol: ldns_key_EVP_load_gost_id failed! Both the bpo60 and wheezy packages of libldns1 are based on the same version (1.6.13-1), and the bpo60 changelog contains only one item: ldns (1.6.13-1~bpo60+1) squeeze-backports; urgency=low * Backport for Debian 6.0 -- Ondřej Surý ond...@debian.org Sun, 10 Jun 2012 08:56:58 +0200 However, the two versions, while being very close to each other, are in fact incompatible with each other. And no dependency information is given so that packages that are linked with the version in wheezy can be trivially installed without requiring libldns1 update, and hence breaking other packages. At the very least, the library (actually libldns-dev package) should provide symvers information, so that dpkg is able to track this sort of things automatically. I'm not sure how to deal with the current mess in bpo60 -- here I had to use my smartphone in order to d/load libldns1 from wheezy, since the update broke our DNS resolver and I weren't able to d/load anything anymore. But since no package provides any dependency information, it's difficult to say how to actually fix this properly... Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696917: roxterm does not handle quotes in URLs correctly
Source: roxterm
Version: 2.6.5-1
Severity: grave
Tags: security
When trying to click on an URL inside the roxterm window that contains
a single quote ('), the resulting command sent to the shell includes
this quote and is interpreted by the shell, for example:
http://example.com/quote'here
will be handled as
x-www-browser 'http://example.com/quote'here'
In this example, shell will complain that there's no closing quote before
the end of command, but I can guess this can be (ab)used for some more
interesting scenarious, like to spawn commands unexpectedly:
http://example.com/one'foo|bar'two
or the like. The charset allowed in this context does not contain space
and tab, so it isn't directly possible to run some even more interesting
commands (like rm -rf /), but it is enough for a good exploit already.
I think this issue deserves a CVE#.
Thanks,
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696917: roxterm does not handle quotes in URLs correctly
Control: severity -1 normal
Control: tags -1 - security
29.12.2012 15:49, Michael Tokarev wrote:
Source: roxterm
Version: 2.6.5-1
Severity: grave
Tags: security
When trying to click on an URL inside the roxterm window that contains
a single quote ('), the resulting command sent to the shell includes
this quote and is interpreted by the shell, for example:
http://example.com/quote'here
will be handled as
x-www-browser 'http://example.com/quote'here'
In this example, shell will complain that there's no closing quote before
the end of command, but I can guess this can be (ab)used for some more
interesting scenarious, like to spawn commands unexpectedly:
http://example.com/one'foo|bar'two
After trying to exploit this, followed by the code analisis, I found out
that this is not the case.
roxterm indeed constructs the command line in a single string, and adds
single quotes around the URL. But next thing it does is to call
g_shell_parse_argv() on the resulting string, to create argv[] array.
And this is this function - g_shell_parse_argv() from glib - which
complains about unbalanced quotes. No shell or external command run
is actually involved here. So I don't think this issue is exploitable.
The bug is present still, since it errors out on certain URLs instead of
displaying them, but it is not a security issue anymore, as I initially
thought.
Downgrading severity and untagging accordingly.
I think the easiest fix will be to disallow single quotes in URLs just
like double quotes are currently handled (so that a single quote will
be treated as end of URL). Yes, this way it wont be possible to use
URLs with quotes in them, like
http://en.wikipedia.org/wiki/What_we've_got_here_is_(a)_failure_to_communicate
but it's a minor issue in my opinion.
Thanks,
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678042: seabios - Please enable Xen support
29.12.2012 16:59, Fabio Fantoni wrote: Updated debian seabios package to 1.7.1 (on personal repository for now), tested with wheezy and xen-unstable and is working. Package repository: https://github.com/Fantu/pkg-seabios Hmm. This repository contains just 2 commits: initial import with seabios 1.7.1 and Updated debian/optionrom from qemu 1.3.0 keeping debian changes This is definitely not the way how it can be imported into debian repository, all changes needs to be re-done again -- unless there's a way which I don't see. Changelog of my build: --- seabios (1.7.1-0.1) experimental; urgency=low * Non-maintainer upload * New upstream release 1.7.1 featuring xen support (Closes: #678042) 1.7.1 needs a few more fixes on top, which are unrelated to xen but should be present for qemu. It does not mean it isn't a good idea to update it now anyway. * Removed debian/patches/fix-==-in-shell.patch (applied upstream). * Updated debian/optionrom from qemu 1.3.0 keeping debian changes. Which debian changes is that? Could be uploaded into Debian and hence enabling qemu upstream into xen on experimental repository? Yes, we basically forgot about this stuff already, it's a good idea to ping us so we'll start doing things again. I'm looking at it now. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692249: sata boot+grub unknown filesystem without boot=on
Control: tags -1 + moreinfo unreproducible 04.11.2012 08:49, Gianluigi Tiesi wrote: Package: qemu-kvm Severity: minor Hi, I've noticed my kvm warns about using boot=on so I've decided to find some documentation, as I found boot=on enables extboot option rom removed upstream because seabios can boot directly from sata. References in #652447, perhaps I was able to boot as linux vm from a scsi disk using latest seabios code without using lsi proprietary rom (maybe they implemented scsi boot). if I run: vm -m 1024 -snapshot -device ahci,id=ahci0,bus=pci.0,addr=0x5 -drive file=/dev/sda,if=none,id=drive-sata0-0-0,format=raw,boot=on -device ide-hd,bus=ahci0.0,drive=drive-sata0-0-0,id=sata0-0-0 This is not scsi, this is ahci, FWIW. kvm complains about deprecated boot=on, grub loads and it can boot but if I run: kvm -m 1024 -snapshot -device ahci,id=ahci0,bus=pci.0,addr=0x5 -drive file=/dev/sda,if=none,id=drive-sata0-0-0,format=raw -device ide-hd,bus=ahci0.0,drive=drive-sata0-0-0,id=sata0-0-0 grub loads but it's unable to identify the filesystem Well. Which version of seabios is that? I'm asking because this does not boot at all with current seabios+qemu-kvm from wheezy: guest bios does not find any boot device. If in your case guest bios finds the boot device and loads grub, it must be some other version of either qemu-kvm or seabios. But at any rate, you forgot one more parameter: it is bootindex. Try this: kvm -m 1024 -snapshot \ -device ahci,id=ahci0,bus=pci.0,addr=0x5 \ -drive file=/dev/sda,if=none,id=drive-sata0-0-0,format=raw \ -device ide-hd,bus=ahci0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=0 This works here just fine. Does it answer your question/issue? sda4 is ext4, and I'm trying to boot my windows from my linux maybe seabios it's unable to correcly map whole drive? Nope, it is completely unrelated. For any virtual disk drive given by qemu to the guest - no matter at all which it is on the host - the guest (including the bios) sees it just like a regular disk drive. It is up to qemu to make the host representation of it completely transparent, and qemu does a good job in there. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678042: seabios - Please enable Xen support
29.12.2012 19:52, Fabio Fantoni wrote: [] I have taken debian folder from sid package, if you want simple see/update repository override debian folder of debian seabios repository, if there will be a problem tell me and I'll redo all forking repository from debian, updating seabios upstream to 1.7.1, ovveriding debian folder and doing commit, so you can see all my changes in one commit and also use that commit for update debian repository. I just uploaded seabios_1.7.1-1 to unstable - is that okay with you? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696051: Reopening 696051
Control: reopen -1 Control: retitle -1 potential guest-side buffer overflow caused by e1000 device emulation and large incoming packets - CVE-2012-6075 Control: tags -1 + patch pending upstream There is another half of the same issue. Current patch/fix which has been applied is about the case when no jumbo frames are enabled at all - in this case the maximum packet size is 1522 bytes. But the re's another case - when jumbo frames are actully enabled but not any size (there's another bit that enables very large packets, in this case receiving method is different). In this case, maximum packet size a guest can handle is 16384 bytes. In both cases old code allowed larger packets to be received, and in both cases it will result in guest-side buffer overflow with potential to execute any code in guest. Reopening this bug now and updating the subject, mentioning meanwhile-assigned CVE#. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490298: qemu: Please generate unique MAC address in mcast network mode
Control: severity -1 wishlist Control: tags -1 + wontfix [Replying to an old bugreport...] 11.07.2008 15:34, Petter Reinholdtsen wrote: Package: qemu Version: 0.9.1-1 When trying to run several qemu machines in a local mcast based network, the hosts are not able to reliably talk to each other, because all of them have the same MAC address. I know I can hardcode MAC addresses for each client, but it would be more convenient if this wasn't required, as I could use the same network setting for all hosts on the same network. The script I use to test with qemu is available as qemu-test-network from URL: http://svn.debian.org/viewsvn/debian-edu/trunk/src/debian-edu-config/share/debian-edu-config/tools/ . Please make qemu pick a MAC address at random, or using some algorithm that will increase the chances of each host getting an unique one. Perhaps some algorithm based on PID and time of day could be used? This is something which is really easy to script (making mac addresses random), but you're asking something which will break lots of guests, -- for example, almost all modern linux systems will create new ethX device on each boot in this case, since the MAC will be different and the NIC will be treated as different device. The same applies to windows guests. Marking as wontfix. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696985: SGA device does not work in qemu-system: sgabios.bin missing
Package: qemu-system Version: 1.1.2+dfsg-1 Severity: minor Tags: confirmed (This is actually an old problem, but still unsolved, reporting against wheezy version). qemu does not come with sgabios.bin file necessary for the SGA device to work, it is because this (rom) image is not packaged for Debian. With current versions of qemu it comes in source form in roms/sgabios/ and in compiled form in pc-bios/sgabios.bin, but this is x86-only executable and can not be re-built on other architectures, while all architectures needs it. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529314: qemu: AIX / system-p/p-series support
Version: 1.1.2+dfsg-1 I'm closing this bugreport, since (at least some) support for pseries is included in 1.1 version. Maybe some bits are missing still (like (semi-optional) firmware), but general support should be here. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#326886: qemu: Confusing error when /tmp is not writable
Control: tags -1 + confirmed upstream This is still the case on version 1.3, but at least it prints the real error message now (Permission denied). See also #390444. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697000: android: format working on ntfs but not ext3
26.12.2012 02:53, patrick295767 wrote: Package: qemu Version: 0.12.5+dfsg-3squeeze1 Severity: normal Hi, If you install android you cannot make it to an image of ext3. yeap indeed. If you receive this error: cannot mount /dev/sdaX Then select the ntfs file system instead and repeat the operation. You will be then prompted whether to install or not the GRUB boot loader, select Yes and press Enter: I join you the link to the bug that should be fixed. It works with ntfs as you may see into the screenshots. Please describe in a bit more details what the issue is. Somehow I fail to understand what you're talking about, ie, at all. What do you do, what you expect qemu to do, and what it actually does. Note that qemu package itself is a meta-package, it contains no files and can't be buggy by definition. Note also there's something wrong with clock on your computer. I hope that it helped. No, it didn't help, at all. Sorry. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585681: qemu-user: mmap: Operation not permitted
Control: tags -1 + moreinfo unreproducible
[Replying to relatively old bugreport...]
13.06.2010 06:29, Seo Sanghyeon wrote:
Package: qemu-user
Version: 0.12.4+dfsg-2
Severity: important
QEMU user mode emulation binaries (specifically qemu-arm) fail with
mmap: Operation not permitted when run as a user. When run as a root
there is no problem.
With CodeSourcery G++ Lite installed at $HOME:
http://www.codesourcery.com/sgpp/lite/arm/portal/release1293
tinuviel@debian:~$ cat hello.c
#include stdio.h
int main() {
printf(Hello, world!\n);
return 0;
}
tinuviel@debian:~$ /home/tinuviel/arm-2010q1/bin/arm-none-linux-gnueabi-gcc
hello.c -o hello
tinuviel@debian:~$ qemu-arm -L
/home/tinuviel/arm-2010q1/arm-none-linux-gnueabi/libc hello
mmap: Operation not permitted
Do you still observe this issue with current qemu-user?
I can't reproduce it neither with current (1.x) version
nor with reported (0.12) version, but maybe it is the
host kernel which is different in my case, or maybe it
is 32/64bit difference.
Thanks,
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692249: sata boot+grub unknown filesystem without boot=on
31.12.2012 00:43, Gianluigi Tiesi wrote: On 12/29/12 15:57, Michael Tokarev wrote: [] vm -m 1024 -snapshot -device ahci,id=ahci0,bus=pci.0,addr=0x5 -drive file=/dev/sda,if=none,id=drive-sata0-0-0,format=raw,boot=on -device ide-hd,bus=ahci0.0,drive=drive-sata0-0-0,id=sata0-0-0 This is not scsi, this is ahci, FWIW. Yes true, but boot=on option was made for scsi, so why it makes work my ahci setup that instead would not work? I mean it should be unrelated but instead looks like related. Well. boot=on was made for general usage, it works (or worked) for any bootable device, including scsi and ahci and network and other stuff. It was a quick hack to allow booting from devices not directly supported by seabios, and is not supported by upstream anymore. but if I run: kvm -m 1024 -snapshot -device ahci,id=ahci0,bus=pci.0,addr=0x5 -drive file=/dev/sda,if=none,id=drive-sata0-0-0,format=raw -device ide-hd,bus=ahci0.0,drive=drive-sata0-0-0,id=sata0-0-0 grub loads but it's unable to identify the filesystem Well. Which version of seabios is that? I'm asking because this does not boot at all with current seabios+qemu-kvm from wheezy: guest bios does not find any boot device. If in your case guest bios finds the boot device and loads grub, it must be some other version of either qemu-kvm or seabios. I'm on sid, and the just updated seabios 1.7.1-1 exposes same behavior qemu-kvm is 1.1.2+dfsg-3 Interesting. Okay. So I need some way to reproduce this. Can you please tell us what do you use as the guest? What is it, how it was setup, etc? Maybe it is enough to do a fresh install of some distribution to expose this issue? [] Unfortunately bootindex options changes nothing Ok. here grub2 without boot=on Booting from Hard Disk... GRUB loading. Welcome to GRUB! error: unknown filesystem. Entering rescue mode... grub rescue ls (hd0) (hd0,msdos4) (hd0,msdos3) (hd0,msdos2) (hd0,msdos1) (fd0) grub rescue ls (hd0,msdos4) error: unknown filesystem. Oh well. It looks like grub is unable to _read_ the drive. I need a way to reproduce this :) I'll try doing some installing/booting here when time permits. Maybe you can provide some instructions or maybe a guest image to speed things up... ;) while it works fine with boot=on Ok. So it appears to be some grub+seabios issue with the correct/modern way of booting things, while old/legacy boot option works fine. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#417930: Provide a qemu-network helper package that sets up tun + vde + dnsmasq
Control: tag -1 + wontfix [Replying to an old bugreport...] 05.04.2007 18:13, Raphael Hertzog wrote: Package: qemu Version: 0.8.2-4 Severity: wishlist Basically implement this but for Debian: http://people.redhat.com/berrange/olpc/sdk/network-bridge.html The package would use vde_switch to create a tun/tap network interface named qemu. This interface is auto-configured at boot time: - with a fixed IP address - dnsmasq runs on it to provide DNS+DHCP for the qemu guests - optionnaly it setups forwarding + ip masquerading so that the qemu virtual network has access to the internet (or the real LAN) Then any user in the vde2-net can start a virtual machine connected on the network (and reachable from the host, contrary to the default user network stack solution provided by qemu) with a command like this one: $ vdeq qemu -m 128 -hda hda.bin -net nic,macaddr=$mac -net vde,sock=/var/run/vde2/qemu.ctl Other pointers on the same topic: http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:vde Currently I configured something like this manually in /etc/network/interfaces: auto qemu iface qemu inet static address 10.0.2.1 netmask 255.255.255.0 vde2-switch - up /etc/init.d/dnsmasq restart || true up echo 1 /proc/sys/net/ipv4/ip_forward up iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE up iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE down iptables -t nat -F and my dnsmasq.conf has the following changes: listen-address=10.0.2.1 bind-interfaces dhcp-range=10.0.2.15,10.0.2.100,12h Add some debconf prettyness to ask for the default address/netmask, etc and this package would be really useful for users which are used to make experiences in several virtual machines. :-) This is about the same thing as libvirt does internally using some GUI sugar. I don't think we want to duplicate this functionality. So marking this as wontfix for now. Thank you for your patience! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697085: qemu-system: tries to overwrite doc/qemu/qemu-doc.html from qemu (missing Breaks+Replaces?)
01.01.2013 06:32, Jonathan Nieder wrote: Package: qemu-system Version: 1.3.0+dfsg-1~exp1 Severity: serious Justification: failed upgrade From today's upgrade: | Preparing to replace qemu-system 1.3.0+dfsg-1~exp1 (using .../qemu-system_1.3.0+dfsg-1~exp3_amd64.deb) ... | Unpacking replacement qemu-system ... | dpkg: error processing //var/cache/apt/archives/qemu-system_1.3.0+dfsg-1~exp3_amd64.deb (--install): | trying to overwrite '/usr/share/doc/qemu/qemu-doc.html', which is also in package qemu 1.3.0+dfsg-1~exp1 | dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Known problem? No, not a known problem. It is me messing up with docs with the result of the same file belonging to 2 packages. I'll fix that. For now, just don't install qemu meta-package. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668658: Possible patch
01.01.2013 23:49, Venkat Kapur wrote: This following patch seems to work, but I am not a really an expert in this field. That patch does not fix the problem for me. It still segfaults as before. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704815: Would it be possible to reenable CONFIG_ACPID
06.04.2013 12:56, Guido Trotter wrote:
Package: busybox-static
Version: 1:1.20.0-7
Severity: wishlist
I know that acpid was disabled on purpose, but would it be possible to
reenable it? It is useful on VMs running with busybox only, for example.
For many years, i've the following replacement for acpid:
cut
#! /bin/sh
[ -d /sys/module/button ] || { modprobe button; sleep 5; }
[ -f /proc/acpi/event ] || exit 1
while read x /proc/acpi/event; do
case $x in
*button/power*)
echo
Power down
/dev/console
shutdown -h -P now
;;
esac
done
cut
Is it not sufficient for you?
If you talk about VMs, I found it is much easier to use Ctrl+Alt+Del
from inittab to signal shutdown, and don't bother with acpi at all.
For this to work, just change cad action in /etc/inittab to do
power down instead of reboot.
As for enabling this applet for wheezy, it definitely is not possible
at this time because of the freeze.
Thanks,
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702278: busybox upload
I'm pinging this bug, as we're getting seriously out of time. Now, I guess, we should either let the whole thing go (it has already been unblocked for, only d-i block remains), or mark the relevant bugs as non-RC for wheezy. Thanks, /mjt 25.03.2013 15:38, Michael Tokarev wrote: Let me start from scratch please. I wasn't aware of this bugreport/discussion, and I made a mistake by not filing a proper unblock request when I uploaded the busybox package with all the fixes. So here are descriptions of every change. A sort of a fore-word first. Busybox is kind of unusual package in a way that it re-implements functionality of various existing packages. Base debian system uses other implementations of the same functionality usually. So from this PoV, any busybox bug is not that important for a user's debian system, since a typical user does not use any busybox applets at all. Busybox _is_ used on almost every end-user system because it provides the set of basic *nix utilities for initramfs, and it is used in debian-installer. But these are very restricted environments with much better defined components and much less chance to have a combination which triggers one or another bug. So, any bug in busybox which does not affect basic initramfs or d-i functionality directly can't be important enough for whole debian system, so to say. On the other hand, sometimes, since busybox is almost always installed and available on any debian system, it gets used by users in various much less restricted environments, which leads to situations where the bugs are actually gets hit. This is minority of users (again, so to say). So this is about whenever we really care about this minority or not, _plus_ about _possible_ issues in d-i or initramfs. Another source of unusuality comes from the fact that busybox implements a ton of _independent_ applets, so that a change in one does not affect anything else (if we don't count changes in, say, memory layout which triggers bugs elsewhere - this has already happened at least once during wheezy development cycle, when we discovered bug with unaligned memory access which was hidden because the objects were actually aligned properly before we changed something unrelated in memory). So, back to the changes. busybox (1:1.20.0-8) unstable; urgency=low * grep-fix-grep--Fw-not-respecting-the--w-option.patch - implement fgrep -w correctly (Closes: #695862) As has been said before, this is a feature fix. It is not. The problem initially has been raized in some other package which had initramfs hook which didn't work. I don't remember which package it was, the context was that it tried to find some CPU feature by grepping /proc/cpuinfo with -w flag to grep, used to remove false positives, and it didn't work. (/proc/cpuinfo is just an example, I don't really remember what it was). This is one of these bugs which makes other, unrelated components fails in unexpected and difficult to debug ways. The fix is somewhat large, because it had to deal with logic of operations in grep applet. On the plus side, it comes with additional testcases which checks for this issue, and there are lots of other grep-related testcases already present. Unfortunatly busybox debian package still does not run any testcases during build (this is on my TODO list of first things to do for jessie), but having in mind the situation (deep freeze) and importance of the applet I ran provided and a few more testcases against the resulting grep on x86, ppc and mips platforms (on debian porterboxes) manually to ensure the fix does not break anything else and actually fixes the bug. If you ask me, this is about the same importance as #686502, but it is less obvious. This grep-w bug does not lead to data loss directly, the problem is that we can't rely on grep doing the right thing when we use it in a familiar, natural way - like when we try to fix a false positive by adding -w _somewhere else_ (in some other package that is), and it stops working. That's why it isn't a feature fix, busybox claimed to support grep-w but it does not work. What we're fixing here mostly is about _further_ d-i or initramfs changes (including possibility to have these changes in wheezy too) which looks completely correct and obvious but don't work in practice. Plus some random rare end-users usage of busybox grep, of these are exists. What we risk here is almost nothing, at least according to my tests on several platforms. * xz-support-concatenated-xz-streams.patch (Closes: #686502) This is the main RC bug currently filed against busybox. The rationale for it being RC is because it causes _silent_ data loss when decompressing certain kinds of XZ streams. Again, the severuty can be argued for sure, due to whole nature of busybox as a second-kind sitizen as mentioned at the beginning of this mail. First, not everyone
Bug#704815: Would it be possible to reenable CONFIG_ACPID
06.04.2013 16:02, Guido Trotter wrote: On Sat, Apr 6, 2013 at 11:05 AM, Michael Tokarev m...@tls.msk.ru wrote: 06.04.2013 12:56, Guido Trotter wrote: Package: busybox-static I know that acpid was disabled on purpose, but would it be possible to reenable it? It is useful on VMs running with busybox only, for example. For many years, i've the following replacement for acpid: [] while read x /proc/acpi/event; do [] CONFIG_ACPI_PROC_EVENT is deprecated and unset in most modern kernels I know it's been deprecated, but I always used local builds of kernel (together with my initramfs and a few other infrastructure), so I didn't know it's been turned off. That's a pity. (I know, I can always build my own kernel, but then again, I could also build busybox, so that defeats the purpose). acpid in busybox can read /dev/input/event* and at least under Xen does the right thing (shuts down the system, with the proper config). Do you aware that any keyboard/mouse/etc event will be read by acpid using this /dev/input/event* interface? That was my main complain when this interface has been introduced - there's no way to filter out things to stop kernel to wake all readers for every and all input event even if 99.99% the readers aren't interested in it. At least acpid can be a bit smarter and only open those devices which actually provide buttons we're interested in, like pwrbtn/lidbtn, instead of reading every mouse and force-feedback device out there. Oh well. Fortunately it might be not as bad for a VM where you don't work at the console. But this is just, well, complaining, I understand that the whole (linux) world already works like that. Is it not sufficient for you? If you talk about VMs, I found it is much easier to use Ctrl+Alt+Del from inittab to signal shutdown, and don't bother with acpi at all. For this to work, just change cad action in /etc/inittab to do power down instead of reboot. Under kvm I can always go for the ctrl+alt+del option you suggest, but that still requires special knowledge that the machine does the right thing, while acpi is supposed to be more standard. Anyway I am not sure I could easily do that under Xen too. I see. This, together with ACPI_PROC_EVENT, are both good points. As for enabling this applet for wheezy, it definitely is not possible at this time because of the freeze. Understood, I only mentioned it because it was enabled in squeeze before, but then again probably busybox is too important to allow exceptions. Well, maybe it can still be discussed and updated in wheezy+1 and backports, perhaps? Backports - sure. For wheezy, I'll have to explain to the release team why fixing this bugreport is important for wheezy, and I'm afraid I can't do that even to myself ;) Your usage is very specific. There's absolutely no reason why it should be forbidden, obviously, and I will, most likely, turn this options back on for jessie - for both regular and static builds - but this wont be for wheezy. I'm sorry to say that. Thank you for the feedback and the bugreport! Seriously, it is always nice to know which applets people use for real and which are dummies. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702278: busybox upload
08.04.2013 11:57, Cyril Brulebois wrote: Forgot to mention one thing: Cyril Brulebois k...@debian.org (08/04/2013): My take is: until we hit real bugs in real situations, we keep busybox as it is. If release managers want to cherry-pick a few fixes, I won't stop them from requesting so. But as far as I'm concerned, I'd really like to see practical issues before getting busybox updated. Nonetheless, I do appreciate your efforts in trying to get things fixed, especially when done by cherry-picking things from upstream, instead of insisting for our moving to latest master. It's just too late for that, for bugs that don't seem to be hit in real life©®™. We've at least two bugs which do hit us in real life - this is the xz multi-stream issue (already seen on kernel.org) and non-working grep -w. But I repeat myself. FWIW. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705111: Please enable the --enable-rdb option when building
Control: reassign -1 qemu-system Control: force-merge -1 689239 10.04.2013 14:11, Thomas Goirand wrote: Package: qemu-kvm Version: 1.1.2+dfsg-6 Severity: wishlist Hi Vagrant, Aurelien and others, To use Ceph in OpenStack, we would need that the --enable-rdb is added in the ./configure. Please add this option. Best would be if it was possible to upload a version of Qemu in Experimental with this option if you can. This is a duplicate of #689239. --enable-rdp needs a working librdp/librados, which we don't have in Debian, see http://packages.qa.debian.org/c/ceph.html . Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705544: CVE-2013-1922 -- qemu-nbd block format auto-detection vulnerability
Package: qemu-utils Version: 1.1.2+dfsg-1 Severity: normal Tags: security patch upstream qemu-nbd utility does not has an option to specify format of the block image it serves, so it is possible by a guest (user of nbd device) to write data to it the way so it looks like some format known to qemu-nbd, and the next time qemu-nbd is restarted with the same image, it will be tricked to interpret (probably especially crafted) that format. It is very similar to old vulnerability in qemu itself, CVE-2008-2004. https://bugzilla.redhat.com/show_bug.cgi?id=923219 http://www.openwall.com/lists/oss-security/2013/04/15/3 The upstream fix -- https://bugzilla.redhat.com/attachment.cgi?id=712650action=diff -- merely adds an option to qemu-nbd that allows to specify format of the image explicitly instead of always relying on guessing. I don't think this is a serious issue, for several reasons: o qemu-nbd isn't usually used in production where there's a chance to hit a malicious guest. Instead, it is used mostly for testing or for access to the guest image from host, for administrative purposes, in both cases the issue isn't serious. o even when modified to understand a new option, all relevant usages should be modified as well, to utilize the new option. However, it's still nice to fix it in debian package. I'm not sure yet whenever we should fix it for wheezy or not. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570516: Not easily reproducible
11.01.2013 20:42, Graham wrote: Hi, Though I'm currently not using md, I have done so in the past, and it has always worked well for me. I saw this bug report and thought that I might try to reproduce it. Here's what I did: That's basically the steps I used too, more or less, when trying to reproduce it locally, except that I used qemu-kvm instead of vmware. And yes, I can confirm it isn't easily reproducible. There's something, some local change/thing, which makes this bug to appear, and it isn't clear so far what it is, exactly. I cleaned up the scripts a bit since that time, stuff should work a bit more reliable, so hopefully it is fixed, but we aren't sure yet, and since the bug is rather serious, I don't want to close it without strong confirmation or without finding the root cause. But thank you very much for the attempts! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698221: unblock: qemu/1.1.2+dfsg-5 qemu-kvm/1.1.2+dfsg-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package qemu The updated release includes 3 bugfixes. Changelog with comments: * e1000-discard-oversized-packets-based-on-SBP_LPE.patch: the second half of the fix for CVE-2012-6075. (Finally Closes: #696051) This is a security fix for CVE-2012-6075. As it turned out, there are 2 sides of this issue, and 2 halves for the fix. While we thought the change in previous release (1.1.2+dfsg-3) was enough, it actually is not, since the bug can be triggered using another conditions too. Complete fix contains in 2 changes (which touches the same area): e1000-discard-packets-that-are-too-long-if-not-SBP-and-not-LPE.patch (which was included in 1.1.2+dfsg-3 release) and e1000-discard-oversized-packets-based-on-SBP_LPE.patch (being included now). These patches are used in a recent qemu qemu-kvm security update in squeeze (stable-security) too. Both patches are from upstream. I tried my usual pile of guests here trying to verify there's no visible regressions due to that, all guests seems to continue working fine. The changes only affects e1000 device emulation, and has no impact on other parts of qemu. * linux-user-fix-mips-32-on-64-prealloc-case.patch (Closes: #668658) This is a simple patch which unbreaks MIPS 32bit emulation on 64bit host. Before this patch, mips32 were completely unusable/unworking on any 64bit host, including the most commonly used amd64 one. Also a low-risk change, since it is specific to this architecture (and only for the 32-on-64 case), and makes previously completely non-working stuff working. It is a fix for bug of priority Important, but I think it really is important to fix this for wheezy and not let wheezy be released without it, since emulation of mips is important enough. * fix USB regression introduced in 1.1 (Closes: #683983) uhci-don-t-queue-up-packets-after-one-with-the-SPD-flag-set.patch Big thanks to Peter Schaefer (https://bugs.launchpad.net/bugs/1033727) for the help identifying the fix. This is another fix for Important bug. As it turned out, many real USB devices which worked in previous versions of qemu[-kvm] (in wheezy/testing, before 1.1 version) were broken since 1.1 version. I've got many reports about various devices not working anymore. It turned out that only certain sequence of events triggers this issue, and not all guests and not all devices triggers it, but general result of this bug is quite bad. Supporting USB in a more or less reliable way is important because qemu is often used to run proprietary windows-only programs to flash a phone over USB or things like that, where there's no other good choice available (short of purchasing a separate PC just for that). I'm requesting to unblock both qemu and qemu-kvm at once, since the two are kept in the same state, and since the fixes applicable to both at the same time. However, the mips-related fix is not needed for qemu-kvm, since this one is x86-only. So qemu-kvm change does not include the mips-related fix. Other than that, the changes are exactly the same, including version numbers. Debdiff between qemu/1.1.2+dfsg-3 (currently in testing) and qemu/1.1.2+dfsg-5: -- diff -Nru qemu-1.1.2+dfsg/debian/changelog qemu-1.1.2+dfsg/debian/changelog --- qemu-1.1.2+dfsg/debian/changelog2012-12-16 23:24:01.0 +0400 +++ qemu-1.1.2+dfsg/debian/changelog2013-01-14 12:20:29.0 +0400 @@ -1,3 +1,20 @@ +qemu (1.1.2+dfsg-5) unstable; urgency=low + + * fix USB regression introduced in 1.1 (Closes: #683983) +uhci-don-t-queue-up-packets-after-one-with-the-SPD-flag-set.patch +Big thanks to Peter Schaefer (https://bugs.launchpad.net/bugs/1033727) +for the help identifying the fix. + + -- Michael Tokarev m...@tls.msk.ru Mon, 14 Jan 2013 12:20:29 +0400 + +qemu (1.1.2+dfsg-4) unstable; urgency=medium + + * linux-user-fix-mips-32-on-64-prealloc-case.patch (Closes: #668658) + * e1000-discard-oversized-packets-based-on-SBP_LPE.patch: the second +half of the fix for CVE-2012-6075. (Finally Closes: #696051) + + -- Michael Tokarev m...@tls.msk.ru Wed, 09 Jan 2013 23:05:17 +0400 + qemu (1.1.2+dfsg-3) unstable; urgency=low * add build-dependency on libcap-dev [linux-any] to enable virtfs support diff -Nru qemu-1.1.2+dfsg/debian/patches/e1000-discard-oversized-packets-based-on-SBP_LPE.patch qemu-1.1.2+dfsg/debian/patches/e1000-discard-oversized-packets-based-on-SBP_LPE.patch --- qemu-1.1.2+dfsg/debian/patches/e1000-discard-oversized-packets-based-on-SBP_LPE.patch 1970-01-01 03:00:00.0 +0300 +++ qemu-1.1.2+dfsg/debian/patches/e1000-discard-oversized-packets-based-on-SBP_LPE.patch 2013-01-14 12:13:18.0 +0400 @@ -0,0 +1,39 @@ +commit 2c0331f4f7d241995452b99afaf0aab00493334a +Author: Michael Contreras mich...@inetric.com +Date: Wed Dec 5 13:31:30 2012 -0500 +Bug-Debian: http
Bug#698508: libseccomp-dev does not provide static library
Package: libseccomp-dev Version: 1.0.1-1 Severity: important The subject says it all: there's no static library provided by libseccomp-dev package. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698606: please provide package for other architectures, not just x86
Source: libseccomp Version: 1.0.1-1 Severity: normal It looks like kernel supports seccomp on a number of architectures, 3.2 has it on: s390 arm sh powerpc microblase mips sparc x86 please provide the package for more architectures, not just i386 and amd64. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698508: libseccomp-dev does not provide static library
Control: severity -1 wishlist 20.01.2013 01:03, Kees Cook wrote: I would strongly prefer to avoid shipping a static library for this package to avoid programs linking to this non-dynamically, especially since it makes security updates more difficult to track. Well, this is a standard excuse for a lack of static library, yet almost all other packages provides static libraries. Policy 8.3 says that the static library is _usually_ provided, but that does not mean it is mandatory. Do you have a compelling need for this? That's a good question. Not anymore actually - I had this issue due to a bug in a way how qemu configure/Makefile system is written (a bug in there). Qemu has a very good reason to be compiled statically, -- namely their user targets, which are able to emulate foreign-arch cpu so that binaries from foreign architectures can be run in emulated mode on the host kernel. So a usual thing to do is to copy a statically-linked qemu-user binary into a foreign chroot and do a chroot there, -- it will work. qemu build/make scripts linked this qemu-user binary with -lseccomp, and that obviously fails due to lack of static library. But this linking was due to error actually, -- seccomp is not used and makes no sence for qemu-user targets, it makes sence only for qemu-system targets, ie, for full-system emulation, where the set of system calls needed is known. I fixed this bug in qemu now, so static -lseccomp isn't needed by qemu anymore. But the lack of static library appears to be quite.. unusual, since other libs provide static versions. So, I downgraded severity to a wishlist at least, since I don't have a good reason for that. Thanks, also for finding a bug in qemu! :) /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698606: closed by Kees Cook k...@debian.org (not a bug)
21.01.2013 03:27, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the src:libseccomp package: #698606: please provide package for other architectures, not just x86 It has been closed by Kees Cook k...@debian.org. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Kees Cook k...@debian.org by replying to this email. I want some bug# to refer when people ask me about seccomp support in qemu again. If it were x86-only by definition I'd agree that it's a bug, but since it's not the case, I'm not sure why you closed it. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697085: qemu-system: tries to overwrite doc/qemu/qemu-doc.html from qemu (missing Breaks+Replaces?)
21.01.2013 01:42, Jonathan Nieder wrote: * add qemu-kvm package (transitional, depends on qemu-system), and add /usr/bin/kvm wrapper that calls qemu-system-x86_64 with some arguments to match original qemu-kvm behavour. (Closes: #560853) Oh, excellent! Actually it might not be as good as it sounds. qemu-kvm:i386 1.1.2: Installed-Size: 4756 Depends: seabios, vgabios, ipxe qemu-system:i386 1.3.0: Installed-Size: 89232 Depends: seabios, vgabios, ipxe, openbios-ppc, openbios-sparc, openhackware, libxen, ... Just the installed size -- 4756 vs 89232 -- is already quite telling, that's about 20 times difference... Oh well. And I'm still not sure if it's a good idea to split qemu-system into multiple packages. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698221: unblock: qemu/1.1.2+dfsg-5 qemu-kvm/1.1.2+dfsg-5
19.01.2013 15:23, Julien Cristau wrote:
qemu{,-kvm} unblocked.
Thank you very much Julien!
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698736: qemu-system: /usr/bin/kvm is a directory, should be a script
23.01.2013 02:06, Gerardo Esteban Malazdrewicz wrote: Package: qemu-system Version: 1.3.0+dfsg-3exp Severity: grave Justification: renders package unusable Dear Maintainer, Newest qemu-system absorbs old qemu-kvm functionality. However, script to launch kvm is /usr/bin/kvm/kvm, where it is looked in /usr/bin/kvm, as shown below. Yes it's a bug indeed. Fixed in git already, I didn't even notice it but I changed the way this wrapper is installed. I'm uploading a new version anyway, so it will be fixed in a few minutes. But I question Severity+Justirication - more or less just curious actually, why do you think this renders package unusable? The file in question (/usr/bin/kvm wrongly packaged as /usr/bin/kvm/kvm) is a compatibility script to simplify moving from old qemu-kvm to new qemu-system. First thing it says is just that -- to move to qemu-system-x86_64. Why do you think the lack (or improper install) of this file renders package unusable? It is not the binary you should be using, the right binary is qemu-system-x86_64... Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698754: Please rebuild 1.1.2+dfsg-5 (or later) for backports
23.01.2013 13:38, Raoul Bhatia [IPAX] wrote: Package: qemu Version: 1.1.2+dfsg-5 Severity: whishlist Now that's interesting you used this version number... ;) But ok. Please rebuild qemu 1.1.2+dfsg-5 (or later), which includes the e1000 CVE-2012-6075 bugfix, for backports. Do you really mean qemu or actually qemu-kvm? But yes, I wanted to build (both) for squeeze-backports in a few days, provided we've no other important changes by then. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698754: Please rebuild 1.1.2+dfsg-5 (or later) for backports
23.01.2013 17:23, Raoul Bhatia [IPAX] wrote: On 2013-01-23 10:47, Michael Tokarev wrote: Do you really mean qemu or actually qemu-kvm? qemu-*? ;) My currently installed packages are qemu-keymaps, qemu-kvm and qemu-utils. Would src:qemu have been more appropriate? qemu-kvm builds from qemu-kvm source, not from qemu source. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691710: unblock: mdadm/3.2.5-4 (pre-upload)
replay (which is done even on a read-only mount) can not be completed, so an uncleanly umounted ext4 can't be mounted. And we need to just provide mdmon binary in initramfs for the whole thing to start working. But we also need 3 extra steps _after_ such an array is started: first, we need to restart mdmon from real root once the system is booted, in order to release initramfs. Second, we need to ensure that these mdmon processes will not be killed by sendsigs during shutdown, because mdmon might still be needed after sendsigs is done - when umounting filesystems etc. And third, we need to wait for such arrays to settle down (to sync metadata etc) at the very end of the shutdown process (mdmon need to finish its task there), or else at next boot the array will not be clean. And one more thing -- the udeb now includes mdmon binary -- for exactly the same reason, mere presence of this binary is enough to start such non-native raid array from within the installer. There's no other changes which affects udeb/d-i in this release. Miquel provided a patch implementing all this, and I reworked it a bit. -- The resulting package has been in -experimental for these 3 months already (I understand it does not say much but.). The changes -- at leaat the changes not related to mdmon/fakeraid -- are necessary for wheezy, the bugfixes are important enough. I think that supporting fakeraid arrays in debian is also very important. We had no enough testing for fakeraid part unfortunately (esp. since there was no d-i built with this functionality so far), but it is at least an attempt to do something. D-i with current mdadm will just hang when the target system has fakeraid array (it will try to remount it read-write and kernel will wait for mdmon to catch up forever). And I tried to ensure that the differences does not affect non-fakeraid usage in any way (*). So, I'm kindly asking, after patiently waiting for 3 months, to unblock mdadm/3.2.5-5 (*) There is one change for non-fakeraid arrays introduced by this mdmon/fakeraid changes. Namely, mdadm-waitidle script now ensures that all arrays which are still running at the very end of the boot process - like, for example, the array on which root filesystem is located -- this script ensures that these arrays are in idle state, ie, that all superblocks are written to disk safely. This closes the possibility that md arrays may become dirty on the next boot. So it is a change with a good effect even for non-fakeraid arrays. Thanks, /mjt 29.10.2012 00:42, Michael Tokarev wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock This is a pre-upload unblock request for mdadm/3.2.5-4. Recently, upstream released a new version of mdadm, v3.2.6, which contains only bugfixes or documentation improvements. I'm cherry-picking only the most important changes from this version. These changes fixes a number of important bugs, each of which is not of RC severity, but important enough to be included into wheezy in my point of view. Each of the bug has relatively low impact or probability, or can be seen in only very specific configurations, but once you hit it, it might be difficult to recover the data which was on the raid array in question. This is why I consider these to be good candidates for wheezy. This unblock request consists of two parts. First, the main part, which talks about several bugfixes: Here are the list of changelog entries of this nature: * Fix 'enough' function for RAID10, to prevent starting of a RAID10 array which does not have required minimum of component devices. (Closes: #691668). * fix segfaults in Detail() - mdadm --detail may segfault if a drive has been removed from the array (Closes: #691670) * super0: do not override uuid with homehost. The bug prevented re-creating an array with v0.90 superblock with the specified uuid when homehost is also specified. (Closes: #686703) Each of the above 3 patches fixes specific bugs relevant to data stability, so to say. * several fixes for mdmon argument processing (Closes: #691671): - allow --takeover when original was started with --offroot - fix arg parsing. - fix arg processing for -a The last series - mdmon argument processing fixes - is not directly relevant for version of the package currently in wheezy, since mdmon utility there is not used right now. For this reason, the fixes above are of zero risk for configurations which are directly supported by mdadm debian package infrastructure. However, mdmon is required to support raid arrays with external metadata, which are all the fakeraid arrays (ahci and other in-chipset implementations), found in almost all modern motherboards or PCs. These tiny bugfixes allows usage of such arrays in saner way. More about mdmon is below. While at it, I'm also fixing 2 minor issues with packaging which were slipped in - one debian
Bug#701926: asertion failure when assigning certain USB devices to guest
18.03.2013 01:06, Michael Gilbert wrote: Do you have a link to the patch fixing this issue? This would be useful for anyone considering nmuing a fix. The fix has been in the qemu-kvm debian package git tree since the day this bug has been reported, and the bug has been marked as pending since the same day. I waited for some other bugs to be identified, but now I'll just push the whole set. I highly doubt an NMU is necessary in this case, there's no rush, this isn't really an RC bug. And since qemuqemu-kvm packages are very, well, special, doing an upload (nmu or not) isn't exactly easy :) Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703315: mdadm: core dump with bad disk
18.03.2013 14:41, Francesco Potortì wrote: Package: mdadm Version: 3.2.5-5 Severity: normal Dear Maintainer, The disk /dev/sdb is broken. However, the kernel sees it, as you can see in /proc/partitions. In this situation, I see this: tucano:~# mdadm /dev/md3 --add /dev/sdb1 Segmentation fault (core dumped) The only way forward from this is to try to get some debugging out of it. You've a coredump, we need a backtrace to see/know where it errors out. For this, the best is to try the same with a binary recompiled to have debugging symbols. Are you familiar with (re)compile process and willing to help finding the bug? I can help a bit with the former, by providing you a debug build of mdadm. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702530: autofs5: fix automounter support on parisc
19.03.2013 01:49, Helge Deller wrote: Hi Michael, On 03/12/2013 09:13 PM, Helge Deller wrote: On 03/09/2013 02:57 AM, Michael Tokarev wrote: As Ian replied to your patch on autofs mailinglist, this is only needed for old kernels, but he applies your patch anyway. I'd go for removing whole hack entirely, maybe after a bit more waiting (say, when all major distributions will move on to the fixed kernel already), because whole thing is just disgusting and hurt eyes. This hack, with or without your change, is definitely not needed on Debian. And if there is, it must be something else, because since the above mentioned commit, it all Just Works, and if there's a problem it is elsewhere. I'll check and try to dig deeper again next week when I'm back from vacation.. Ok, it seems the changes to bring the header file up to date in sync with upstream kernel is not even needed (since it's being built on parisc on 32bit userspace only), but it makes it consistent. The second part (the if arch check) can be dropped. Now I'm completely confused. So do we need any changes or not? Does it work as-is now or doesn't? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703404: debian-installer: wheezy (PXE boot) failes to install busybox and kernel
19.03.2013 15:04, Konrad Vrba пишет: I have exactly the same problem, as described. Is there away to specify (in preseeding) to skip installing busybox ? Busybox is used in regular initramfs. While techincally initramfs might work without busybox, no one really test things that way. So basically you'll end up with unbootable system. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703404: debian-installer: wheezy (PXE boot) failes to install busybox and kernel
19.03.2013 15:29, Konrad Vrba wrote: I see, but custom kernel without initramfs should work. If there is a way to skip installing busybox, I would appreciate. That appears to be a wrong solution to a wrong problem. Something is wrong with the archive mirror system apparently, or with the signing keys, I dunno for now. Any random package might be at fault here (what if it was one of the core packages, such as glibc?). The solution is to fix the network not avoid apparently broken (which are actually not broken) packages. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703315: mdadm: core dump with bad disk
[Replying back to the bugreport AND to NeilB.
Hope you're okay with that
Neilb: This is just the (excellent!) analisys of the problem,
I can send a patch if you like
]
20.03.2013 22:19, Francesco Potortì wrote:
And also (as root) apt-get install build-essential to
install build dependencies
It misses ansidecl.h. I installed gcc-4.7-plugin-dev and copied it from
the standard palce to the build directory to satisfy it.
Interesting. Thank you for letting us know!
Use this executable to manage your arrays and to get a
coredump, and run gdb on it. Or run this executable under
gdb and get a sigsegv.
By mistake, I first built version 3.1.4 which does not crash but rather
gives the correct error message:
mdadm: failed to write superblock to /dev/sdb1
When you hit the issue, run `bt' in gdb to see where it
is failing. This will show you a stack trace, and the
current line of code where it fails. We may want to
examine variables around there, using `p' command.
Okay, that was easy, but I do not understand it. THe problem is in
write_init_super1 in super1.c:
for (di = st-info; di ! rv ; di = di-next) {
if (di-disk.state == 1)
continue;
if (di-fd 0)
continue;
This reads the structure, the second test passes, so the loop continues,
but next is null and the loop ends. After this, di in null. But in
this case:
}
error_out:
if (rv)
fprintf(stderr, Name : Failed to write metadata to %s\n,
di-devname);
Which segsevs because rv is 4. The fact is, I cannot imagine why ever
it is 4. It should be 0.
Today I have not had the time to change the disk, so I could do some
other test. Maybe this evening. If you write to me, I'll try something
else.
Well. This should be all that's needed, actually even more than that!
Your analisys is excellent, you did a very good work! Thank you very much
for helping Francesco!
Obviously these are places difficult to hit in real life...
This is only the error reporting which is broken, -- mdadm will not eat
your data with this bug. So there's nothing to worry about on your
system anymore, except, ofcourse, the bad disk which needs to be
replaced to restore redundancy, as you already know. Hopefully
the next upload of mdadm package will fix this issue, but it is
not very urgent - SIGSEGV'ing isn't nice but it isn't harmful either.
Thank you for the good work!
/mjt
tucano:/usr/local/src/mdadm/mdadm-3.2.5# gdb --args ./mdadm /dev/md3 --add
/dev/sdb1
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/local/src/mdadm/mdadm-3.2.5/mdadm...done.
(gdb) run
Starting program: /usr/local/src/mdadm/mdadm-3.2.5/mdadm /dev/md3 --add
/dev/sdb1
Program received signal SIGSEGV, Segmentation fault.
write_init_super1 (st=0x69b630) at super1.c:1248
1248 fprintf(stderr, Name : Failed to write metadata to
%s\n,
(gdb) bt
#0 write_init_super1 (st=0x69b630) at super1.c:1248
#1 0x00414600 in Manage_subdevs (devname=0x7fffebf3 /dev/md3,
fd=8, devlist=0x698030, verbose=0,
test=0, update=0x0, force=0) at Manage.c:952
#2 0x004060fb in main (argc=4, argv=0x7fffe8f8) at mdadm.c:1245
(gdb) p di
$1 = (struct devinfo *) 0x0
(gdb) p rv
$2 = 4
(gdb) p st
$3 = (struct supertype *) 0x69b630
(gdb) p *st
$4 = {ss = 0x683cc0, minor_version = 2, max_devs = 1920, container_dev =
8388608, sb = 0x6ae000, info = 0x6ad7f0,
ignore_hw_compat = 0, updates = 0x0, update_tail = 0x0, arrays = 0x0, sock
= 0, devnum = 3, devname = 0x0,
devcnt = 0, retry_soon = 0, devs = 0x0}
(gdb) p st-info
$5 = (void *) 0x6ad7f0
(gdb) p *(struct devinfo *)(st-info)
$6 = {fd = -1, devname = 0x7fffec02 /dev/sdb1, disk = {number = 2,
major = 8, minor = 17, raid_disk = -1,
state = 0}, next = 0x0}
(gdb) quit
A debugging session is active.
Inferior 1 [process 6824] will be killed.
Quit anyway? (y or n) y
tucano:/usr/local/src/mdadm/mdadm-3.2.5#
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703825: qemu-x86_64 segfaults when run some x64 binaries on i386 system
Package: qemu-user, qemu-user-static
Version: 1.1.2+dfsg-1
Severity: normal
Tags: upstream, confirmed
Forwarded: http://thread.gmane.org/gmane.comp.emulators.qemu/202103
$ ./x86_64-linux-user/qemu-x86_64 bash64
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
$ gdb x86_64-linux-user/qemu-x86_64
(gdb) ru bash64
Program received signal SIGSEGV, Segmentation fault.
disas_insn (s=s@entry=0xcf98, pc_start=18446744073699066880)
at target-i386/translate.c:4107
4107b = ldub_code(s-pc);
(gdb) p *s
$1 = {override = -1, prefix = 1484501952, aflag = 1, dflag = 1484503884,
pc = 18446744073699066880, is_jmp = 0, cs_base = 0, pe = 1, code32 = 1,
lma = 1, code64 = 1, rex_x = 0, rex_b = 0, ss32 = 1, cc_op = 0, addseg = 0,
f_st = 0, vm86 = 0, cpl = 3, iopl = 0, tf = 0, singlestep_enabled = 0,
jmp_opt = 1, mem_index = 0, flags = 4243635, tb = 0xf50e9f88,
popl_esp_hack = 0, rip_offset = 0, cpuid_features = 126614521,
cpuid_ext_features = -2139086847, cpuid_ext2_features = 563194873,
cpuid_ext3_features = 101}
This is with current git. Previous versions (tried 1.1 and 1.4)
segfaults in the same place too.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702278: t-p-u busybox upload (was: Re: busybox/1:1.20.0-8)
25.03.2013 13:37, Didier Raboud wrote: Hi all, I propose to upload busybox to t-p-u with only the RC bugfixes (#686502 and #701965, CVE-2013-1813). I have cherry-picked thoses changes on top of wheezy's. The resulting debdiff is attached, with version 1:1.20.0-7+deb7u0.1. I really hoped it can go as-is without any further reduction of fixes, all other stuff is also carefully picked and are fixes for real issues. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702278: t-p-u busybox upload
25.03.2013 13:54, Didier Raboud wrote: I propose to upload busybox to t-p-u with only the RC bugfixes (#686502 and #701965, CVE-2013-1813). IRC feedback on that subject lead to dropping the fix for #701965, rationale being http://bugs.debian.org/702278#17 . That's lovely. I haven't even seen this bugreport and this discussion before now. This message #17 mentions few feature fixes, which is completely wrong -- all these are real fixes for serious enough problems. I can only guess by feature fixes Adam meant the grep -w thing. It is not a feature fix, it is a bugfix for incorrectly working grep -w, which already lead to a costly bughunting in another place which relied on correctly implemented grep -w. This has nothing to do at all with the freeze. The CVE-2013-1813 fix is indeed not really interesting (even while the fix is rather stright-forward, it isn't exactly a one-liner and is somewhat ugly) -- I thought we'd fix the CVE anyway, since this is a very specific subsystem and does not affect anything else. But the rest really should go to wheezy. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702278: busybox upload
Let me start from scratch please. I wasn't aware of this bugreport/discussion, and I made a mistake by not filing a proper unblock request when I uploaded the busybox package with all the fixes. So here are descriptions of every change. A sort of a fore-word first. Busybox is kind of unusual package in a way that it re-implements functionality of various existing packages. Base debian system uses other implementations of the same functionality usually. So from this PoV, any busybox bug is not that important for a user's debian system, since a typical user does not use any busybox applets at all. Busybox _is_ used on almost every end-user system because it provides the set of basic *nix utilities for initramfs, and it is used in debian-installer. But these are very restricted environments with much better defined components and much less chance to have a combination which triggers one or another bug. So, any bug in busybox which does not affect basic initramfs or d-i functionality directly can't be important enough for whole debian system, so to say. On the other hand, sometimes, since busybox is almost always installed and available on any debian system, it gets used by users in various much less restricted environments, which leads to situations where the bugs are actually gets hit. This is minority of users (again, so to say). So this is about whenever we really care about this minority or not, _plus_ about _possible_ issues in d-i or initramfs. Another source of unusuality comes from the fact that busybox implements a ton of _independent_ applets, so that a change in one does not affect anything else (if we don't count changes in, say, memory layout which triggers bugs elsewhere - this has already happened at least once during wheezy development cycle, when we discovered bug with unaligned memory access which was hidden because the objects were actually aligned properly before we changed something unrelated in memory). So, back to the changes. busybox (1:1.20.0-8) unstable; urgency=low * grep-fix-grep--Fw-not-respecting-the--w-option.patch - implement fgrep -w correctly (Closes: #695862) As has been said before, this is a feature fix. It is not. The problem initially has been raized in some other package which had initramfs hook which didn't work. I don't remember which package it was, the context was that it tried to find some CPU feature by grepping /proc/cpuinfo with -w flag to grep, used to remove false positives, and it didn't work. (/proc/cpuinfo is just an example, I don't really remember what it was). This is one of these bugs which makes other, unrelated components fails in unexpected and difficult to debug ways. The fix is somewhat large, because it had to deal with logic of operations in grep applet. On the plus side, it comes with additional testcases which checks for this issue, and there are lots of other grep-related testcases already present. Unfortunatly busybox debian package still does not run any testcases during build (this is on my TODO list of first things to do for jessie), but having in mind the situation (deep freeze) and importance of the applet I ran provided and a few more testcases against the resulting grep on x86, ppc and mips platforms (on debian porterboxes) manually to ensure the fix does not break anything else and actually fixes the bug. If you ask me, this is about the same importance as #686502, but it is less obvious. This grep-w bug does not lead to data loss directly, the problem is that we can't rely on grep doing the right thing when we use it in a familiar, natural way - like when we try to fix a false positive by adding -w _somewhere else_ (in some other package that is), and it stops working. That's why it isn't a feature fix, busybox claimed to support grep-w but it does not work. What we're fixing here mostly is about _further_ d-i or initramfs changes (including possibility to have these changes in wheezy too) which looks completely correct and obvious but don't work in practice. Plus some random rare end-users usage of busybox grep, of these are exists. What we risk here is almost nothing, at least according to my tests on several platforms. * xz-support-concatenated-xz-streams.patch (Closes: #686502) This is the main RC bug currently filed against busybox. The rationale for it being RC is because it causes _silent_ data loss when decompressing certain kinds of XZ streams. Again, the severuty can be argued for sure, due to whole nature of busybox as a second-kind sitizen as mentioned at the beginning of this mail. First, not everyone is using busybox unxz (which is used in busybox tar and other archivers too), second, concatenaed xz streams aren't frequent either (but this becomes more and more of a problem, because such streams are produced by parallel xz, and this already seen in the wild - in particular, recent kernel sources on kernel.org are of this kind). We're unlikely to met all the conditions for this
Bug#702278: busybox upload
And sure thing I forgot to Cc debian-boot@. I think if this needs to be discussed further, debian-boot@ should receive it too. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677654: Bug #677654
On 14.11.2012 13:22, Laurent Joye wrote: Hello, I need to use the virtfs support of Qemu. Because the virtfs support is not enabled in the latest versions (Debian testing), I still need to use an old version (1.0.1). This is a packaging error. In new qemu, additional build dependency were introduced for virtfs, and I overlooked it. The result is that the debian qemu package is built w/o virtfs, while in previous versions virtfs were enabled. Could you please send me the status of this bug? Is there any action planed? No action planned for this issue for Wheezy -- Debian Wheezy will have qemu without virtfs. This is because since July-2012, only bugfixes for serious bugs are allowed to enter wheezy archive. Post wheezy, and in wheezy-backports, we will enable virtfs support, and will ensure it will be supported in all subsequent versions. Why did you decide to compile the qemu package without the virtfs support? No comment. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696043: libiscsi: New upstream version of libiscsi
Control: tags -1 + confirmed On 16.12.2012 13:15, Tomas Martišius wrote: Package: libiscsi1 Version: 1.4.0-3 Severity: wishlist File: libiscsi Dear Maintainer, There are new new upstream version of libiscsi, please upgrade. Some projects as proxmox depend on new wesion. Yes I know there's a new version out, and I wanted to upgrade. But I'm trying to avoid putting new stuff into unstable before wheezy is released. Once it is out, and new testing will be open, I'll upload it. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678029: also in 1.1.2
On 16.12.2012 14:23, Geert Stappers wrote: Over here with version 1.1.2 I also get a qemu: uncaught target signal 11 (Segmentation fault) - core dumped Not much changed in MIPS emulation in 1.1.x stable series. But I can't find the dumped core with sudo find . -name *core* Does it chdir to some other place perhaps? But anyway. Please tell us something about your environment, what you're trying to run, maybe some minimal reproducer, and whenever it happens with non-static variant too. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696050: possible data corruption bug in vmdk image format handler
Source: qemu Severity: serious Tags: patch upstream pending There's a long-standing bug in qemu's vmdk format handling, which may lead to data corruption when using vmdk-format images. It is fixed by upstream commit b1649fae49a899a222c3ac53c5009dd6f23349e1 . Original thread: http://patchwork.ozlabs.org/patch/197870/ Final submission: http://patchwork.ozlabs.org/patch/198177/ Marking as serious even if vmdk isn't used often, -- corrupting data is not a nice side-effect of trying a not-so-often-used format. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696051: potential guest-side buffer overflow caused by e1000 device emulation and large incoming packets
Source: qemu Severity: serious Tags: upstream patch pending security When guest does not enable large packet receiving from the qemu-emulated e1000 device, and a large packet is received from the network, qemu will happily transfer whole thing to guest, causing a guest buffer overflow. This is fixed by upstream commit b0d9ffcd0251161c7c92f94804dcf599dfa3edeb , with the following comment by Michael Contreras: Tested with linux guest. This error can potentially be exploited. At the very least it can cause a DoS to a guest system, and in the worse case it could allow remote code execution on the guest system with kernel level privilege. Risk seems low, as the network would need to be configured to allow large packets. So it can be considered a low-risk security issue, too. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696052: improper ahci emulation prevents some guests (windows) from seeing sata devices
Package: qemu-kvm Version: 1.1.2+dfsg-2 Severity: important Tags: upstream patch pending There's a small bug in ahci emulation which results, among others, in some guests (eg windows 7) to not recognize emulated SATA drives, asking for a driver disk during install. This is fixed by upstream commit 2a4f4f34e6fe55f4c82507c3e7ec9b58c2e24ad4. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696057: networking does not initialize tap device properly (vnet header)
Package: qemu-kvm Version: 1.1.2+dfsg-2 Severity: normal Tags: patch upstream pending When qemu opens a tap device on host to configure networking, it assumes that the device is not configured to use vnet header. But this might not be the case with persistent tap devices, when previously vnet were in use. In this case guest network will not work. Fix is trivial, to always initialize vnet header presence/absence on open, in order to not rely on unitialized value. This is upstream commit 58ddcd50f30cb5c020bd4f9f36b01ee160a27cac . /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696061: network stall when using e100 emulated device
Package: qemu-kvm Version: 1.1.2+dfsg-2 Severity: normal Tags: upstream patch pending This is a bug in e100 emulation in qemu, fixed by upstream commit 1069985fb132cd4324fc02d371f1e61492a1823f . Commit description says: From: Bo Yang boy...@suse.com Date: Wed, 29 Aug 2012 19:26:11 +0800 Subject: eepro100: Fix network hang when rx buffers run out This is reported by QA. When installing os with pxe, after the initial kernel and initrd are loaded, the procedure tries to copy files from install server to local harddisk, the network becomes stall because of running out of receive descriptor. [Whitespace fixes and removed qemu_notify_event() because Paolo's earlier net patches have moved it into qemu_flush_queued_packets(). Additional info: I can reproduce the network hang with a tap device doing a iPXE HTTP boot as follows: $ qemu -enable-kvm -m 1024 \ -netdev tap,id=netdev0,script=no,downscript=no \ -device i82559er,netdev=netdev0,romfile=80861209.rom \ -drive if=virtio,cache=none,file=test.img iPXE ifopen net0 iPXE config # set static network configuration iPXE kernel http://mirror.bytemark.co.uk/fedora/linux/releases/17/Fedora/x86_64/os/images/pxeboot/vmlinuz I needed a vanilla iPXE ROM to get to the iPXE prompt. I think the boot prompt has been disabled in the ROMs that ship with QEMU to reduce boot time. During the vmlinuz HTTP download there is a network hang. hw/eepro100.c has reached the end of the rx descriptor list. When the iPXE driver replenishes the rx descriptor list we don't kick the QEMU net subsystem and event loop, thereby leaving the tap netdev without its file descriptor in select(2). Stefan Hajnoczi stefa...@gmail.com] /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696063: possible network stalls/slowness in e1000 device emulation
Package: qemu-kvm Version: 1.1.2+dfsg-2 Severity: normal Tags: upstream From upstream qemu commit series intro message (http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01594.html): When the guests replenish the receive ring buffer, the network device should flush its queue of pending packets. This is done with qemu_flush_queued_packets, and patches 2+3 add the missing call to two drivers, e1000 and xen. More may come later---no time to test them now. However, the device should not just retry delivery of packets that were already read from the tap device, it should also try to read more packets from the tap device. The latter requires a qemu_notify_event to force recomputation of the fd_sets. virtio already does this, but it is a layering violation; patch 1 moves the call from virtio to the network subsystem, so that e1000 and xen will then get it for free. Paolo Bonzini (3): net: notify iothread after flushing queue e1000: flush queue whenever can_receive can go from false to true xen: flush queue when getting an event This means, among other things, that it is possible for e1000 to stall under normal load, provided there's no other activity around the guest -- like (virtual) disk access, timers and so on - actions which causes internal qemu FD# watchers to re-initialize. In usual conditions, when the guest uses disk or has timers, the impact can be very low. But for certain workload, like (virtual) diskless router, this might be more problematic. There are 2 patches needed from upstream to fix this: 987a9b483567b1a47a379255e886a77d57ea net: notify iothread after flushing queue e8b4c680b41bd960ecccd9ff076b7b058e0afcd4 e1000: flush queue whenever can_receive can go from false to true (and also a98b140223d3a627eab7ee3ddec645bab630d756 for xen). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524820: qemu: fails to use usb token product in virtual computer runs windowsxp
Control: tag -1 + moreinfo On 20.04.2009 10:38, gulfstream wrote: Package: qemu Version: 0.10.1-1 Severity: normal In order to use online bank services, I install a windowsxp in qemu because it supports ie only. The transactions of online bank need a usb token to encrypt and sign the messages. But the qemu does not support the usb token fine. I can view the certifcate which stores in the usb token, but the internet explorer crash when internet explorer use the certifcate stored in the usb token to encrypt and sign the messages of online bank services without any informations. I suspect the issue was lead by usb interface compatibility of qemu. Hello. Answering to an old bugreport submitted in 2009. There are lots of stuff changed in qemu since that time and version. In particular, USB subsystem received major improvements, and USB2.0 support has been implemented. Does the problem still persist in current version? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
