Bug#752044: qemu-kvm: ich9-ehci1, plus ich9-uhci1, ... result in attempts to use USB passthrough to fail in Windows
Control: tag -1 + moreinfo 19.06.2014 09:05, Daniel Dickinson wrote: > Package: qemu-kvm > Version: 1.1.2+dfsg-6+deb7u3 > Severity: normal > > The ich9-ehc1, with ich9-uchi1, ... as slaves (the configuration used by > libvirt-bin when virt-manager's USB2 option is selected) results in USB > passthrough devices failing to start with either Code 43 or Code 10 messages > from (at least) Windows 8.1. These combo of USB passthrough with ich9 and > Windows seems to have bugs at the moment (at least in Wheezy). USB2 support in qemu changed _dramatically_ in qemu version 1.2. What we have in wheezy in qemu 1.1 is more or less just a "preview" of how it can be done. It works for some devices, but does not work for most. Please try current version from backports. If that one works for you, just use it. It is unrealistic to backport USB(2) stack from 1.2 to wheezy 1.1 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
Bug#751754: qemu-system-x86: update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Control: severity -1 minor 16.06.2014 14:26, Paul Wise wrote: > Package: qemu-system-x86 > Version: 2.0.0+dfsg-6+b1 > Severity: normal > > I got this warning on upgrade: > > Setting up qemu-system-x86 (2.0.0+dfsg-6+b1) ... > update-rc.d: warning: start and stop actions are no longer supported; falling > back to defaults This warning is completely harmless. I considered fixing it in the past, but decided not to, Because I think it is actually an update-rc.d bug (or misfeature). The only way left in jessie and up to install a service is to use `update-rc.d foo defaults', which, in jessie, reads the LSB headers from the given script. This is good. However, this way does not work at all on wheezy, because there, update-rc.d does not look at LSB headers at all. So, there's no way which works on both wheezy and jessie. But qemu is one of packages which are really backports- worty, so to say, -- due to fast development of qemu, I can't keep wheezy without backporting current version. And if I to fix this warning from update-rc.d, I'll have to undo this change on each backport, which is very much error prone. So, while this is an actual warning on update-rc.d part, it is not helpful at all. Especially (and here's why I consider it a bug in update-rc.d) because the levels specified on the command line are the same as in the LSB headers - at least in this case it can stop producing useless warnings... Besides, I don't think this warning deserves `normal' severity, since it is completely harmless. And finally, this very initscript is not even needed on jessie anymore, because kernel past (iirc) 3.9 autoloads kvm modules. This script, basically, is only needed for old (wheezy) kernel. Maybe I'll just remove it completely for jessie release. 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#752520: RFS: lilyterm/0.9.9.4-1 [ITP]
24.06.2014 16:41, ChangZhuo Chen (陳昌倬) wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "lilyterm" > > Package name: lilyterm > Version : 0.9.9.4-1 > Upstream Author : Lu, Chao-Ming (Tetralet) > URL : http://lilyterm.luna.com.tw/ > License : GPL-3+ > Section : x11 > > It builds those binary packages: > > lilyterm - Light and eazy-to-use terminal emulator for X > lilyterm-data - Data files for lilyterm > lilyterm-dbg - Debug symbols for lilyterm What is the advantage of lilyterm over a gazzilion of other *terms debian already ships? What's wrong with, say, roxterm? Besides, why did you create lilyterm-data? Can't you just swallow it by main lilyterm package? You may need extra -data in two cases -- when that -data comes from a separate source, or when you have several different variations of your term package (say, gtk2 and gtk3 versions) which all use a common set of data files. Apparently neither of the two cases applies 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#744213: CVE-2013-4544: vmxnet3: lack of data validation coming from guest
Source: qemu Version: 1.4.0~rc0+dfsg-1exp Severity: grave Tags: security upstream patch jessie sid There's a security hole reported for vmxnet3 device as emulated by qemu. This is a vmware network device. The vulnerability has been assigned CVE-2013-4544. The device has been introduced in qemu version 1.4, so older debian releases are not affected. The impact is somewhat low still, since only guests using vmxnet3 device are affected, which should not be many. Upstream maintainer has a patchset for this issue: http://thread.gmane.org/gmane.comp.emulators.qemu/265562 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#744221: CVE-2014-0150: guest-triggerable buffer overrun in virtio-net
Source: qemu Version: 0.6.1-1 Severity: grave Tags: security patch upstream squeeze wheezy jessie sid This is a guest-triggerable buffer overrun in virtio-net device in qemu. The relevant code has been added to qemu in version 0.6, which means it is in all versions of debian. The network device is one of the most important network devices which qemu implements, so impact might be very high. Upstream commit fixing this issue: http://thread.gmane.org/gmane.comp.emulators.qemu/266713 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#744382: librbd-dev and librados-dev does not provide correct shlibs/symbols file
Package: librbd-dev, librados-dev Version: 0.72.2-2 Severity: grave Currently, testing+unstable has librbd version 0.72.2-2. When linking, for example, qemu against this version of librbd, the resulting depends on unversioned librbd1. But for example, librbd1 version 0.47.2-1 does not provide some library symbols which are provided by 0.72.2 - eg, rbd_aio_flush. As a result, programs linked with 0.72.2-2 version does not work with older version of the library, and no indication of the version needed is given. That to say, linking programs with librbd or librados breaks those programs in random way. This has already been reported before wheezy, this is exactly the reason why ceph has been removed from wheezy. I haven't looked at the updated librbd/librados before enabling ceph support in qemu. Looks like this enabling has been done too early, since the libraries aren't yet ready to be used. 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#744342: qemu: We apologize for the inconvenience but Windows did not start ...
13.04.2014 11:03, Kingsley G. Morse Jr. wrote: > Package: qemu > Version: 1.7.0+dfsg-8 > Severity: normal > > Hi, > > Thank you for maintaining qemu. > > It can be handy when you need to run a program > compiled for a different operating system. > > I happened to notice that after upgrading from > > 1.6.0+dfsg-1+b1 > > to > > 1.7.0+dfsg-8 > > Windows XP would no longer boot in qemu. > > XP complained with > > "We apologize for the inconvenience but > Windows did not start successfully. A recent > hardware or software change might have caused > this." Wow. > I was surprised that upgrading qemu stopped it > from running XP. It should not, obviously. > Maybe the new version of qemu looked to XP like it > had different hardware or software. > > I read that it has new USB 3.0 code. > > I tried having qemu emulate a variety of machine > types with the "-M" option. > > No luck. > Nor would XP boot into safe mode. > > > I ended up > > 1.) removing the new versions of qemu and its ~12 > related packages, > > 2.) looking in /var/log/dpkg.log to see what > versions I was running before, > > 3.) finding each at > > snapshot.debian.org > > 4.) downloading each to a subdirectory and > > 5.) running > > $ dpkg -i * > > 6.) in that subdirectory. Oh well, the procedure is much simpler. You only need to install qemu-system-x86 plus qemu-system-common, and the latter can be keep the latest. You don't need all the various system emulators for various different hardware. So, have you found which version broke? > Humble suggestion: > > Ask what changed between 1.6 and 1.7, and try > adding command line options to let users keep the > old behavior if they wish. It is a bug which needs fixing. I can't immediately reproduce it here (especially because you haven't specified the qemu command line you used to run your guest). Please at least try 1.7.0+dfsg-2 and see if that one works. 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#729961: qemu-system-x86: rbd support
09.01.2014 10:53, Christian Balzer wrote: > > Hello, > > Meanwhile, we're at qemu 1.7, ceph is at 0.72, both in sid and > wheezy-backports. > > I'd really, really would love to see RBD re-enabled by default for these > and when things have trickled into jessie. I just removed librbd support in qemu once again, because the same old issue - lack of library/symbol versioning - which prevented ceph from going into wheezy - is _still_ not fixed. Because once I uploaded rbd- enabled qemu, I received a new grave bugreport against qemu-system which tells me that running qemu-system binary results in dynamic linker not finding symbol rbd_aio_flush or some other. And now I need _really_ good reason to re-enable it again, because, well, guys, this is not funny at all. 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#742386: wheezy-pu: package qemu/1.1.2+dfsg-6a+deb7u1
13.04.2014 21:39, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sun, 2014-03-23 at 12:45 +0100, Gabriele Giacone wrote: >> On Sun, Mar 23, 2014 at 01:48:34PM +0400, Michael Tokarev wrote: >>> Please note that the same changes should be done for qemu-kvm package on >>> wheezy. >>> >>> Also note that the names of patches does not reflect reality. >>> These are fixing real bugs in qemu, not hurd-specific issues. >> >> Renamed patches, attached qemu-kvm one too. > > Please go ahead. There's a pending security update for qemu fixing CVE-2014-0150 (#744221), which uploads +deb7u1 for both qemu and qemu-kvm, 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#742386: wheezy-pu: package qemu/1.1.2+dfsg-6a+deb7u1
13.04.2014 22:04, Adam D. Barratt wrote: > On Sun, 2014-04-13 at 21:49 +0400, Michael Tokarev wrote: >> 13.04.2014 21:39, Adam D. Barratt wrote: >>> >>> On Sun, 2014-03-23 at 12:45 +0100, Gabriele Giacone wrote: >>>> On Sun, Mar 23, 2014 at 01:48:34PM +0400, Michael Tokarev wrote: >>>>> Please note that the same changes should be done for qemu-kvm package on >>>>> wheezy. >>>>> >>>>> Also note that the names of patches does not reflect reality. >>>>> These are fixing real bugs in qemu, not hurd-specific issues. >>>> >>>> Renamed patches, attached qemu-kvm one too. >>> >>> Please go ahead. >> >> There's a pending security update for qemu fixing CVE-2014-0150 (#744221), >> which uploads +deb7u1 for both qemu and qemu-kvm, fwiw. > > Okay, thanks. > > I guess the stable updates should be +deb7u2 then, incorporating the u1 > upload, once it's released. Yes indeed. And I want to take care of this, again, once security fix will be released. Thank you Gabriele for the work! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744213: CVE-2013-4544: vmxnet3: lack of data validation coming from guest
Control: severity -1 important 11.04.2014 17:30, Michael Tokarev wrote: > The impact is somewhat low still, since only guests using vmxnet3 device are > affected, which should not be many. Lowering severity to be important, not grave. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744342: qemu: We apologize for the inconvenience but Windows did not start ...
14.04.2014 00:25, Kingsley G. Morse Jr. wrote: > Hi Michael, Hello! [] > I like your idea of specifying the command line > that elicited the bug. > > It's > > $ /usr/bin/qemu -hda //.raw -m 512 -localtime -no-acpi -cdrom > /dev/cdrom Hmm. It is most likely -no-acpi. I don't have any windows image which will work with -no-acpi, will have to install another for that. But mind you, -no-acpi is something which hasn't been well supported for a few years already, both in qemu and in various operating systems, because all modern systems have acpi. > I think the "-M" options I tried were It is not about -M option, most likely, but I'll try those too 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#729961: qemu-system-x86: rbd support
14.04.2014 04:26, Christian Balzer wrote: > On Sun, 13 Apr 2014 19:04:45 +0400 Michael Tokarev wrote: [] >> I just removed librbd support in qemu once again, because the same old >> issue - lack of library/symbol versioning - which prevented ceph from >> going into wheezy - is _still_ not fixed. Because once I uploaded rbd- >> enabled qemu, I received a new grave bugreport against qemu-system which >> tells me that running qemu-system binary results in dynamic linker not >> finding symbol rbd_aio_flush or some other. >> > Where is that NEW bug report? Would that be the OLD: The new bugreport against qemu is #744364, which is the same as very old #680307 which started all this stuff. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679686 > > you merged things with? I didn't merge anything with #679686. But that one is messy due to my actions, but is still valid. >> And now I need _really_ good reason to re-enable it again, because, well, >> guys, this is not funny at all. >> > Firstly I am running 1.7.0+dfsg-6 under Jessie and it works just fine. > As did source build versions with RBD enabled in the past, either by using > the inktank Ceph packages or since 0.72.x entered sid and then jessie. > > Secondly, Bug 679686 is about something that is not true in Jessie, as it > contains Ceph 0.72.2 (at this time). > That version is not in wheezy-backports yet and for that particular case > it would be true. > However for Jessie it most emphatically isn't. It is the still present issue which pops up any time someone ends up with half- updated system, for whatever reason, because dpkg/apt does not tell user about the correct dependencies. And this time, the new bugreport was filed against qemu right when I was waiting for the 2-day "urgent" package upload to migrate to testing, to fix an important security hole. The new bug prevents the testing migration. 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#744382: [Ceph-maintainers] Bug#744382: librbd-dev and librados-dev does not provide correct shlibs/symbols file
14.04.2014 10:47, Dmitry Smirnov wrote: > Hi Michael, Hello! > On Sun, 13 Apr 2014 18:32:05 Michael Tokarev wrote: [] >> That to say, linking programs with librbd or librados breaks those >> programs in random way. > > Thank you for detailed report. This is the same as #680307, I think the two should be just merged together. [] > By the way do you think that just using "dh_makeshlibs -V" would be > sufficient? Although I committed .symbols files I've never had good > experience > with symbols in C++ libraries and I have concerns for potential build > problems > on multiple architectures... Yes, this has happened in the past - a naive attempt to use dh_makeshlibs -V resulted in package FTBFS on all arches except of the one where makeshlibs were run, due to differences in complier and architectures wrt C++ symbols. I don't know ceph internals. If those C++ symbols are internal, and only regular symbols should be exposed, maybe just hiding them all should be a good idea. If, on the other hand, those are parts of public ABI, I'm afraid there's no good solution except of the way you did it -- making all C++ symbols to be part of the latest release. Note that makeshlibs supports symbols.arch file in addition to symbols file, maybe that one can be used to export (limited) set of C++ ABI. I too have no expirience with C++ exporting and .symbols files. Besides, you added the two .symbols files into 0.79 package, -- maybe you may run makeshlibs on 0.72 instead (or even on 0.44/0.48), to generate initial .symbols files, and run mkshlibs again on new version(s) to make additions. This way, even older lib may be used for symbols which were present long time ago. Dunno how important it is. 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#744382: [Ceph-maintainers] Bug#744382: librbd-dev and librados-dev does not provide correct shlibs/symbols file
14.04.2014 11:42, Dmitry Smirnov wrote: > On Mon, 14 Apr 2014 11:23:29 Michael Tokarev wrote: >> 14.04.2014 10:47, Dmitry Smirnov wrote: >>> By the way do you think that just using "dh_makeshlibs -V" would be >>> sufficient? Although I committed .symbols files I've never had good >>> experience with symbols in C++ libraries and I have concerns for >>> potential build problems on multiple architectures... >> >> Yes, this has happened in the past - a naive attempt to use dh_makeshlibs -V >> resulted in package FTBFS on all arches except of the one where makeshlibs >> were run, due to differences in complier and architectures wrt C++ symbols. > > Actually I thought that "dh_makeshlibs -V" would be safe to use, safer than > adding .symbols file(s) but perhas not that flexible... I'm considering to > make upload of 0.72.2-3 with "dh_makeshlibs -V" -- would you recommend not to > do that? > How "dh_makeshlibs -V" can cause FTBFS? Um. I misunderstood. dh_makeshlibs can generate shlibs file and/or use symbols file. Ofcourse, using dh_makeshlibs -V without .symbols file is safe, but not very useful as comments in man dh_makeshlibs says: Beware of using -V without any parameters; this is a conservative setting that always ensures that other packages' shared library dependencies are at least as tight as they need to be (unless your library is prone to changing ABI without updating the upstream version number), so that if the maintainer screws up then they won't break. The flip side is that packages might end up with dependencies that are too tight and so find it harder to be upgraded. In other words, it solves the immediate problem, but it might become more problematic in the future, since we'll have migration probs every time upstream version changes. What I mean about FTBFS is that there was a naive attempt to provide .symbols files, which, together with C++ instability over architectures, resulted in FTBFS. Ofcourse it was done using dh_makeshlibs. Which has little to do with your question. >> I don't know ceph internals. If those C++ symbols are internal, and only >> regular symbols should be exposed, maybe just hiding them all should be a >> good idea. If, on the other hand, those are parts of public ABI, I'm afraid >> there's no good solution except of the way you did it -- making all C++ >> symbols to be part of the latest release. > > I wish I knew the answer to those questions. :) Hm. That's.. interesting indeed ;) Maybe we can ask upsteam for some comments? Maybe they'll even consider providing version-script files for gcc/linker in the same way many other libs are providing, to clean up the list of exports they're doing. Actually this might not be that a bad idea. See eg http://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility/index.html http://www.akkadia.org/drepper/dsohowto.pdf (the first link is about aix but still useful). I can't immediately find a very good (and short) writeup about this and gnu linker, I remember coming across this somewhere before. > By the way thank you for > useful comments in > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679686#53 > >> Note that makeshlibs supports symbols.arch file in addition to symbols file, >> maybe that one can be used to export (limited) set of C++ ABI. > > Thank you, I'll remember that. There's more to this: a single symbols file may contain arch-specific symbols with quite flexible syntax. >> I too have no expirience with C++ exporting and .symbols files. > > I found it so difficult to maintain symbols in C++ libraries so I just used > "dh_makeshlibs -V" and it never failed me. Yeah, it never fails, but it has its own downside which I mentioned above. >> Besides, you added the two .symbols files into 0.79 package, -- maybe you >> may run makeshlibs on 0.72 instead (or even on 0.44/0.48), to generate >> initial .symbols files, and run mkshlibs again on new version(s) to make >> additions. This way, even older lib may be used for symbols which were >> present long time ago. Dunno how important it is. > > Will do, that's exactly what I was thinking about. Just need a bit more time > to build... :) > > Thank you. And thank you too for tryin to clear the mess! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744382: [Ceph-maintainers] Bug#744382: librbd-dev and librados-dev does not provide correct shlibs/symbols file
Josh, thank you very much for stepping in an for your explanations! A few more comments below. 15.04.2014 03:06, Josh Durgin wrote: > On 04/14/2014 02:43 AM, Dmitry Smirnov wrote: [] >> Specifically in regards to Ceph for a moment I feel much more comfortable >> with >> "dh_makeshlibs -V" not only due to lack of confidence in C++ symbols approach >> but mostly because of rapid upstream development. The amount of changes >> between 0.72.2 and 0.79 is huge. I would feel quite uncomfortable if "qemu" >> would be built successfully with 0.79 but wouldn't pull newer libraries when >> used with 0.72.2... For example Ceph cluster has to be completely upgraded to >> 0.79 as it just doesn't work with mix of 0.72.2 and 0.79 components (i.e. >> OSD,MON,MDS)... > > As a ceph developer, the mixed-cluster issue is a bug (possibly fixed > already since 0.79 is undergoing heavy testing and fixes before the > next long term stable release, 0.80, is out). If you have more details > we'd be happy to hear about them. No, this is not about mixed-cluster issue (to be fair I'm not really sure what you're talking about, but I _think_ you're referring to a situation when different parts of the cluster is using different versions of the software). This is about build-time vs run-time version/interface difference in 3rd party software. The bug in question is debian-specific but it shows a more deep issue within the mentioned libraries, which you confirm below. When building everything from source on target machines, the problem does not exist. The problem comes when you build different system components on different machines or at different time, and run a combination of all this, again, on different machines. I mean not that different parts of ceph software/ stack have different versions, but when you build a 3rd party software using one version of rbd.h/librbd.so, but run it against a system- installed librbd.so.1 from different build of librbd. In this situation, a distribution needs to ensure the runtime librbd.so.1 has the right ABI. ABI does not change _that_ often, and it is quite normal when an app which was built against, say, 0.79 version of librbd.so, can happily work with librbd.so.1 version 0.72 (when it actually does NOT use any symbols which are present in 0.79 but didn't exist in 0.72). So when a 3rd party app actually uses such symbols which are present in 0.79 but not present in earlier versions, a distribution should include metadata for this 3rd party application that it needs librbd.so.1 AT LEAST of version 0.79, to satisfy library symbol (and hopefully ABI) requiriments. When we may have a situation when an app is built against a more recent version but is run against an older version of a library? For example, most distributions have some "unstable" branch where all new most current versions of all software are uploaded to. On the other hand, users may run stable branches with older versions of everything. And imagine a ceph cluster running with a 0.72 version, and the user wants to try qemu (3rd party app) from unstable branch, because their "stable" qemu has a bug with their guest OS. The easiest way here is just to install qemu from unstable branch. With all the rest of the cluster still running the same 0.72 version, without mixed-cluster issues. So we need a mechanism to tell the package management system the minimum version of a library an app requires. For this, we need a .symbols file with a list of all exported symbols together with library version at which they first appeared. And this is what this whole talk is about, nothing more. One possible way here, as suggested by Dmitry, is to record the build version of the library as minimum required for the app linked to it (dh_makeshlibs -V does just that). This way, qemu built against 0.72 version of librbd will require librbd >= 0.72 according to package manager metadata, even if it actually uses only symbols introduced in 0.44 version of librbd and before. This approach works, but, as you've shown below, not for ceph, because ceph does not tolerate mixed-cluster, so once you update any 3rd party, not cluster-related but cluster-used, software, you'll have to upgrade whole cluster too, because according to the package manager, you'll have to update - in this case - librbd to the latest, which will most likely require updating whole ceph stack on one node, which ofcourse requires upgrading ceph stack on other nodes as well. Dmitry: this is a good example of why naive `makeshlibs -V' approach sometimes should NOT be used... > Regarding library symbols, the ceph libraries each have C++ as well as > C interfaces, and there's been some suggestions to move to > visibility=hidden by default, to avoid some of the hairier problems > with C++ libraries [1]. It seems like this would make .symbols files approach > more tenable, since passing through all C++ symbols would > not be as bad if only the desired ones are exported in the first pl
Bug#690889: udhcpc always returns a domain of "bad" when receiving a valid dhcp ack packet
18.04.2014 00:21, Иван Сусанин wrote: [] > I've already reopened original udchpc bug at busybox bugtracker > (https://bugs.busybox.net/show_bug.cgi?id=3979), but it looks like I'm asking > for a miracle... I've seen that discussion. And frankly, I strongly support Denis here. We've a well-documented dhcp options used for various things - namely, for setting domain name and for setting domain search path. However, for some reason, those options has been abused (or, rather, used incorrectly) for years. Now, when software actually refuses to let this abuse happen, we complain that the software is bad. But it just follows the standard. > What can be done on this matter? I think the best is to fix the setup. 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#742386: wheezy-pu: package qemu/1.1.2+dfsg-6a+deb7u1
18.04.2014 15:40, Adam D. Barratt wrote: > On 2014-04-13 19:05, Michael Tokarev wrote: [] >>>> There's a pending security update for qemu fixing CVE-2014-0150 (#744221), >>>> which uploads +deb7u1 for both qemu and qemu-kvm, fwiw. >>> >>> Okay, thanks. >>> >>> I guess the stable updates should be +deb7u2 then, incorporating the u1 >>> upload, once it's released. >> >> Yes indeed. And I want to take care of this, again, once security fix will >> be released. > > I noticed that the security updates have now been released. > > Not wishing to chase, just a gentle reminder that the window for getting > updates in to 7.5 closes over the weekend. (Although getting in to 7.6 > instead is presumably not a huge problem.) I've another security bugfix for qemu+qemu-kvm, CVE-2014-2894, assigned today, see https://lists.nongnu.org/archive/html/qemu-devel/2014-04/msg02016.html The fix is also one-liner. Maybe we can combine the two - this #742386 and CVE-2014-2894 - into single pu? If not, I guess I'll go with this #742386 first and CVE-2014-2894 on top of 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#745157: guest-triggerable out-of-bounds buffer access via IDE SMART command (CVE-2014-2894)
Package: qemu-system, qemu-kvm Version: 1.1.2+dfsg-1 Severity: serious Tags: security upstream patch wheezy jessie CVE-2014-2894, a guest-triggerable out of bounds memory access using IDE SMART commands. This can lead to qemu process memory corruption and potentially (unlikely) to invalid code execution with host qemu process privileges. Introduced past 2009. Qemu 0.12 (on squeeze, oldstable) is not affected, wheezy/stable and current testing are affected, fixed in upstream 2.0 which is currently in sid. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745170: O: vgabios -- VGA BIOS software for the Bochs and Qemu emulated VGA card
Package: wnpp Severity: normal I intend to orphan the vgabios package. The package description is: The goal of this project is to provide a Video BIOS for Bochs and Qemu. This VGA BIOS is very specific to the bochs/qemu emulated VGA card. . WARNING: It is NOT meant to drive a physical vga card. You will probably fry it if you try. You have been warned. QEMU does not use it anymore, it switched to vga bios implementation provided by seabios (seavgabios) which is actively maintained. vgabios was used by bochs but it is now orphaned 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#742386: wheezy-pu: package qemu/1.1.2+dfsg-6a+deb7u1
18.04.2014 16:27, Adam D. Barratt wrote: > On 2014-04-18 12:54, Michael Tokarev wrote: >> 18.04.2014 15:40, Adam D. Barratt wrote: >>> Not wishing to chase, just a gentle reminder that the window for getting >>> updates in to 7.5 closes over the weekend. (Although getting in to 7.6 >>> instead is presumably not a huge problem.) >> >> I've another security bugfix for qemu+qemu-kvm, CVE-2014-2894, >> assigned today, see >> https://lists.nongnu.org/archive/html/qemu-devel/2014-04/msg02016.html >> The fix is also one-liner. >> >> Maybe we can combine the two - this #742386 and CVE-2014-2894 - into single >> pu? > > Looking at the source for the 2.0.0 packages uploaded to unstable yesterday, > it looks like they contain the CVE fix? If so then the security-tracker needs > updating, as https://security-tracker.debian.org/tracker/CVE-2014-2894 lists > unstable as vulnerable. If the security team don't plan to issue a DSA for > the issue (which I don't know if they've decided yet) then the patch looks > sane enough to include in the p-u. Yes, 2.0.0 contains the (last-minute) fix. And no, this fix is definitely worth a DSA. So I'm uploading +deb7u2 to wheezy-pu as has been already agreed before, to catch the train to 7.5. With intention to fix CVE-2014-2894 later. 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#745269: qemu-system: Ctrl+Alt keyboard shortcuts not working in qemu-system-* when compiled against SDL 2.0
Control: severity 745185 important Control: reassign 745185 qemu-system Control: merge 745269 745185 Control: forwarded 745269 http://thread.gmane.org/gmane.comp.emulators.qemu/267839 20.04.2014 09:03, M. Vefa Bicakci wrote: > Package: qemu-system > Version: 2.0.0+dfsg-2 > Severity: important > > Hello, > > On a Debian Sid system that is up-to-date as of today, when I use > qemu-system-* > (i.e. qemu-system-i386, qemu-system-x86_64, ...) with the SDL user interface, > I > cannot use the Ctrl+Alt+2 keyboard shortcut from within the GUI window in > order > to access qemu's "monitor" mode. Similarly, Ctrl+Alt+f does not switch to > full-screen mode either. Because these are important features in qemu, I > marked > this bug report as important. > > While trying to debug this issue, I rebuilt the qemu (2.0.0+dfsg-2) source > package with a modification to the debian/control-in file which forces qemu > to be compiled against SDL 1.2 (as opposed to the maintainer's default of > SDL 2.0). With SDL 1.2 the aforementioned keyboard shortcuts work as intended > and as expected. Yes, I debugged it yesterday too, after receiving #745185, and yes your observation are correct. > Is there any possibility of uploading a version of qemu 2.0.0+dfsg compiled > against SDL 1.2 to Debian unstable, at least until this issue with SDL 2.0 > is resolved? Sure, that appears to be the solution. I asked upstream about this (see Forwarded URL), but no reply so far, and looking at the code I don't see an easy fix, apparently monitor and guest serial output are not even implemented for sdl2. Please give me one more day for this, to get definitive opinion. I have quite some changes pending for the next release already which will have to be backed up for this change to be uploaded (new changes introduces some new packages, namely libcacard, so will wait in NEW). Note that usage of SDL2 is required for modular monitor (in loadable modules), because SDL1 replaces main() routine to do pre-initialization and hence can't be loaded later. Thank you for the excellent bugreport! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745490: qemu-system-x86: Guests fail to start with Linunz 3.13 (3.12 is fine)
22.04.2014 13:19, Patrice Pillot wrote: > Package: qemu-system-x86 > Version: 1.7.0+dfsg-9 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > Since kernel 3.13 migrated into jessie, I cannot start KVM guests > anymore. > > If I boot on the last jessie 3.12 kernel (3.12.9-1), I can start the > guests with no problem. Well. In that case, why are you filing a bug report against qemu? As far as I can see, in your case the HOST kernel breaks, receiving an NMI for all CPUs. This is something which no user-space program should be able to achieve, no matter what. And you state that previous kernel version worked fine, so it is the kernel which broke when updating to 3.13 version. How it is a qemu problem? Note also that you're running a 32bit kernel - this is something which has not been tested for a very long time. No developers run qemu/kvm on 32bit kernels. No testing environment has 32bit kernels. We in Debian have a few bugreports against qemu involving 32bit kernels, and those stays unfixed forever because it is an environment which has very little value nowadays, and which bitrots slowly because no one tests it anymore. Does the same problem occurs when you run it with 64bit kernel instead? Do you know whenever it worked with older version(s) of qemu but with the current kernel? 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
22.04.2014 03:21, Dmitry Smirnov wrote: > Dear Michael, > > I just want to let you know that Ceph_0.72.2-3 introduced library versioning > mechanism and it already migrated to "testing". Ceph_0.79 in "experimental" > now provides symbols (starting from 0.72.2) for all its libraries. I built > qemu/1.7.0+dfsg-8 with ceph_0.79/experimental and (as expected) generated > dependencies were conservative: "librados2 (>= 0.72.2), librbd1 (>= 0.72.2)". I looked at what's currently in 0.72.2-3 and 0.79 in experimental, and I think this is a very good start. Just one thing - maybe you can remove -V option of dh_makeshlibs in 0.79, since you have good .symbols files already. > Now I hope you can safely enable RBD support in Qemu. > > Please let me know if you need anything else to re-introduce RBD support. > I'm eagerly looking forward to have it back. ;) I think that's all what needed, I will re-enable rbd/ceph on the next qemu upload. BTW, I found another link which might be useful for this: http://pkg-kde.alioth.debian.org/symbolfiles.html Thank you for taking care of this! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745269: Twisted wording in changelog entry
22.04.2014 18:40, Bruno Kleinert wrote: > Hi Michael, > > I think you wanted to write "switch back to sdl1 from sdl2, as the > latter apparently isn't ready [...]". Hehe. Yes, you're obviously right, it is twisted and wrong indeed :) Fixed in git, will be there on 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#745684: Regression: qemu 2.0.0+dfsg-3 lacking rbd support (from 1.7.0+dfsg-8)
Control: reassign -1 qemu-system Control: merge -1 689239 24.04.2014 05:09, Michael Evans wrote: > Package: qemu > Version: 2.0.0+dfsg-3 > Severity: important There's absolutely no need to report the same bug 5th time. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740397: busybox: please add support for parallel building
01.03.2014 06:17, Cyril Brulebois wrote: > Package: busybox > Version: 1:1.20.0-7 > Severity: normal > Tags: patch > > Hi, > > the title and the attached patch say it all. Oh well. This come several times in the past for various packages, and it always ends up in some strange place. I always build my packages in parallel mode locally and ofcourse ensure they build fine that way. Because, well, I dislike waiting for too long when my machine have many cores doing nothing. The way I alway do this is by passing -jX flag to dpkg-buildpackage, sbuild, or just ./d/rules -jX, and so on. This ends up being a flag for the top-level make (which calls d/rules) so the job server becomes global. It is the easiest and most strightforward way. Now, when adding support for DEB_BUILD_OPTIONS's parallel=X suboption, I always end up in either my packages building in just one thread (because I still haven't figured how to pass environment variables to sbuild for example), or I have to use a non-easy, much more verbose way to run dpkg-buildpackage (setting DEB_BUILD_OPTIONS= instead of just passing -j). Because DEB_BUILD_OPTIONS handling, at the end, overrides -j somehow. The way how you proposed to fix your initial proposal -- add "else\nNUMJOBS = 1" -- makes this obvious, -- no matter what -jX is passed to the top-level, the build will be done according to DEB_BUILD_OPTS (whenever it is set or unset). I asked about this several times on #irc but got no good answer. And after some tries I ended up in what we have now, -- I just ignore DEB_BUILD_OPTIONS, because I try to build the package much more often than it is built on buildds, and I want the process to be easiest for me not for machines, and I value my own time much more than CPU time of debian buildd network (even of the slowest machines in there). When you look at debhelper in this context, things becomes even more interesting. I wasn't able to make it work with -j _and_ with its --parallel flag. Also, when you set -j just for submakes, quite often make complains about various issues with the job server. When -j is set for the top-level d/rules, this doesn't happen (unless there's a bug in the submake invocation or in upstream build system). > (On a slightly, but not totally unrelated note: supporting nocheck as > well would be nice.) Yeah, nocheck is something I wanted to implement but forgot. Will do. > Reference: > https://www.debian.org/doc/debian-policy/ch-source.html Yes, I know parallel= in there. And I tried numerous times to obey the rules and to make it work. Every time had issues and finally gave up. 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#740397: busybox: please add support for parallel building
Control: tag -1 + pending 01.03.2014 12:01, Michael Tokarev wrote: > 01.03.2014 06:17, Cyril Brulebois wrote: >> Package: busybox >> Version: 1:1.20.0-7 >> Severity: normal >> Tags: patch >> >> Hi, >> >> the title and the attached patch say it all. > > Oh well. > > This come several times in the past for various packages, and it always > ends up in some strange place. > > I always build my packages in parallel mode locally and ofcourse > ensure they build fine that way. Because, well, I dislike waiting > for too long when my machine have many cores doing nothing. > > The way I alway do this is by passing -jX flag to dpkg-buildpackage, > sbuild, or just ./d/rules -jX, and so on. This ends up being a flag > for the top-level make (which calls d/rules) so the job server becomes > global. It is the easiest and most strightforward way. > > Now, when adding support for DEB_BUILD_OPTIONS's parallel=X suboption, > I always end up in either my packages building in just one thread > (because I still haven't figured how to pass environment variables to > sbuild for example), or I have to use a non-easy, much more verbose > way to run dpkg-buildpackage (setting DEB_BUILD_OPTIONS= instead of > just passing -j). Because DEB_BUILD_OPTIONS handling, at the end, > overrides -j somehow. > > The way how you proposed to fix your initial proposal -- add > "else\nNUMJOBS = 1" -- makes this obvious, -- no matter what -jX > is passed to the top-level, the build will be done according to > DEB_BUILD_OPTS (whenever it is set or unset). > > I asked about this several times on #irc but got no good answer. > And after some tries I ended up in what we have now, -- I just ignore > DEB_BUILD_OPTIONS, because I try to build the package much more > often than it is built on buildds, and I want the process to be > easiest for me not for machines, and I value my own time much more > than CPU time of debian buildd network (even of the slowest machines > in there). Ok. After looking around I found a recipe which I used in other packages to satisfy both those requiriments: # support parallel build using DEB_BUILD_OPTIONS=parallel=N ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) MAKEFLAGS += \ -j$(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) endif (which is quite similar to what the debian policy says), and it appears to work. So I've added the same to busybox d/rules and it at least continues to work with -jN, so I know that my way of doing things hasn't broke, which is good. Other related topics (how to pass DEB_BUILD_OPTIONS or anything else to sbuild, or how to make simple -j work together with this DEB_BUILD_OPTIONS in dh-style d/rules etc), while related, are not holding this bug in any way. 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#740464: Fwd: Bug#740464: qemu-kvm: support for seabios option "screen-and-debug"
I'm forwarding this to upstream, such enhancements, in my opinion, should not be done inside a single distribution, and since I don't use (and don't even know how to use) the mentioned features I can't further comment on this, and don't really want to become a broken phone. Thank you for the good analisys (in initial email and in a folllowup at http://bugs.debian.org/740464 ). BTW, this is not qemu-kvm, this is qemu. Qemu-kvm has been merged into qemu since version 1.3. Thanks, /mjt --- Original message Subject: Bug#740464: qemu-kvm: support for seabios option "screen-and-debug" Date: Sat, 01 Mar 2014 14:27:35 -0800 From: Matt Taggart Package: qemu-kvm Version: 1.7.0+dfsg-3 Severity: wishlist I am using seabios with sgabios in kvm (in order to get early BIOS messages on serial), and during the bootloader stage I am seeing all characters printed twice. I found this page http://www.coreboot.org/SeaBIOS#Adding_sgabios_support which explains the problem and that you can fix it by disabling the "screen-and-debug" config option. It also references this list of other config options http://www.coreboot.org/SeaBIOS#Other_Configuration_items Looking at the qemu-kvm source, I see that in hw/nvram/fw_cfg.c and qemu-options.hx there is support for changing a few of these, things like show-boot-menu, boot-menu-wait, splashfile. Could you please add support for enabling the "screen-and-debug" option? Also interesting from that list might be boot-menu-message boot-menu-key boot-fail-wait i(the others are either obscure or I don't know what they are for, so I don't know if they would be useful). Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734218: spice: Please support powerpcspe (and maybe other architectures)
05.03.2014 15:02, Petter Reinholdtsen wrote: > Where can I find the rationale for limiting the spice package to amd64 > and i386 only? I need it on arm to use it with my Raspberry Pi, and > fail to understand why the Debian package is missing there. http://www.spice-space.org/page/FAQ -- see the "Which architecture can spice run on" question. This is what upstream says. We may try to let it build on other arches, but not if this requires patches. Thanks, /mjt > According to https://admin.fedoraproject.org/pkgdb/acls/name/ >, > the package is built for armv7hl on Fedora, so the source seem to handle > it just fine. > http://koji.fedoraproject.org/koji/rpminfo?rpmID=4563258 > got > some patches, perhaps some of them are needed, but none of them seem arm > related? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689239: Re-enable rbd/rados support ?
07.03.2014 15:11, Gonéri Le Bouder wrote: > For your information, some weeks ago, I rebuilt qemu 1.7.0+dfsg-2~bpo70 > against ceph.com Wheezy backport. The packages are there: > http://people.debian.org/~goneri/debian/wheezy-backports/ > > We use them in my company without any issue. So I support Matthias > suggestion. I think it's now save to re-enable this feature in sid. The problem is not that qemu can't be used with rbd/rados. The problem is that debian ceph package is barely maintained. Just take a look at http://packages.qa.debian.org/c/ceph.html - the current version has been sitting in unstable for 64 days now, and no one bothered to take a look at the only new bug it introduced, which should be trivial to fix. It is the same situation we were at before, and it was the reason why the package has been removed from wheezy: some issues which need to be dealt with, and this state is going on forever. For example, if I'll enable cepth now in qemu for debian, qemu package will be stuck in unstable until cepth is fixed, because qemu will depend on librbd version >= 0.72 which is not in testing. But I really need to have ability to upload things much faster, to be able to fix real bugs in qemu people are hitting. I just can't afford to wait forever while debian ceph maintainer(s) -- who, as it seems, work in "fire and forget" mode, -- will perform next upload which - may be - will enable migration of qemu. Please note: the version of ceph which is currently in -testing is - almost - the same as has been removed from wheezy (just the debian release number - the last number in version string - has been updated by one). That to say: nothing has changed there since wheezy pre-release. > I can provide a patch if you want. The patch should uncomment just 2 lines in debian/control. That's not a problem at all, all the infrastructure is already here and we're just waiting for someone to actually maintain ceph in debian. I for one can't do that because I don't use cepth and don't know it, so don't understand from which side to come to 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#742730: image format processing issues: lack of input validation
Package: qemu, qemu-kvm Version: 1.1.2+dfsg-6 Severity: grave Tags: security patch upstream Several flaws were found in guest image format processing in qemu. CVEs are as follows: parallels: Sanity check for s->tracks (CVE-2014-0142) parallels: Fix catalog size integer overflow (CVE-2014-0143) qcow2: Check maximum L1 size in qcow2_snapshot_load_tmp() (CVE-2014-0143) qcow2: Fix L1 allocation size in qcow2_snapshot_load_tmp() (CVE-2014-0145) qcow2: Fix NULL dereference in qcow2_open() error path (CVE-2014-0146) block: Limit request size (CVE-2014-0143) dmg: prevent chunk buffer overflow (CVE-2014-0145) dmg: sanitize chunk length and sectorcount (CVE-2014-0145) qcow2: Fix new L1 table size check (CVE-2014-0143) qcow2: Avoid integer overflow in get_refcount (CVE-2014-0143) qcow2: Don't rely on free_cluster_index in alloc_refcount_block() (CVE-2014-0147) qcow2: Validate active L1 table offset and size (CVE-2014-0144) qcow2: Validate snapshot table offset/size (CVE-2014-0144) qcow2: Check refcount table size (CVE-2014-0144) qcow2: Check backing_file_offset (CVE-2014-0144) qcow2: Check header_length (CVE-2014-0144) curl: check data size before memcpy to local buffer. (CVE-2014-0144) vhdx: Bounds checking for block_size and logical_sector_size (CVE-2014-0148) vdi: add bounds checks for blocks_in_image and disk_size header fields (CVE-2014-0144) vpc: Validate block size (CVE-2014-0142) vpc/vhd: add bounds check for max_table_entries and block_size (CVE-2014-0144) bochs: Check extent_size header field (CVE-2014-0142) bochs: Check catalog_size header field (CVE-2014-0143) bochs: Use unsigned variables for offsets and sizes (CVE-2014-0147) block/cloop: refuse images with bogus offsets (CVE-2014-0144) block/cloop: refuse images with huge offsets arrays (CVE-2014-0144) block/cloop: prevent offsets_size integer overflow (CVE-2014-0143) block/cloop: validate block_size header field (CVE-2014-0144) Upstream patches: https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg04994.html Some of those issues affects wheezy and even squeeze versions of qemu and qemu-kvm packages, and needs quite some backporting work. 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#742910: src:qemu: Tanglu GNU/Linux support
Control: tag -1 + wontfix - patch 29.03.2014 01:28, Jon Severinsson wrote: > Package: src:qemu > Version: 1.7.0+dfsg-5 > Severity: wishlist > Tags: patch > > Please apply the attached patch adding support for the Tanglu GNU/Linux [1] > distribution. I don't think it is necessary, for several reasons. We added ubuntu because in there, qemu was different from debian, so now ubuntu has a different set of packages and conflicts/breaks, and that difference makes it very difficult to maintain as a change. In your case, the package should be the same as on debian, so there's no need to make a separate case for it. Just set the distribution field to the default "debian" and it will work fine as is, unless you want to divirge far from debian. In the latter case, it might be better idea to actually maintain it as a patch on your side locally, together with all the other changes. 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#743235: qemu: vm with multiple NICs do not start anymore: RAMBlock "blahblah.rom" already registered, abort!
31.03.2014 21:50, Udo Rader wrote: > Package: qemu > Version: 1.7.0+dfsg-2~bpo70+2 > Severity: important > Tags: upstream > > I have a vm with multiple NICs configured like this: > > > > > >function='0x0'/> > > > > > >function='0x0'/> > > > > > >function='0x0'/> > Can you please show the resulting qemu command line? I can't reproduce this here without libvirt, and I don't have libvirt right now. > trying to start this machine, I get > > Error starting domain: internal error: process exited while connecting to > monitor: RAMBlock "/rom@genroms/pxe-rtl8139.rom" already registered, abort! For me it Just Works... > This is probably related to this change: > > https://lists.nongnu.org/archive/html/qemu-devel/2014-03/msg02061.html > > Originally I had the virtio model for each device, but that did not change > anything. > > I can "fix" the issue by giving each NIC a different model. Thank you for the bugreport! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743235: qemu: vm with pc-0.11 machine and multiple NICs do not start anymore: RAMBlock "blahblah.rom" already registered, abort!
Control: tag -1 + confirmed Control: retitle -1 qemu: vm with pc-0.11 machine and multiple NICs do not start anymore: RAMBlock "blahblah.rom" already registered, abort! 31.03.2014 23:00, Udo Rader wrote: > On 03/31/2014 08:37 PM, Michael Tokarev wrote: >> Can you please show the resulting qemu command line? > > hmm, not sure what my MTA and the bugtracker will make out of this line, > but lets try :) That's very much enough.. > qemu-system-x86_64 -enable-kvm -name sulis -S -machine > pc-0.11,accel=kvm,usb=off -cpu This is it. -machine pc-0.11 does this. -machine pc-0.12 does not. So something broke in 1.7 for very old machine types. I'll try to envestigate. But please note that support of such very old machine types is of low priority. Please try to migrate to some current machine type. 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#740901: qemu-ppc-static: Invalid instruction
Control: tag -1 + confirmed Control: found -1 2.0.0~rc1+dfsg-1exp 06.03.2014 04:35, Christoph Biedl wrote: > Package: qemu-user-static > Version: 1.7.0+dfsg-3 > Severity: normal > > Dear Maintainer, > > this seems to be different from #731082 but I might be wrong. Yes it is. > My scripts that create a foreign chroot call ssh-keygen rather at the > end of that process, and that one triggers an "Invalid instruction" > > How to repeat: > > Create a foreign wheezy chroot for powerpc at /tmp/chroot, make sure > the openssh-client is installed there, copy/link > /usr/bin/qemu-ppc-static into the chroot, then run: > > # chroot /tmp/chroot/ /usr/bin/qemu-ppc-static /usr/bin/ssh-keygen > > Output: > > Invalid instruction > NIP 6fe34874 LR 6fe34c78 CTR 6fc59508 XER ... > FPR28 > FPSCR > Generating public/privat > (...) > > Quite a surprise, the program continues to run and seems to do the > right thing. So it might be just a visual thing, severity left at > normal. Yeah. The same happens with 2.0.0-rc1. Tagging the bugreport for now. 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#660663: qemu-system-ppc -cpu 7455 doesn't start
Control: found -1 2.0.0~rc1+dfsg-1exp Control: severity -1 minor Control: tag -1 + upstream This bugreport has been here for quite some time, and it is still valid for current version of qemu (which is 2.0-tobe). Yes, qemu does not work for this cpu type (-cpu 7455), but it works just fine for some other, similar, cpu types. Here's what the ppc qemu maintainer says about this issue: iirc the problem with 7455 is that it has a soft-tlb mmu model by default and we'd probably have to switch it over into htab mode in openbios or so no os I'm aware of uses the soft-tlb mode anyways but why bother? just use -cpu G4 and be happy :) Or better yet, just use kvm mode, which automatically enables -cpu host. Please note that using the same cpu type as on your host, but at the same time running in TCG (emulation, non-kvm) mode, does NOT make the guest faster. The cpu is emulated anyway, and in this mode, it is easier and faster to emulate simpler cpu with simpler instructions.. So choosing host cpu in TCG mode makes no real sense. I'm lowering the severity of this bug, because it is trivial to work around 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#740901: qemu-ppc-static: Invalid instruction
05.04.2014 22:18, Michael Tokarev wrote: > 06.03.2014 04:35, Christoph Biedl wrote: [] >> # chroot /tmp/chroot/ /usr/bin/qemu-ppc-static /usr/bin/ssh-keygen >> >> Output: >> >> Invalid instruction >> NIP 6fe34874 LR 6fe34c78 CTR 6fc59508 XER > ... >> FPR28 >> FPSCR >> Generating public/privat >> (...) >> >> Quite a surprise, the program continues to run and seems to do the >> right thing. So it might be just a visual thing, severity left at >> normal. Actually this is not a bug per se. ssh-keygen runs two instructions: fcfid f1,f1 and vor v0,v0,v0 First is only available in ppc64 (64bit) mode, and qemu-ppc64 does not complain on it. Yet the 32bit ssh-keygen somehow tries it. The second is from altivec set, which qemu does not implement. Apparently what happens here is - ssh-keygen tries some specialized instructions and will use them if available. And if not, it will fall back to some software implementation. qemu just reports that it does not know the instruction it were asked to run, and generates a trap just like a real CPU will do. The difference with real CPU is that the CPU is silent in this case, it does nothing besides generating the trap. But qemu _also_ produces this quite scary message, because more often this happens when qemu actually misses some instruction which it _should_ implement, and from this message it can be decoded and necessary implementation added. The only possible complain to the qemu side is this extra output which it produces. Besides that, the rest works the way it should work. Thanks, /mjt > > Yeah. The same happens with 2.0.0-rc1. > > Tagging the bugreport for now. > > 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#745935: qemu-sparc32plus-static: segfault loop while trying to set up sparc foreign chroot
Control: tag -1 + confirmed upstream Control: found -1 2.0.0+dfsg-1 26.04.2014 20:00, Christoph Biedl wrote: > Package: qemu-user-static > Version: 1.7.0+dfsg-9 > Severity: normal > > Dear Maintainer, > > while trying to set up a foreign chroot for sparc, loosely based in > the instructions found for armel[0], I encountered a hang while > starting second stage. > > How to repeat: > > # mkdir /tmp/dest > # debootstrap --variant=buildd --include=fakeroot,build-essential \ > --arch=sparc --foreign sid /tmp/dest http://ftp.de.debian.org/debian > # cp -p /usr/bin/qemu-sparc32plus-static /tmp/dest/usr/bin/ > # chroot /tmp/dest ./debootstrap/debootstrap --second-stage > qemu: Unsupported syscall: 210 This syscall is madvise64_64 which is not implemented by qemu indeed but should not affect anything, as it is only a hint for the memory management. > ... then debootstrap hangs while eating 100% CPU. Running strace on > that process shows That's what I can confirm here as well. At least it is a huge improvement compared with the wheezy version of qemu-user[-static] which can't run even bash alone. Tagging as confirmed+upstream, but please don't expect high activity on this bug. This is something that needs to be addressed upstream. 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#745490: qemu-system-x86: Guests fail to start with Linunz 3.13 (3.12 is fine)
Control: severity -1 normal Not replying to questions helps. Since no one uses 32bit kernels with kvm nowadays, and since it looks like the bugreport is misfiled anyway, downgrading severity from grave to normal. 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#746467: pixz creates new file with default permissions and does not preserve permissions
Package: pixz Version: 1.0.2-2 Severity: important Tags: security upstream When pixz creates a file for the result of (de)compression, it uses default umask, so file gets created with, say, 0644 permissions. Even if the original file we're about to (de)compress has stricter permissions. This way, the data can be read by others during whole (de)compression process, which, depending on the size of the input, can be quite slow/long. $ ls -l data -rw-r- 1 mjt mjt 8589942784 Apr 30 13:50 data $ pixz data & $ ls -l data.xz -rw-r--r-- 1 mjt mjt 135106560 Apr 30 13:52 data.xz It is even more than this: the permissions are never restored even after the process is completed. The final data.xz has the same 0644 permissions as the temp file: $ wait; ls -l data.xz -rw-r--r-- 1 mjt mjt 725922432 Apr 30 13:55 data.xz So the file stays with wide-open permissions, unlike the original. Other compressors - gzip, xz, etc - tries to preserve the permissions, and tries to keep the new/temp file (during compression) unreadable. That's why user does not expect the new file created by pixz to have wider permissions than its original. (It looks like pixz does not preserve any attributes, including the date, and it also looks like it modifies mtime of the _source_ file too). -- 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
01.05.2014 04:36, Dmitry Smirnov wrote: > On Tue, 22 Apr 2014 14:32:30 Michael Tokarev wrote: >> I think that's all what needed, I will re-enable rbd/ceph on the next qemu >> upload. > > We're waiting for this functionality so eagerly but apparently it is still > absent in (just uploaded) qemu_2.0.0+dfsg-4. Is there are any problems? We've several security issues and regressions in -testing and I really want them to be fixed first. The last upload fixes a bug which prevented qemu from migrating to -testing (which I overlooked because I was busy with family stuff -- perhaps pts should have a service to notify about stalled migrations?) I didn't forget about rdb. Please believe me, it is _very_ difficult to forget about it after all this story. I'm just afraid of something else popping up from its side, or elsewhere - as you can see, qemu is having lots of small issues recently which constantly prevents it from migrating in time. And I have real users with issues (like virtio-scsi bug with windows64 in 1.7.1 and 2.0 for which there's a band-aid included in 2.0 debian package) who are waiting for things to appear in -bpo. It will be enabled, like a few other things (new libcacard packages for example, which I also was holding for too long - needed for spice and other things too). Please give me some time for the dust after 2.0 to settle. 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#671735: qemu-kvm: 1.0 regression: Certain x86_32 guests crash after migration
31.07.2012 10:19, Christoph Biedl wrote: > Michael Tokarev wrote... [] >> But first, can you please try the new 1.1 version of qemu-kvm (currently >> in sid), whenever it shows the same issue too (please be aware about a >> new bug in 1.1, http://bugs.debian.org/679788, which should be easy to >> work around). If it still present, I'll try to work with your kernel >> config and see what's the problem (I don't have lots of hw power currently >> for kernel compiles, and for migration too -- so I'll try migrating on a >> single host between two kvm instances -- does this way shows the problem >> too -- provided libvirt supports it to start with?). > > I will give that a try when time permits, this might take a few days. Hello again. It's been about 2 years since this bugreport. Were you able to get your hands on this migration problem? Is it still present in wheezy version? Or in current jessie or sid version? 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#744829: libssh2-1-dev: newer gcrypt
Now once libssh2 which build-depends on new gcrypt hit the archive, other programs which use it but also use gnutls (but not _new_ gnutls yet) become unbuildable. https://buildd.debian.org/status/package.php?p=qemu Dependency installability problem for qemu on armel and sparc: qemu build-depends on: - libssh2-1-dev libssh2-1-dev depends on: - libgcrypt20-dev qemu build-depends on: - libgnutls-dev libgnutls-dev depends on: - libgcrypt11-dev (>= 1.4.0) libgcrypt20-dev conflicts with: - --virtual-libgcrypt-dev So we've some fun transitions happening now.. ;) I think that for qemu I can easily disable libssh2 support for now, while the dust settles, because for qemu it really is of very low priority. For other packages it might not be that easy. Oh well... (See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748535#35 ) 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#749062: mdadm: add "containers" to emergency config file
23.05.2014 19:03, Miquel van Smoorenburg wrote: > If no mdadm.conf file is found in initramfs, the local-top mdadm script will > create one on the fly like this: > > echo DEVICE partitions > $CONFIG > $MDADM --examine --scan >> $CONFIG > > However, this config will fail to assemble Intel RAID (imsm) arrays, since > those are "containers" and that needs to be explicitly added to the DEVICE > line. > > Also, from the manpage: > > If no DEVICE line is present, then "DEVICE partitions contain- > ers" is assumed. > > So please add "containers" to the DEVICE line or just leave out the DEVICE > line completely. I think we should just omit this line entirely and rely on mdadm defaults. Maybe add it as a 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#749331: spice: Stop building spicec, it's obsolete and superseded by remote-viewer (part of virt-viewer)
Control: tag -1 pending 26.05.2014 16:57, Fabio Fantoni wrote: > Source: spice > Severity: normal > > I saw that obsolete spicec is still in latest spice packages (0.12.5-1). > I think can be good remove it. Yes it should be good to remove it, AND I planned to remove it, just not right now. It's been in the debian package for quite some time, and there's nothing bad if it'll be there for some more time. I don't plan to push it to jessie release. 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#743628: Jessie freezes sometimes when run in a virtual machine.
I'm sorry to say that, but when you suspend the host, unsuspecting guests just aren't prepared for the timers to stop. This is something which should not be done. 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#743628: Jessie freezes sometimes when run in a virtual machine.
Control: tag -1 + wontfix 29.05.2014 23:18, Michael Tokarev wrote: > I'm sorry to say that, but when you suspend the host, > unsuspecting guests just aren't prepared for the timers > to stop. This is something which should not be done. I'll mark it as wontfix for now, due to the above, because there's not much really we can do here and this bugreport will always pop up in my regular qemu bugfixing. 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#749950: qemu-utils: performance inferior than older version
Control: tag -1 + moreinfo 31.05.2014 02:23, Ernesto wrote: > Package: qemu-utils > Version: 2.0.0+dfsg-4+b1 > Severity: normal > > Dear Maintainer, > > I use qemu-nbd to mount a ext4 filesystem from a virtual disk image which is > stored in an NTFS partition. I have more space in the NTFS partition than in > my native-linux ones, but I need ext4, so this is a good solution. > > I use the virtual disk to compile source code, which grows up to 8-9 GB. I > mount it with: > > modprobe nbd && qemu-nbd -c /dev/nbd0 /path_to_image/trunk.qcow2 && mount > /dev/nbd0 /path_to_mountpoint/mnt/ > > I used to have this setup on a Wheezy system, and its performance was very > good. Now, I upgraded to Jessie, and the same setup performs poorly. I ran > iozone disk benchmark on both systems, several times, over the ext4 > filesystem in the virtual disk: I already told you that what you use makes very little sense. Now with this setup, you have at least 2 main components involved: the kernel and qemu-nbd. If you want this bugreport to go _anywhere_ instead of just being ignored, please try keeping one of the 2 components the same and changing another. I mean, run wheezy kernel and qemu-nbd ver. 2.0 and see how it performs - this keeps kernel unchanged but changes qemu-nbd. Run jessie kernel and try two versions of qemu-nbd - this will keep kernel unchanged at other version but changes qemu-nbd. If, when running the same kernel, by changing qemu-nbd you can reproduce the slowdown, in both cases, it will mean it's something in qemu-nbd. If speed drops when you change kernel, it must be kernel. Or just get life and get a real setup instead of spending more time on this. 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#751078: qemu-system-x86: "No bootable device." with option "-machine type=q35"
Control: retitle -1 legacy -cdrom/-hda options does not work with q35 Control: severity -1 wishlist Control: tag -1 + upstream confirmed 10.06.2014 09:16, Thomas wrote: > Package: qemu-system-x86 > Version: 2.0.0+dfsg-6 > Severity: normal > > Dear Maintainer, > > I want to use the Q35 qemu platform for my virtual machines. > > I start qemu with the following command line: > vimaowner@osprey:~$ qemu-system-x86_64 -enable-kvm -machine type=q35 \ > -cpu kvm32 -m 512 -balloon none -hda virtuals/fai/fai_root.img -cdrom \ > cdroms/grml96-full_2014.03.iso -boot order=d -name fai -vga qxl -spice \ > port=5900,addr=localhost,disable-ticketing -monitor stdio With q35 machine type you have to use the "real" syntax. The above -cdrom and -hda becomes: -drive file=virtuals/fai/fai_root.img,id=d0,if=none -device ide-drive,drive=d0 -drive file=cdroms/grml96-full_2014.03.iso,id=c0,media=cdrom,if=none -device ide-cd,drive=c0 It is just the legacy shortcuts -hda and -cdrom doesn't work. Just like the expansion of these options (as documented in the manpage). This is an upstream issue. And I'm not sure upstream is very interested in fixing it. Retitling and lowering severity accordingly. 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#751376: qemu-system-x86: usb2.txt not included
Control: severity -1 wishlist Control: retitle -1 docs are not easy to find 12.06.2014 12:48, Michal Suchanek wrote: Package: qemu-system-x86 Version: 2.0.0+dfsg-6 Severity: normal Hello, qemu git includes docs/usb2.txt which the debian packages d not seem to package. Actually _all_ available documentation is shipped. The problem is that it is shipped in the "main" metapackage named "qemu", which also pulls _whole_ qemu. And these docs can be found in /usr/share/qemu. The problem is that I don't really know what to do with the docs. These docs are not a property of qemu-system-x86 package, because other qemu-system-* packages equally needs them, and shipping them in every subpackage is wrong. I can move at least qemu-system-specific docs to qemu-system-common, but this way, it will be difficult to find, because the docs will be in /usr/doc/qemu-system-common/ while you maybe be more expecting to find them in /usr/doc/qemu-system-x86/ - the package you're working with. Other docs are qemu-user-specific, but we have 2 of them - qemu-user and qemu-user-static, and again, adding docs to both is wrong, and there's no "common" package for qemu-user. On another side, in upstrem docs/ directory (in the source) there's no clear separation of what's system docs, what's user docs and what is other stuff (like programming docs or just overview). So any attempt to split them up is, well, at least difficult. Especially having in mind the docs are being shipped in the qemu metapackage currently (and that's the case since the beginning), so we'll have to "stole" these files from qemu package. That to say - I understand full well that current situation with documentation in qemu packaging is very bad. But I don't really know how to improve it. Suggestions welcome :) 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#747417: pkg-config --libs libssh2 exposes build ldflags
Package: libssh2-1-dev Version: 1.4.2-1.1 Severity: normal $ pkg-config --libs libssh2 -Wl,-z,relro -lssh2 -lgcrypt It should not list -Wl,-z,relro 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#747417: pkg-config --libs libssh2 exposes build ldflags
08.05.2014 16:36, Michael Tokarev wrote: > Package: libssh2-1-dev > Version: 1.4.2-1.1 > Severity: normal > > $ pkg-config --libs libssh2 > -Wl,-z,relro -lssh2 -lgcrypt > > It should not list -Wl,-z,relro here. And it should not list -lgrcypt here too, it should go to libs.private instead. 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#747636: qemu: when using -smb parameter does not startup smbd
10.05.2014 20:25, Michael Meier wrote: > Package: qemu > Version: 2.0.0+dfsg-4 > Severity: normal > > When using the -smb parameter, qemu does not start up the smbd service. > it creates the necessary config file in the /tmp/ folder though. Please try to browse \\10.0.2.4\ from windows with your command line, and see if any additional files will be created in that temp folder. > If I start it up by hand: > smbd -s /tmp/qemu-smb.19409-0$/smb.conf > smbd gets started up correctly and i can access it from the virtual machine > using: > \\10.0.2.2\qemu (not 10.0.2.4) 10.0.2.2 is redirected to host. So if you start qemu manually on the host, sure thing it will be available as 10.0.2.2. Only 10.0.2.4 (by default) is redirected to qemu-started smbd. > the command used to start up qemu is (generated by aqemu): > /usr/bin/kvm -monitor stdio -soundhw ac97 -k es -vga std -enable-kvm -m 2048 > -localtime -snapshot -drive file="/home/rmm/data/Virtual > Machines/windows-7-x64.qcow2",if=virtio -boot once=c,menu=off -net > nic,vlan=0,model=virtio -net > user,vlan=0,smb=/home/rmm/data/tmp,smbserver=10.0.2.4 -name "Windows 7 x64" Ok. > not using kvm doesn't make any difference, also giving a fixed ip to the smb > parameter (host). does not make any difference. >From the virtual machine I can't ping 10.0.2.4 (the default ip it should use) >so I guess this virtual nic never gets created? No, 10.0.2.4 does not support ping. Only samba ports (139 and 443) are redirected, not ICMP. What version of samba do you use? 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#747703: bpo60 vlc should not pull samba4 from bpo too
Source: vlc Version: 2.1.2-2~bpo70+2 Severity: serious Backport of vlc to wheezy uses libsmbclient from samba4, which means that when installing vlc on a wheezy system, whole samba suite has to be upgraded too if samba is installed. This is because vlc runtime-depends on libsmbclient >= the one it was built against, but samba, due to its nature, requires exact version of libsmbclient. So, in particular, samba3 requires libsmbclient from samba3. So when installing vlc, it automatically upgrades libsmbclient, which triggers upgrading whole samba. But upgrading samba from version 3 to version 4 is a major step, and should not be pefrormed as a side-step of some unrelated software. It is more: vlc ises jut a "tiny bit" of samba, yet pulls whole new major version of it. I see the changelog entry in vlc: 2.1.2-2~bpo70+1: Tighten build dependencies on gettext, libsmbclient (for pkg-config file) and libav9 I see there's no pkg-config file in version of libsmbclient-dev in wheezy, but since I don't know vlc sources and build process much I don't know how difficult it will be to build vlc with wheezy version of libsmbclient. Please consider doing so and allowing using samba from wheezy together with vlc from bpo. 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#747636: qemu: when using -smb parameter does not startup smbd
Control: retitle -1 samba4 does not work with qemu -smb Control: found -1 1.1.2+dfsg-1 Control: tag -1 + confirmed upstream After some digging around it turns out that the problem is the different interface used by samba4. With samba3 everything works fine. It looks like samba4 does not work in "inetd" mode anymore, and this mode was the way how samba3 was used by qemu. The way qemu used samba has been implemented a very long time ago, so the same "bug" applies to older versions of qemu too. Retitling as such. But if adopting to samba4 changes requires major changes on qemu side, I'm afraid this problem wont be fixed soon. 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#747703: bpo60 vlc should not pull samba4 from bpo too
11.05.2014 13:04, Michael Tokarev wrote: > Backport of vlc to wheezy uses libsmbclient from samba4, which > means that when installing vlc on a wheezy system, whole samba > suite has to be upgraded too if samba is installed. ... > I see the changelog entry in vlc: > > 2.1.2-2~bpo70+1: > Tighten build dependencies on gettext, libsmbclient (for pkg-config > file) and libav9 It looks like just adding SMBCLIENT_CFLAGS=" " SMBCLIENT_LIBS=-lsmbclient environment variables to ./configure invocation fixes this issue. (SMBCLIENT_CFLAGS should not be empty or else it won't be recognized). Indeed, in wheezy libsmbclient-dev there was no .pc file for pkg-config, and samba4 configure switched to using pkg-config to detect libsmbclient. So there are 2 possible solutions for this issue: 1) add the above hack (which works for both 3 and 4 versions of libsmbclient), and 2) modify configure.ac to include previous test for libsmbclient, as found in vlc-2.0. Note that 2) requires automake-1.4 to be available at build time (which is not in wheezy). Debdiff for case 1 is below. Thanks, /mjt --- +vlc (2.1.2-2~bpo70+3) wheezy-backports; urgency=low + + * lessen versioned build dependency on libsmbclient. + + -- Michael Tokarev Sun, 11 May 2014 16:18:18 +0400 + vlc (2.1.2-2~bpo70+2) wheezy-backports; urgency=low * No change rebuild. diff -Nru vlc-2.1.2/debian/control vlc-2.1.2/debian/control --- vlc-2.1.2/debian/control2014-01-24 05:15:42.0 +0400 +++ vlc-2.1.2/debian/control2014-05-11 16:18:17.0 +0400 @@ -77,7 +77,7 @@ libsdl1.2-dev (>= 1.2.10), libshout3-dev, libsidplay2-dev, - libsmbclient-dev (>= 2:3.6.19), + libsmbclient-dev, libspeex-dev (>= 1.0.5), libspeexdsp-dev (>= 1.0.5), libssh2-1-dev, diff -Nru vlc-2.1.2/debian/rules vlc-2.1.2/debian/rules --- vlc-2.1.2/debian/rules 2014-01-11 18:21:03.0 +0400 +++ vlc-2.1.2/debian/rules 2014-05-11 16:18:09.0 +0400 @@ -240,7 +240,7 @@ dh_auto_clean override_dh_auto_configure: - dh_auto_configure -- $(confflags) + SMBCLIENT_CFLAGS=" " SMBCLIENT_LIBS=-lsmbclient dh_auto_configure -- $(confflags) override_dh_auto_test: ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747703: bpo60 vlc should not pull samba4 from bpo too
11.05.2014 16:21, Michael Tokarev wrote: [] > It looks like just adding > > SMBCLIENT_CFLAGS=" " SMBCLIENT_LIBS=-lsmbclient > > environment variables to ./configure invocation fixes this issue. > (SMBCLIENT_CFLAGS should not be empty or else it won't be recognized). http://www.corpit.ru/debian/tls/vlc/ , and in particular, http://www.corpit.ru/debian/tls/vlc/vlc_2.1.2-2~bpo70+3.debdiff I can just upload it now. (Tested and it works). 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#635999: qemu architectures are now split in separate packages
Control: tag -1 + wontfix Tagging as wontfix. I really see a reason to split qemu-user packages into parts. Disk space is cheap, and there aren't any further dependencies, and you get whole thing without much thinking which one do you need (which, with many similar arches like -arm -armel etc, may become a real question). 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#747927: qemu-utils: qemu-nbd blocks
Control: reassign -1 linux-image-3.13-1-amd64 3.13.10-1 Your qemu-nbd process blocks in kernel mode, apparently while trying to do some ext4 operation (and from your description I don't see what's going on: you said qemu-nbd just exports an image with ext4 fs, it should not do cause any ext4 calls itself). This is something we can't do anything with in userspace, it is a kernel problem. Maybe it is something to do with the way you mount ntfs (fuse?). Reassigning to linux-image. But overall, what you do does not look sane. It is just too many (complex) levels of indirection for a task which requires streamlined operations. So I'd suggest to find a more clean way to do what you want (maybe shrinking windows partition a bit and create a new linux partition for your compiles; maybe avoiding qemu-nbd and whole nbd layer and using a loop device instead (avoids extra kernel=>user=> kernel trip), maybe something else). Thanks, /mjt 13.05.2014 06:42, Ernesto wrote: > Package: qemu-utils > Version: 2.0.0+dfsg-4 > Severity: normal > > Dear Maintainer, > > I use qemu-nbd to mount a ext4 filesystem from a virtual disk image which is > stored in an NTFS partition. I have more space in the NTFS partition than in > my native-linux ones, but I need ext4, so this is a good solution. > > I use the virtual disk to compile source code, which grows up to 8-9 GB. I > mount it with: > > modprobe nbd && qemu-nbd -c /dev/nbd0 /path_to_image/trunk.qcow2 && mount > /dev/nbd0 /path_to_mountpoint/mnt/ > > Now I often find out the compilation hangs. I can kill the processes, but > then I can't do ls. When I try to detach with: > > qemu-nbd -d /dev/nbd0 > > also get a console blocked. > > The system's performance feels degraded, and I have to shut down the system > by cutting power. > > I get this on dmesg: > > [44918.309453] INFO: task qemu-nbd:29898 blocked for more than 120 seconds. > [44918.309458] Tainted: G O 3.13-1-amd64 #1 > [44918.309459] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [44918.309460] qemu-nbdD 88010679d350 0 29898 1 > 0x > [44918.309463] 88010679d010 0082 00014280 > 00014280 > [44918.309465] 880107ce5fd8 88010679d010 88019fad4ac8 > 88019fdc0068 > [44918.309467] 0002 811a7520 880107ce55b0 > > [44918.309469] Call Trace: > [44918.309475] [] ? generic_block_bmap+0x50/0x50 > [44918.309479] [] ? io_schedule+0x94/0x130 > [44918.309481] [] ? sleep_on_buffer+0x5/0x10 > [44918.309483] [] ? __wait_on_bit+0x54/0x80 > [44918.309485] [] ? generic_block_bmap+0x50/0x50 > [44918.309487] [] ? out_of_line_wait_on_bit+0x72/0x80 > [44918.309490] [] ? autoremove_wake_function+0x30/0x30 > [44918.309511] [] ? ext4_wait_block_bitmap+0xc0/0xd0 [ext4] > [44918.309518] [] ? ext4_mb_init_cache+0x20e/0x6e0 [ext4] > [44918.309524] [] ? ext4_mb_load_buddy+0x2ce/0x360 [ext4] > [44918.309530] [] ? > ext4_discard_preallocations+0x1e8/0x450 [ext4] > [44918.309539] [] ? ext4_clear_inode+0x21/0x80 [ext4] > [44918.309541] [] ? evict+0xa3/0x190 > [44918.309544] [] ? dispose_list+0x31/0x40 > [44918.309546] [] ? prune_icache_sb+0x3f/0x50 > [44918.309548] [] ? super_cache_scan+0xea/0x150 > [44918.309551] [] ? shrink_slab+0x1b6/0x350 > [44918.309554] [] ? do_try_to_free_pages+0x3fd/0x550 > [44918.309556] [] ? try_to_free_pages+0xe8/0x170 > [44918.309559] [] ? __alloc_pages_nodemask+0x684/0x9d0 > [44918.309562] [] ? alloc_pages_current+0x97/0x150 > [44918.309565] [] ? sock_alloc_send_pskb+0x1fa/0x3b0 > [44918.309567] [] ? __wake_up_sync_key+0x38/0x60 > [44918.309569] [] ? unix_stream_sendmsg+0x263/0x3e0 > [44918.309571] [] ? sock_sendmsg+0x86/0xc0 > [44918.309573] [] ? poll_select_copy_remaining+0x130/0x130 > [44918.309575] [] ? poll_select_copy_remaining+0x130/0x130 > [44918.309577] [] ? ___sys_sendmsg+0x3c3/0x3d0 > [44918.309579] [] ? wake_futex+0x55/0x70 > [44918.309581] [] ? futex_wake+0x1a7/0x1d0 > [44918.309583] [] ? do_futex+0x116/0xd10 > [44918.309585] [] ? fsnotify+0x24e/0x330 > [44918.309588] [] ? eventfd_ctx_read+0x55/0x210 > [44918.309590] [] ? __sys_sendmsg+0x39/0x70 > [44918.309592] [] ? system_call_fastpath+0x16/0x1b > [44918.309594] INFO: task jbd2/nbd0-8:1138 blocked for more than 120 seconds. > [44918.309596] Tainted: G O 3.13-1-amd64 #1 > [44918.309596] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [44918.309597] jbd2/nbd0-8 D 880141c05350 0 1138 2 > 0x > [44918.309599] 880141c05010 0046 00014280 > 00014280 > [44918.309601] 880144eb1fd8 880141c05010 88019fad4ac8 > 88019fdb4068 > [44918.309602] 0002 811a7520 880144eb1c80 > 8801023adb80 > [44918.309604] Call Trace: > [44918.309606] [] ? generic_block_bmap+0x50/0x50 > [44918.309608] [] ? io_schedule+0x94/
Bug#748043: qemu-user-static: qemu-arm-static bug in signal handling avoids using mono
Control: tag -1 - patch Control: forwarded -1 https://bugs.launchpad.net/qemu/+bug/1319100 13.05.2014 19:31, Manuel Traut wrote: > Package: qemu-user-static > Version: 2.0.0+dfsg-4 > Severity: normal > Tags: upstream patch > > Dear Maintainer, > > running mono in a chroot environment with qemu-user-static is not posible > because at least one signal used during termination of mono is routed to the > host. Oh ma. Yes, mono is a very problematic thing, just like java. Almost anything java- or mono-related in qemu-user breaks in pieces because of significant usage of threads on these platforms, while qemu-user lacks correct thread implementation. Signals are also racy, especially when combined with threads. The patch you referred to is a gross hack, so I'm untagging "patch", -- it is something which should not be used really (tho, it is a good question -- whenever to ship working but bad or non-working but bad packages). So I'm not really sure what to do here. I for one don't know any (good) solution to this. 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#742730: image format processing issues: lack of input validation
Control: reopen -1 There are 2 more CVEs assigned to new issues found in qcow1 format processing. Since there's the same set of isssues, and since the relevant bug has only been closed for -testing anyway (and needs backporting to -stable and even maybe -oldstable), I'm adding them here. CVE-2014-0222 Qemu: qcow1: Validate L2 table size Too large L2 table sizes cause unbounded allocations. Images actually created by qemu-img only have 512 byte or 4k L2 tables. To keep things consistent with cluster sizes, allow ranges between 512 bytes and 64k (in fact, down to 1 entry = 8 bytes is technically working, but L2 table sizes smaller than a cluster don't make a lot of sense). This also means that the number of bytes on the virtual disk that are described by the same L2 table is limited to at most 8k * 64k or 2^29, preventively avoiding any integer overflows. https://lists.gnu.org/archive/html/qemu-devel/2014-05/msg02155.html CVE-2014-0223 Qemu: qcow1: Validate image size A huge image size could cause s->l1_size to overflow. Make sure that images never require a L1 table larger than what fits in s->l1_size. This cannot only cause unbounded allocations, but also the allocation of a too small L1 table, resulting in out-of-bounds array accesses (both reads and writes). https://lists.gnu.org/archive/html/qemu-devel/2014-05/msg02156.html This is qcow1, which is old qemu image format which is very rarely used nowadays (if at all), but we have other exotic formats in this bug too. So, with this in place, proposed patches for wheezy needs to be reworked, adding the new fixes. 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
I uploaded a new qemu package to unstable yesterday, it enables rbd support again. However, since it contains one new package (unrelated), it went to a NEW queue, so expect some more delay while this queue is processed. 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#739589: qemu: Multiple security issues
Adding more issues to the same bugreport. CVE-2014-3461 http://article.gmane.org/gmane.comp.emulators.qemu/272322 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#741494: qemu-system-x86 has a file conflict with ovmf
13.03.2014 05:32, Christoph Anton Mitterer wrote: > Package: qemu-system-x86 > Version: 1.7.0+dfsg-4 > Severity: grave > Justification: renders package unusable > > > Hey there. > > Unpacking qemu-system-x86 (1.7.0+dfsg-4) over (1.7.0+dfsg-3) ... > dpkg: error processing archive > /var/cache/apt/archives/qemu-system-x86_1.7.0+dfsg-4_amd64.deb (--unpack): > trying to overwrite '/usr/share/qemu/OVMF.fd', which is also in package ovmf > 0~20131112.2590861a-2 Sigh. This is the link to ovmf firmware which were initially added to qemu (not by me) but later we decided to move it to ovmf, and I forgot to remove it from qemu. But I don't want to re-upload this package just to remove this symlink. Note that the package stays prefectly usable, it only conflicts with ovmf (which means guest uefi support does not work). 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#741873: qemu-kvm: crashes booting gnumach (Hurd) with multiboot options
16.03.2014 23:24, Gabriele Giacone wrote: > Package: qemu-kvm > Version: 1.1.2+dfsg-6 > Severity: important > Tags: wheezy > Control: fixed -1 1.7.0+dfsg-3 > > [ jessie machine with qemu packages from wheezy ] Hello. Thank you for the bugreport. It is always nice when the bug is submitted in already-fixed form. But I'm not really sure what to do with it. Maybe it is possible to find the necessary change which fixed the issue in later versions and backport it to wheezy -- is that what you have in mind? We'll have to explain to the release team that this change is safe and is important to have in wheezy in this case. Please note that this looks to me like a very specific use-case, which can, hopefully (with my lack of knowlege about gnumach), be worked around using different booting method. Can you please elaborate a bit what do you have in mind and expect from the maintainer to do? 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#741873: qemu-kvm: crashes booting gnumach (Hurd) with multiboot options
19.03.2014 06:17, Gabriele Giacone wrote: [] > Current qemu on wheezy (1.1.2) can boot hurd CD only on systems with > hwaccel and by specifying --enable-kvm. it crashes without hwaccel, > see [0]. Not a real problem on jenkins.d.n which has hwaccel, but IMHO > [0] is important enough to get an upload to stable, it makes > installing a hurd VM on a wheezy host hardware dependent. > Whereas this bug affects Debian infrastructure, assuming d.n as part > of Debian infrastructure and assuming that would count something if it > was d.o. Please note that without hwaccel, it is just tooo slow to be useful. In my opinion anyway. This hardware dependency only means x86 (because on other arches we'll have to emulate the CPU anyway, and a. this bug will show up, and b. it will be painfully slow due to emulation), but x86 is the majority of debian machines these days. Other than that, -- it is difficult to find real (non-trash) x86 machine without hwaccel. Almost all machines without svn/vmx are just too old and slow to be useful. > How about identifying changes to backport fixing this bug and > proposing both to release team? > [0] https://bugs.debian.org/719633 Here's the fix, which is rather simple (and is included into upstream 1.7.1 stable release): http://git.qemu.org/?p=qemu.git;a=commitdiff;h=33dfdb56f2f3c8686d218395b871ec12fd5bf30b However, if we're to made a new stable release, I'd like to include quite some more changes too, which are useful for other users. Not that right now I have time for 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#741873: qemu-kvm: crashes booting gnumach (Hurd) with multiboot options
23.03.2014 03:55, Gabriele Giacone wrote: > Bisected. It works fine on wheezy. > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4de6467cbc8f3ddff7f2dcb63f427b0e92de0e9d Ok, thank you! > I'll file a SPU with both #719633 and #741873 patches. > Michael, if you have other changes, integrate. Unfortunately, due to some family issues, I don't have any time these days for anything, so I can'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#742386: wheezy-pu: package qemu/1.1.2+dfsg-6a+deb7u1
23.03.2014 05:31, Gabriele Giacone wrote: > > Package: release.debian.org > Severity: normal > Tags: wheezy > User: release.debian@packages.debian.org > Usertags: pu > > Hello, > this upload would fix two bugs with severity important regarding booting > GNU/Hurd machines. Please note that the same changes should be done for qemu-kvm package on wheezy. Also note that the names of patches does not reflect reality. These are fixing real bugs in qemu, not hurd-specific 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#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 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 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 +Date: Wed Dec 5 13:31:30 2012 -0500 +Bug-Debian: http://bugs.de
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 (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 . 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 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)
, mdmon should be in the initramfs too, because else, say, ext4 journal 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
Bug#699134: /usr/bin/qemu-system-x86_64: can not detect hdd images (-drive) with unprivleged users
28.01.2013 04:09, skeksix wrote: Please, can you close this bug report? I am sorry with my lser bug report xDD There's no problem with qemu-system-x86_64, there's a problem with a luser :D I have used network install isos, which by default did not use virtio modules. Well, maybe this bug should be filed against the debian installer instead, because the network install ISOs should contain these modules? 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)
28.01.2013 05:07, Cyril Brulebois wrote: Julien Cristau (26/01/2013): 3.2.5-5 unblocked. unblock-udeb pending d-i ack, probably post-rc1. Looks like post-rc1 material to me indeed. FWIW (not insisting for earlier inclusion, just noting), for the d-i, the noticeable change is the inclusion of an extra binary, mdmon, which is unused on all currently working setups and is only used internally by mdadm when it tries to assemble a "fakeraid" IMSM array. The bugfixes (code fixes) included in this release does^Wshould not affect d-i, these are mostly about routine array maintenance which isn't done in d-i. A bit wider testing, however, is veery welcome, -- for one, I don't know whenever it will work in d-i or not, because I don't have hardware where I can test 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#390420: qemu: DotWhenNoCursor ignored with -vnc
[Replying to an old bugreport...] 01.10.2006 12:02, Francesco Potorti` wrote: Package: qemu Version: 0.8.2-1 Severity: normal When using -vnc, disabling DotWhenNoCursor does not work, neither from the command line, by using -DotWhenNoCursor=0, nor from the F8 menu. The dot appears whatever the settings. I've no idea what does "DotWhenNoCursor" mean. It definitely is not a qemu option. Maybe this bug was misfiled and was intended to be against some vnc viewer? Closing 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#389599: qemu: save vm state does not work with Windows 98
Version: 1.1.2+dfsg-1 [Answering to an old bugreport...] 26.09.2006 21:30, Francesco Potorti` wrote: Package: qemu Version: 0.8.2-1 Severity: normal Saving and restoring the vm state does not work when running Windows 98 under an emulated 386. This happens equally when giving commands by hand on the monitor or when using qemuctl. Saving the state apparently does what is expected. When restoring it, the window appears exactly as it was when saved, but the mouse pointer is completely black. Double clicking restores the normal mouse pointer appearance. However, the only thing that is apparently working is the mouse pointer movement. Neither mouse clicks nor key presses do anything. I tried to reproduce this issue with current qemu (v. 1.1) - installed Windows98 SE in the virtual machine. The system works as expected, savevm and loadvm works. The original bugreport were filed against very old version, so the bug has most likely been fixed. Closing it now for wheezy version. If you find that the issue persist, please reopen this bugreport. 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#649127: network-manager wrongly reports "disconnected" state
Package: network-manager Version: 0.9.0-2 Severity: critical Having this network configuration (/etc/network/interfaces): - cut - auto lo iface lo inet loopback auto br0 iface br0 inet static address 192.168.88.2 netmask 255.255.255.0 gateway 192.168.88.4 bridge-ports eth0 bridge-maxwait 0 bridge-fd 0 #auto eth0 iface eth0 inet manual up ip link set $IFACE up down ip link set $IFACE down - cut - network-manager, which was installed as a dependency of other packages, always reports "State: disconnected" to its clients, even if the machine in question always has connectivity. There's no other network interfaces on this system, and the bridge is here in order to run virtual machines (qemu/kvm) As a result, numerous applications - like, system update agent in gnome - reports that there's no connection and fails to do its work (hence Severity: it breaks other packages). -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (990, 'stable'), (600, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.0.8-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages network-manager depends on: ii adduser 3.112+nmu2 add and remove users and groups ii dbus1.4.16-1 simple interprocess messaging syst ii isc-dhcp-client 4.1.1-P1-17 ISC DHCP client ii libc6 2.13-21 Embedded GNU C Library: Shared lib ii libdbus-1-3 1.4.16-1 simple interprocess messaging syst ii libdbus-glib-1-20.88-2.1 simple interprocess messaging syst ii libgcrypt11 1.5.0-3 LGPL Crypto library - runtime libr ii libglib2.0-02.28.8-1 GLib library of C routines ii libgnutls26 2.12.11-1GNU TLS library - runtime library ii libgudev-1.0-0 164-3GObject-based wrapper library for ii libnl1 1.1-6library for dealing with netlink s ii libnm-glib4 0.9.0-2 network management framework (GLib ii libnm-util2 0.9.0-2 network management framework (shar ii libpolkit-gobject-1-0 0.102-1 PolicyKit Authorization API ii libuuid12.17.2-9 Universally Unique ID library ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii udev172-1/dev/ and hotplug management daemo ii wpasupplicant 0.7.3-5 client support for WPA and WPA2 (I Versions of packages network-manager recommends: ii dnsmasq-base 2.55-2+b1 A small caching DNS proxy and DHCP ii iptables 1.4.8-3 administration tools for packet fi pn modemmanager (no description available) ii policykit-1 0.102-1 framework for managing administrat ii ppp 2.4.5-4+tls Point-to-Point Protocol (PPP) - da Versions of packages network-manager suggests: pn avahi-autoipd (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#649127: network-manager wrongly reports "disconnected" state
Um. I haven't realized that it is possible to just stop networkManager process (and disable it in /etc/rc?.d/) in order to restore the functionality back, -- after stopping it, all applications which were previously refusing doing anything starts working again (What a nice feature it is, NetworkManager!..) So indeed, the severity of this bug may be lowered. Now, after stopping nm, I realized it ruined my /etc/resolv.conf with some non-trivial sorting rules in it, replacing it with a file with just one comment line -- "# generated by NM". So I had to resort to restoring that file from a backup. So it looks like NM does good job at _ruining_ network. Note that the bridge setup becomes more and more common, with more and more people discovering virtualisation technologies. 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#637082: #637082
On 01.11.2011 21:24, Robert Millan wrote: > 2011/11/1 Michael Tokarev : >> But whole approach - trying to canonicalize the path this way - >> is most likely wrong. It shouldn't be needed for the kernel >> since it will do path resolution internally anyway during >> mount. And it breaks various pseudo filesystems, incl. >> tmpfs, aufs, nfs, etc, where the device part of mount operation >> is not really a pathname. > > So let's just not canonicalize it then. Would you like a new patch to do > that? I'm reviewing stuff for the next update of busybox. No, I don't need a new patch - it's easy to do once it's clear _what_ has to be done.. ;) > (FYI, FreeBSD mount canonicalizes, but it might be gratuitous there too) I don't see where it does that. It canonicalizes the target directory argument, that's for sure, but not the "spec" argument. See http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/mount/mount.c?rev=1.117 , function mountfs() -- it calls checkpath() on `name' but does not touch `spec'. Later in mount_fs.c:mount_fs(), it again canonicalizes `dir' but does not touch `dev'. The only reason to canonicalize the `device' part is to put it into /etc/mtab "properly", but even there it is not terrible important: if it's an object in a filesystem it may be moved or renamed or deleted anyway, making mtab information inaccurate. Actually I don't see a good reason to canonicalize the directory part either, but that's a different story. So I'll just drop this one realpath() call for the time being. Thank you for the 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#635370: Bug #635370: busybox: integer overflow in expression on big endian
reopen 635370 thanks For the fun out of it all. The original code, even if gcc produced a warning, worked correctly. Several attempts to silence this warning produced worse or incorrect _code_. I'm reverting the "fix" and marking this bug as not fixed. The issue here is that enums in C are signed. So once you set the most significant bit to 1 the result gets promoted to larger size (64bit in this case). So further arith with this constant were done in 64bits instead of 32bits. 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#646961: #646961 (was: D-I changes needed for xterm transition)
On 20.11.2011 17:31, Robert Millan wrote:
> Cool. Btw, there's also #646961 (with patch available).
Yeah I looked at it today too, but have some.. issues with it.
For which I installed kFreeBSD system in kvm again.
The proposed change:
- /sbin/route add default gw $i dev $interface metric $metric
+ if [ ${uname} = "GNU/kFreeBSD" ] ; then
+ /lib/freebsd/route add -net 0.0.0.0 $i dev $interface
metric $metric
+ else
+ /sbin/route add default gw $i dev $interface metric $metric
+ fi
the only difference here is the usage of "gw" keyword on
the linux side -- linux route understands -net 0.0.0.0 just
fine and the same way as "default". And the usage such as
route add <...> gw 192.168.88.1
on freebsd completes on my host successfully, because there's
a host named "gw" and it places wonderful route with
_netmask_ 192.168.88.1 to the same IP address. Which does
not exactly work ;)
So maybe freebsd route can recognize and skip this "gw"
keyword between source and destination?
This way, there will be no need to distinguish between
linux and freebsd routes anymore.
Or alternatively, maybe it is better to teach linux route
to not require this "gw" (it gives syntax error if "gw" is
not used).
The other change:
- while /sbin/route del default gw 0.0.0.0 dev $interface; do :; done
+ if [ ${uname} = "GNU/kFreeBSD" ] ; then
+ /lib/freebsd/route -q flush
+ else
+ while /sbin/route del default gw 0.0.0.0 dev $interface; do :;
done
+ fi
appears to be not required, the loop (with command line corrections)
works on freeBSD too. But I'm not sure this change is right in the
first place: isn't `route flush' flushes _all_ routes, not only the
default one?
So basically, we only need to sort out this "gw" thing (maybe with
the mentioned /sbin/route wrapper, maybe with source-level changes),
and - provided we use /lib/freebsd/ version - modify $PATH in the
script, instead of resorting to somewhat-ugly uname comparisons.
What do you think about this?
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#502035: busybox-udeb: Add support for LABEL= mounting
tags 502035 + wontfix thanks [Replying to rather old bugreport...] On 13.10.2008 01:34, Andrew Deason wrote: > Package: busybox-udeb > Severity: wishlist > Tags: patch d-i > > I was about to file a wishlist bug against partman with a patch for > using LABEL= mounting in /etc/fstab during the install process, but > right now this fails since the installer tries to mount the partitions > from the same values that are written to /etc/fstab. It uses busybox's > `mount` to do this, and so fails because busybox-udeb right now isn't > compiled with support for mounting via labels (or UUIDs). > > Would it be possible to enable mounting via labels? It appears to add > less than 4k to the busybox x86 udeb binary. Is that acceptable? I think now when d-i always uses udev which is configured to fill in /dev/disk/by-label/ and /dev/disk/by-uuid/ directories for all block devices it finds, this bugreport maybe closed -- it is as easy to use the "long" paths instead of enabling an (incomplete) volume-id support in busybox. What do you think? In any way, I'm tagging this as "wontfix" 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#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
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#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#692448: qemu: system crash on 'libaio1' removal
Control: tags -1 unreproducible moreinfo On 06.11.2012 15:40, Teodor wrote: > Package: qemu > Version: 0.12.5+dfsg-3squeeze2 > Severity: serious > > Hi, > > I've just had a system crash a few seconds after I removed 'libaio1 > package (declared orphan by deborphan). What kind of crash? Crash of what, exactly? What you were running? None of qemu-system or qemu-user binaries are linked with libaio. libaio1 is not used and hence not needed. Note that qemu package - against which you filed the bugreport - is a meta-package, it does not use any library at all. > On KVM systems this is not > a problem because its a dependency of qemu-kvm. But on Xen systems > (+libvirtd) this package is useless and 'qemu' is enough. Which package is useless? > I believe 'qemu' should also depend on 'libaio1'. qemu can be made dependent on libaio1 if it were linked with libaio1. For this, it needs to contain at least one binary, which it does not. Note that library dependencies are automatic in debian -- once a binary is linked with a library, the corresponding dependency is reflected in the package control information, so the only thing necessary to do is to actually _use_ the library. > Another alternative > is to add the dependency on 'xen-qemu-dm*' packages. xen-qemu-dm* packages are not relevant for qemu. Please describe your issue in a bit more details. Currently what you wrote makes no sense, sorry. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#692448: qemu: system crash on 'libaio1' removal
On 06.11.2012 17:02, Teodor MICU wrote: > 2012/11/6 Michael Tokarev : >> On 06.11.2012 15:40, Teodor wrote: >>> I've just had a system crash a few seconds after I removed 'libaio1 >>> package (declared orphan by deborphan). >> >> What kind of crash? Crash of what, exactly? What you were running? > > Debian Linux 6.0 (amd64) on top of Xen 4.0 hypervisor. > > reboot system boot 2.6.32-5-xen-amd Tue Nov 6 02:59 - 05:01 (02:02) > root pts/2vpn-120.DOMAIN Tue Nov 6 02:27 - crash (00:32) So, can you start it again when libaio1 is NOT installed? Note that after you remove a library - any library - applications linked against it will continue running just fine. You wont be able to start new applications linked to this library, -- that's for sure, but already running will continue, since the library will still be in memory and on disk (but deleted). >> None of qemu-system or qemu-user binaries are linked with libaio. >> libaio1 is not used and hence not needed. >> >> Note that qemu package - against which you filed the bugreport - >> is a meta-package, it does not use any library at all. > > # aptitude why qemu > i xen-qemu-dm-4.0 Depends qemu-system | qemu qemu depends on qemu-system. I don't know what xen-qemu-dm-4.0 uses for its qemu component. I think it too comes with integrated qemu, just another variant of it (like qemu-kvm is yet another variant). > # aptitude why libaio1 > i libvirt-bin Recommends qemu-kvm | qemu (>= 0.9.1) > p qemu-kvmDependslibaio1 So libaio1 is used only by qemu-kvm (correctly), not by any other installed packages. Which is exactly what I tried to say initially. > Maybe qemu is not the right package, then which is the right pkg? I dunno - in particular, I don't know how xen uses qemu and if it uses its own copy or not. I can _guess_ this dependency is only for some support files, not for qemu-system binaries, but that's just a guess. >>> On KVM systems this is not >>> a problem because its a dependency of qemu-kvm. But on Xen systems >>> (+libvirtd) this package is useless and 'qemu' is enough. >> >> Which package is useless? > > qemu-kvm is useless on a Xen hypervisor. Ah ok. I guess qemu-system is also useless, if not some support files included in there. >> xen-qemu-dm* packages are not relevant for qemu. >> >> Please describe your issue in a bit more details. Currently >> what you wrote makes no sense, sorry. > > Do you need more info? I don't see any issue so far. Especially since you're having issue with xen which - most likely - does not use separate qemu package at all. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
