Bug#309537: openbsd-inetd: wrong AF_UNIX socket file permissions
Package: openbsd-inetd
Version: 0.20040915-1
Severity: normal
Tags: patch
On *BSD, AF_UNIX socket files permission bits are ignored, but
on linux they're not, and should be created with mode 0777 to
match *BSD behaviour. In order to do that, the included patch
(below) temporarily changes umask to zero while creating the
socket, so that the socket file will be created with mode 0777.
-- System Information:
Debian Release: 3.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.11-k7-0
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Versions of packages openbsd-inetd depends on:
ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an
ii libwrap07.6-9Wietse Venema's TCP wrappers libra
ii netbase 4.20 Basic TCP/IP networking system
-- no debconf information
--- inetd.c.origWed May 18 00:00:19 2005
+++ inetd.c Tue May 17 23:53:19 2005
@@ -1077,6 +1077,10 @@ setup()
errno = saveerrno;
}
}
+ } else if (sep-se_family == AF_UNIX) {
+ int saved_umask = umask(0);
+ r = bind(sep-se_fd, sep-se_ctrladdr, sep-se_ctrladdr_size);
+ umask(saved_umask);
} else
r = bind(sep-se_fd, sep-se_ctrladdr, sep-se_ctrladdr_size);
if (r 0) {
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299026: subscribe
subscribe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299026: RFA: tinycdb -- a package for creating and reading constant databases
Hi here.
I'm the author of this software, and am very glad there's
some interest in it... thank you for your support.
I prepared a 0.75 version of the package, as available
at http://www.corpit.ru/mjt/tinycdb/tinycdb_0.75.tar.gz --
as a native Debian package. Christian said it's not a
good idea, but it worked well for rbldnsd and I don't
see why it can't work for tinycdb as well. But ofcourse
it's trivial to make it non-native package again ;)
But the most important news is: I prepared the package,
adopting several requested changes, and it is ready for
at least some review. Unlike previously, it now provides
several packages:
libcdb1 - the shared library
libcdb-dev - development files
tinycdb - the command-line utility
libnss-cdb - cdb module for nss (new)
Previously, libcdb* and tinycdb was in one package named
'tinycdb', which is against Debian practices (packaging
shared libraries separately). The library is very small
really, so I'm not quite sure still if it's the right
way (the small size was the reason it was put in a single
package initially).
The last package is new and is optional.
Christian said 'libcdb' is a bad name for the library, and
offered to name it 'libtinycdb' instead. Well, as it provides
libcdb.{so,a} instead of libtinycdb.{so,a} (which may also
be wrong ofcourse), I'm not sure such naming is good or not...
So here we go. The package is ready for review, and I did
everything I can think of to simplify the life of Debian
developer who may continue maintaining it for Debian.
Again, thank you for your interest.
/mjt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339970: rbldnsd: doesn't remove /var/lib/rbldns on purge
Lars Wirzenius wrote: Package: rbldnsd Version: 0.995 When testing rbldnsd with piuparts, I get the following error: 0m7.6s ERROR: Package purging left files on system: /var/lib/rbldns Lars, care to check whenever a bug has been already reported before submitting a new one? See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=280903 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=258012 See also /usr/share/doc/rbldnsd/README.user (since 0.995). So, can we agree which behaviour is a bug and which isn't, finally? /mjt This directory is created by the postinst, and it is the home directory of the rbldns user. Neither the use nor the directory are removed when the package is removed. Do you think it would be reasonable to remove at least the directory when the package is removed (or purged)? If not, I'll add the directory to piuparts so it can be ignored, but it does mean the package leaves cruft on the filesystem, although that can't always be avoided. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398560: rbldnsd: postinst fails: /var/lib/dpkg/info/rbldnsd.postinst: line 30: adduser: command not found
Blah. It should Depends: on adduser (or is it Pre-Depends? adduser is only used in postinst script.) Also, the same postinst script references getent. While it's a part of libc6, on which we already depends on, for other libc variations it might not be the case. For example, libc6-udeb does not have getent (but i doubt anyone will try to include rbldnsd into installer ;), or there are also uClibc, dietlibc etc... But ok, that's not very important issue if at all... ;) Looks like I should update the package.. again. In Debian, rbldnsd is currently at version 0.996, here it's at 0.996a. I'll update my tarball to include the Depends: change. /mjt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398560: rbldnsd: postinst fails: /var/lib/dpkg/info/rbldnsd.postinst: line 30: adduser: command not found
Santiago Vila wrote: On Tue, 14 Nov 2006, Lucas Nussbaum wrote: [] Michael, this is just a missing dependency on adduser, which is needed because adduser is not Essential: yes. Here is a patch: Yup. I already replied to the original report a few minutes after I received it. Should I add Cc: to you? (I think not, because BTS should do that automatically.. or not?) We've several issues already, some are Debian-specific and some are generic, all of which (except of this new adduser dep) are fixed in 0.996a which has been released Jul-27, but hasn't been uploaded to Debian. I repackaged 0.996a and updated all the files at http://www.corpit.ru/mjt/rbldnsd/ Here are the list of Debian-related changes, from debian/changelog: * debian: - Build-Depends on debhelper4, and set DH_COMPAT to 4 - Build-Depends on zlib1g-dev, and pass --enable-zlib to ./configure - bump Standards-Version to 3.7.2 - add Depends: on adduser (Closes: #398560) Complete list of changes between 0.996 and 0.996a is at http://www.corpit.ru/mjt/rbldnsd/rbldnsd_0.996a_i386.changes I think it should go before too long... ;) Thanks! /mjt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460988: Wrong section for bsdtar - should be utils, not libs
Package: bsdtar Version: 2.2.4-1 Severity: minor bsdtar package is placed into wrong section - it's currently in libs as libarchive, not in utils as it should be. Apart from obvious but cosmetic issue, this leads to things like deborphan listing it as orphaned and hence usual dpkg -P $(deborphan) does the wrong thing. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23-i686smp Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968) Versions of packages bsdtar depends on: ii libacl1 2.2.41-1 Access control list shared library ii libattr12.4.16-1 Extended attribute shared library ii libbz2-1.0 1.0.3-6 high-quality block-sorting file co ii libc6 2.7-6GNU C Library: Shared libraries ii zlib1g 1:1.2.3.3.dfsg-8 compression library - runtime bsdtar recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459643: fflush() change wrt pending write in glibc causes others to break
Package: glibc Version: 2.7-5 Severity: important Since 2.7, glibc changed behavour of fflush() wrt pending write in the FILE* buffer. Before, the pending write data was cleared on fflush(), now it's keept in the buffer. As a result, we see some.. interesting stuff, like this: $ echo foo /dev/full bash: echo: write error: No space left on device $ echo bar foo bar $ _ Note the 2nd echo prints BOTH foo and bar. Here, echo(1) is built-in to bash, and bash just switches filedescriptor #1 behind the scenes of stdio when doing redirects. It correctly calls fflush() (which reports error on first echo) and clearerror(), but neither of them now clears the pending write, and the data remains in the buffer attached to stdout FILE* structure. The same behavour is reported for zsh, too, which seems to do similar behind-the-scenes trick when doing redirections. As far as I can see, this is a grey area in C standard - whenever the pending write should be cleared and when. More, I see no stdio function to force clearing the pding write - at least not a standard one. So the bug seems to be in bash (and in zsh) - (ab)users of fflush(), but I'm filing bugreport against glibc as the change lies here, and it's more generic. I see several possible portable, white way to do it all cleanly: o issue freopen() on each redirection (which is tricky too, because freopen() does not accept a file descriptor) o use separate FILE stream instead of stdout (requires many changes in bash and other places) o don't use stdio at all And finally, to revert glibc to do the same as was done before 2.7. What exactly to do is a.. good question. Oh well. /mjt -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23-i686smp Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Versions of packages bash depends on: ii libc6 2.7-5 GNU C Library: Shared libraries ii bash 3.1dfsg-8 The GNU Bourne Again SHell -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459643: fflush() with WRITE ERROR it really is
While trying to save space in Subject line, I created an unclear bugreport. The change in fflush() was with write error only. Under normal conditions, fflush() writes pending data just fine AND clears the write buffer. But in case write(2) errors out, fflush() now does nothing, while in pre-2.7 glibc it cleared the write buffer. Please excuse me for possible confusion. /mjt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459643: It's Debian-specific, after all
$subj. debian/patches/any/submitted-fileops-and-signals.diff in glibc package. See #429021 for details. The change was made for 2.6-1, at 07 Jul 2007. /mjt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301204: libpam-ssh: pam-ssh incorrectly re-uses values returned by getpwnam()
Package: libpam-ssh Version: 1.91.0-5 Severity: critical A long time ago (circa 1998 or so) I looked at pam-ssh project and noticied several problems with it. And since it's now in Debian, the same problems applies to Debian too. Here's one. in pam_sm_authenticate() routine, pam_ssh saves struct passwd as a pam variable, this way (error checking removed for simplicitly): pwent = getpwnam(user); ... /* copy the passwd entry (in case successive calls are made) and save it for the session phase */ pwent_keep = malloc(sizeof *pwent); memcpy(pwent_keep, pwent, sizeof *pwent_keep); pam_set_data(pamh, ssh_passwd_entry, pwent_keep, ssh_cleanup); and later, in pam_sm_open_session(), it reuses the entry to create ~/.ssh/... files and to set user IDs: pam_get_data(pamh, ssh_passwd_entry, (const void **)(void *)pwent); openpam_borrow_cred(pamh, pwent); asprintf(per_agent, %s/.ssh/agent-%s, pwent-pw_dir, hname); env_write = open(per_agent, O_CREAT | O_EXCL | O_WRONLY, S_IRUSR); ... struct passwd contains pointers to strings (pw_dir, pw_name etc). So, any call to getpwent() and other getpw*() routines in between pam_sm_authenticate() and pam_sm_open_session() of this module poses a high risk of the strings to be overwritten (or even the whole internal pwent buffer re-allocated), so the module will create files in a wrong place using wrong userid. Luckly, most (depending on the other modules in the PAM stack) getpw* calls will be the same as this module does, and hence the problem will not occur. I pointed this problem out to the author the same time I looked at the module, but instead of an ACK he replied with something like If you don't like my program write your own. Later on, he changed logic a bit -- previously he where saving the pwent pointer, now he saves the whole structure (as pwent_keep), but the same problem is still here. There where other issues with this package at that time, but by now I forgot which ones. -- System Information Debian Release: 3.0 Kernel Version: Linux paltus.tls.msk.ru 2.6.11-k7-0 #1 Wed Mar 2 20:04:17 MSK 2005 i686 GNU/Linux Versions of the packages libpam-ssh depends on: +++-==-==- ii libc6 2.3.2.ds1-16 GNU C Library: Shared libraries and Timezone ii libpam0g 0.76-22Pluggable Authentication Modules library ii libssl0.9.70.9.7e-3 SSL shared libraries -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301204: libpam-ssh: pam-ssh incorrectly re-uses values returned by getpwnam()
Justin Pryzby wrote: On Thu, Mar 24, 2005 at 03:55:06PM +0300, Michael Tokarev wrote: Package: libpam-ssh Version: 1.91.0-5 Severity: critical A long time ago (circa 1998 or so) I looked at pam-ssh project and noticied several problems with it. And since it's now in Debian, the same problems applies to Debian too. Here's one. in pam_sm_authenticate() routine, pam_ssh saves struct passwd as a pam variable, this way (error checking removed for simplicitly): Are any other getpwnam()-type functions actually called, allowing the buffers to be overwritten? Well, all pam modules and libpam itself does alot of getpw*() calls. An application may call them too ofcourse, between pam auth and session calls. Documentation is not clear about how the fields of the struct are allocated; a minimal test indicates that they are malloc()ated for the first call only, but that implementation could change; I don't know if there are relevant standards, and it may be that it is intentionally opaque. It's really implementation-dependant. In glibc, they're implemented as wrappers around getpwent_r(); a buffer sufficiently large will be allocated on the first call, and if that buffer isn't sufficient for the next line in /etc/passwd, it will be reallocated (while scanning the file). Other implementations may use diffefent techniques. It does seem like best-practice would be to copy the entire contents of the structure, and not just the pointers. Well, basically yes. With the only small issue: other systems may have additional fields in the structure, which will not be copied without quite a bit of autoconf magic. I can't say from memory, but I've seen HP/UX or NetBSD had several non-standard fields in struct passwd. So, at least, such copying have to be done with care. The struct passwd pointer in pam_sm_open_session() is passed into openpam_borrow_cred() -- and nothing stops this last routine from using those additional fields on a platform which actually has them. I think... ;) Well, ok, as I don't have any direct reference to those extra fields.. maybe the problem isn't a problem after all ;) Luckly, most (depending on the other modules in the PAM stack) getpw* calls will be the same as this module does, and hence the problem will not occur. I think you are implying that every libpam module shares memory space with every other libpam module, which AIUI is incorrect. libpam are ELF shared objects, and every process that links with such an object (at runtime) will get its own private copy of the data section, but the text section will be shared (mmaped, really, it is backed by disk). I mean that other modules in the stack will most likely call getpwnam() with the same argument, the same username which is being logged into. So, provided the user info has not changed since pam-ssh call, the whole structure/fields layout will be the same again. But if some other module or application itself will call getpwnam() with different username, the memory layout will change. Does your claim still stand? Does *that* module call getpwnam()-type functions multiple times, without memcpy the pointers, and then reuse the top-level pointer? It does not matter which module performs any calls to getpw* routines. I pointed this problem out to the author the same time I looked at the module, but instead of an ACK he replied with something like If you don't like my program write your own. Later on, he changed logic a bit -- previously he where saving the pwent pointer, now he saves the whole structure (as pwent_keep), but the same problem is still here. Right; it is a static buffer, and multiple calls to getpwnam() return the same pointer, *and* the pointer structure fields always point to the same place. Well.. not into the same place, if it's the different username. The line from /etc/passwd (whatever) is read into that buffer, and when parsed into fields. And pointers are initialized to point to the found fields, to whatever place they're at. If you parse the same line, the pointers will be exactly the same. If you parse different line, the pointers will be different. One way or another, no one guaranteed that content of the memory in question will be valid and the same after other module work. The content of the structure and pointed-to memory is valid only up to the next call to getpw*() routine. It seems that your request can be easily satisfied by using the reentrant versions of these functions, like getpwnam_r. I'm including a test file I've been playing with, which indicates that a patch, if necessary, would be unintrusive. Yes, getpwnam_r will work. It's a PITA to deal with, and it may not be sufficiently portable, but it will work. But: why are you trynig to save the pwent pointer in the first place? To remove extra getpwnam() call? It will be done by other modules and by the application too, anyway... Why not just call it again in pam_sm_open_session(), based on pam_get_user() ? BTW, there was a discussion on linux-pam list
Bug#301204: libpam-ssh: pam-ssh incorrectly re-uses values returned by getpwnam()
A small followup with additional comments.
Justin Pryzby wrote:
[]
It seems that your request can be easily satisfied by using the
reentrant versions of these functions, like getpwnam_r. I'm including
a test file I've been playing with, which indicates that a patch, if
necessary, would be unintrusive.
I said it's a PITA to get getpwnam_r() usage right. Here's why:
#include unistd.h
#include pwd.h
#include sys/types.h
int main()
{
struct passwd p,q;
char *buf,*buf2;
int buflen=sysconf(_SC_GETPW_R_SIZE_MAX);
buf=(char *)malloc(buflen);
buf2=(char *)malloc(buflen);
struct passwd *v=malloc(sizeof (void *));
//struct passwd *p=getpwnam(pryzbyj);
getpwnam_r(pryzbyj, p, buf, buflen, (struct passwd **)v);
Here, we have to deal with errno = ERANGE.
I re-read linux getpwnam_r() manpage - it changed since I last looked there.
Now it says:
The maximum needed size for buf can be found using sysconf(3) with the
_SC_GETPW_R_SIZE_MAX parameter.
(exactly the thing you did here). Previously, preferred way
to call getpwnam_r was a loop like this (error checking omitted):
int bufsize = _GETPWNAM_PREFERRED_BUFSIZE;
char *buf = malloc(bufsize);
while((err = getpwnam_r(name, pwent, buf, bufsize, pwent)) == ERANGE) {
bufsize *= 2;
buf = realloc(buf, bufsize);
}
(again, I don't remember how the constant GETPWNAM_PREFERRED_BUFSIZE was
named, it's a suggested initial bufsize).
Here's what glibc.info says about getpwuid_r():
If a user with ID UID is found, the pointer returned in RESULT
points to the record which contains the wanted data (i.e., RESULT
contains the value RESULT_BUF). If no user is found or if an
error occurred, the pointer returned in RESULT is a null pointer.
The function returns zero or an error code. If the buffer BUFFER
is too small to contain all the needed information, the error code
`ERANGE' is returned and ERRNO is set to `ERANGE'.
(no mention of that POSIX sysconf stuff).
Obviously, this loop-way is.. difficult and ugly.
And BTW, not all systems are using /etc/passwd. For other database
implementations, things may be different.
/mjt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301204: Debian bug #301204: libpam-ssh: pam-ssh incorrectly re-uses valuesreturned by getpwnam()
zze-Beta Testeur LABROSSE A ext RD-CSRD-GRE wrote: Hi, I'd read your posts to the bug, and now I wonder what to do. I Add an url to a patch[1] that seems to reduce number of call to getpwnam(), and improve the behaviour of all the module. Please tell me if the patch fix problems you're talking about to close this bug. I included patches that fix other bugs, so the package could be bug-free (at this time) if the patch[1] fixes #301204. Well, the patch looks ok to me. This is exactly what I proposed back when I first saw the module several years ago - to stop keeping cached pwent and call getpwnam() in session module directly. Probably should be a good idea to add a call to endpwent() somewhere at the end of the module too. /mjt Thanks by advance, Aurelien [1] :http://sourceforge.net/mailarchive/forum.php?thread_id=5792275forum_id=12884 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302714: mdadm fails to start a degraded raid6 array
Matthias Urlichs wrote: I have a 7-disk raid6 array. Two of the disks have shut down due to a flaky power supply. I rebooted the system. The degraded RAID didn't come up. $ mdadm -A /dev/md7 /dev/hd[bceijkl]1 mdadm: failed to add /dev/hdk1 to /dev/md7: Invalid argument mdadm: failed to add /dev/hdl1 to /dev/md7: Invalid argument mdadm: /dev/md7 assembled from 3 drives - not enough to start the array. This is wrong. There are *five* working devices in that array, and in fact all of them showed up in /proc/mdstat (the array was inactive, of course). $ mdadm -A /dev/md7 /dev/hd[bceij]1 This worked. Matthias, please provide your /etc/mdadm/mdadm.conf entries for the array in question (/dev/md7). From the description of your problem it seems it is due to incorrect content of the array entry in there -- not all and wrong devides are listed. If I'm right, please try booting with correct mdadm.conf contents. /mjt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294404: The commited fix is WRONG
The last mdadm change -- 1.9.0-2.1 -- did NOT fix the bug,
but made the situation worse.
rcS.d/S04mdadm-raid is now the FIRST thing the system is
doing when booting. At that stage, /proc is not mounted
(it is mounted later), and in mdadm-raid bootscript, there's
the following code:
if [ x$AUTOSTART = xtrue ] ; then
if [ ! -f /proc/mdstat ] [ -x /sbin/modprobe ] ; then
/sbin/modprobe -k md /dev/null 21
fi
test -f /proc/mdstat || exit 0
echo Starting raid devices:
Obviously, without /proc mounted, the script will do right nothing,
will not start your arrays, and the system becomes unbootable.
The fix for this #294404 is a one-liner for mdadm-raid script.
From the mdadm(8):
-a, --auto{=no,yes,md,mdp,part,p}{NN}
Instruct mdadm to create the device file if needed,
possibly allocating an unused minor number. md causes
a non-partitionable array to be used. mdp, part or
p causes a partitionable array (2.6 and later) to be
used. yes requires the named md device to have a from
this. See DEVICE NAMES below.
This --auto options has been added recently to mdadm, to work
around exactly this #294404 problem. So the real fix was just:
- $MDADM -A -s
+ $MDADM -A -s --auto=md
and probably similar for /sbin/mdrun too.
But now with current state of the package, some more steps are
necessary -- ie, to move the symlink back. I think the best
is to add a test into postinst to check if the link is at
S04 and if yes, move it back to S25.
Please note: mdrun MUST DIE. I don't know why it is still here,
this kludge has been written before people discovered mdadm can
do all the work much better...
So, to summarize, I don't think this bug has been fixed...
/mjt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302714: mdadm fails to start a degraded raid6 array
Matthias Urlichs wrote: Hi, Michael Tokarev: $ mdadm -A /dev/md7 /dev/hd[bceij]1 This worked. Matthias, please provide your /etc/mdadm/mdadm.conf entries for the array in question (/dev/md7). From the description of your problem it seems it is due to incorrect content of the array entry in there -- not all and wrong devides are listed. If I'm right, please try booting with correct mdadm.conf contents. No, that's not it. The mdadm.conf is rather simple: DEVICE partitions [ other arrays ] ARRAY /dev/md7 uuid=8303b89b:70284d24:1f751455:b2e2c40d I can boot correctly *now*, but of course I have no missing disks any more... Aha. I mis-read your initial bugreport - i didn't notice you where starting your array manually. Anyway. Looks like more info is needed. You said your array didn't come up during boot, but provided a command line which you executed which failed: $ mdadm -A /dev/md7 /dev/hd[bceijkl]1 mdadm: failed to add /dev/hdk1 to /dev/md7: Invalid argument mdadm: failed to add /dev/hdl1 to /dev/md7: Invalid argument mdadm: /dev/md7 assembled from 3 drives - not enough to start the array. At this point, the situation should be something like: mdadm have choosen to use 5 drives out of 7 - only 3 of hd[bceij]1 (first 5) and hd[kl]1. Why it did so is impossible to say - as there's no additional error messages, it means mdadm tried to open all 7 devices in turn, found everything is ok, but descided not to touch 2 of them. Or, another possible cause, there wasn't all of the nodes in question present in /dev, so shell wildcard expanded to less than 7 entries. for some reason, kernel didn't like the 2 last devices (hd[kl]1) and complained. dmesg should contain more info (incl. exact reason why kernel didn't like the two) -- and the dmesg from that time still *may* be in your logs. So finally, the thing tried to start 7-drive array out of 3 drives, which obviously didn't work. If you still have dmesg from that time, showing failed attempt to assemble the array, it may be possible to understand what's going on. If not, I guess we will never know... /mjt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#259647: arrays made with non-partitioned disks doesn't start !
Folks, can we close this bug now? mdrun and AUTOSTART mess has been sorted out long ago (the latter really means what it should mean now). mdrun will not work with whole disks, and isn't supposed to, and should go away completely. There's a standard way to use either partitions or whole disks with mdadm, by specifying proper settings in mdadm.conf. I'd say it's Not A Bug (tm)... /mjt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432906: integrate lckdo in moreutils?
Robert Edmonds wrote at Thu, 12 Jul 2007 18:59:23 -0400: Package: moreutils Version: 0.22 Severity: wishlist Hi, Joey: I currently have a single binary package called 'lckdo' -- I didn't realize the upstream author (mjt) was a Debian developer when I packaged it, however. What do you think about including it in moreutils? Here's the current package description: Description: execute a program with a lock set lckdo is a utility for controlling the invocation of another program based on a lock file. It supports both shared (read) and exclusive (write) locks and can wait for a configurable amount of time for the lock to become free. lckdo is commonly used to make automated rsync mirroring more robust. I've found it very handy for doing simple locking in shell scripts. Robert, First of all, please excuse me for the loong delay with the answer. I was (and still is) at vacation and was busy with family stuff. But it's better later than never, isn't it? :) Speaking of your question(s). No, I'm not really a Debian Developer (yet, still, ...). My packages in Debian are sponsored by other people. Concering lckdo - it's a very tiny utility. Yes it's handy sometimes, and I was VERY surprized when I tried to find something similar but found nothing (newslock, lockexec or something like those - used in shell scripts to do locking - works a bit differently, and mostly too complex and too unreliable). I don't think it deserves its own package due to it's size. I wish to see something like lckdo as a standard utility somewhere, maybe like in coreutils -- but moreutils looks ok too. So if you want(ed) to package it together with the rest of small assorted utilities, I'm ok with that. And thank you for your interest, support and asking me first!.. /mjt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446752: libcdb-dev: /usr/lib/pkgconfig/libcdb.pc is missing
Ralf Hildebrandt wrote: Package: libcdb-dev Version: 0.76 Severity: normal I tried to use pkg-config today and found that libcdb-dev does not write /usr/lib/pkgconfig/libcdb.pc information (unlike libpcre3-dev etc). I wonder why people are using that stupid thing in the first place -- pkg-config. I for one absolutely detest it, pretty much like libtool with its .la files which gets installed in /lib and gets opened by some idiotic dlopen() wrapper. In short: things works directly without any wrappers, in both cases... /mjt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408329: udns: please update
I'm - slowly - catching up with my inbox... [EMAIL PROTECTED] wrote: Hello, Thomas. Michael Tokarev, the author of udns requested me to exclude udns from Debian Etch, since he claims it is not stable API yet, and should not be distributed in a system like Debian right now. Well, it isn't because of unstable API (yes, I plan to change the API quite significantly for the next release, but that's not the point). The thing is that 0.0.8 version as now included in Debian is just too buggy. On the other hand, current 0.0.9 has all the known bugs fixed, together with some (not all) limitations. I think udns is great software and useful enough to deserve distribution, although no other software in Debian depends on it yet. Unless he says that he is OK in keeping it in Debian (he has not answered my reply to him yet), I will request tomorrow the removal of udns from Debian Etch. Perhaps, I will maintain it on experimental. Well, if it's not yet too late for etch, I think you can release it there if you really want.. ;) At least I'm not THAT ashamed by 0.0.9 as I was by 0.0.8 (at least not until more stupid bugs will be discovered ;) I think I owe you something. At least, I did the release, without discussing everything I wanted to with you (that other email I didn't reply to yet) - just because it happened that I had almost no time to do anything and due to some umm.. pressure from various users wanting to use the new code... ;) OT: Hope we can meet sometime. I need to stop working and studying this much and go back to hack a little more on Hurd. Please, keep the good job you've done. Eh, there's quite alot of people I'd like to meet with. Not that it's easy to do in many cases... Thanks! /mjt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416512: removed disk md-device
Neil Brown wrote: [] But joggling a usb stick (similar to your use case) would probably be OK since it would be hot-removed and then hot-added. This still needs user-space interaction. If the USB layer detects a removal and a re-insert, sdb may well come back a something different (sdp?) - though I'm not completely familiar with how USB storage works. This is in fact an.. interesting issue. Suppose I pulled the USB cable of sdb -- the WRONG one -- by a mistake. I noticed this immediately (since the led on the disk stopped lighting), and plugged the cable back again. There was no write requests to the array during this time, there was no ANY requests to it at all, it was completely idle. But. The unplug immediately triggers USB device removal. But md subsystem still holds a reference to (now orphan) sdb. So upon plugging it back, since sdb is busy, scsi subsystem (which handles USB disks) grabs first available sdX device, let's say it'll be sdp. So we've orphan sdb which is in use by the array, and fresh new sdp, which is unused but contains the orphaned array component. And there's no way to hot-re-add sdp to the array (there's nothing to do to the array itself!) but.. to powercycle the machine! Because on hot-remove, event count will be updated on the still-plugged-in device (sda let it be), and upon hot-add, md will start resyncing. Oh well... (the only help from md subsystem here is in case if it is using bitmaps, but that's different issue.) In any case, it should really be a user-space decision what happens then. A hot re-add may well be appropriate, but I wouldn't want to have the kernel make that decision. The question now isn't about decision anymore. The question is now about a possibility to implement that decision. /mjt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379340: [Pkg-sysvinit-devel] Bug#379340: inappropriate dependency on e2fsprogs
Henrique de Moraes Holschuh wrote: On Sun, 10 Sep 2006, Marco d'Itri wrote: [1] by setting FSCKTYPES=none in /etc/default/rcS and 0 in fstab Yes, that would cripple it into not needing e2fsprogs, all right... However, not doing any fsck at all is not the right solution. Removing the fsck wrapper from e2fsprogs would be the correct one. Not doing fsck is perfectly right solution IFF there's nothing to fsck. For example, disk-less systems (mounting all filesystems over NFS or staying entirely on RAM), or virtual systems like linux-vserver, openvz, etc. /mjt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423405: RAMRUN and RAMLOCK doesn't work if /var is a separate filesystem
Package: initscripts Version: 2.86.ds1-38 Severity: normal When either of RAMRUN or RAMLOCK are set to yes (supposed to mount /var/run and /var/lock as tmpfs), AND /var is a separate filesystem (a good thing to do really), mount of /var/run and/or /var/lock fails, because mountkernfs.sh (which mounts the two in this case) tries to mount them before /var is mounted, hence /var is still empty at this stage. I wonder why this RAMRUN and RAMLOCK, (and other stuff like /sys, /proc, /proc/bus/usb, /dev/shm etc) is ever introduced in the first place. Why not mount it the traditional way, listing them in /etc/fstab, which is designed to do the Right Way? Ok ok, /proc /sys are special, because many things will break before mountall.sh is called to mount all filesystems. So I'm shutting up here. Back to the original issue. I see many griefs in initscripts to preserve the two mentioned filesystems over mounting of /var. So I suppose (and it seems I'm right) that making empty /var/run and /var/lock on the root filesystem should work (the question is how to do that without booting off the rescue CD, but that's another question, and I for one know several answers, but it's beyong an average user expirience). Shouldn't all this grief be removed and regular /etc/fstab be used instead for things like /var/run and /var/lock ? Thanks. /mjt -- System Information: Debian Release: 3.1 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20-i686smp Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Versions of packages initscripts depends on: ii debianutils 2.17 Miscellaneous utilities specific t ii e2fsprogs 1.37-2sarge1 ext2 file system utilities and lib ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii lsb-base3.1-23.1 Linux Standard Base 3.1 init scrip ii mount 2.12r-19 Tools for mounting and manipulatin ii sysvinit-utils 2.86.ds1-38 System-V-like utilities Versions of packages initscripts recommends: ii psmisc22.3-1 Utilities that use the proc filesy -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312466: update uucp: chown: cannot access `/etc/uucp/call': No such file or directory
Package: uucp Version: 1.07-12 Severity: normal When upgrading uucp package, the upgrade fails with the following message: Setting up uucp (1.07-12) ... chown: cannot access `/etc/uucp/call': No such file or directory dpkg: error processing uucp (--configure): This is due to /etc/uucp/call file missing as it has been deleted (probably by me) previously, for some reason. In postinst script, we have: if [ -n $version ] \ dpkg --compare-versions $version lt 1.07-10 then chown uucp:uucp /etc/uucp/call fi I think this chown should be conditional, based on presence of the file in question. More, I think the ownership here is wrong: no files in /etc/uucp should be owned by uucp for security reasons. I know it' stricky with current uucico being setgid dialout... -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.11-k7-8 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Versions of packages uucp depends on: ii cron 3.0pl1-72 management of regular background p ii debconf 1.4.30.5Debian configuration management sy ii libc62.3.2.ds1-21GNU C Library: Shared libraries an ii libpam0g 0.76-22 Pluggable Authentication Modules l ii mailx1:8.1.2-0.20020411cvs-1 A simple mail user agent. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312466: update uucp: chown: cannot access `/etc/uucp/call': No such file or directory
[EMAIL PROTECTED] removed from Cc list - don't submit replies to bugreports as new bugs, ok? ;)] Peter Palfrader wrote: On Wed, 08 Jun 2005, Michael Tokarev wrote: [] In postinst script, we have: if [ -n $version ] \ dpkg --compare-versions $version lt 1.07-10 then chown uucp:uucp /etc/uucp/call fi I think this chown should be conditional, based on presence of the file in question. You're right. Too bad nobody noticed before. I'd noticied that but too bad I had locally modified package which I tried to upgrade only now... BTW, probably I should've set priority to minor, not normal. I assume you managed to upgrade eventually, or do you still need some help? Sure I did: touch /etc/uucp/call ;) More, I think the ownership here is wrong: no files in /etc/uucp should be owned by uucp for security reasons. I know it' stricky with current uucico being setgid dialout... Actually it turned out to be almost impossible for the file to stay root:uucp :( Read one of the bug reports for a lengthy discussion about that. It's unfortunate, but that's the way it is. Well, I've seen it after submitting this bugreport. Yeah, the problem is umm.. er. Good I don't have that file anymore ;)) And oh, it's a good thing that this stuff popped up: now I know to watch other systems which actually do have that file, to restore file ownership back to root -- in my case, uucico either uses only TCP ports, or is started from cron job with appropriate initgroups, so uucp group is here even if uucico itself is setgid(dialout). Probably some warning around that chown is needed too, how do you think? /mjt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415441: s2disk and raid
Neil Brown wrote: On Tuesday April 3, [EMAIL PROTECTED] wrote: [] After the power cycle the kernel boots, devices are discovered, among which the ones holding raid. Then we try to find the device that holds swap in case of resume and / in case of a normal boot. Now comes a crucial point. The script that finds the raid array, finds the array in an unclean state and starts syncing. [] So you can start arrays 'readonly', and resume off a raid1 without any risk of the the resync starting when it shouldn't. But I wonder why this raid is necessary in the first place. For raid1, assuming the superblock is at the end, -- the only thing needed for resume is one component of the mirror. I.e, if your raid array is (was) composed off hda1 and hdb1, either of the two will do as source of resume image. The trick is to find which, in case the array was degraded -- and mdadm does the job here, but assembling it isn't really necessary. Maybe mdadm can be told to examine the component devices and write a short line to stdout *instead* of real assembly (like mdadm -A --dummy), to show the most recent component, and the offset if superblock is at the beginning... having that, it will be possible to resume from that component directly... By the way, my home-grown initramfs stuff accepts several devices for resume= command line, and tries each in turn. If main disks has more-or-less stable names, this may be an alternative way. To mean, just give the component devices in resume= line... Yes, this way it may do some weird things in case when the original swap array was degraded (with first component, which contained a valid resume image, removed from the array)... But it's not really a big issue, since - usually anyway - if one uses resume=, it means the machine in question isn't some remote 100-miles-away, but it's here, and it's ok to bypass the resume for recovery purposes. Just some random thoughts. /mjt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366843: apache postinstall script insists of (quietly) setting ServerName (to localhost)
Package: apache Version: 1.3.33-6sarge1 Severity: grave When upgrading apache (or dpkg-reconfiguring it), ServerName directive is set to some value (defaults to `localhost'). Before upgrade the configuration was perfectly valid, with ServerName taken from hostname apache is running on. After upgrades, ServerName is set to invalid 'localhost'. Usually I keep local modifications in another file (httpd.conf.local) - stuff like MinSpareServers, mod_proxy configs (if any) etc - it's easy to overwrite those even if set in the default httpd.conf. But I can't unset ServerName which is being forcedly set in httpd.conf. There's some words about black magic in /usr/share/apache/postinst.common wrt setting ServerName. I probably can just remove the text postinst.common searches for, to avoid this issue, but.. that required me about an hour to figure it all out!.. ;) Why the ServerName is being set in the first place, anyway? Setting it quietly is bad (hence Severity set to grave - it silently brokes valid configuration), but why to set it at all? Thanks. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.16-i686 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Versions of packages apache depends on: ii apache-common 1.3.33-6sarge1 support files for all Apache webse ii debconf 1.4.30.13 Debian configuration management sy ii dpkg 1.10.28Package maintenance system for Deb ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libdb4.2 4.2.52-18 Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii libmagic1 4.12-1 File type determination library us ii logrotate 3.7-5 Log rotation utility ii mime-support 3.28-1 MIME files 'mime.types' 'mailcap ii perl 5.8.4-8sarge4 Larry Wall's Practical Extraction -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383417: cdb_seek returns incorrect data length
Tatsuya Kinoshita wrote:
I'm forwarding this bug report to the members of bug#299026, `ITP: tinycdb'.
[]
--- cdb_seek.c~ 2006-08-17 15:02:16.0 +0900
+++ cdb_seek.c 2006-08-17 15:02:43.0 +0900
@@ -75,7 +75,7 @@
/* read the key from file and compare with wanted */
unsigned l = klen, c;
const char *k = (const char*)key;
-if (*dlenp)
+if (dlenp)
*dlenp = cdb_unpack(rbuf + 4); /* save value length */
for(;;) {
if (!l) /* the whole key read and matches, return */
Yeah, it's a typo. Funny we never hit it before - well, I myself
don't use cdb_seek() interface, preferring cdb_find(), so it's
not very surprizing.
[]
Daiki, thanks for your report.
This bug causes my packages dbskkd-cdb and skksearch unusable.
I'm thinking about applying workaround patches to dbskkd-cdb and
skksearch due to this bug for the moment. Anyway, I hope this bug
will be fixed shortly...
Michael, could you fix this bug in tinycdb 0.76? Could anyone
update the Debian tinycdb package?
Yeah, fixed in cvs, I'll refresh 0.76-pre tarball on my site shortly.
But the question with the upload remains. You reminded me that I'm
still not become a DD, and still didn't find anyone to upload the
thing. Lemme try again... ;)
/mjt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344572: Package maintainer
Bernhard R. Link agreed to sponsor tinycdb package, which I prepared at http://www.corpit.ru/mjt/tinycdb/tinycdb_0.76pre2.tar.gz, if no one steps in till the next Friday. The tarball includes nss_cdb module still, but I plan to comment it out for the final 0.76, just to reduce possible problems with uploading/testing - at least for now, as it's already too much changes. Thank you Bernhard for your time, you already spent quite some of it reviewing my packaging and making useful suggestions. /mjt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#605800: [KVM] AQEMU/KVM segmentation fault after upgrade. Libc related.
tags 605800 + unreproducible quit 03.12.2010 19:20, Gustavo Moreno wrote: Package: KVM Version: 1:0.12.5+dfsg-5 Severity: grave After upgrading, any KVM virtual machine crashes when it try to start, althought Qemu machines work fine. AQEMU gui doesn't crash. I'm runnuing a amd64 kernel, in i5 processor and 6 GB RAM. Dmesg shows this: [ 1727.452869] kvm[3247]: segfault at ff8c ip f7275047 sp f680718c error 6 in libc-2.11.2.so[f71b1000+14] Gustavo, please understand this bug report is completely useless, and the severity is unjustified either. First there's absolutely no information about how to reproduce the problem. At least, you should include kvm command line, indicate what guest(s) you're running, and when exactly it crash. Second, lots of other people who are running kvm disagree that this bug renders package unusable for most people (which is how grave severity is interpreted) -- so far you're the first person who complains about kvm segfaulting. I'm marking this bug as unreproducible for now, awaiting for a way to reproduce it (see above). I need _something_ to work with, if you want this to be fixed ofcourse. Also, please indicate which upgrade did you perform - from which version did you upgrade the 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#605800:
03.12.2010 23:08, Gustavo Moreno wrote: Please, excuse my fault about lack of information and misclassification, also for my mistakes with English. This is my first bug report! I marked it as serious because I understood that would be a problem that could affect a lot of users, making their VM's not loadable. You marked it as grave, which is more than serious :) And you're welcome - it is really difficult to get all things right from the start. I installed a month ago lenny from CD and then I did a dist-upgrade to squeeze. Since then, I use to do system upgrades once a week. I did the last upgrade just today and then I could not boot any of my KVM virtual machines. before failure, KVM was version 1:0.12.5+dfsg-4 right now, KVM version is 1:0.12.5+dfsg-5 [] Ok, now I see, so it affects all kinds of guests, and happens right on the start. Now, the only missing information I'd like to know is your kernel version. If your kernel package is linux-image-2.6.32-686 ver. 2.6.32-28, this is the same problem as http://bugs.debian.org/604956 . If it's the case, for now you can choose to install 64bit kernel which does not have this issue, or wait for updated 32bit kernel (the bugfix is pending upload, if everything turns out to be ok). Please indicate which kernel you're running. 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#605800: (no subject)
reassign 605800 linux-2.6 2.6.32-28 severity 605800 normal merge 604956 605800 thanks 04.12.2010 00:01, Gustavo Moreno wrote: I've already got a precompiled 64 bit kernel on this machine, namely. linux-image-2.6.32-5-amd64 version:2.6.32-28 linux-headers-2.6.32-5-amd64 version:2.6.32-28 That is the kernel loaded right now by grub. Here you go, that's the kernel with the problem. And I was incorrect in my previous email saying the 64bit version works and 32bit works, it's exactlty the opposite - 64bit kernel is broken while 32bit is ok. I'm mergeing this bug with #604956. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#310440: 310440: busybox-udeb
reassign 310440 busybox-udeb thanks the bug is about busybox-udeb: busybox and busybox-static enables mktemp applet. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#310440: 316847: busybox-udeb
reassign 316847 busybox-udeb thanks the bug is about busybox-udeb. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606646: dovecot-2.0 fails to start - wrong built-in default for vsz_limit for managesieve-login
Package: dovecot-common Version: 1:2.0.8-1~2.gbp45a01a Severity: normal Tags: experimental (report against unreleased version) When starting dovecot for the first time, it refuses to start (and even doveadm complains) like this: Starting IMAP/POP3 mail server: dovecotdoveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf: service(managesieve-login): vsz_limit is too low (This isn't even true since vsz_limit isn't mentioned). It appears the default value for vsz_limit is set to 64 (bytes) somehow, not the intended 64M (megabytes). -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606648: dovecot-common includes conffiles from -imapd and -pop3d
Package: dovecot-common Version: 1:2.0.8-1~2.gbp45a01a Severity: normal Tags: experimental (report against unreleased package) dovecot-common inctalls /etc/dovecot/conf.d/20-pop3.conf and /etc/dovecot/conf.d/20-imap.conf which belong to subpackages. The result of this is that when only -common package is installed (or -common and -imapd), dovecot fails to start like this: Starting IMAP/POP3 mail server: dovecotFatal: service(pop3) \ access(/usr/lib/dovecot/pop3) failed: No such file or directory Or, if only pop3d is installed without imapd: Starting IMAP/POP3 mail server: dovecotFatal: service(imap) \ access(/usr/lib/dovecot/imap) failed: No such file or directory The mentioned files should be moved to appropriate subpackages, I think. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606649: dovecot-2.0 fails to start, attempting to listen on each port twice
Package: dovecot-common Version: 1:2.0.8-1~2.gbp45a01a Severity: normal Tags: experimental (report against unreleased package) When starting a freshly-installed dovecot, it fails to start, attempting to listen on each port twice: Starting IMAP/POP3 mail server: dovecotError: service(pop3-login): listen(::, 110) failed: Address already in use Error: service(pop3-login): listen(::, 995) failed: Address already in use Error: service(imap-login): listen(::, 143) failed: Address already in use Error: service(imap-login): listen(::, 993) failed: Address already in use Fatal: Failed to start listeners failed! The only way I found to force it to start was to set protocols to none in dovecot.conf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606649: dovecot-2.0 fails to start, attempting to listen on each port twice
10.12.2010 18:06, Michael Tokarev пишет: Package: dovecot-common Version: 1:2.0.8-1~2.gbp45a01a Severity: normal Tags: experimental (report against unreleased package) When starting a freshly-installed dovecot, it fails to start, attempting to listen on each port twice: Starting IMAP/POP3 mail server: dovecotError: service(pop3-login): listen(::, 110) failed: Address already in use Error: service(pop3-login): listen(::, 995) failed: Address already in use Error: service(imap-login): listen(::, 143) failed: Address already in use Error: service(imap-login): listen(::, 993) failed: Address already in use Fatal: Failed to start listeners failed! The only way I found to force it to start was to set protocols to none in dovecot.conf. This happens because of the default listen = *, ::. For some reason, when IPv6 is unavailable, it tries to create IPv4 socket for the second listening address, which obviously fails. Using listen = * fixes that. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610981: window title changed compared with previous version and no way to specify it
Package: roxterm Version: 1.20.7-1 Severity: normal With the new version, which changed window title by default from %s to ROXterm: %s (so that all window names are now different from what they were before), there's no way to change the format in the configuration, but only per-window (menu Edit - Window Title). Maybe it is possible to set it in the config file, but I don't see how to do that, either. -- System Information: Debian Release: 6.0 APT prefers testing APT policy: (990, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.36-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 roxterm depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libdbus-1-3 1.2.24-4 simple interprocess messaging syst ii libdbus-glib-1-2 0.88-2.1 simple interprocess messaging syst ii libglade2-0 1:2.6.4-1 library to load .glade files at ru ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii libice6 2:1.0.6-2 X11 Inter-Client Exchange library ii libpango1.0-0 1.28.3-1 Layout and rendering of internatio ii librsvg2-common 2.26.3-1 SAX-based renderer library for SVG ii libsm62:1.1.1-1 X11 Session Management library ii libvte9 1:0.24.3-2 Terminal emulator widget for GTK+ Versions of packages roxterm recommends: ii openssh-client1:5.5p1-6 secure shell (SSH) client, for sec roxterm 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#610981: window title changed compared with previous version and no way to specify it
24.01.2011 19:44, Tony Houghton wrote: With the new version, which changed window title by default from %s to ROXterm: %s (so that all window names are now different from what they were before), there's no way to change the format in the configuration, but only per-window (menu Edit - Window Title). [] You can use -T or --title on the command-line and that supports %s too. Is that any use? The old title handling code didn't quite do what Yes, while browsing sources I found that it can accept the same string from --title, but not from the config file. And yes, it is useful as a temporary workaround, till real solution emerges: right now I have /usr/bin/x-terminal-emulator as a symlink pointing to roxterm, so I'll have to change that (globally, for whole system) to a shell script that adds --title option. it should and I felt that having profile options for both would make the dialog a little complex. But it's not hard to persuade me to change my mind on details like this :-). Um, I'm not sure I understand: for _both_ of what? I see one option to change _current_ window title, which is good. But it is, in my opinion, entirely illogical to not have it in profile section too -- as in, profile first, current window second for almost every option out there is, again IMHO, the plan... ;) Maybe I don't understand something and just don't know how to use it properly, -- just tell me how it is supposed to be used :) Note that, as far as I know, roxterm is the only terminal emulator out there that adds its own name before user string in the title. Usually it's done the other way around -- adding the name _after_ the most important information (which is the user string in this case), if at all. And oh, thank you very much for fixing the window size which I reported on SF a while back. This was the reason I switched to 1.20 from experimental :) /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611134: CVE-2011-0011 qemu-kvm: Setting VNC password to empty string silently disables all authentication
26.01.2011 00:25, Moritz Muehlenhoff wrote: Package: kvm Severity: grave Tags: security Please see the following entry in the Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-0011 Yes, I've seen this even before CVE ID were assigned. The impact is not entirely obvious to me? Do I understand it correctly that a malicious application accessing a KVM instance could lock out other apps to this virtual machine? This is completely wrong understanding. First of all, only one instance is affected. Second, this is an intended behavour. Emty vnc password meant to be no authentication, not a lockdown. When you start it without specifying a password it lets everyone in. There was a bug in previous versions of qemu which is now fixed by the commit mentioned in that RH bugreport. A bug which resulted in inability to change vnc to no auth mode at runtime if a password has been specified. The implication is this: if there was an application that relied on the wrong behavour, thinking that changing VNC password at runtime to an empty string means a lockdown, that combination is now broken, since instead of a lockdown we're getting wide-open access. But I'm not aware of any application like that. Do you think this needs to be fixed for Squeeze or in a point update? I think this does not need to be fixed at all. Maybe a wishlist bug requesting a way to explicitly enable/disable vnc at runtime, or - provided an application that relies on the buggy behavour is found - a fix for that application, but definitely not like RH has put it. I think. 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#611134: CVE-2011-0011 qemu-kvm: Setting VNC password to empty string silently disables all authentication
On 26.01.2011 11:25, Julien Cristau wrote: On Wed, Jan 26, 2011 at 08:56:06 +0300, Michael Tokarev wrote: Second, this is an intended behavour. Emty vnc password meant to be no authentication, not a lockdown. When you start it without specifying a password it lets everyone in. Intended by whom? Well, that's a good question. From how qemu works that's quite logical thing to expect, to me anyway. Empty password means empty password, ie, wide access instead of no access. IMHO anyway. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611134: CVE-2011-0011 qemu-kvm: Setting VNC password to empty string silently disables all authentication
Please excuse me for late reply - I missed your email initially somehow. 28.01.2011 00:59, Moritz Mühlenhoff wrote: [] Thanks for the verbose explanation. I've updated the Debian Security Tracker. While we're at it; could you please also look into http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0435 ? That's a problem in the (host) kernel. Is this something that still needs to be fixed for Squeeze? It is fixed in 2.6.32.27, by the following patch: -- From 85dedd445698c5bbd096289cfcc6034f74941815 Mon Sep 17 00:00:00 2001 From: Gleb Natapov g...@redhat.com Date: Wed, 10 Nov 2010 12:08:12 +0200 Subject: KVM: VMX: fix vmx null pointer dereference on debug register access There is a bug in KVM that can be used to crash a host on Intel machines. If emulator is tricked into emulating mov to/from DR instruction it causes NULL pointer dereference on VMX since kvm_x86_ops-(set|get)_dr are not initialized. Recently this is not exploitable from guest userspace, but malicious guest kernel can trigger it easily. CVE-2010-0435 On upstream bug was fixed differently around 2.6.34. -- As far as I can see, 2.6.32.27 patch is included in current debian kernels. So no action appears to be necessary. 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#612098: etherboot-qemu rom images are built with the default pause
Package: etherboot-qemu Version: 5.4.4-7 Severity: wishlist The ROMs in etherboot-qemu package are built with the usual boot from network or local pause which causes unnecessary boot delays when booting virtual machines, where the choice (where to boot from) is controlled in the qemu command line. It'd be nice if etherboot-qemu boot ROMs were built without this pause, just like upstream qemu boot ROMs are made. One note however: when enabling this pauseless mode, while we solve one issue (slow boot), we may encounter another issue: when using bridged networking for the guest, the virtual port may not be ready yet (forward_delay in bridge) when we send DHCP requests, which results in boot failure. This should be addressed either in the kernel or in the bridge configuration, separately. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612105: qemu-kvm: hangs and irq timeout unless -no-kvm-irqchip passed
tags 612105 + unreproducible moreinfo thanks 06.02.2011 02:09, Jonathan Nieder пишет: Package: qemu-kvm Version: 0.13.0+dfsg-2 Severity: important Hi, See [1] for the war story. When I boot the HURD without passing -no-kvm-irqchip on the command line, the system usually will print hd2: irq timeout: status=0x50 hd2: irq timeout: status=0x50 hd2: irq timeout: status=0x50 hd2: unexpected_intr: status=0x58 [and so on] at boot time and not get past that. If lucky, the system boots up but still hangs (not responding to keyboard input) at seemingly random moments. Based on a hint from guillem, I tried passing -no-kvm-irqchip on the kvm command line. And now it works great! Known problem? Ideas for tracking it down? Jonathan $ : host $ uname -a Linux elie 2.6.38-rc3+ #2 SMP PREEMPT Thu Feb 3 17:51:50 CST 2011 x86_64 GNU/Linux $ (cd ~/src/linux-2.6 git rev-parse --short HEAD) 831d52b $ dpkg-query -W qemu-kvm vde2 libaio1 libvdeplug2 iproute \ bridge-utils etherboot-qemu qemu-utils bridge-utils 1.4-5 etherboot-qemu 5.4.4-9 iproute 20100519-3 libaio1 0.3.107-7 libvdeplug2 2.2.3-3 qemu-kvm 0.13.0+dfsg-2 qemu-utils 0.13.0+dfsg-2 vde2 2.2.3-3 [1] I was installing the hurd using a Debian installation CD-ROM (see http://www.debian.org/ports/hurd/hurd-cd) like so: wget http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/mini.iso qemu-img create hurd-install.qemu 3G kvm -m 512 -net nic,model=ne2k_pci -net user \ -hda hurd-install.qemu -cdrom mini.iso -boot d Puzzlingly, the result would hang (and not respond to keyboard input) at seemingly random moments. Sometimes right after Enabling FXSR during bootup, sometimes after the text auth was printed, sometimes later. I can't reproduce this with either of the released kernels - neither standard 2.6.32, nor 2.6.37-trunk from unstable, nor with my custom kernels (2.6.32 or 2.6.36). It works with or without -no-kvm-irqchip, on 32 or 64bits (I did about a dozen of boots, but I didn't try to actually install hurd, just answering a few questions installer asks and stopping there). How about trying one of supported kernels first, instead of (ab)using a development snapshot of the kernel? /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612105: qemu-kvm: hangs and irq timeout unless -no-kvm-irqchip passed
06.02.2011 20:48, Jonathan Nieder wrote: How about trying one of supported kernels first, instead of (ab)using a development snapshot of the kernel? Okay, will try. (Is testing kernels before they flow into Debian really abuse?) No, that's not what I mean. If it looked harsh to you, please accept my apologies, it wasn't my intention. What I mean is: it is unrealistic to deal with bug reports when some of the main components involved are some randome beta release candidates with its own pile of not-yet-settled bugs. If you try such a combination, you'll have to understand how to handle such situation yourself, and especially how to contact upstream who understands the whole picture much better. From my side it isn't practical to act as a broken phone between you and kernel developers, you've much shorter route and you understand your own versions and configs much better too. If at least most important components are the ones which are available in debian - from one of the released (even in -experimental) versions, so at least their respective maintainers checked the configs, maybe tried to run that stuff themselves on a few machines, and just know what it is all about, -- in that case it is practical to file bugreports against debian packages and use BTS. In your case, - provided the original information, namely using a 3rd release candidate of next kernel version - and provided the behavour didn't exist on previous released kernel - the best will be to use upstream bugtracker or mailinglist (most likely kvm@vger). But since you observed it also happens on 2.6.37 as exists in debian (even experimental), and that kernel is actually released, things may change. I can't reproduce it on 2.6.37 still, but at least now I'll try harder. 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#612711: jabberd14: jabberd does not report errors - either silently or suggesting stupid workarounds
Package: jabberd14 Version: 1.6.1.1-5+b1 Severity: normal jabberd error reporting is nearly non-existing. For example, access denied opening user profile .xml file is silently ignored (returning unauthorized to client without a way to understand what's wrong, only strace on the server helps). Another example is #256622. When initializing network connections and socket() fails (see #579945), instead of providing at least errno code it suggests that this is due to another server is running, which is stupid. Severity is at least normal not a wishlist, since there are numerous other issues which can be only diagnosed using a hammer (strace) without at least minimal attempt for error reporting. -- System Information: Debian Release: 6.0 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-i686 (SMP w/1 CPU core) Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages jabberd14 depends on: ii adduser 3.112+nmu2 add and remove users and groups ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8GCC support library ii libidn111.15-2 GNU Libidn library, implementation ii libjabberd2 1.6.1.1-5+b1 Runtime library for the Jabber/XMP ii libmysqlclient165.1.49-3 MySQL database client library ii libpopt01.16-1 lib for parsing cmdline parameters ii libpq5 8.4.7-0squeeze2 PostgreSQL C client library ii libpth202.0.7-16 The GNU Portable Threads ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii openssl 0.9.8o-4 Secure Socket Layer (SSL) binary a jabberd14 recommends no packages. jabberd14 suggests no packages. -- Configuration Files: /etc/default/jabberd14 changed [not included] /etc/jabber/jabber.xml [Errno 13] Permission denied: u'/etc/jabber/jabber.xml' -- 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#612712: reportbug complains about unicode conversion error
Package: reportbug Version: 4.12.6 Severity: important When filing bugeports when some non-ascii locales are in effect - for example, Russian ru_RU.UTF-8 (default for ru), reportbug complains about unicode conversion errors and aborts, like this: cut $ reportbug jabberd14 Warning: no reportbug configuration found. Proceeding in novice mode. Detected character set: UTF-8 Please change your locale if this is incorrect. Using 'Michael Tokarev m...@tls.msk.ru' as your from address. Getting status for jabberd14... [...] (1-12/12) Is the bug you found listed above [y|N|b|m|r|q|s|f|?]? Maintainer for jabberd14 is 'Miguel Landaeta mig...@miguel.cc'. Looking up dependencies of jabberd14... Getting changed configuration files... *** WARNING: The following configuration files have been modified: /etc/default/jabberd14 Send modified configuration files [Y|n|d|?]? n Traceback (most recent call last): File /usr/bin/reportbug, line 2098, in module main() File /usr/bin/reportbug, line 1045, in main return iface.user_interface() File /usr/bin/reportbug, line 1733, in user_interface conftext = conftext + u'%s %s\n' % (f, confinfo[f]) UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 11: ordinal not in range(128) $ echo $LANG ru_RU.UTF-8 cut It works only when explicitly unsetting $LANG. Now, it may be python bug (2.6), and it may be related to #539736 But in any case, the problem makes it difficult to submit _any_ bugreport for a Russian user of Debian Sueeze, -- yes, more experienced users will be able to figure out that it'll work after resetting $LANG, but others wont... That's why Severity is set to important. Thanks! -- Package-specific info: -- System Information: Debian Release: 6.0 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-i686 (SMP w/1 CPU core) Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages reportbug depends on: ii apt 0.8.10.3 Advanced front-end for dpkg ii python 2.6.6-3+squeeze5 interactive high-level object-orie ii python-reportbug4.12.6 Python modules for interacting wit reportbug recommends no packages. Versions of packages reportbug suggests: pn debconf-utilsnone (no description available) ii debsums 2.0.48+nmu3 tool for verification of installed pn dlocate none (no description available) pn emacs22-bin-common | emacs23 none (no description available) ii file 5.04-5 Determines file type using magic ii gnupg1.4.10-4GNU privacy guard - a free PGP rep ii postfix [postfix]2.6.5-tls0 Postfix Mail Transfer Agent pn python-gtk2 none (no description available) pn python-gtkspell none (no description available) pn python-urwid none (no description available) pn python-vte none (no description available) pn xdg-utilsnone (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#612775: please upgrade qemu-kvm PXE roms from Ethereboot to gPXE
tags 612775 + moreinfo thanks 10.02.2011 18:34, Michal Suchanek wrote: Package: qemu-kvm Version: 0.12.5+dfsg-5 Severity: normal Hello gPXE does not work when loaded with Etherboot on an e1000 or virtio card. I'm not sure I understand this. Since Etherboot is much older the error is more likely on Etherboot side. Which error? PXE (network) booting with qemu-kvm_0.12.5 works for me using at least 4 common (virtual) network adaptors - e1000, virtio, default rtl8139 and ne2k_pci. Other less commonly used NICs works with less success, but that's a different question. Either way it is resolved by using gPXE as the rom. This wont happen till gPXE is not part of Debian. When it will be, we'll sure take appropriate actions. So far I don't see it to be necessary however. Please explain your rationale. 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#613413: qemu-kvm 0.12.5+dfsg-5 scsi
tags 613413 + moreinfo unreproducible thanks 14.02.2011 19:24, Xavier Martin wrote: Package: qemu-kvm Version: 0.12.5+dfsg-5 x@locahost:~$ kvm -m 1024 -cdrom x.iso -drive file=w.img,if=scsi,boot=on -nographic -vnc :0 kvm: /tmp/buildd/qemu-kvm-0.12.5+dfsg/hw/lsi53c895a.c:596: lsi_reselect: Assertion `s-current == ((void *)0)' failed. I can't reproduce this. I tried to use debian install iso image x.iso an empty 2Gb file for w.img. Can you tell me what's in your w.img and x.iso, so it'll be possible for me to trigger that? Besides, scsi support in 0.12 is quite unstable still. Things has changed in later versions but scsi is still second-class citizen in qemu, much less tested than ide and virtio. there's a patch that might solve the issue http://thread.gmane.org/gmane.comp.emulators.qemu/79660 Why do you think it's relevant? 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#604034: seabios: BIOS error!
Adding some info about an oldish bugreport. FWIW, but in 0.14 qemu-kvm (with seabios version 0.6.1.2) I can't reproduce this problem anymore, so it appears to be fixed. So I'll close this bugreport by uploading 0.14 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#607391: qemu-kvm: /dev/kvm should have group id kvm
tags 607391 + moreinfo unreproducible thanks [Somehow I didn't see the bugreport - neither of the messages reached me. Dunno why] Richard Kettlewell wrote at Mon, 07 Feb 2011 22:12:18 +: There is actually a file in /lib which can help achieve this. I used these commands: # cp /lib/udev/rules.d/60-qemu-kvm.rules /etc/udev/rules.d/ # udevadm test $(udevadm info -q path -n /dev/kvm) There is also a section in the postinst which references a nonexistent rules file, which be a failed attempt to do the same. The lines you refer to is a compensation for a very old udev rules file which previously (in pre-historic times) has been in /etc/udev/rules.d/. Sure thing it does not exist in modern systems. But the thing is: /lib/udev/rules.d/60-qemu-kvm.rules file is sufficient for udevd to pick that file up, there's no need to copy that file into /etc/udev/rules.d/ unless you want to _modify_ that file. This was the intention when moving stuff from /etc/udev/rules.d/ to /lib/udev/ - in order to be able to modify the rules that comes with each package without worrying about local changes. If a file named the same is present in /etc/udev/rules.d/, that file will be used instead of the one in /lib/udev/rules.d/. So I'm not sure I understand the problem, it all works as intended, on my systems and on many other systems all over the world. Maybe you have very old udev package (from Lenny?) which does not look at /lib/udev/rules.d 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#607391: qemu-kvm: /dev/kvm should have group id kvm
23.02.2011 23:10, Netvalue Support wrote: I found /etc/udev/rules.d/65-kvm.rules on some of my systems, which I had to remove. These started off as Etchnhalf and were previously upgraded to Lenny; systems that started off as Lenny were fine. But to muddy the waters a little, I've also had qemu-kvm from backports or built from upstream sources on these machines at times. Do you have these 65-kvm.rules files somewhere still? Currently qemu-kvm ships /lib/udev/rules.d/60-qemu-kvm.rules, but the rules in there (especially setting permissions/ ownership) may be owerwritten by 65-kvm.rules (since it sorts after 60-*), so the only possible explanation of this issue is an error in 65-kvm.rules. And the only place I can think of where that file may come from is kvm package v. 85 or nearby, which were present in backports for some time, and for which I don't have any upgrade paths. In any case, it'd be nice to see the content of that file (if it's still possible), and the solution is to just remove that file. Maybe I will be able to come with some automatic solution, but I'm afraid it's too late for squeeze, -- I don't want to mess up with config files risking to create more serious breakage. 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#615280: unshare segfaults on invalid or incomplete long options
Package: util-linux
Version: 2.17.2-9
Severity: normal
Tags: patch
unshare utility from util-linux segfaults when given an invalid
or incomplete (abbreviated) long option. This is because the
option array in sys-utils/unshare.c:main() is not NULL-terminated.
The attached patch fixes the issue, which has been fixed upstream
too.
Thanks!
/mjt
--- a/sys-utils/unshare.c 2010-03-19 01:11:23.0 +0300
+++ b/sys-utils/unshare.c 2011-02-26 19:10:48.276153002 +0300
@@ -77,4 +77,5 @@ int main(int argc, char *argv[])
{ ipc, no_argument, 0, 'i' },
{ net, no_argument, 0, 'n' },
+ { NULL, 0, 0, 0 },
};
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615485: FTBFS after debian/rules clean
Package: lxc Version: 0.7.2-1 Severity: normal Tags: upstream when building lxc from source, it's impossible to re-build the package after running ./debian/rules clean. This is because config/Makefile.am has this: distclean: @$(RM) -f compile config.guess config.sub depcomp install-sh ltmain.sh missing Makefile.in Makefile which removes all files which are actually necessary for compilation (for configuring stage actually), so next ./configure run fails with missing install-sh message. The same problem exists in more recent releases as well (in 0.7.3 and recently released 0.7.4). I'll try to address this upstream, this bugreport is for reference. 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#607290: qemu-kvm scripts not run
16.12.2010 22:40, Yves-Alexis Perez wrote: [] There's no such thing as internal script. By default qemu - given -net tap as above - _creates_ a network device, and runs the script specified only _after_ the device is created. Here, you don't have permission to _create_ a network device to start with. The various howtos found on the net seem to indicate the script is responsible for creating the device. See http://en.wikibooks.org/wiki/QEMU/Networking for example. We can't be responsible for every error in every internet publication out there. The above wiki page is wrong in that it's wrong to _create_ the tap device inside the configuration script. [] The script runs against already created tap device - created either by qemu itself, or pre-created (and given with ifname=NNN to qemu). Ok so passing ifname=NNN should prevent the device to be created by kvm. No. qemu will create a device if it's not already exist, be it a named or randomly-numbered one. There's no point or ability to _create_ a tap device _inside_ the script - because it has the same permissions anyway, and because now there's no way to pass the tap device back to qemu. I thought the name was given has an argument to the script, so qemu already knows it. And that means it's possible to gain root in the script using sudo. Yes, the iface name is passed as first argument to the script, because qemu has it created and open at the time when the script is run. Using script=no fixes the problem but means one has to setup everything himself. Fixes which problem? Qemu still need the tap device - either created internally or pre-created. I meant that when passing script=no, qemu didn't try to create the tap device itself, but that's wrong, it's when I used ifname=foo. And you're wrong again. Qemu needs a working tap device, - either pre-created or created by qemu itself, no matter if you use ifname=foo or script=foo or script=no. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607483: squeeze crashes trying to open any rar archive
Package: squeeze Version: 0.2.3-8 Severity: normal Tags: squeeze When trying to open any rar archive squeeze segfaults immediately with a SIGSEGV error, and kernel reports just that: [138304.063587] squeeze[7792]: segfault at 0 ip (null) sp ff92994c error 14 in squeeze[8048000+23000] Apparently not related to #475072. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.36-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 squeeze depends on: ii exo-utils 0.3.107-1Utility files for libexo ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra ii libdbus-1-3 1.2.24-3 simple interprocess messaging syst ii libdbus-glib-1-20.88-2 simple interprocess messaging syst ii libexo-0.3-00.3.107-1Library with extensions for Xfce ii libfontconfig1 2.8.0-2.1generic font configuration library ii libfreetype62.4.2-2.1FreeType 2 font engine, shared lib ii libglib2.0-02.24.2-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii libpango1.0-0 1.28.3-1 Layout and rendering of internatio ii libthunar-vfs-1-2 1.0.2-1+b2 VFS abstraction used in thunar ii libxfce4util4 4.6.2-1 Utility functions library for Xfce ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime squeeze recommends no packages. squeeze 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#607483: [Pkg-xfce-devel] Bug#607483: squeeze crashes trying to open any rar archive
19.12.2010 10:09, Yves-Alexis Perez wrote: On dim., 2010-12-19 at 01:07 +0300, Michael Tokarev wrote: When trying to open any rar archive squeeze segfaults immediately with a SIGSEGV error, and kernel reports just that: [138304.063587] squeeze[7792]: segfault at 0 ip (null) sp ff92994c error 14 in squeeze[8048000+23000] Do you have an unrar utility? Well, rar is in nonfree, and it's installed here too. The prob happens with _any_ rar archive so far, incl. the attached one, for which rar is able to list and extract file without any issue. I probably should not attach it since you can create a rar archive too just fine, but here we go ;) /mjt random32.rar Description: application/rar
Bug#607515: extlinux quietly overwrites conffile
Package: extlinux Version: 2:4.02+dfsg-7 Severity: serious Tags: squeeze extlinux-update script quietly overwrites /etc/default/extlinux file on each invocation. The file in question, according to the Policy, is a configuration file, so the local changes made to this file should be preserved. I think handling of this file should be done differently: only create this file if not already exist, and not update it after. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607516: extlinux-update manipulates boot files in unsafe ways
Package: extlinux Version: 2:4.02+dfsg-7 Severity: important Tags: squeeze update-extlinux script modifies boot-related files in unsafe ways, which is a good way to make system unbootable: it re-creates several files in /boot/extlinux/ by zeroing the content at start and adding information to them piece by piece. In case of a power failure during this time, the system will be unbootable. We're talking about the need to perform f(data)sync() on important files to ensure data integrity, but this case is much more important since it affects whole system, but here, file manipulation is much less safe than just omitting fsync. The rigth way to create these files is to create a temp file first, and when it's done, rename it into place atomically. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607515: extlinux quietly overwrites conffile
19.12.2010 14:31, Daniel Baumann wrote: On 12/19/2010 12:25 PM, Michael Tokarev wrote: extlinux-update script quietly overwrites /etc/default/extlinux file on each invocation. The file in question, according to the Policy, is a configuration file, so the local changes made to this file should be preserved. while i agree that the handling of the update of the file could be upgraded, user changes are preserved as the file is read in by extlinux-update before writing it again, therefore closing the bug. I discovered this while trying (something like) this: EXTLINUX_MENU_LABEL=Debian GNU/Linux, node $(cat /var/run/nodeinfo), kernel which evaluates to different things (running several nodes from a common image). But once something calls update-extlinux on the master node, the variable is not evaluated anymore on the other nodes. Besides, I had a few things on that file which tried to create valid menu system without help of the themes - since on our small terminals in server room I can't use vesamenu which is used by syslinux themes. This too were overwritten. Maybe these aren't common usages, but the bug is here anyway. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616159: qemu-kvm: SEGV inside vnc tight encoding
03.03.2011 00:31, Roland Dreier wrote: Package: qemu-kvm Version: 0.14.0+dfsg-1~tls Severity: important I'm running a 32-bit guest (Xubuntu 10.04 to be precise) on a 64-bit host with the command line: kvm -drive file=xubuntu.img,if=virtio,format=qcow2,boot=on -net nic,model=virtio -net user -m 1024 -vga vmware -usbdevice tablet -smp 2 -vnc :1 Roland, can you please tell me which vnc client are you using, and with what options? I use VNC alot here, but never encountered this bug so far. 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#616487: qemu-kvm: New or existing VM unbootable with '-vga vmware' option
04.03.2011 23:57, Philippe Latu wrote: I'm encountering initialization problems when using the '-vga vmware' option. [] All these VMs run fine without the '-vga vmware' option. vmware isn't the best-tested virtual device out there, I'm afraid, but it shouldn't be _that_ broken. With 0.14, both cirrus and stdvga become quite alot faster, and with linux guests (X) too, so the current workaround is to use one of these for now, and switch to spice (qxl) later when I will be available. That's JFYI, I will take a look at this 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#616723: Add support for bitmap option of md device
07.03.2011 01:00, Pierre Bernhardt wrote: Package: debian-installer Severity: whishlist Tags: d-i Latest debian installer on Squeeze Iso disk debian-6.0.0-amd64-BD-1.iso used to install new computer. At the level of creating md devices it is not possible to add an bitmap as I can do with --bitmap=internal. Please add (for me internal is good enough ;-). MD bitmap can trivially be done later... FWIW. md configuration is quite complex nowadays, and some things (various options for different layouts like r10 near and far copies, chunk size, algorithm for r5 etc) are more important than bitmap, because these can't be changed after the array has been created (or requires rebuilding (reshaping) the array). /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#237351: busybox-cvs: ash loves to terminate randomly on my SS10
tags 237351 + moreinfo thanks Replying to a several-years-old email. 11.03.2004 08:36, Joshua Kwan wrote: Package: busybox-cvs Severity: normal Within the d-i initrd, ash loves to randomly quit while i'm typing a command out. It is vastly annoying. I don't know what the cause is, but I can't reproduce it on my i386... Joshua, is this bug still present on your machine? It's been quite a while since 2004, busybox is now at version 1.18, and that bug has probably been fixed long ago. 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#588324: busybox: Please include cttyhack and setsid to enable ^C in initramfs shell
07.07.2010 15:23, Taisuke Yamada wrote: Package: busybox Version: 1:1.15.3-1 Severity: wishlist Because current debian build of busybox (and busybox-static) does not include 'cttyhack' and 'setsid', it is impossible to use ^C and other job control feature in initramfs shell. - http://lists.busybox.net/pipermail/busybox/2008-January/029936.html As you can see in above URL, enabling CONFIG_SETSID and CONFIG_CTTYHACK would be a big plus, as then you can interrupt command in case it doesn't return (like ipconfig -c dhcp or ping). Being forced to reboot just because of one inappropriate command is not a very happy option. See also http://bugs.debian.org/528234 ;) Is it really needed? Maybe setsid is enough? /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#348314: busybox-udeb: please enable getopt
16.01.2006 12:39, Colin Watson wrote: Package: busybox-udeb Version: 1:1.01-4 Severity: wishlist Please enable CONFIG_GETOPT in config-udeb and config-udeb-linux. I need this in order to merge Kickstart support; it's not feasible to do this properly in shell without the help of getopt (I tried), and a C implementation would be significantly bigger. Isn't it sufficient to use getopts ash built-in? It does approx. the same thing (with different usage), and it's already enabled in busybox. 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#348314: busybox-udeb: please enable getopt
10.03.2011 17:09, Otavio Salvador wrote: On Thu, Mar 10, 2011 at 12:12, Colin Watson cjwat...@debian.org wrote: On Thu, Mar 10, 2011 at 02:37:20PM +0300, Michael Tokarev wrote: Isn't it sufficient to use getopts ash built-in? No, getopts can't deal with long options, which Kickstart requires. What is the binary size change enabling it? The size is relatively small: textdata bss dec hex filename 22273014988684 232912 38dd0 current 22435415028684 234540 3942c +long_getopt +1624 bytes for long_getopt 22465615068684 234846 3955e +long_getopt+mktemp +302 bytes for mktemp (+long_getopt - CONFIG_GETOPT + CONFIG_GETOPT_LONG_OPTIONS) Note that we already have chown with long options and cp with long options in busybox udeb. textdata bss dec hex filename 22248014948680 232654 38cce current -longopts +getopt 22146214948680 231636 388d4 current -longopts -1268 bytes for getopt_long (-longopts - i disabled long options for cp and chown). /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#133212: busybox-static: busybox will not exec /sbin/init
Version: 1:1.17.3-8 10.02.2002 17:32, Vincent Beffara wrote: Package: busybox-static Version: 1:0.60.2-3.1 Severity: normal I'm trying to build a boot CD using initrd and busybox as a shell. The initrd contains : [] exec /sbin/init --- I boot using 'init=/linuxrc' so that linuxrc gets PID 1. /sbin/init is a real file in the new root fs - but busybox will not use it, it will instead switch to its own version of init, hence not recognize /etc/inittab. This was effect of prefer applets and standalone shell options or maybe a patch to that old busybox. It has been fixed long long time ago, so closing this bug now, before it hits its 10th anniversary. 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#609231: kvm: improper handling of commandline arguments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 severity 609231 wishlist retitle 609231 filename parser in qemu chokes on colons tags 609231 + upstream confirmed thanks 07.01.2011 18:59, Michal Suchanek wrote: Package: qemu-kvm Version: 1:0.12.5+dfsg-5 Severity: normal Apparently kvm cannot handle CD images with odd names. While I don't insist that such image names should work it points at some bug in argument handling which is something to be avoided. $ ln -s clonezilla-live-1.2.6-58-amd64.iso\?r\=http\:%2F%2Fsourceforge.net%2Fprojects%2Fclonezilla%2Ffiles%2Fclonezilla_live_testing%2F1.2.6-58%2F clonezilla-live-1.2.6-58-amd64.iso $ kvm -cdrom clonezilla-live-1.2.6-58-amd64.iso $ kvm -cdrom clonezilla-live-1.2.6-58-amd64.iso\?r\=http\:%2F%2Fsourceforge.net%2Fprojects%2Fclonezilla%2Ffiles%2Fclonezilla_live_testing%2F1.2.6-58%2F qemu: could not open disk image clonezilla-live-1.2.6-58-amd64.iso?r=http:%2F%2Fsourceforge.net%2Fprojects%2Fclonezilla%2Ffiles%2Fclonezilla_live_testing%2F1.2.6-58%2F: Invalid argument This happens when filename contains a colon character (:), which is documented to be used as a delimiter between a protocol name and actual filename (URL). Note that kvm supports http as file store protocol, so you can specify -cdrom http://host/some/where/file.iso Currently kvm does not have a way to escape the delimiter, nor does it check if the portion of filename before the delimiter makes any sense as protocol name (for the above example, chars like - and . and ? before : surely makes the protocol name invalid). I'm downgrading this bug to a wishlist for a better filename parser in qemu, plus better diagnostics. Thanks! /mjt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iJwEAQECAAYFAk0tXdwACgkQUlPFrXTwyDiq9AP/XRRvMY185txcY5Y9ChJl8loY dCgDpenFm/98HSlOvgNAkMRizbUJEfuUgRx5iSRLna/edRyZIrGOqNR/09ZL+8Z9 Ijq0IzT8H8jSU88j2Uj8eJaEIzSWACmePyz4IhMcejOnixmFm0hdKNiJ3LIiPubE 2TgWYNtMgxZvyDz7CF0= =/TMS -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558361: zero instead of real stats (vmstat and others) after counter wrap
Package: procps
Version: 1:3.2.8-2tls
Severity: normal
Tags: patch
Most in-kernel counters nowadays are 64bits, even on 32bit arches.
But procps uses unsigned long internally, and strtoul() to convert
from text to number. In case of overflow, strtoul() returns -1,
and comparing two -1s always results in 0. So with large in-kernel
counters vmstat stops displaying statistics properly, leading to
false system troubleshooting analisys.
The attached patch provides a very simple fix for this, which does
not solve the root problem but makes it disappear in almost all
cases (it only occurs when the actual counter overflows, in which
case the difference between this and previous will be around
2**32, only once, and this difference is easy to understand) s
that it stops becoming an issue. Real fix involves major code
changes.
Thanks.
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (990, 'stable'), (60, 'testing'), (50, 'unstable'), (1,
'experimental')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.32-rc7-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/bash
Versions of packages procps depends on:
ii initscripts 2.86.ds1-61Scripts for initializing and shutt
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libncurses5 5.7+20081213-1 shared libraries for terminal hand
ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip
Versions of packages procps recommends:
ii psmisc22.6-1 Utilities that use the proc filesy
procps suggests no packages.
-- no debconf information
after some uptime, vmstat starts displaying zeros in various
stats columns instead of real numbers. This is because most
kernel counters are now 64bit but in procps they're 32bits on
i386 (and other 32bit arches). To convert values read from
files in /proc, procps uses strtoul(), which returns -1 in
case of overflow. But comparing two -1s always gives 0, so
the statistics becomes useless.
The real fix to this and other similar problems is to always
use 64bit counters in procps. But that requires alot more
changes all over the places.
But much simpler fix is possible too: changing strtoul() to
strtoull() which returns 64bit integer. Hopefully that one
will not overflow. We convert the result into our native
unsigned long by truncating the most significant part if
necessary. This way, we will still have proper least
significant part, which is enough for comparison with
previous value of the same nature, and substraction gives
good result.
Signed-off-by: Michael Tokarev m...@tls.msk.ru
--- procps-3.2.8/proc/sysinfo.c.orig2008-03-24 07:33:43.0 +0300
+++ procps-3.2.8/proc/sysinfo.c 2009-11-28 11:53:45.816811421 +0300
@@ -606,3 +606,3 @@ void meminfo(void){
if(!found) goto nextline;
-*(found-slot) = strtoul(head,tail,10);
+*(found-slot) = (unsigned long)strtoull(head,tail,10);
nextline:
Bug#570245: resolved
Christophe Benz wrote: Experimental package kvm 88+dfsg-3 resolved the bug for me. JFYI: kvm package is dead. It should be removed from all the archives completely. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562052: Correctly identify touchpads
Dmitry Torokhov wrote: [] This is exactly what happens, to me and to the original bug reporter -- we both are running 32bit userspace and 64bit kernel. [] Does the following patch fixes it for you guys? No, Dmitry, it does not. It's buggy. With this patch applied, the bits are all completely wrong. # hexdump -C /sys/devices/platform/i8042/serio4/input/input6/capabilities/key 00 00 00 00 20 30 20 00 00 00 00 00 20 30 20 00 | 0 . 0 .| 0010 20 30 20 00 20 30 20 00 20 30 20 00 0a | 0 . 0 . 0 ..| 001d # hexdump -C /sys/devices/platform/i8042/serio4/input/input6/capabilities/ev 00 0a |..| 0002 The same's in /proc/bus/input/devices, obviously. I'll try to take a look at the patch tomorrow. 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#562052: Correctly identify touchpads
Dmitry Torokhov wrote: On Sun, Jan 10, 2010 at 02:01:08AM +0300, Michael Tokarev wrote: Dmitry Torokhov wrote: [] This is exactly what happens, to me and to the original bug reporter -- we both are running 32bit userspace and 64bit kernel. [] Does the following patch fixes it for you guys? No, Dmitry, it does not. It's buggy. With this patch applied, the bits are all completely wrong. [] Doh, amazing what min/max mixup will do. The patch below should fix that. With the fixup applied on top of previous patch, the whole thing appears to work correctly. 2.6.32-amd64: 32bit grep: /sys/devices/platform/i8042/serio4/input/input6/capabilities# grep . * abs:1103 ev:b ff:0 key:6420 0 7000f 0 0 0 0 0 0 0 0 led:0 msc:0 rel:0 snd:0 sw:0 64bit grep: /sys/devices/platform/i8042/serio4/input/input6/capabilities# ~/grep . * abs:1103 ev:b ff:0 key:6420 7000f 0 0 0 0 led:0 msc:0 rel:0 snd:0 sw:0 A few questions still: o I think the 'key' attribute used to be shorter previously, eliminating unnecessary trailing zeros, but it is not anymore. Just curious. o How about other systems such as sparc 32/64 or power 32/64? I'm not sure the patch is endian-clean. 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#527371: qemu-kvm: diff for NMU version 0.11.0+dfsg-1.1
Stefano Zacchiroli wrote: Dear maintainer, I've prepared an NMU for qemu-kvm (versioned as 0.11.0+dfsg-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. It's fixed in git on collab-maint for quite some time ago, in `mjt-changes' branch, by explicitly invoking `make clean' in kvm/userspace/. I'm trying to push it, together with other fixes and an update to 0.11.1. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562052: Correctly identify touchpads
Martin Pitt wrote: Michael Tokarev [2009-12-25 1:51 +0300]: Not really :( We print in groups of longs so it is either 32 or 64 bits worth of data per number. Ok, I stand corrected. I verified the issue with 32bit kernel, and there, hald works as expected, listing `synaptics' as x11_driver and correct input.touchpad capability. Just to have all the data, could you please find the input device number (from lshal, as you did before), and send the output of cat /sys/class/input/inputX/capabilities/key (replace X with the particular input device number) under a 32 and 64 bit system? It's shown in /proc/bus/input/devices too. Sure I can, here we go: 32bit: 6420 0 7000f 0 0 0 0 0 0 0 0 64bit: 6420 7000f 0 0 0 0 Also, do you get correct or wrong ID_INPUT_* flags for the synaptics device in udevadm info --export-db|less? I expect it to be wrong as well, since it's pretty much the same code. in both cases userspace is 32bit, but kernel bitness is different: 32bit: P: /devices/platform/i8042/serio4/input/input9 E: UDEV_LOG=3 E: DEVPATH=/devices/platform/i8042/serio4/input/input9 E: PRODUCT=11/2/7/12b1 E: NAME=SynPS/2 Synaptics TouchPad E: PHYS=isa0060/serio4/input0 E: EV==b E: KEY==6420 0 7000f 0 0 0 0 0 0 0 0 E: ABS==1103 E: MODALIAS=input:b0011v0002p0007e12B1-e0,1,3,k100,101,102,103,110,111,112,145,14A,14D,14E,ra0,1,18,1C,mlsfw E: SUBSYSTEM=input 64bit: P: /devices/platform/i8042/serio4/input/input9 E: UDEV_LOG=3 E: DEVPATH=/devices/platform/i8042/serio4/input/input9 E: PRODUCT=11/2/7/12b1 E: NAME=SynPS/2 Synaptics TouchPad E: PHYS=isa0060/serio4/input0 E: EV==b E: KEY==6420 7000f 0 0 0 0 E: ABS==1103 E: MODALIAS=input:b0011v0002p0007e12B1-e0,1,3,k100,101,102,103,110,111,112,145,14A,14D,14E,ra0,1,18,1C,mlsfw E: SUBSYSTEM=input Udev merely collects text attributes from sysfs, so it's expected that all the attributes are the same as kernel says they are. udev/hal already use sizeof(long) to determine the length of a long word length, and it doesn't seem to happen everywhere. (I am running a 64 bit kernel/userspace and get correct results). It works correctly with 32bit userspace and 32bit kernel too. I might have misunderstood you, but did you actually try to run a 64 bit kernel under 32 bit userspace? That would explain the bug, since hal/udev were compiled with the assumption that sizeof(long) == 4, while the kernel prints those in groups of 8 bytes. This is exactly what happens, to me and to the original bug reporter -- we both are running 32bit userspace and 64bit kernel. Note that the difference between ioctl and sysfs is exactly in this kind of issues: to be independent of word size... ;) So if we want to support mixed kernel/userspace word lenghts, we need to change the logic to do a dynamic word size detection based on uname(). Not uname please. There should be a better way :) For example, see the number of words shown in key attribute: for 32bits it's two times of 64bits... /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562125: Windows XP install bluescreens after copying files when I enable kvm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Never mind. I checked the Debian packages page, looked at the readme and discovered my error. I had assumed that qemu-kvm added kvm to the qemu package when in fact it replaces it, but also requires a different command to start. Can you elaborate please? What did you mean by requires a different command to start ? The binary name did not change with package name change. It was kvm and it still is kvm, in /usr/bin/kvm. What command change do you mean? Thanks! /mjt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iJwEAQECAAYFAks7zfsACgkQUlPFrXTwyDhxyAP/cZTLZ3BW+hT4cF7bS6VIX2uT +pcpTPcpFXi9bjhL52o81Ydm59FDmmr2DxEoGEeg0BC62Sj7uKGKd0v23+Oyu7Tp ktn7c/w8jOboCqBMl+qRp6yuUjwvrs8/sO/zwyZV0AscXM5QlxQXzeaqZFD8By6c bAcfIlG3jO1I+m6WILk= =vUZd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560853: #560853: qemu-kvm: embeds qemu and kvm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael, You states that your package embeds source code from both qemu and kvm. This is wrong. Kvm *is* qemu, just another variant of it, modifications to qemu to support native CPU execution on CPUs with virtualization extensions. The two projects, while very close to each other, are separate. Kvm pushes changes back to qemu, but currently acts like staging area for the kvm-related features, before they're pushed to qemu. The end goal is to have only one project, qemu. But as of now, it isn't the case. So we've 3 choices in Debian: a) do not provide kvm(*) at all. This is wrong, since the project is very useful (qemu in its current form does not work as well). Note that first goal of Debian is its users. b) do not provide qemu but package only kvm. This does not work right, since kvm version does not care that much about other architectures, focusing only on kvm- related features and often breaking other things, including running on x86 without kvm enabled. Yes that's bugs, but they're of lower priority for kvm. c) package both and wait till either the two projects merges or when b) will be more appropriate than now. (*) By kvm here and everywhere I mean either kvm or qemu-kvm which is the same thing but one is development snapshots and another is stable series. I think we're doing the best thing possible at this time -- providing both and letting the user to choose which one works best for him: if he wants native virtualisation here's kvm, if he wants to emulate other architecture, it's qemu. But in any way, saying that the project embeds both qemu and kvm is wrong, since, again, kvm *is* qemu. Thanks. /mjt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iJwEAQECAAYFAks7zA0ACgkQUlPFrXTwyDhsVQP8DNAcJmwD9LPtunvioCuamQog 5e8inrRzj/zLaXlsb2SsV2Np2Em35Fv9laznO7JmkTlCfsPjAExRzf1hlmCdBD1r zGhgtmQJLgBfE+CThHjvUN5QJg2t3La7Fg7bPOcTxuc/cOx/Ff+nrYpyuI+9ISYL /Q5QW0PpzVcmIkeVDXU= =G/Z6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540686: /etc/init.d/kvm: Stop action seems unnecessary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Actually this action was useful and still may be. The problem here is that there are other virtualization solutions (virtualbox, vmware and others) who may use the same CPU support as kvm uses. At least in the past, up to and including kernel 2.6.31, it wasn't possible to run vmware when kvm modules were loaded. So the stop action here served as a workaround, a shorthand for rmmod kvm-amd or rmmod kvm-intel before running anything else that requires the same CPU extensions. Now with 2.6.32+ and updated vmware modules that becomes unnecessary, but I'd say let it be there for some time, when we will be sure different virtualisation solutions does not fight with each other any more. Thanks. /mjt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iJwEAQECAAYFAks702wACgkQUlPFrXTwyDjxKQQAxcb0YrzUaFYvB9LwgTsnLxE4 CKZSkr+13u+YiKa7ufdAAdRXxGNF/sixLf7Wpxu3KUQLQo+bJI8yZ9uiWGmvDcGQ 1O5sevbcfQZHfAJZZ5WTsq90euofl5whD7Wdg3zWelTk09wwa24W0xizGCl69CFa voUcU5QDDHwRt/m5qQw= =hyqV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528077: #528077: kvm - fails to setup timer interrupt via io-apic
tags 528077 + moreinfo unreproducible thanks Bastian, is the problem you reports in #528077 is still relevant for current qemu-kvm (0.11.0 and above)? I tried using XEN in a kvm guest even before version 0.84 (against which you filed the original bugreport), I think it was 0.81 (I might be wrong), and it worked just fine with xen-3.4 (I didn't try earlier versions). I tried to run xen inside kvm again, in both current and 0.84 versions, but I can't reproduce the problem. 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#560059: #560059: qemu-kvm: cirrus graphics stopped working with Windows XP
tags + moreinfo unreproducible thanks Marcus, can you please tell me what's your (host) graphics card and host kernel version? I suspect the problem really is not in kvm but in host video driver, but I might be completely wrong. There are several points about this issue. o in 0.88 and 0.11.0, the guest screen has been made resizeable. This leads to quite alot of confusion, and I think it's actually an under-developed feature - the resizability of guest screen is a good thing to have sometimes, but there should be a way to restore the correct (1:1) size. Again, I don't know if you're talking about this issue or something else -- sure thing when you resize guest screen you'll see somewhat garbled display. o As I mentioned before, I've seen very similar issue here, and it turned out to be bug in kernel radeon drm driver. The issue occured infrequently enough so that I didn't notice it anywhere but in kvm, where it happened 100% of the time. Unfortunately I can't find the relevant info right now, but will do once you reply to the first question. o There are many, many installs out there with working cirrus logic emulation. Me included - I've a shitload of windowsXP guests here, most are running with -vga cirrus (the default), and most were survived upgrade to current kvm version without any noticeable issues. In short, I can't reproduce your issue... ;) 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#566028: Bug#566032 Bug#566028: qemu-kvm: Unstated dependency on libgssapi_krb5.so.2
Adrian Irving-Beer wrote: Package: qemu-kvm Version: 0.11.1+dfsg-1 Severity: serious Justification: Policy 3.5 In Debian bug #566028, I reported that the latest version of qemu-system had an unstated dependency on libgssapi_krb5.so.2. It seems that qemu-kvm now has the same dependency now as well: % ldd /usr/bin/kvm | grep gss libgssapi_krb5.so.2 = /usr/lib/libgssapi_krb5.so.2 (0x7f7b648e) neither kvm nor qemu link directly with libgssapi. In order to examine a binary dependencies, use `objdump -p' command. Here it is for the kvm binary from 0.11.1+dfsg-1 package: $ objdump -p usr/bin/kvm ... Dynamic Section: NEEDED libm.so.6 NEEDED libpthread.so.0 NEEDED librt.so.1 NEEDED libz.so.1 NEEDED libasound.so.2 NEEDED libpulse-simple.so.0 NEEDED libgnutls.so.26 NEEDED libsasl2.so.2 NEEDED libbluetooth.so.3 NEEDED libpci.so.3 NEEDED libutil.so.1 NEEDED libSDL-1.2.so.0 NEEDED libX11.so.6 NEEDED libncurses.so.5 NEEDED libvdeplug.so.2 NEEDED libcurl-gnutls.so.4 NEEDED libc.so.6 NEEDED libpulse.so.0 ... ldd reports _all_ needed libraries, including the ones needed by all the above. In our case, it looks like gssapi come from libcurl-gnutls.so.4: $ objdump -p /usr/lib/libcurl-gnutls.so.4 ... NEEDED libgssapi_krb5.so.2 Please verify that libcurl3-gnutls package lists the requiriments properly on your system. As in that bug, unless I have package libgssapi-krb5-2 installed (which is not depended on by any package on my system), I cannot run qemu-kvm. This is not kvm or qemu bug. A package A should not list all deps of another package B on which A depends. I.e., if A depends on B, and B depends on C, A should only include B in the Depends: field, and not C. Because it is possible to upload a new version of B which will depend on entirely different package D, or even conflict on C. Listing C as a dependency of A will be a bug in this case. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566388: qemu-kvm: Early Kernel Panic trying to mount NFS-Root
Michael Tokarev wrote: Michael Goetze wrote: Package: qemu-kvm Version: 0.11.1+dfsg-1 Severity: important I'm trying to install virtual machines with FAI, and for this purpose have installed a full FAI infrastructure (using dnsmasq) on my host system, listening on br0. Currently I'm booting 2.6.31-grml64, but I have tried this with standard Lenny kernels as well, both 32- and 64-bit. I create the virtual machine with: virt-install -n test -r 256 --vcpus=1 --os-variant=debianlenny --pxe --disk path=/dev/vg2/test_root --disk path=/dev/vg2/test_swap -w bridge=br0,mac=52:54:00:25:00:00,model=virtio --vnc The PXE boot works after a few tries (the boot ROM always claims to not get an answer the first few times) and then the kernel boots. Once the I use PXE here quite alot (with kvm and with real hardware) but never saw anything like you describe. Probably worth the effort to experiment with various guest network drivers, but again: not the case here. initrd proclaims Begin: Mounting root filesystem ... I get the following kernel messages: NET: Registered protocol family 17 Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: init Not tainted 2.6.31-grml63 #1 Call Trace: [81529290] panic+0xc6/0x17c [8105e03b] ? put_files_struct+0xc9/0xec [8105935b] ? mmput+0x49/0xde [81068125] ? exit_ptrace+0xbf/0x153 [8105f950] do_exit+0x8d/0x6a6 [8105fff0] do_group_exit+0x87/0xb4 [81060047] sys_exit_group+0x2a/0x42 [810120b2] system_call_fastpath+0x16/0x1b So your init (process with pid=1) is exiting while it should not do so. This is not the cause, this is the symptom. The cause is a few lines before. I have quite a bit of experience with FAI and I have never seen this problem on real hardware. On my host system I am running squeeze with 2.6.32-trunk-amd64 and a triple core AMD Phenom 8650. I've no idea what is FAI. But in any case it does not look like a bug related in any way to qemu-kvm. There's something wrong with your initrd, and I don't think that BTS (Bug Tracking System) is a good place to find out what it is. You have to find out why your initrd/initramfs (this is either kinit or the initial shell in the initrd or something like that) exits instead of calling the real init. The fact that the previous line is NET: Registered protocol family 17, which means the kernel finished initializing networking right before the panic, suggests that your initrd does not attempt to mount anything nor is trying to load any device drivers. Usually you get this message right before initrd enters the game. But you state that you do have some messages from initrd (Begin: Mounting root filesystem). Your initrd is not functioning correctly. It's probably a good idea to reassingn this to fai instead. As I said above, I don't know what FAI is. Now I looked. And it seems like it's FAI who creates the initrd, not you. Hence it might be FAI issue. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513717: startup script chowns files writable by nsd thus making nsd user==root
Package: nsd
Version: 2.3.7-1.1
Severity: security
In /etc/init.d/nsd script there's a construct (repeated twice):
[ -n ${nsd_user} ] chown ${nsd_user}: ${dbfile}
where dbfile defaults to /var/lib/nsd/nsd.db, or in chroot, and
the parent directory of it (/var/lib/nsd) is owned by $nsd_user
(default nsd).
The whole chroot idea is to protect system from someone who managed
to get a way to break into the system utilizing a bug in - in this
case - nsd daemon. Assuming that in worst case, an attacker can
execute arbitrary code on the system as a user running nsd.
Now suppose the attacker changes /var/lib/nsd/nsd.db to be a
symlink to /etc/password. And after the next restart or reload
of nsd, that file's owner will be happily changed to nsd. With
all bad stuff follows it.
I can only guess where this chown come from, in the first place.
But I *think* that proper solution will be to always run
`nsdc rebuild' as that user instead of root. Note that running
it as root so that the result is written into nsd-owned directory
does no good too.
This is, as far as I can see, Debian-specific security bug.
-- System Information:
Debian Release: 5.0
APT prefers stable
APT policy: (990, 'stable'), (500, 'testing'), (50, 'unstable'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.28-i686smp (SMP w/2 CPU cores)
Shell: /bin/sh linked to /bin/bash
Versions of packages nsd depends on:
ii adduser 3.110 add and remove users and groups
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libssl0.9.8 0.9.8g-14 SSL shared libraries
ii libwrap0 7.6.q-16 Wietse Venema's TCP wrappers libra
nsd recommends no packages.
nsd 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#520095: removes the toplevel mountpoint directories and fails to start the next time
Jan Christoph Nordholz wrote: Hi Michael, (the following holds for both autofs v4 and v5) usually the daemon creates these directories on startup and removes them on exit. If you do not want that to happen, it suffices to mark the directory as u-w: ] r...@apocatequil:/etc# grep ^/misc /etc/auto.master ] /misc /etc/auto.misc ] r...@apocatequil:/etc# ls -ld /misc ] ls: cannot access /misc: No such file or directory ] r...@apocatequil:/etc# /etc/init.d/autofs start ] Starting automount: done. ] r...@apocatequil:/etc# ls -ld /misc ] drwxr-xr-x 2 root root 0 2009-07-25 16:08 /misc ] r...@apocatequil:/etc# /etc/init.d/autofs stop ] Stopping automount: done. ] r...@apocatequil:/etc# ls -ld /misc ] ls: cannot access /misc: No such file or directory ] r...@apocatequil:/etc# mkdir /misc; chmod 0555 /misc ] r...@apocatequil:/etc# ls -ld /misc ] dr-xr-xr-x 2 root root 4096 2009-07-25 16:08 /misc ] r...@apocatequil:/etc# /etc/init.d/autofs start ] Starting automount: done. ] r...@apocatequil:/etc# ls -ld /misc ] drwxr-xr-x 2 root root 0 2009-07-25 16:08 /misc ] r...@apocatequil:/etc# /etc/init.d/autofs stop ] Stopping automount: done. ] r...@apocatequil:/etc# ls -ld /misc ] dr-xr-xr-x 2 root root 4096 2009-07-25 16:08 /misc ] r...@apocatequil:/etc# # ls -l /misc /bin/ls: cannot access /misc: No such file or directory # cat /etc/auto.master /misc /etc/auto.misc # /etc/init.d/autofs start Starting automounter: done. # ls -l /misc /bin/ls: cannot access /misc: No such file or directory # tail -n2 /var/log/daemon.log Jul 25 18:22:57 gandalf automount[4547]: failed to create iautofs directory /misc Jul 25 18:22:57 gandalf automount[4547]: /misc: mount failed! # mount | grep -w / rootfs on / type rootfs (rw) /dev/sda1 on / type ext3 (rw,noatime,commit=30,data=ordered) # mkdir /misc # /etc/init.d/autofs start Starting automounter: done. # ls -l /misc total 0 # /etc/init.d/autofs stop Stopping automounter: done. # ls -l /misc /bin/ls: cannot access /misc: No such file or directory # mkdir -m 0755 /misc # ls -ld /misc drwxr-xr-x 2 root root 4096 Jul 25 18:24 /misc # /etc/init.d/autofs start Starting automounter: done. # ls -l /misc total 0 # /etc/init.d/autofs stop Stopping automounter: done. # ls -l /misc /bin/ls: cannot access /misc: No such file or directory So I presume the real problem here is that autofs cannot create the /net mountpoint upon startup. This is not a very usual case, because the only possibility I can think of is a NFS root with root squashing enabled (but how can it remove that directory then when it's going down?)... I'm not sure if this justifies grave. But I admit that it's not in the documentation (at least nowhere I know of) and that the initscript startup exit code is not helpful. As I mentioned before, the ONLY way to stop it from removing the top-level dir is to chattr+i it. So it *is* grave bug, making the package unusable. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520095: removes the toplevel mountpoint directories and fails to start the next time
Jan Christoph Nordholz wrote: Hi, As I mentioned before, the ONLY way to stop it from removing the top-level dir is to chattr+i it. ah, autofs4 indeed removes the directory even without write permission (v5 doesn't), I thought I'd checked that, too. But this behaviour has been around for ages, and I still don't understand why it fails for you (i.e. why is root unable to create /net, but perfectly able to remove it later?). Could you please explain what's going on there? No idea. If I were knew, I'd attach a patch for this issue. The code is quite.. funny and fragile, I tried to understand it right before submitting a bugreport but that wasn't quite successful. I ran it under strace - pure automountd, without any startu scripts but with the same args. It never ever tried to mkdir or rename. It created two random dirs in /tmp, mounted a tmpfs over one of them (running mount(8)), bind-mounted it on second dir, next did stat(/misc) (which returned ENOENT) and immediately gave up returning it can't mount /misc. I just installed autofs5 (I didn't know it exist) - and that one seems to be ok (it gives me another error in daemon.log, like this: Jul 25 19:23:45 gandalf automount[15097]: \ syntax error in nsswitch config near [ syntax error ] , but that's another matter). I've one guess pending still: my /tmp is tmpfs, maybe it checks for st_rdev somehow, and does not do anything useful if /tmp and / are on different filesystems? But I've to run now, can't verify it today.. perhaps tomorrow. 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#493599: pushing udns into squeeze
Thadeu Lima de Souza Cascardo wrote: Hello, folks. Hello. Thank you for bringing this issue up again. While udns has no entered etch or lenny, we should reconsider that situation in the case of squeeze. Some software in Debian depends or may be improved while depending on udns. libapache2-mod-defensible, for example, was rebuilt without udns for the lenny release. Now, jabberd2 depends on udns and can only go into a stable release if udns goes too or udns stops being used by it. Although Michael didn't think it was ready for release some three years ago and not a lot has changed in the library since then, it has being used by these software in response to its usefulness and quality. I don't know if Michael has reconsidered, but I'd like to know his opinion as of now. Yes I had plans for udns, but now I don't think I'll ever finish it. Maybe, who knows, but well... I'm watching another project, ldns, which is a base for unbound and nsd nameservers (see www.unbound.net). It is much more adequate for today, in my opinion anyway, than my attempt with udns. And almost as easy to use as udns, but at the same time much more correct and also supports DNSSEC out of the box. Regarding the security issue, which Michael has already answered about in his comments in the source code even before people have published their exploit results and many servers had their code changed to make them safer, I don't think udns requires any change. All the (similar) security issues with stub resolvers w.r.t. on LANs are real issues, unfortunately. Yes I added that famous comment to the code explaining it (and it was interesting to re-read it today ;) and noticed that it's very difficult to deal with the issue on LAN with its speeds. On LAN, the only way to solve all the issues of this sort is to use DNSSEC or IPSEC between a stub resolver and nearby (on the LAN) recursive resolver, or better yet, between local (on localhost) caching resolver and nearby (on LAN) recursive resolver. As I mentioned earlier, ldns has DNSSEC support out of the box. It's a stub resolver and many other stub resolvers have not changed anything in response to the announcement of the increased possibility of an attack. And stub resolvers should use secure servers in a secure environment/network. I think we could release some notes in README.Debian regarding this and close this bug altogether and let udns move into squeeze and keep it there for the release, allowing other packages to follow, including jabberd2. Given the fact that I did not update the code in all these years (oh well)... I've nothing against including udns into Debian anymore. The only concern I had is that I planned to change the API. But it looks like it wont be done and better alternatives emerges. 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#581355: qemu-kvm: Fails to start with Cannot boot from non-existent NIC error
tags 581355 + pending thanks Örjan Persson wrote: Package: qemu-kvm Version: 0.12.3+dfsg-4 Severity: important Tags: squeeze sid After upgrading kvm and using the version in lenny-backports, KVM fails to start and giving a Cannot boot from non-existent NIC error. I found this problem reported here[1] and after applying upstream commits 4e9e9d6e0a68f1691bcdcc80601a9a1bc2954736 ... 4e9e9d6e0a68f1691bcdcc80601a9a1bc2954736 the problem went away. [1] http://lists.gnu.org/archive/html/qemu-devel/2010-04/msg00378.html It's in qemu-kvm debian package git tree for quite some time already, pending upload: http://git.debian.org/?p=collab-maint/qemu-kvm.git;a=commit;h=8737e37ee07e1ac66db44a4d0908356ebd6b48b3 I'm attaching a working patch. Feel free to do whatever with it. As mentioned in qemu-devel, it's only the patch #2 which fixes the problem. Yeah. I'm about to release a new qemu-kvm package. 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#581631: please build cfdisk with ncurses, not libslang
Package: util-linux Version: 2.16.2-0 Severity: wishlist It's been over 12 years already since cfdisk is built against libslang. It can be built either againt libncurses or libslang. The interface it shows is basically the same. Reasoning: o libslang2 can be made optional, since the only reason why it is currently marked as required is due to the fact that it is used by util-linux package. On all my systems for example, cfdisk (util-linux) the only user of libslang. o to my taste anyway, ncurses interface looks more usual, since it uses the same interface as many other screen-based programs uses (editors, file browsers and even dpkg frontends like dialog). I even used to rebuild util-linux packages a while ago to replace slang with ncurses. This is just a (small) wishlist. People has their own preferences for such things, mine is with ncurses, but sure thing others may disagree. 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#581355: qemu-kvm: Fails to start with Cannot boot from non-existent
19.05.2010 12:52, Vladimir Kozhukalov wrote: I've included sid repositories in my /etc/apt/sources.list (debhttp://ftp.debian.org/debian sid main non-free contrib) and updated my cache (aptitude update)? but there is no new package qemu-kvm_0.12.4+dfsg-1, but only 0.12.3+dfsg-4 is the newest version available. Could you point where can I find new version? It will be available after next archive/mirror rebuild, as far as I understand. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582434: qemu-kvm: VNC console does not accept keyboard input once PXELinux loads during PXE boot
20.05.2010 22:20, Matthew Ernisse wrote: Package: qemu-kvm Version: 0.12.4+dfsg-1 Severity: important We originally noticed this problem on Ubuntu Lucid (lp:579596) but it appears to also effects the current version of qemu-kvm (which we have backported to lenny). Upon booting a VM and PXELinux loading keyboard input is no longer accepted (so one cannot select the target). If one connects to the serial console at this point, and then either inputs an invalid target or boots a valid target the VNC console begins to accept keystrokes again. Interesting. I run net-booted guests a _lot_ here. A few days ago I were developing a sort of live CD but run from network, so that a diskless workstation can boot from network and run something useful on it. Quite naturally I use KVM for that since it's easier to (re)boot, and quite naturally it is using pxelinux. And quite naturally I use the same qemu-kvm package as I work with when maintaining it... I never had any problems with network at that place, and I always use pxelinux boot menu to choose the thing to run on the diskless (kvm) workstation, and edit kernel command line while in pxelinux. I used all supported network adaptors, and I re-verified it again before replying - it all works for me. We are using the following version of libvirt ii libvirt-bin 0.8.1-1 ii libvirt0 0.8.1-1 the XML for this domains is as follows: Um. How this translates into kvm command line please? interface type='bridge' mac address='02:00:00:60:a7:70'/ source bridge='br0'/ target dev='vnet22'/ model type='e1000'/ address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/ /interface Um. You know that officially e1000 does not work due to bug in etherboot bootrom for it -- see #581356. What did you use for the e1000 bootrom? I used the one that comes with qemu-kvm-0.12.4 official sources. Does the problem occurs with other network cards? 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#582493: block device corruption with virtio and 1Tb device size
Package: qemu-kvm Version: 0.12.4+dfsg-1 Severity: important Tags: patch upstream pending There's upstream patch for a data corruption that occurs with 1Tb disk images and virtio-blk. Fix is available at http://marc.info/?l=qemu-develm=127436114712437 . /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575439: qemu-kvm - Windows NT4 virtual machine stops with BSOD during boot
21.05.2010 16:01, Michael Tokarev пишет: This is a guest issue, not kvm issue. See http://marc.info/?l=qemu-develm=127439130431895 And indeed, I tried to set up winNT on two other machines here, it fails the same way during boot, with the same STOP: 0x0003 error (incorrect multi-processor configuration). It has been fixed in service pack 6. There's also a workaround in kvm, to use -cpu qemu64,level=1 (the level is what matters, not qemu64). Correction. The original bugreport, about 0x003E code, is something to do with the windows NT reacting to (slight) hardware change it is running on. This is something outside of scope of kvm - yes, kvm changes, and virtual devices it emulates for the guest changes too, it's just like hardware upgrade (usually leads to reinstall of windowsNT). At least upgrading kvm from -72 to -0.12 does not make windowsNT install performed in kvm-72 to break, it must be some even older than -72 install. The other problem reported in this thread, about 0x03 error code, which leads to inability to reinstall the system, is also due to windowsNT bug. The recommended course of things is to reinstall windows NT (or find a way to fix the issue inside it without reinstalling), for which -cpu qemu64,level=1 is a work-around for the bug mentioned. After install, either continue using the level=1 suboption, or apply service pack 6, which will fix the bug in the guest. Just to clarify things... 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#575439: qemu-kvm - Windows NT4 virtual machine stops with BSOD during boot
21.05.2010 16:14, Michael Tokarev wrote: 21.05.2010 16:01, Michael Tokarev wrote: This is a guest issue, not kvm issue. See http://marc.info/?l=qemu-develm=127439130431895 And indeed, I tried to set up winNT on two other machines here, it fails the same way during boot, with the same STOP: 0x0003 error (incorrect multi-processor configuration). It has been fixed in service pack 6. There's also a workaround in kvm, to use -cpu qemu64,level=1 (the level is what matters, not qemu64). Correction. The original bugreport, about 0x003E code, is something to do with the windows NT reacting to (slight) hardware change it is running on. This is something outside of scope of kvm - yes, kvm changes, and virtual devices it emulates for the guest changes too, it's just like hardware upgrade (usually leads to reinstall of windowsNT). At least upgrading kvm from -72 to -0.12 does not make windowsNT install performed in kvm-72 to break, it must be some even older than -72 install. The other problem reported in this thread, about 0x03 error code, which leads to inability to reinstall the system, is also due to windowsNT bug. Ehm. Another correction. the two problems: 0x003E - invalid smp configuration this is the guest bug seen during install, fixed in sp6 0x001E - inaccessible boot device this is what you get by changing (even virtual) hardware on a machine running windows NT Since the bug mentions both problems. Please excuse me for the noise: the number of digits in the error codes puzzled me :) The recommended course of things is to reinstall windows NT (or find a way to fix the issue inside it without reinstalling), for which -cpu qemu64,level=1 is a work-around for the bug mentioned. After install, either continue using the level=1 suboption, or apply service pack 6, which will fix the bug in the guest. Just to clarify things... 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#579751: network problem with Solaris 10u8 guest
21.05.2010 16:36, Harald Dunkel wrote: On 05/12/10 12:41, Harald Dunkel wrote: Hi folks, I am trying to run Solaris 10u8 as a guest in kvm (kernel 2.6.33.2). Problem: The virtual network devices don't work with this Solaris version. Short update: Virtualbox 3.1.6 seems to be more reliable in this case. I forgot to send my testing results. I installed solaris from sol-10-u8-ga-x86-dvd.iso. It were with the default rtl8138 NIC, and the installer configured rtls0 interface (so it actually at least recognizable). I left `ping -f $solaris-ip' process running for whole night - it were still running in the morning without any visible issues, at 100% CPU usage (2 cores - for ping, host kernel and kvm processes). Now, it looks like I forgot solaris enough to being unable to set up new network driver, so I can't easily switch to e1000. Maybe reinstall will be faster for me. So, basically, I can't reproduce the issue. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579751: network problem with Solaris 10u8 guest
22.05.2010 10:29, Harald Dunkel wrote: It took me some time to get back into Solaris, too. To change the network driver: After changing the kvm configuration you should boot Solaris at usual. It will complain about some services not being run, and put you into single user mode. It does not enter single-user mode, it boots as usual (but indeed, it complains about some services not started). I can perform reconfiguration boot - either by touching /reconfigure or adding -r kernel command line in grub (I used solaris some 10 years ago and still remember _some_ things). Now you can run ifconfig -a to get the new network device name (e.g. e1000g0. Rename /etc/hostname.rtl0 to /etc/hostname.e1000g0. Rename /etc/dhcp.rtl0 to dhcp.e1000g0. Reboot. But the problem is that even after reconfigure step, it does not show anything but lo0 in `ifconfig -a' output. More, prtdiag -v shows no add-on cards at all, even if the NIC is configured and running and network is working. I don't remember something like lspci in linux... I should have mentioned that my virtual Solaris hosts are supposed to get IP address and host name via DHCP. Sorry, I forgot. I will try a fixed address when I am back in the office. I used dhcp too. But it does not matter (or should not matter), since once the IP address is obtained, the NIC will be configured the same way as when using static address. I left `ping -f $solaris-ip' process running for whole night - it were still running in the morning without any visible issues, at 100% CPU usage (2 cores - for ping, host kernel and kvm processes). No ping replies have been lost? There were several replies lost. Ping -f prints a dot when it sends a packet out and backspace when receives a reply. There were several dots printed after whole night of pings 4 or 5, I don't remember. I re-installed it yesterday, using -nic ...,model=e1000. Setup procedure recognized Intel NIC and configured it. I didn't try to stress-test it for whole night, but quick (over 5 minutes) ping -f didn't reveal anything, it all just works. But now when I re-read the whole bugreport thread, I've an idea. Let's try it, both of us. I used the old, traditional, qemu -net..-net syntax. You're using libvirt which uses the new -netdev syntax. Let's try the other way around, -netdev for me and -net for you, and share the results. 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#579968: Emulated mice should support a horizontal scroll wheel
I opened a bugreport against upstream qemu, see https://bugs.launchpad.net/qemu/+bug/584155 Apparently upstream is _very_ interested in 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#579751: network problem with Solaris 10u8 guest
tags 579751 + unreproducible severity 579751 minor thanks 22.05.2010 11:29, Michael Tokarev wrote: 22.05.2010 10:29, Harald Dunkel wrote: [] I left `ping -f $solaris-ip' process running for whole night - it were still running in the morning without any visible issues, at 100% CPU usage (2 cores - for ping, host kernel and kvm processes). No ping replies have been lost? There were several replies lost. Ping -f prints a dot when it sends a packet out and backspace when receives a reply. There were several dots printed after whole night of pings 4 or 5, I don't remember. I re-installed it yesterday, using -nic ...,model=e1000. Setup procedure recognized Intel NIC and configured it. I didn't try to stress-test it for whole night, but quick (over 5 minutes) ping -f didn't reveal anything, it all just works. But now when I re-read the whole bugreport thread, I've an idea. Let's try it, both of us. I used the old, traditional, qemu -net..-net syntax. You're using libvirt which uses the new -netdev syntax. Let's try the other way around, -netdev for me and -net for you, and share the results. I left it running with the new network configuration, like this: kvm \ -device rtl8139,netdev=n0 \ -netdev type=tap,ifname=tap-kvm,id=n0 \ -hda sol.raw -monitor stdio -m 512 for several hours with `ping -f $guest_ip' running on another terminal. It works as expected, no single packet were lost during this time. So I'm marking this as unreproducible by now, and downgrade the severity to minor 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#578672: qemu-kvm: kvm kills my screen saver / power manager
06.05.2010 04:29, Gary Dale wrote: When I use virt-manager to start the Windows XP virtual machine, the screen saver works normally. However, I'm back having to use the kvm command to launch it and the screen power saver issue is back. Can you please try setting SDL_VIDEO_ALLOW_SCREENSAVER=1 before starting kvm, something like this: $ SDL_VIDEO_ALLOW_SCREENSAVER=1 kvm and see if it fixes the problem? See http://www.libsdl.org/faq.php?action=listentriescategory=9#90 Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
