Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries
Le 16/09/2020 à 22:05, Michael Tokarev a écrit : > 16.09.2020 22:55, John Paul Adrian Glaubitz wrote: > >> It's called "--persistent yes", not preserve, my bad. > > It is entirely different thing, --persistent (or --fix-binary. F flag) > is here for quite some time and helps with chroots and the like. > > BTW, it turned out not that simple as I thought, the wrapper as > used by SUSE is still needed - or else it's impossible to distinguish > between direct qemu-foo invocation and the same invocation using > binfmt. The patch that is not merged and Adrian was thinking about is: https://patchew.org/QEMU/20191024153847.31815-1-laur...@vivier.eu/ Thanks, Laurent
Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries
Le 16/09/2020 à 19:53, Michael Tokarev a écrit : > 16.09.2020 20:15, John Paul Adrian Glaubitz wrote: >> >>> On Sep 16, 2020, at 6:57 PM, Thorsten Glaser wrote: >>> >>> I’m attaching a test program that does the following: >>> >>> • if argv[1] is "-" it just outputs argv[0] and argv[1] >>> • otherwise it also execve(2)s argv[1] with its argv[0] set to "meow" >> >> That’s been fixed upstream and can be configured with the qemu-binfmt.sh >> script and the option “preserved=yes”. > > Where it's been fixed? current git version of scripts/qemu-binfmt-conf.sh > does not have 'preserved' option, and if the P flag is set when registering > binfmt, the kernel will _prepend_ additional argv[0] element which is not > expected by current linux-user/main.c code (so the tst.c example will be > running with 3 args, not 2). Yes, it's not fixed. For 10 months I'm trying to have a patch merged into the kernel to be able to detect if PRESERVE flag is set or not. https://patchwork.kernel.org/patch/11354255/ Thanks, Laurent
Bug#920032: [Qemu-devel] Bug#920032: qemu-user uses wrong struct timeval on sparc
On 22/01/2019 07:12, Thomas Huth wrote:
> Hi Ben,
>
> could you please submit this as a proper patch to the qemu-devel mailing
> list, with Signed-off-by line?
> (see https://wiki.qemu.org/Contribute/SubmitAPatch for details)
>
> Thanks,
> Thomas
>
>
> On 2019-01-22 06:42, Michael Tokarev wrote:
>> Forwarding to qemu-devel@.
>> http://bugs.debian.org/920032
>>
>> Thanks!
>>
>> 21.01.2019 22:09, Ben Hutchings wrote:
>>> Package: qemu-user
>>> Version: 1:3.1+dfsg-2
>>> Severity: important
>>> Tags: patch
>>>
>>> On sparc (only) Linux defines timeval::tv_usec with type int, not
>>> long. However qemu-user's definition of struct target_timeval uses
>>> abi_long unconditionally. This results in the syscall translation
>>> layer effectively multiplying tv_usec by 2**32. All sparc syscalls
>>> passing non-zero values for this field fail with -EINVAL. The
>>> following patch seems to fix this.
>>>
>>> Ben.
>>>
>>> --- a/linux-user/syscall_defs.h
>>> +++ b/linux-user/syscall_defs.h
>>> @@ -210,7 +210,11 @@ struct target_linger {
>>> struct target_timeval {
>>> abi_long tv_sec;
>>> +#if defined (TARGET_SPARC)
According to the kernel definition, I think it should be:
#if defined(TARGET_SPARC64) && !defined(TARGET_ABI32)
See include/uapi/linux/time.h
struct timeval {
__kernel_time_t tv_sec; /* seconds */
__kernel_suseconds_ttv_usec;/* microseconds */
};
and arch/sparc/include/uapi/asm/posix_types.h
#if defined(__sparc__) && defined(__arch64__)
...
typedef int__kernel_suseconds_t;
>>> + abi_int tv_usec;
>>> +#else
>>> abi_long tv_usec;
>>> +#endif
>>> };
>>> struct target_timespec {
>>> --- END ---
>>>
>>> -- System Information:
>>> Debian Release: buster/sid
>>> APT prefers unstable-debug
>>> APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500,
>>> 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
>>> Architecture: amd64 (x86_64)
>>> Foreign Architectures: i386
>>>
>>> Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
>>> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
>>> LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
>>> Shell: /bin/sh linked to /bin/dash
>>> Init: systemd (via /run/systemd/system)
>>> LSM: AppArmor: enabled
>>>
>>> Versions of packages qemu-user depends on:
>>> ii libc6 2.28-3
>>> ii libcapstone3 3.0.5-3
>>> ii libgcc1 1:8.2.0-13
>>> ii libglib2.0-0 2.58.1-2
>>> ii libstdc++6 8.2.0-13
>>> ii zlib1g 1:1.2.11.dfsg-1
>>>
>>> Versions of packages qemu-user recommends:
>>> ii qemu-user-static [qemu-user-binfmt] 1:3.1+dfsg-2
>>>
>>> Versions of packages qemu-user suggests:
>>> ii sudo 1.8.26-2
>>>
>>> -- no debconf information
>>>
>>
>
>
Bug#886421: python-escript: FTBFS on m68k: hwloc_set_cpubind returned "Error" for bitmap "0"
Le 05/01/2018 à 20:35, Aaron M. Ucko a écrit : > Source: python-escript > Version: 5.1-5 > Severity: important > Tags: upstream > Justification: fails to build from source (but built successfully in the past) > User: debian-...@lists.debian.org > Usertags: m68k > > Builds of python-escript for m68k (admittedly not a release > architecture) have been failing lately per the below excerpts from > https://buildd.debian.org/status/fetch.php?pkg=python-escript=m68k=5.1-5=1514854858=0. > FWIW, automatic builds for this architecture run with nocheck in > DEB_BUILD_OPTIONS because there's little overall incremental value to > running tests on such a slow architecture. However, it's perhaps just > as well that that setting had no effect here, since this problem > doesn't affect any other Debian architectures and may be worth > investigating. > > Could you please take a look? > > Thanks! > > -- > > /<>/debian/stage2M/bin/run-escript > /<>/debian/tmp2M/scripts/release_sanity.py > -- > WARNING: a request was made to bind a process. While the system > supports binding the process itself, at least one node does NOT > support binding memory to the process location. > > Node: vs90 > > Open MPI uses the "hwloc" library to perform process and memory > binding. This error message means that hwloc has indicated that > processor binding support is not available on this machine. > [...] > This is a warning only; your job will continue, though performance may > be degraded. > -- > -- > Open MPI tried to bind a new process, but something went wrong. The > process was killed without launching the target application. Your job > will now abort. > > Local host:vs90 > Application name: /<>/debian/stage2M/lib/pythonMPI > Error message: hwloc_set_cpubind returned "Error" for bitmap "0" > Location: rtc_hwloc.c:190 > -- > scons: *** [dummy] Error 213 > scons: building terminated because of errors. > > *** Config Summary (see config.log and /lib/buildvars for details) *** > Escript revision 6608 > Install prefix: /<>/debian/stage2M > Python: /usr/bin/python (Version 2.7.14) >boost: /usr (Version 1.62.0) >numpy: YES (with headers) > MPI: OPENMPI (Version 2.1.1) > Solver library: paso >Direct solver: NONE > domains: dudley, finley, ripley, speckley > netcdf: YES (3) >weipa: YES > openmp: YES > > DISABLED features: boomeramg cppunit cuda debug gdal gmsh gzip lapack mkl > papi parmetis pyproj scipy silo sympy trilinos umfpack visit > Treating warnings as errors > > WARNING: Cannot import scipy. NetCDF sources will not be available for > inversions. > WARNING: Cannot import pyproj. Inversions may not work. > WARNING: Cannot import gdal. Inversions will not honour WKT coordinate system > information. > WARNING: Cannot import sympy. Symbolic toolbox and nonlinear PDEs will not be > available. > WARNING: matplotlib not found, will skip some unit tests > WARNING: gmsh not available. Skipping tests usersguide/trapezoid.py > usersguide/quad.py usersguide/brick.py usersguide/refine.py > cookbook/example04a.py cookbook/example04b.py cookbook/example05a.py > cookbook/example05b.py cookbook/example05c.py cookbook/example06.py > cookbook/example08c.py cookbook/example09m.py cookbook/example09a.py > cookbook/example10m.py inversion/dc_forward.py! > > ERROR: build stopped due to errors > > debian/rules:57: recipe for target 'override_dh_auto_build' failed > make[1]: *** [override_dh_auto_build] Error 2 > make[1]: Leaving directory '/<>' > debian/rules:30: recipe for target 'build-arch' failed > make: *** [build-arch] Error 2 > dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit > status 2 > It seems this buildd is running a m68k chroot on AMD64 using qemu-m68k. Samuel Thibault has posted patches to qemu-devel mailing-list to fix CPU affinity related functions: [PATCH] linux-user: Add getcpu() support https://www.mail-archive.com/qemu-devel@nongnu.org/msg502788.html [PATCH] linux-user: Fix sched_get/setaffinity conversion https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg05242.html Perhaps it could fix this problem. Thanks, Laurent
Bug#805827: qemu-sh4*: Segfaults on amd64 hosts when using chroot
Le 12/12/2015 13:31, John Paul Adrian Glaubitz a écrit : > On 12/12/2015 01:26 PM, Michael Tokarev wrote: >> While your patch looks sane, I don't know enough about linux-user >> to judge wheenver it does the right thing. So unlike #805826, >> I can't really apply this directly, I'd rather wait for upstream >> to apply it first, and next it can be cherry-picked to debian. >> >> Did you try to file this bug report upstream and/or send this >> patch upstream? > > Yes, this patch came directly from Laurent Vivier who does qemu > upstream development. He posted it upstream, but I haven't checked > again whether it has been merged yet. > > I am CC'ing Laurent, so he can maybe comment on this question. It has not been merged, but QEMU is in soft freeze phase, so we must wait the new development phase. http://wiki.qemu.org/Planning/2.5 Laurent
Bug#805827: qemu-sh4*: Segfaults on amd64 hosts when using chroot
Le 12/12/2015 16:28, John Paul Adrian Glaubitz a écrit : > Le 12/12/2015 13:31, John Paul Adrian Glaubitz a écrit : >>> On 12/12/2015 01:26 PM, Michael Tokarev wrote: >>>> While your patch looks sane, I don't know enough about linux-user >>>> to judge wheenver it does the right thing. So unlike #805826, >>>> I can't really apply this directly, I'd rather wait for upstream >>>> to apply it first, and next it can be cherry-picked to debian. >>>> >>>> Did you try to file this bug report upstream and/or send this >>>> patch upstream? >>> >>> Yes, this patch came directly from Laurent Vivier who does qemu >>> upstream development. He posted it upstream, but I haven't checked >>> again whether it has been merged yet. >>> >>> I am CC'ing Laurent, so he can maybe comment on this question. >> >> It has not been merged, but QEMU is in soft freeze phase, so we must >> wait the new development phase. > > But can you answer whether it's safe to apply without breaking other things? It is safe to apply: it only modifies SH4 linux-user functions. So if it breaks something (I doubt) it is linux-user for SH4 on 32bit host (as this patch is a fix for broken 64bit host). Laurent
Bug#648933: Orphaning emile
Tested with a floppy disk on a mac mystic and a LCIII: works fine. If someone can provide me an installation CD iso of the current release, I can try to make a bootable one. Regards, Laurent Le vendredi 16 décembre 2011 à 05:29 +0100, Laurent Vivier a écrit : Le mercredi 14 décembre 2011 à 10:44 +1100, Finn Thain a écrit : On Tue, 13 Dec 2011, Thorsten Glaser wrote: Hi, I can try to update the package and build it with gcc-4.4 (which is our current standard although people would love to switch to gcc-4.6), if that works. I was able to built it (without docs, I didn't have the tools) from the gitorious source. http://gitorious.org/projects/emile/ It fails to build with error: dereferencing type-punned pointer will break strict-aliasing rules. An untested patch follows. Corrected and pushed, but not tested. Laurent -- - laur...@vivier.eu -- Tout ce qui est impossible reste à accomplirJules Verne Things are only impossible until they're not Jean-Luc Picard -- - laur...@vivier.eu -- Tout ce qui est impossible reste à accomplirJules Verne Things are only impossible until they're not Jean-Luc Picard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648933: Orphaning emile
Le mercredi 14 décembre 2011 à 10:44 +1100, Finn Thain a écrit : On Tue, 13 Dec 2011, Thorsten Glaser wrote: Hi, I can try to update the package and build it with gcc-4.4 (which is our current standard although people would love to switch to gcc-4.6), if that works. I was able to built it (without docs, I didn't have the tools) from the gitorious source. http://gitorious.org/projects/emile/ It fails to build with error: dereferencing type-punned pointer will break strict-aliasing rules. An untested patch follows. Corrected and pushed, but not tested. Laurent -- - laur...@vivier.eu -- Tout ce qui est impossible reste à accomplirJules Verne Things are only impossible until they're not Jean-Luc Picard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648933: Orphaning emile
Hi, Le mercredi 14 décembre 2011 à 10:44 +1100, Finn Thain a écrit : On Tue, 13 Dec 2011, Thorsten Glaser wrote: Hi, I can try to update the package and build it with gcc-4.4 (which is our current standard although people would love to switch to gcc-4.6), if that works. Where can I find a gcc-4.4 .deb for my debian etch-m68k ? Or a cross-compiler ? Laurent -- - laur...@vivier.eu -- Tout ce qui est impossible reste à accomplirJules Verne Things are only impossible until they're not Jean-Luc Picard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648933: Orphaning emile
EMILE sources are now hosted on gitorious: https://www.gitorious.org/emile Since commit bc40d969f it can be compiled with gcc-4: https://www.gitorious.org/emile/mainline/commit/5d2fe2dbb2daa7b5d4b2f3b1ddf9ccbbc40d969f commit 5d2fe2dbb2daa7b5d4b2f3b1ddf9ccbbc40d969f Author: Laurent Vivier laur...@lvivier.info Date: Mon Oct 27 20:51:15 2008 +0100 Allow to compile with gcc-4 by adding a contraint on memory for MacOS traps Since commit f176744 it can be build for debian with gcc-4.1: https://www.gitorious.org/emile/mainline/commit/82b93bd326ea310c1007d61b27689658f1767448 commit 82b93bd326ea310c1007d61b27689658f1767448 Author: Laurent Vivier laur...@vivier.eu Date: Tue Feb 1 00:40:21 2011 +0100 debian: allows to compile emile with gcc-4.1 (but you should also include https://www.gitorious.org/emile/mainline/commit/c1b482e48a80c670ad9a6931b3d99ef0a9d7d28b) Moreover since commit 14b0a3d56 it is able to boot from CDROM without using Apple copyrighted drivers: https://www.gitorious.org/emile/mainline/commit/31fb7a324e294b50b51141d8becad5914b0a3d56 Le jeudi 08 décembre 2011 à 23:42 +0100, Niels Thykier a écrit : reassign 648933 wnpp retitle 648933 O: emile -- the Early Mac Image LoadEr severity 648933 normal thanks I am here by orphaning emile on behalf of the maintainers. The description of emile is: the Early Mac Image LoadEr EMILE provides a way to natively boot Macintosh computers which normally require Penguin to boot. It is however still in an unfinished state; users unfamiliar with Linux should note that Penguin currently is a more safe option. A list of machines that are supported by EMILE is maintained at http://wiki.debian.org/EmileSupportedHardware If you are interested in adopting this package, please be prepared to fix #533800 (and #629789). A quick look at the homepage suggests that upstream might be dead as well. If no one picks this package up within 14 days or so, I will push for its removal on the grounds it that it is RC-buggy and has extremely low popcon. ~Niels -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ee13d6b.5040...@thykier.net -- - laur...@vivier.eu -- Tout ce qui est impossible reste à accomplirJules Verne Things are only impossible until they're not Jean-Luc Picard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548257: Could you apply the patch ?
It also corrects a bug as a void * (sizeof() = 8) cannot be assigned to an int (sizeof() = 4) on an 64bit system. We must use long (sizeof() = 8). See in the patch, the part hfsplus-1.0.4/libhfsp/src/os.c: [...] - int fd = (int) *priv; + long fd = (long) *priv; [...] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548257: Compiling package hfsplus generates a lot of warnings on my debian-amd64
Package: hfsplus Version: 1.0.4-12 Severity: normal I've tried to compile hfsplus on my debian x86_64 and lot of warnings is generated. I can provide a patch to correct this (by using PRIX32 and PRIu32 in printf, at least, and by correcting some casts) -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages hfsplus depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii libhfsp0 1.0.4-12 Shared library to access HFS+ form hfsplus recommends no packages. hfsplus suggests no packages. -- 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#548257: A patch
---
libhfsp/src/btreecheck.c | 98 +++
libhfsp/src/fscheck.c| 51
libhfsp/src/os.c | 13 +++---
libhfsp/src/partitions.c |1
libhfsp/src/record.c |6 +-
libhfsp/src/swab.h | 20 -
libhfsp/src/unicode.c|4 -
src/copyout.c|6 +-
src/hpcache.c|5 +-
src/hpls.c |9 ++--
11 files changed, 112 insertions(+), 103 deletions(-)
Index: hfsplus-1.0.4/libhfsp/src/btreecheck.c
===
--- hfsplus-1.0.4.orig/libhfsp/src/btreecheck.c 2009-09-24 23:30:16.0 +0200
+++ hfsplus-1.0.4/libhfsp/src/btreecheck.c 2009-09-24 23:31:27.0 +0200
@@ -34,6 +34,7 @@
# include limits.h
# include errno.h
# include time.h
+# include inttypes.h
# include libhfsp.h
# include volume.h
@@ -57,7 +58,7 @@
{
char buf[255]; // mh this _might_ overflow
unicode_uni2asc(buf, key-name, 255);
-printf(parent cnid : %ld\n, key-parent_cnid);
+printf(parent cnid : % PRIu32 \n, key-parent_cnid);
printf(name: %s\n, buf);
}
@@ -87,19 +88,19 @@
*/
if (head-root = node_count)
{
- printf(root node out of range %lX = %lX\n,
+ printf(root node out of range % PRIX32 = % PRIX32 \n,
head-root, node_count);
result |= FSCK_ERR; // This is really evil
}
if (head-leaf_head = node_count)
{
- printf(leaf_head out of range %lX = %lX\n,
+ printf(leaf_head out of range % PRIX32 = % PRIX32 \n,
head-leaf_head, node_count);
result |= FSCK_ERR; // dont know how to fix that by now
}
if (head-leaf_tail = node_count)
{
- printf(leaf_head out of range %lX = %lX\n,
+ printf(leaf_head out of range % PRIX32 = % PRIX32 \n,
head-leaf_tail, node_count);
result |= FSCK_ERR; // dont know how to fix that by now
}
@@ -117,14 +118,14 @@
}
if (head-free_nodes = node_count)
{
- printf(free_nodes out of range %lX = %lX\n,
+ printf(free_nodes out of range % PRIX32 = % PRIX32 \n,
head-free_nodes, node_count);
result |= FSCK_ERR; // dont know how to fix that by now
}
// head-reserved1 nothing to check here
if (head-clump_size % blocksize)
{
- printf(clump_size %ld not a multiple of blocksize %ld\n,
+ printf(clump_size % PRIu32 not a multiple of blocksize % PRIu32 \n,
head-free_nodes, blocksize);
result |= FSCK_ERR; // dont know how to fix that by now
}
@@ -136,7 +137,7 @@
// head-reserved2 nothing to check here
if (head-attributes HFSPLUS_TREE_RESERVED)
{
- printf(Unexpected bits in btree header node attributes %lX\n,
+ printf(Unexpected bits in btree header node attributes % PRIX32 \n,
head-attributes);
result |= FSCK_ERR; // dont know how to fix that by now
}
@@ -149,16 +150,16 @@
{
UInt32 attr;
printf( depth : %#X\n, head-depth);
-printf( root: %#lX\n, head-root);
-printf( leaf_count : %#lX\n, head-leaf_count);
-printf( leaf_head : %#lX\n, head-leaf_head);
-printf( leaf_tail : %#lX\n, head-leaf_tail);
+printf( root: %# PRIX32 \n, head-root);
+printf( leaf_count : %# PRIX32 \n, head-leaf_count);
+printf( leaf_head : %# PRIX32 \n, head-leaf_head);
+printf( leaf_tail : %# PRIX32 \n, head-leaf_tail);
printf( node_size : %#X\n, head-node_size);
printf( max_key_len : %#X\n, head-max_key_len);
-printf( node_count : %#lX\n, head-node_count);
-printf( free_nodes : %#lX\n, head-free_nodes);
+printf( node_count : %# PRIX32 \n, head-node_count);
+printf( free_nodes : %# PRIX32 \n, head-free_nodes);
printf( reserved1 : %#X\n, head-reserved1);
-printf( clump_size : %#lX\n, head-clump_size);
+printf( clump_size : %# PRIX32 \n, head-clump_size);
printf( btree_type : %#X\n, head-btree_type);
attr = head-attributes;
printf( reserved2 : %#X\n, head-reserved2);
@@ -183,9 +184,9 @@
static void print_node_desc(UInt32 nodeIndex, btree_node_desc* node)
{
-printf(Node descriptor for Node %ld\n, nodeIndex);
-printf(next : %#lX\n, node-next);
-printf(prev : %#lX\n, node-prev);
+printf(Node descriptor for Node % PRIu32 \n, nodeIndex);
+printf(next : %# PRIX32 \n, node-next);
+printf(prev : %# PRIX32 \n, node-prev);
printf(height : %#X\n, node-height);
printf(num_rec : %d\n, node-num_rec);
printf(reserved : %#X\n, node-reserved);
@@ -225,13 +226,14 @@
HFSP_EXTENT_DATA, bt-cnid);
if (!p)
{
- printf(Unable to read block 1 of b*tree for cnid:%ld\n, bt-cnid);
+ printf(Unable to read block 1 of b*tree for cnid:% PRIu32 \n,
+ bt-cnid);
return FSCK_ERR;
}
p = btree_readnode(node, p);
if (node-prev != 0)
{
- printf(Backlink of header node is not zero (%lX) \n, node-prev);
+
Bug#514803: libvirt-bin: virsh net-create /etc/libvirt/qemu/networks/default.xml allows to start the VM
Package: libvirt-bin
Version: 0.4.6-10
Followup-For: Bug #514803
This bug is found using virt-manager.
The VM has been created and run without problem the first time.
After a reboot of the host, when I try to start the VM the problem
appears.
My VM is defined by:
domain type='kvm'
namedebian-i386/name
uuida8c92ab9-870d-3965-3ab4-5100d43ff5e4/uuid
memory524288/memory
currentMemory524288/currentMemory
vcpu2/vcpu
os
type arch='x86_64' machine='pc'hvm/type
boot dev='hd'/
/os
features
acpi/
apic/
pae/
/features
clock offset='utc'/
on_poweroffdestroy/on_poweroff
on_rebootrestart/on_reboot
on_crashrestart/on_crash
devices
emulator/usr/bin/kvm/emulator
disk type='file' device='cdrom'
target dev='hdc' bus='ide'/
readonly/
/disk
disk type='block' device='disk'
source dev='/dev/mapper/Quad-debian--i386'/
target dev='vda' bus='virtio'/
/disk
interface type='network'
mac address='54:52:00:0a:7f:c2'/
source network='default'/
/interface
serial type='pty'
source path='/dev/pts/3'/
target port='0'/
/serial
console type='pty' tty='/dev/pts/3'
source path='/dev/pts/3'/
target port='0'/
/console
input type='mouse' bus='ps2'/
graphics type='vnc' port='-1' autoport='yes' keymap='fr'/
sound model='es1370'/
/devices
/domain
virt-manager.log:
[mar, 07 avr 2009 21:51:59 virt-manager 6727] DEBUG (error:67) Uncaught
Error: Error starting domain: internal error Network 'default' not found
: Traceback (most recent call last):
File /usr/share/virt-manager/virtManager/engine.py, line 531, in
run_domain
vm.startup()
File /usr/share/virt-manager/virtManager/domain.py, line 380, in
startup
self.vm.create()
File /usr/lib/python2.5/site-packages/libvirt.py, line 262, in
create
if ret == -1: raise libvirtError ('virDomainCreate() failed',
dom=self)
libvirtError: internal error Network 'default' not found
If I run:
$ sudo virsh net-create /etc/libvirt/qemu/networks/default.xml
Network default created from /etc/libvirt/qemu/networks/default.xml
The VM can be started without problem.
-- System Information:
Debian Release: 5.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libvirt-bin depends on:
ii adduser3.110 add and remove users and groups
ii libavahi-client3 0.6.23-3lenny1Avahi client library
ii libavahi-common3 0.6.23-3lenny1Avahi common library
ii libc6 2.7-18GNU C Library: Shared libraries
ii libdbus-1-31.2.1-5 simple interprocess messaging syst
ii libgcrypt111.4.1-1 LGPL Crypto library - runtime libr
ii libgnutls262.4.2-6+lenny1the GNU TLS library - runtime libr
ii libgpg-error0 1.4-2 library for common error values an
ii libpolkit-dbus20.9-2 library for accessing PolicyKit vi
ii libpolkit2 0.9-2 library for accessing PolicyKit
ii libreadline5 5.2-3.1 GNU readline and history libraries
ii libsasl2-2 2.1.22.dfsg1-23 Cyrus SASL - authentication abstra
ii libselinux12.0.65-5 SELinux shared libraries
ii libtasn1-3 1.4-1 Manage ASN.1 structures (runtime)
ii libvirt0 0.4.6-10 library for interfacing with diffe
ii libxenstore3.0 3.2.1-2 Xenstore communications library fo
ii libxml22.6.32.dfsg-5 GNOME XML library
ii logrotate 3.7.1-5 Log rotation utility
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
Versions of packages libvirt-bin recommends:
ii bridge-utils 1.4-5 Utilities for configuring the Linu
ii dnsmasq 2.45-1 A small caching DNS proxy and DHCP
ii iptables 1.4.2-6administration tools for packet fi
ii netcat-openbsd1.89-3 TCP/IP swiss army knife
ii qemu 0.9.1-10 fast processor emulator
Versions of packages libvirt-bin suggests:
pn policykit none (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519639: libsane: Canoscan LiDE e35 is detected but not usable
Le samedi 14 mars 2009 à 09:49 +0100, Julien BLACHE a écrit : Laurent Vivier laur...@vivier.eu wrote: Hi, [ 616.516233] usb 8-3.3: usbfs: USBDEVFS_CONTROL failed cmd scanimage rqt 64 rq 12 len 1 ret -71 [ 616.738681] usb 8-3.3: USB disconnect, address 5 [ 617.035314] usb 8-3.3: new high speed USB device using ehci_hcd and address 8 That looks like the scanner is resetting on its own. How is it connected to the machine? Any USB hub involved? ISTR those scanners are bus-powered, so you want to connect the scanner either to the machine directly or to a *powered* USB hub. So if there is a hub involved, remove it, remove any USB device from the machine that you don't need and plug the scanner into a USB 2.0 port on the machine. If there isn't a hub involved, we'll need to investigate further. Yes, you're right: it works fine without the hub. Thank you. Laurent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519495: [Pkg-phototools-devel] Bug#519495: libgphoto2-2: Cannot findphoto on an iPhone 3G
tag 519495 pending thanks Laurent Vivier laur...@vivier.eu (13/03/2009): Version: 2.4.1-3 FWIW we have 2.4.3-1 in experimental (but I didn't check whether that's fixed there). The attached patch corrects the problem. Thanks. 2.4.4.x series in preparation, due when the release process allows it (we don't want an shlibs bump entangled with other migrations). Will be forwarded upstream if not already there. I've just checked: it is in libgphoto2 SVN since r11247: http://gphoto.svn.sourceforge.net/viewvc/gphoto/trunk/libgphoto2/camlibs/ptp2/library.c?r1=11241r2=11247 Thank you, Laurent -- - laur...@vivier.eu - Tout ce qui est impossible reste à accomplirJules Verne Things are only impossible until they're not Jean-Luc Picard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519639: libsane: Canoscan LiDE e35 is detected but not usable
Package: libsane
Version: 1.0.19-23
Severity: important
scanimage -L detects my scanner, but I'm not able to scan anything.
$ sane-find-scanner
# sane-find-scanner will now attempt to detect your scanner. If the
# result is different from what you expected, first make sure your
# scanner is powered up and properly connected to your computer.
# No SCSI scanners found. If you expected something different, make sure that
# you have loaded a kernel SCSI driver for your SCSI adapter.
# Also you need support for SCSI Generic (sg) in your operating system.
# If using Linux, try modprobe sg.
found USB scanner (vendor=0x0bda, product=0x8187) at libusb:004:003
found USB scanner (vendor=0x04a9 [Canon], product=0x2213 [CanoScan],
chip=GL841) at libusb:008:005
# Your USB scanner was (probably) detected. It may or may not be supported by
# SANE. Try scanimage -L and read the backend's manpage.
# Not checking for parallel port scanners.
# Most Scanners connected to the parallel port or other proprietary ports
# can't be detected by this program.
# You may want to run this program as root to find all devices. Once you
# found the scanner devices, be sure to adjust access permissions as
# necessary.
$ scanimage -L
device `v4l:/dev/video0' is a Noname UVC Camera (046d:08ca) virtual device
device `genesys:libusb:008:005' is a Canon LiDE 35/40/50 flatbed scanner
$ scanimage -d genesys:libusb:008:005
scanimage: sane_start: Invalid argument
$ dmesg
...
[ 616.511009] usb 8-3.3: usbfs: USBDEVFS_CONTROL failed cmd scanimage rqt 64
rq 12 len 1 ret -71
[ 616.516233] usb 8-3.3: usbfs: USBDEVFS_CONTROL failed cmd scanimage rqt 64
rq 12 len 1 ret -71
[ 616.511009] usb 8-3.3: usbfs: USBDEVFS_CONTROL failed cmd scanimage rqt 64
rq 12 len 1 ret -71
[ 616.516233] usb 8-3.3: usbfs: USBDEVFS_CONTROL failed cmd scanimage rqt 64
rq 12 len 1 ret -71
[ 616.511009] usb 8-3.3: usbfs: USBDEVFS_CONTROL failed cmd scanimage rqt 64
rq 12 len 1 ret -71
[ 616.516233] usb 8-3.3: usbfs: USBDEVFS_CONTROL failed cmd scanimage rqt 64
rq 12 len 1 ret -71
[ 616.511009] usb 8-3.3: usbfs: USBDEVFS_CONTROL failed cmd scanimage rqt 64
rq 12 len 1 ret -71
[ 616.516233] usb 8-3.3: usbfs: USBDEVFS_CONTROL failed cmd scanimage rqt 64
rq 12 len 1 ret -71
[ 616.738681] usb 8-3.3: USB disconnect, address 5
[ 617.035314] usb 8-3.3: new high speed USB device using ehci_hcd and address 8
[ 617.145409] usb 8-3.3: configuration #1 chosen from 1 choice
[ 617.145409] usb 8-3.3: New USB device found, idVendor=04a9, idProduct=2213
[ 617.145409] usb 8-3.3: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 617.145409] usb 8-3.3: Product: CanoScan
[ 617.145409] usb 8-3.3: Manufacturer: Canon
$ strace scanimage -d genesys:libusb:008:008
...
nanosleep({0, 1000}, NULL) = 0
ioctl(3, USBDEVFS_CONTROL, 0x7fff8ede4050) = 1
ioctl(3, USBDEVFS_CONTROL, 0x7fff8ede4050) = 1
ioctl(3, USBDEVFS_CONTROL, 0x7fff8ede4050) = 1
ioctl(3, USBDEVFS_CONTROL, 0x7fff8ede4050) = 1
ioctl(3, USBDEVFS_CONTROL, 0x7fff8ede4050) = -1 EPROTO (Protocol error)
ioctl(3, USBDEVFS_CONTROL, 0x7fff8ede4050) = -1 EPROTO (Protocol error)
ioctl(3, USBDEVFS_CONTROL, 0x7fff8ede4050) = -1 EPROTO (Protocol error)
ioctl(3, USBDEVFS_CONTROL, 0x7fff8ede4050) = -1 EPROTO (Protocol error)
ioctl(3, USBDEVFS_CONTROL, 0x7fff8ede4050) = -1 EPROTO (Protocol error)
ioctl(3, USBDEVFS_CONTROL, 0x7fff8ede4050) = -1 EPROTO (Protocol error)
ioctl(3, USBDEVFS_CONTROL, 0x7fff8ede3f50) = -1 EPROTO (Protocol error)
write(2, scanimage: sane_start: Invalid ar..., 40scanimage: sane_start:
Invalid argument
) = 40
close(1)= 0
ioctl(3, USBDEVFS_CONTROL, 0x7fff8ede4070) = -1 EPROTO (Protocol error)
ioctl(3, USBDEVFS_RELEASEINTERFACE, 0x7fff8ede5224) = 0
close(3)= 0
munmap(0x7f028623f000, 2288992) = 0
munmap(0x7f0285fbc000, 2629848) = 0
munmap(0x7f0285db4000, 2128016) = 0
exit_group(4) = ?
$ export SANE_DEBUG_GENESYS=255
$ export SANE_DEBUG_GENESYS_GL841=255
...
[genesys] sane_start: start
[genesys] genesys_start_scan
[genesys_gl841] gl841_save_power: enable = 0
[genesys] sanei_genesys_read_register (0x6d, 0xdf) completed
[genesys] sanei_genesys_write_register (0x6d, 0xdf) completed
[genesys] sanei_genesys_read_register (0x6c, 0x11) completed
[genesys] sanei_genesys_write_register (0x6c, 0x10) completed
[genesys] sanei_genesys_read_register (0x6c, 0x11): failed while setting
register: Invalid argument
[genesys] sanei_genesys_write_register (0x6c, 0x13): failed while setting
register: Invalid argument
[genesys] sanei_genesys_read_register (0x6b, 0x11): failed while setting
register: Invalid argument
[genesys] sanei_genesys_write_register (0x6b, 0x11): failed while setting
register: Invalid argument
[genesys] sanei_genesys_read_register (0x6b, 0x11): failed while setting
register: Invalid argument
[genesys] sanei_genesys_write_register (0x6b, 0x13):
Bug#519495: libgphoto2-2: Cannot find photo on an iPhone 3G
Package: libgphoto2-2
Version: 2.4.1-3
Severity: normal
My iPhone 3G is detected but gthumb is not able to connect to it.
It seems the USB product number of iPhone 3G is not known by libgphoto2.
The attached patch corrects the problem.
-- System Information:
Debian Release: 5.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libgphoto2-2 depends on:
ii adduser 3.110 add and remove users and groups
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libexif12 0.6.16-2.1 library to parse EXIF files
ii libgphoto2-port0 2.4.1-3gphoto2 digital camera port librar
ii libjpeg62 6b-14 The Independent JPEG Group's JPEG
ii libltdl3 1.5.26-4 A system independent dlopen wrappe
Versions of packages libgphoto2-2 recommends:
ii udev 0.125-7/dev/ and hotplug management daemo
Versions of packages libgphoto2-2 suggests:
ii gphoto2 2.4.0-1The gphoto2 digital camera command
-- no debconf information
*** a/camlibs/ptp2/library.c 2009-03-13 01:32:56.0 +0100
--- b/camlibs/ptp2/library.c 2009-03-13 01:32:47.0 +0100
***
*** 806,811
--- 806,812
/* from Mike Meyer m...@mired.org */
{Apple:iPhone (PTP mode), 0x05ac, 0x1290, PTPBUG_DCIM_WRONG_PARENT},
+ {Apple:iPhone 3G (PTP mode), 0x05ac, 0x1292, PTPBUG_DCIM_WRONG_PARENT},
/* https://sourceforge.net/tracker/index.php?func=detailaid=1869653group_id=158745atid=809061 */
{Pioneer:DVR-LX60D, 0x08e4, 0x0142, 0},
