Bug#919694: elogind triggers ACPI suspend on laptop lid close, contrary to prior acpi-support configuration
On Wed, Mar 20, 2019 at 01:37:50PM +, Mark Hindley wrote: > Tags: moreinfo > > On Sat, Jan 19, 2019 at 10:34:02AM +, Mark Hindley wrote: > > One issue I will pass upstream is why the Docked status is taking so long to > > update. Once docked elogind should be ignoring lid events by default. (I > > know > > this doesn't address the underlying issue in this case, but it would no > > longer > > be problematic.) > > Zygo, > > We have not yet found why the Docked status is slow to update and we don't > have > access to any hardware to reproduce. > > Are you able to build a debugging version of elogind and post the log? The hardware has been returned to the end user (with no elogind package). About 1 in 4 laptops that I see needs to have ACPI suspend disabled or limited, either because of broken switch sensors, or because the ACPI firmware or Linux kernel crashes before completing resume. On desktops...I've never personally seen a desktop running Linux successfully suspend and resume afterwards, but I'm told they exist. We don't have time to debug ACPI firmware--the defect rate is just too high. We just disable suspend by default, and re-enable it only on hardware where it is known to work. Earlier: > Users should be warned of potential interactions among the two > packages, but not deprived of the freedom to handle and resolve those > interactions if they like to, IMHO. Maybe it should be in the package's news or debconf, so the admin is notified when the package is installed for the first time on an existing system (as opposed to a fresh install). A statement something like: "Installing this package may change the way ACPI events such as lid-close are handled. If you know that's going to be a problem on your hardware, you should do something about this now." That would give a chance to defer or abort the installation while workarounds get lined up. If it was debconf, you could even ask whether suspend should be enabled and put the installer's answer in the config file. Bonus points for something like "I'm going to try 10 suspend/resume cycles now, if the system crashes, reboot it, and when the installer runs again, I'll disable suspend for you." };-> > Thanks > > Mark signature.asc Description: PGP signature
Bug#919694: elogind triggers ACPI suspend on laptop lid close, contrary to prior acpi-support configuration
On Fri, Jan 18, 2019 at 09:27:27PM +, Mark Hindley wrote: > On Fri, Jan 18, 2019 at 03:19:11PM -0500, Zygo Blaxell wrote: > > I get: > > [snipped] > > > HandleLidSwitch=suspend > > HandleLidSwitchDocked=ignore > > Docked=yes > > > It seems there is some significant lag (several seconds, maybe a minute > > or two) before "Docked" changes to the correct value. The "Docked" state > > definitely does not update while the rapid suspends are happening. I can > > wake the laptop with the docked keyboard spacebar, but it immediately > > goes back to sleep again, at least 20 times. After that it starts > > ignoring the spacebar and stays asleep until I undock and open the lid. > > > > I encountered a similar problem on another laptop some months ago, where > > that laptop's lid switch was always reporting closed. That system was > > running systemd, and the fix was to set HandleLidSwitch=ignore, but in > > a different configuration file from what elogind uses. > > And does that fix work for elogind too if you set it in > /etc/elogind/logind.conf? It seems to. Given that elogind conflicts with and functionally replaces pieces of systemd, wouldn't it make sense for them to use the same config file? I proactively install systemd configuration fragments on systems running sysvinit to avoid cases precisely like this one, where some piece of systemd gets split off and suddenly appears on a sysvinit system during an apt-get. Had elogind read the systemd-logind config file instead of its own, this could have been avoided (or at least resolved sooner by replaying a previously documented solution). > > I had configured acpi-support to take no suspend > > action on lid close, docked or otherwise. elogind appears to be > > unaware of acpi-support's overlapping functionality, and the maintainer > > scripts for elogind don't adjust elogind's configuration to disable > > lid/power/hibernate key handling if there's another ACPI event handler > > already installed on the system. Both can be installed at the same time, > > and by default both will try to suspend the system, so in the worst case > > you could get two suspend/resume cycles per lid close (which is a great > > way to find ACPI firmware bugs). > > Yes, maybe elogind and acpi-support should just conflict. That seems unfortunate as the two packages are not exact functional replacements of each other, but it would solve this particular problem. I'd expect systemd and acpi-support to conflict for the same reason, but they don't. Maybe the problem is solved there in a different way? Or maybe installing systemd on a machine with previously configured acpi-support has the same bug. > Mark signature.asc Description: PGP signature
Bug#919694: elogind triggers ACPI suspend on laptop lid close, contrary to prior acpi-support configuration
On Fri, Jan 18, 2019 at 05:00:19PM +, Mark Hindley wrote: > On Fri, Jan 18, 2019 at 11:18:27AM -0500, Zygo Blaxell wrote: > > Source: elogind > > Version: 239.3-4+debian1 > > Severity: important > > > > Dear Maintainer, > > > > I installed elogind on a laptop because it was a dependency of other > > packages. When I attempted to use the laptop in a docking station > > with the lid closed, it immediately and repeatedly went into suspend, > > despite my prior configuration of acpi-support to not take any action > > on lid close. > > Zygo, > > Thanks for this. > > Could you reinstall elogind and post the output of 'loginctl show-seat' when > in > the docking station? I am particularly interested in the values of Docked, > HandleLidSwitch and HandleLidSwitchDocked. I get: EnableWallMessages=no KillUserProcesses=no RebootToFirmwareSetup=no IdleHint=yes IdleSinceHint=0 IdleSinceHintMonotonic=0 InhibitDelayMaxUSec=5s UserStopDelayUSec=0 HandlePowerKey=poweroff HandleSuspendKey=suspend HandleHibernateKey=hibernate HandleLidSwitch=suspend HandleLidSwitchDocked=ignore HoldoffTimeoutUSec=30s IdleAction=ignore IdleActionUSec=30min PreparingForShutdown=no PreparingForSleep=no Docked=yes RemoveIPC=yes RuntimeDirectorySize=1649360896 InhibitorsMax=8192 NCurrentInhibitors=0 SessionsMax=8192 NCurrentSessions=0 It seems there is some significant lag (several seconds, maybe a minute or two) before "Docked" changes to the correct value. The "Docked" state definitely does not update while the rapid suspends are happening. I can wake the laptop with the docked keyboard spacebar, but it immediately goes back to sleep again, at least 20 times. After that it starts ignoring the spacebar and stays asleep until I undock and open the lid. I encountered a similar problem on another laptop some months ago, where that laptop's lid switch was always reporting closed. That system was running systemd, and the fix was to set HandleLidSwitch=ignore, but in a different configuration file from what elogind uses. Note that docked state tracking is irrelevant to the original issue I was reporting. I had configured acpi-support to take no suspend action on lid close, docked or otherwise. elogind appears to be unaware of acpi-support's overlapping functionality, and the maintainer scripts for elogind don't adjust elogind's configuration to disable lid/power/hibernate key handling if there's another ACPI event handler already installed on the system. Both can be installed at the same time, and by default both will try to suspend the system, so in the worst case you could get two suspend/resume cycles per lid close (which is a great way to find ACPI firmware bugs). signature.asc Description: PGP signature
Bug#919694: elogind triggers ACPI suspend on laptop lid close, contrary to prior acpi-support configuration
Source: elogind Version: 239.3-4+debian1 Severity: important Dear Maintainer, I installed elogind on a laptop because it was a dependency of other packages. When I attempted to use the laptop in a docking station with the lid closed, it immediately and repeatedly went into suspend, despite my prior configuration of acpi-support to not take any action on lid close. Using inotifywatch I found that elogind was the process that wrote the suspend command to /sys/power/state. Purging the elogind package resolves the issue (and also doesn't require removing the package I intended to install). -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (500, 'stable'), (189, 'testing'), (179, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.91-zb64+ (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init)
Bug#916313: perl: open "|command" does not set up child process's stdin correctly on perl 5.28 (5.24 is OK)
Package: perl Version: 5.28.1-3 Severity: normal Dear Maintainer, The following one-line perl script fails: perl -e 'close(STDIN); open(CHILD, "|wc -l")' On Debian stable (5.24.1-3+deb9u5) it produces: $ perl -e 'close(STDIN); open(CHILD, "|wc -l")' 0 but on Debian testing/unstable (5.28.1-1, 5.28.1-3) it produces: $ perl -e 'close(STDIN); open(CHILD, "|wc -l")' wc: 'standard input': Bad file descriptor 0 wc: -: Bad file descriptor Other variants of open to a command (e.g. open(CHILD, "-|") || exec ...) are similarly broken if STDIN is closed. This wreaks havoc on Perl filter scripts that pass data between child shell commands: the commands unexpectedly get EBADF when reading from stdin, or they unexpectedly use one of the other files they open as their stdin. *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Noticed Perl scripts operating incorrectly after upgrading Perl packages to Debian testing (apt-get -uf install perl -t testing) or unstable. * What exactly did you do (or not do) that was effective (or ineffective)? Reverted to snapshot of root filesystem with earlier Perl version. * What was the outcome of this action? Everything works again. * What outcome did you expect instead? No regression on a core Perl feature. *** End of the template - remove these template lines *** -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (500, 'stable'), (189, 'testing'), (179, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.71-zb64+ (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages perl depends on: ii dpkg 1.18.25 ii libperl5.285.28.1-3 ii perl-base 5.28.1-3 ii perl-modules-5.28 5.28.1-3 Versions of packages perl recommends: ii netbase 5.4 Versions of packages perl suggests: pn libb-debug-perl ii libterm-readline-gnu-perl 1.35-4+b1 ii libterm-readline-perl-perl1.0303-1 ii make 4.1-9.1 ii perl-doc 5.28.1-1 ii perl-modules-5.24 [liblocale-codes-perl] 5.24.1-3+deb9u5 -- no debconf information
Bug#762297: [pkg-cryptsetup-devel] Bug#762297: cryptsetup: fails to create tmp filesystem due to false positive from blkid
On Tue, Oct 07, 2014 at 07:24:37PM +0200, Jonas Meurer wrote: Am 02.10.2014 um 16:43 schrieb Zygo Blaxell: 1. Create an encrypted tmpfs header. A simple static header (or a stripped down LUKS header) can be unambiguously recognized by blkid or even cryptdisks itself[...] Mh, interesting idea. You mean to prefix the encrypted data by an identifying header on the plain device? The precheck could skip the un_blkid check in case that this header is detected. Yes. The presence of the header would state positively that the partition is intended for use with a tmpfs, as opposed to relying on each of the growing list of blkid tests to provide a negative result when fed random data. It fits well with tools that rely on blkid to identify partitions. tmpfs/swap encrypted partitions are currently not recognized automatically, but everything else is (except for plain dm-crypt non-tmpfs, which is intentionally unrecognizable). While this solution would be reliable for plain dm-crypt encrypted tmpfs and swap partitions, it wouldn't work for any other plain dm-crypt encrypted partitions - especially as users do use plain dm-crypt exactly for the reason that it doesn't write an identifying header (plausible deniabilty). That's my biggest argument against this solution. I wouldn't expect the new header to be used for non-tmpfs partitions. cryptdisks_start would not need to format the partition, and once the partition is correctly decrypted it will most likely have a signature that can be recognized by blkid (not to mention the mount or swapon). We already have LUKS when there is a need for identification prior to decryption. The new header would mean this partition is safe to format and use for irretrievably encrypted data with a random key in a way that blkid can distinguish from other recognized parition types with certainty. It's a special case that is only needed for encrypted tmpfs and swap. Feel free to provide patches [...] Any ideas on a header format? LUKS headers provide most of what we need--places to store key size, cipher, data offset, and other parameters, and it's already recognized by blkid. It could be as simple as extending cryptsetup to store and understand Hash spec: random (instead of the usual sha1) and load a random key instead of processing key slots. On the other hand, getting those changes into cryptsetup might not be simple. 3. blkid could be more strict about identifying a HFS filesystem to avoid false positives[...] That's the solution I like the most, it's the easiest one for me ;) No, jokes aside. If detection of HFS actually can be improved in blkid, then that should be done, regardless whether one of your proposed solutions from above will be added to the cryptsetup package or not. I could make an attempt, but I don't have any real HFS filesystems to test with, and I'd worry about false negatives too. I could use Linux fs/hfs code as a reference but I'm not even sure blkid and Linux completely agree on what a HFS filesystem is. I'd prefer to leave that to someone who knows what they're doing. Also there would still be a small probability of failure. Some blkid recognizers look at 32 bits, which could still fail a few times in a very large user population. signature.asc Description: Digital signature
Bug#762297: [pkg-cryptsetup-devel] Bug#762297: cryptsetup: fails to create tmp filesystem due to false positive from blkid
On Thu, Oct 02, 2014 at 01:16:16PM +0200, Jonas Meurer wrote: Am 20.09.2014 um 22:07 schrieb Zygo Blaxell: un_blkid is not a suitable precheck for plain dm-crypt 'tmp' or 'swap' devices due to the potential for false positives from previous runs on the same device. That's really unfortunate. To my knowledge, you're the first one who hit this issue so far. Yay I win! ;) Out of every million attempts to create a tmp filesystem there should be about 31 failures. I won't be the last. Unfortunately, no better solution than un_blkid is known to me to prevent serious data loss in case of device rearrangement or missconfiguration with plain dm-crypt devices and automated swap or tmpfs creation. Thus I'll mark the bug as wontfix. There are at least three ways to fix this: 1. Create an encrypted tmpfs header. A simple static header (or a stripped down LUKS header) can be unambiguously recognized by blkid or even cryptdisks itself. cryptdisks can offset the encrypted payload by the length of that header. Since the data is ephemeral there is no backward compatibility issue. For upgrades, run the existing un_blkid check (it is the best we have so far, even though it's still bad), then install the header when a few tmp FS is created and use the header from then on. 2. When the underlying devices are identified by UUID (or through some layer that uses UUID, such as LVM or md-raid) the precheck can be skipped, since rearranging devices will not change their UUIDs. UUID has enough bits to avoid random collisions. un_blkid could detect this case the same way lsblk does, and ignore false positives from blkid. 3. blkid could be more strict about identifying a HFS filesystem to avoid false positives. It looks like blkid detects HFS after inspecting only 16 bits of the block device, and it ignores implausible superblock parameter values (there are plenty it could be checking). HFS is an obsolete filesystem, so the probability of encountering a real HFS in the field is certainly less than the probability of a false positive ID in random data. Maybe the bug should be reassigned to the blkid (util-linux) package. ;) In case that you really know what you're doing, you can set precheck=/bin/true in the crypttab and prevent the precheck for particular plain dm-crypt devices that way. This is what I have had to do. Changing both CRYPTDISKS_CHECK and CRYPTDISKS_PRECHECK to /bin/true in /etc/default/cryptdisks was not sufficient. This bug potentially leads to information disclosure in some configurations. This is true for encrypted tmp filesystems if the rootfs is not encrypted. Still, the boot scripts print clear error messages and the boot process should fail in that case anyway. It should be obvious that things don't work as expected in that case ;) That is not what happens. There are error messages, but the boot process continues past them. The boot could be stopped by a fsck failure when mounting the tmp filesystem, except that the fsck would normally be skipped in that case (why would you fsck a filesystem you just created?). The system operates normally except for leaking data and having the wrong filesystem on /tmp. If we weren't auditing the systems regularly, the first sign of trouble in production would probably be an unexpected ENOSPC on /. signature.asc Description: Digital signature
Bug#762297: cryptsetup: fails to create tmp filesystem due to false positive from blkid
Package: cryptsetup
Version: 2:1.6.6-1
Severity: normal
un_blkid is not a suitable precheck for plain dm-crypt 'tmp' or 'swap'
devices due to the potential for false positives from previous runs
on the same device. This bug potentially leads to information disclosure
in some configurations.
I had an example of this today:
root@host:~# grep tmp /etc/crypttab
tmp /dev/vgroup/tmp /dev/urandom
size=256,cipher=aes-xts-plain,tmp=btrfs
root@host:~# cryptdisks_start tmp
Starting crypto disk...tmp (starting)...
tmp: the precheck for '/dev/vgroup/tmp' failed: - The device /dev/vgroup/tmp
contains a filesystem type hfs. ... (warning).
tmp (failed)...failed.
root@host:~# blkid /dev/vgroup/tmp
/dev/vgroup/tmp: UUID=dba39fe4-922e-3fc4-963c-835245a69787
LABEL=0(M-G^W^Yr~M-2 m{lM- M-8tM-^L^Z0
[nM-BM-^Y))M-^TvM-rM-;tuM-^O^CM-^YM-T'M-^\M-`xM-^]M-eM-I;M-9M-^[M-`y^\M-\M-^UM-OM-IsM-LBtM-9M-$1M-^M
TYPE=hfs
'/dev/vgroup/tmp' contained an encrypted filesystem with a random key
(as it always does). On the last run, the encrypted data matched the
blkid logic for an HFS filesystem. The system involved proceeded to boot
using the root filesystem for /tmp, resulting in /tmp files written to
storage without encryption.
-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz root=/dev/mapper/vgroup-root
rootflags=compress,subvol=/current ro
-- /etc/crypttab
# target name source device key file options
swap/dev/vgroup/swap/dev/urandom
size=256,cipher=aes-xts-plain,swap
tmp /dev/vgroup/tmp /dev/urandom
size=256,cipher=aes-xts-plain,tmp=btrfs
-- /etc/fstab
# /etc/fstab: static file system information.
#
# file system mount point type options
dump pass
/dev/vgroup/root/ autoskip_balance,compress
0 0
/dev/mapper/tmp /tmpauto
compress,noatime,nosuid,nodev 0 0
/dev/mapper/swapnoneswapsw,pri=50
0 0
-- lsmod
Module Size Used by
rpcsec_gss_krb539679 0
nfsv4 320976 1
algif_skcipher 17269 0
af_alg 14217 1 algif_skcipher
tun27226 16
softdog13319 1
iTCO_wdt 13480 0
iTCO_vendor_support13419 1 iTCO_wdt
xt_nat 12681 6
xt_tcpudp 12884 35
xt_owner 12534 1
xt_state 12578 7
ip6table_mangle12700 0
iptable_mangle 12695 1
xt_LOG 17723 7
xt_limit 12711 7
ip6table_nat 13015 0
nf_conntrack_ipv6 18894 1
nf_defrag_ipv6 34712 1 nf_conntrack_ipv6
nf_nat_ipv613213 1 ip6table_nat
iptable_nat13011 1
nf_conntrack_ipv4 20106 8
nf_defrag_ipv4 12702 1 nf_conntrack_ipv4
nf_nat_ipv413199 1 iptable_nat
nf_nat 25065 5
nf_nat_ipv4,nf_nat_ipv6,xt_nat,ip6table_nat,iptable_nat
nf_conntrack 100330 8
nf_nat,xt_state,nf_nat_ipv4,nf_nat_ipv6,ip6table_nat,iptable_nat,nf_conntrack_ipv4,nf_conntrack_ipv6
ip6table_filter12815 0
ip6_tables 26808 3 ip6table_filter,ip6table_mangle,ip6table_nat
iptable_filter 12810 1
ip_tables 27026 3 iptable_filter,iptable_mangle,iptable_nat
x_tables 27889 12
ip6table_filter,ip6table_mangle,ip_tables,xt_tcpudp,xt_limit,xt_owner,xt_state,xt_LOG,xt_nat,iptable_filter,iptable_mangle,ip6_tables
ppdev 17635 0
lp 17874 0
rfcomm 69126 0
bnep 19538 2
bluetooth 408222 10 bnep,rfcomm
6lowpan_iphc 18632 1 bluetooth
cpufreq_userspace 12920 0
cpufreq_stats 13351 0
cpufreq_powersave 12618 0
cpufreq_conservative15314 0
binfmt_misc17431 1
uinput 17566 1
ctr13049 2
ccm17730 2
fuse 91068 1
af_packet 35772 8
nfsd 288113 2
auth_rpcgss58269 2 nfsd,rpcsec_gss_krb5
nfs_acl12741 1 nfsd
nfs 236432 2 nfsv4
lockd 93420 2 nfs,nfsd
fscache 106183 2 nfs,nfsv4
sunrpc276579 14
nfs,nfsd,rpcsec_gss_krb5,auth_rpcgss,lockd,nfsv4,nfs_acl
ipv6 370918 70
ip6table_mangle,nf_defrag_ipv6,nf_nat_ipv6,ip6table_nat,nf_conntrack_ipv6
dummy 12960 0
tcp_illinois 12974 1730
dm_crypt 27366 4
arc4 12615 2
snd_hda_codec_realtek65855 1
snd_hda_codec_generic66957 1 snd_hda_codec_realtek
rtl8192cu 98169 0
rtl_usb22773 1 rtl8192cu
rtlwifi88192 2
Bug#586388: executables built with libc6-dev 2.11.1-3 segfault in string handling functions
On Sat, Jun 19, 2010 at 05:59:03AM +, Clint Adams wrote: On Fri, Jun 18, 2010 at 10:55:52PM -0400, Zygo Blaxell wrote: After upgrading from libc6-dev 2.10.2-9 to 2.11.1-3, executables built with libc6-dev segfault on startup. gdb says that the segfault happens in string functions such as strrchr or strlen. The executables build without error. Are you using binutils-gold or are you using a ridiculously old version of binutils? I'm using whatever the Debian package dependencies for libc6-dev et al tell aptitude to use. ;) That would happen to be 2.18.1~cvs20080103-7. signature.asc Description: Digital signature
Bug#586388: executables built with libc6-dev 2.11.1-3 segfault in string handling functions
On Sat, Jun 19, 2010 at 10:51:49AM -0400, Zygo Blaxell wrote: That would happen to be 2.18.1~cvs20080103-7. Sorry, that would be *binutils* 2.18.1~cvs20080103-7. binutils-gold is not installed. signature.asc Description: Digital signature
Bug#586388: executables built with libc6-dev 2.11.1-3 segfault in string handling functions
On Sat, Jun 19, 2010 at 03:06:30PM +, Clint Adams wrote: On Sat, Jun 19, 2010 at 10:54:36AM -0400, Zygo Blaxell wrote: Sorry, that would be *binutils* 2.18.1~cvs20080103-7. binutils-gold is not installed. binutils from stable does not work with libc6-dev = 2.11 Currently the package libc6-dev Conflicts: binutils ( 2.17cvs20070426-1). Can that be upgraded to Conflicts: binutils (= 2.18.1~cvs20080103-7) or even Conflicts: binutils ( 2.20.51.20100617-1)? signature.asc Description: Digital signature
Bug#586388: executables built with libc6-dev 2.11.1-3 segfault in string handling functions
Package: libc6-dev Version: 2.11.1-3 Severity: critical Justification: breaks unrelated software After upgrading from libc6-dev 2.10.2-9 to 2.11.1-3, executables built with libc6-dev segfault on startup. gdb says that the segfault happens in string functions such as strrchr or strlen. The executables build without error. The version currently in unstable (2.11.2-1) seems to have identical problems. Unlike the other users who filed the currently open critical bugs against libc6, I don't seem to have any difficulty executing programs that were built against earlier versions of libc6-dev--i.e. all my existing software still works, but when I build anything new from source, the new binaries segfault. Changing or unsetting LANG, LC_CTYPE, et al. did not seem to affect this bug. Downgrading libc6-dev (and libc6, libc-bin, libc-dev-bin, locales, and some other related packages) to 2.10.2-9 fixes the problem for me. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable'), (189, 'testing'), (179, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31.13-zb64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libc6-dev depends on: ii libc-dev-bin 2.11.1-3Embedded GNU C Library: Developmen ii libc62.11.1-3Embedded GNU C Library: Shared lib ii linux-libc-dev 2.6.26-22lenny1 Linux support headers for userspac Versions of packages libc6-dev recommends: ii gcc [c-compiler] 4:4.3.2-2 The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.6-9The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.2-25 The GNU C compiler ii gcc-4.2 [c-compiler] 4.2.4-6The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.2-1.1 The GNU C compiler Versions of packages libc6-dev suggests: ii glibc-doc 2.7-18lenny4 GNU C Library: Documentation ii manpages-dev3.05-1 Manual pages about using GNU/Linux -- 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#569505: git-core: 'git add' corrupts repository if the working directory is modified as it runs
On Wed, Mar 03, 2010 at 09:12:04AM -0600, Jonathan Nieder wrote: Zygo Blaxell wrote: If the index is then committed, the corrupt blob cannot be checked out (or is checked out with incorrect contents, depending on which tool you use to try to get the file out of git) in the future. Do you remember more details? Some commands might be worth changing to be more permissive (to more easily recover from corruption) or strict (to more easily catch it). I think whether you get no object vs. corrupt object depends on whether the object is loose or packed. Different git versions behave slightly differently, though I can't get a corrupt data case at all at the moment. git checkout gives you a working tree where corrupt files are missing, and an index where corrupt files are marked deleted. git filter-branch aborts when it sees the corrupt data if you have a tree-filter, but if you only have an index-filter it will ignore corrupt objects unless you do something to force it to examine their contents. filter-branch index-filter won't help you if other objects have been deltaified based on corrupt objects--at that point, recovery is very hard. I've only seen that occur on pack files that were corrupted outside of git, though, so it's not a Git problem. Surprisingly, it's possible to clone, fetch, push, pull, and sometimes even gc the corrupted repo several times before anyone notices the corruption. For push, I do not think it is worth the slowdown; better to spend the time needed to be robust in hash-object. On the other hand, it does not seem overly burdensome to me to make ???git gc??? imply a ???git fsck --no-full???. That wouldn???t be needed to catch on-disk corruption (the CRC32 already does that), but it could be a good idea anyway. Cloning the bug. git gc will notice the corruption if it's packing corrupt loose objects. It fails to notice if it's not packing loose objects, e.g. because the loose objects are not old enough. push and fetch cases are covered by the receive.fsckObjects config variable. It defaults to off, but if it's turned on then it will catch the corruption at push/fetch time. Obviously this doesn't help if you have a corrupt repo and you never push/fetch it anywhere, and it also doesn't help you if you don't change the setting from the default. If the affected commit is included in a merge with history from other git users, the only way to fix it is to rebase I assume you used rebase -f? Clever. I reset to one commit before the corruption, then manually extract the surviving changes between the commit after the corruption and the next commit that modifies the corrupted file. After that usually all future commits can be cherry-picked. After that gets pushed, everyone *else* working on the project has to rebase their changes. If it does not fail, git filter-branch --tree-filter : should accomplish the same thing without making the history linear, though it does not scale well to deep histories. It should be possible to devise an appropriate index-filter for this, too, if that is too slow. The problem isn't speed--the problem is tree-filter's requirement to check out the data. It can't, because the data is corrupt. filter-branch does check in that case, and it should (otherwise a filesystem on unreliable media could spray undetected junk into your repo). (or come up with a blob whose contents match the affected SHA1 hash somehow). Yes, depending on how the file was changing this could be easy or hard to do. /usr/share/doc/git-doc/howto/recover-corrupted-blob-object.txt is about something like this. It's usually hard when the file was in some transient state during the SHA1 calculation. ;) ???Something like git that can handle snapshots??? tends to be something people want every once in a while. Of course, git has some problems for these uses: - racy add, as you noticed; Only Git seems to have that. SVN and CVS didn't. Or maybe they did, but they lacked the internal integrity-checking mechanisms to detect it. - checkout is not atomic or close to atomic; Not a problem in my use cases. Checkouts are very rare, usually only occurring after some disaster or other. - large files are not supported well (but there is some work going on to change this); Large is relative to the size of the system doing the work. 15 years ago, 1MB was a large file; today, 1MB is on the high end of small. - uncompressible files are not supported well; Much better than CVS. - file metadata is not tracked; Usually not a problem. - directories with many entries are not supported well; ext3 doesn't support that use case well either. Fortunately it rarely comes up. - rename detection works poorly with binary files; Still better than CVS or SVN. - no quick way to throw away old history. I don't intend to throw away old history at all. Some of my snapshot repos go back more than 10 years (they have
Bug#569505: git-core: 'git add' corrupts repository if the working directory is modified as it runs
On Wed, Mar 03, 2010 at 11:49:37AM -0600, Jonathan Nieder wrote: Zygo Blaxell wrote: I assume you used rebase -f? Clever. [...] I guess I was expecting it to be easier because the object data is all there; it just has the wrong SHA-1. That is not the case in other corruption scenarios, so maybe it is silly to spend too much time thinking about how to deal with it, but I think it???s worth trying anyway (at least maybe to write a script for contrib/). The problem with rebase -f is that rebase normally expects to do a diff between commit and commit~ for each commit to be included in the rebase. At some point in that process it must try to retrieve a corrupt object, and stops. It might be nice to have an option on filter-branch that tries to extract what it can by brute force, and removes everything else. If a parent commit is inaccessible, create a new root commit instead. One variant nukes any file that can't be retrieved (so corrupt files end up deleted), another keeps corrupt data (so corrupt files end up containing whatever deflate/unpack can salvage). Ideally this feature would write a log file explaining exactly what objects were deleted from which commits. The problem isn't speed--the problem is tree-filter's requirement to check out the data. It can't, because the data is corrupt. filter-branch does check in that case, and it should (otherwise a filesystem on unreliable media could spray undetected junk into your repo). It just does checkout-index, clean, and update-index; the only obvious difference from a checkout + (munge) + add I can see is the clean. Exactly--the checkout step notices the bad SHA1 on the corrupt objects, and causes filter-branch to abort. Or did I miss something here? It's usually hard when the file was in some transient state during the SHA1 calculation. ;) Ah, I guess this happens with e.g. text editor swapfiles? Ick. Anything that uses sqlite or Berkeley DB. Anything that modifies files in-place instead of using the Unix create-temporary-write-close-rename idiom. gzip does it too, if you're writing from a pipe to a plain file (it rewinds to fill in the size header at the beginning). Lots of foreign software (ported from OSes other than Unix) modifies data in place. - racy add, as you noticed; Only Git seems to have that. SVN and CVS didn't. Or maybe they did, but they lacked the internal integrity-checking mechanisms to detect it. [...] CVS and RCS I have no clue about. Neither has any integrity checking that I'm aware of. - checkout is not atomic or close to atomic; [...] True enough --- if you can wait to checkout until nothing cares about what???s happening with those files (e.g. a shutdown), there???s no problem. Usually I check them out somewhere else entirely, e.g. onto a replacement system disk. A snapshot repo is normally supposed to observe, not modify. Sure, as far as version control systems go, git is a good back up systems, but what about backup systems? Sadly, I don???t even know enough to say what replicating snapshot-based backup system is the standard of care so to speak. I have a multi-terabyte snapshot-based backup filesystem. git is a long way away from managing that. Git can handle workloads like the entire contents of a firewall machine's filesystem or everything in ~/.firefox except [Cc]ache/* just fine though, as long as it runs on a host with enough RAM. Compression, integrity checking, and replication are the big wins for me. The compression advantage of Git vs. other tools is not trivial. Git outperforms Subversion by something like 200:1. I think any good backup system should have these things. Your other reasons are more compelling. An unstated reason --- that git, like cvs and svn, is a tool developers already often know quite well how to use --- is also probably important. If Linus's Git video at Google is anything to go by, Git's object store was designed to be the kind of distributed data repository that can survive events ranging from incompetent IT departments to deliberate sabotage. That's the minimum feature set I'd expect from my backup software. ;) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569505: git-core: 'git add' corrupts repository if the working directory is modified as it runs
Package: git-core Version: 1:1.6.6.1-1 Severity: important 'git add' will happily corrupt a git repo if it is run while files in the working directory are being modified. A blob is added to the index with contents that do not match its SHA1 hash. If the index is then committed, the corrupt blob cannot be checked out (or is checked out with incorrect contents, depending on which tool you use to try to get the file out of git) in the future. Surprisingly, it's possible to clone, fetch, push, pull, and sometimes even gc the corrupted repo several times before anyone notices the corruption. If the affected commit is included in a merge with history from other git users, the only way to fix it is to rebase (or come up with a blob whose contents match the affected SHA1 hash somehow). It is usually possible to retrieve data committed before the corruption by simply checking out an earlier tree in the affected branch's history. The following shell code demonstrates this problem. It runs a thread which continuously modifies a file, and another thread that does 'git commit -am' and 'git fsck' in a continuous loop until corruption is detected. This might take up to 20 seconds on a slow machine. #!/bin/sh set -e # Create an empty git repo in /tmp/git-test rm -fr /tmp/git-test mkdir /tmp/git-test cd /tmp/git-test git init # Create a file named foo and add it to the repo touch foo git add foo # Thread 1: continuously modify foo: while echo -n .; do dd if=/dev/urandom of=foo count=1024 bs=1k conv=notrunc /dev/null 21 done # Thread 2: loop until the repo is corrupted while git fsck; do # Note the implied 'git add' in 'commit -a' # It will do the same with explicit 'git add' git commit -a -m'Test' done # Kill thread 1, we don't need it any more kill $! # Success! Well, sort of. echo Repository is corrupted. Have a nice day. I discovered this bug accidentally when I was using inotifywait (from the inotify-tools package) to automatically commit snapshots of a working directory triggered by write events. I tested this with a number of kernel versions from 2.6.27 to 2.6.31. All of them reproduced this problem. I checked this because strace shows 'git add' doing a mmap(..., MAP_PRIVATE, ...) of its input file, so I was wondering if there might have been a recent change in mmap() behavior in either git or the kernel. git 1.5.6.5 has this problem too, but some of the error messages are different, and the problem sometimes manifests itself as silent corruption of other objects (e.g. if someone checks out a corrupt tree and then does 'git add -u' or 'git commit -a', they will include the corrupt data in their commit). -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable'), (189, 'testing'), (179, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31.8-zb64 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages git-core depends on: ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libcurl3-gnutls7.18.2-8lenny3Multi-protocol file transfer libra ii libdigest-sha1-perl2.11-2+b1 NIST SHA-1 message digest algorith ii liberror-perl 0.17-1Perl module for error/exception ha ii libexpat1 2.0.1-4+lenny3XML parsing C library - runtime li ii perl-modules 5.10.1-9 Core Perl modules ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages git-core recommends: ii less 418-1 Pager program similar to more ii openssh-client [ssh-client] 1:5.1p1-5 secure shell client, an rlogin/rsh ii patch 2.5.9-5Apply a diff file to an original ii rsync 3.0.3-2fast remote file copy program (lik Versions of packages git-core suggests: pn git-arch none (no description available) ii git-cvs 1:1.6.6.1-1 fast, scalable, distributed revisi pn git-daemon-run none (no description available) ii git-doc 1:1.6.6.1-1 fast, scalable, distributed revisi pn git-emailnone (no description available) pn git-gui none (no description available) ii git-svn 1:1.6.6.1-1 fast, scalable, distributed revisi ii gitk 1:1.6.6.1-1 fast, scalable, distributed revisi pn gitweb none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe.
Bug#534908: possibly symlink attack due to client-connect script
Why does a simple shell script create a vulnerability here? A shell script should already be using code like this: set -e tmp=`mktemp` echo blah blah $tmp echo more blah blah $tmp mv -f $tmp $1 for two reasons: using mktemp avoids a symlink race condition, and the rename-temporary-file-after-successfully-writing-it idiom avoids writing an incomplete set of configuration directives for openvpn. The last of those (to avoid incomplete configuration directives) I would argue is a good reason to use a temporary file rather than doing something like popen() and reading from a child process's stdout. signature.asc Description: Digital signature
Bug#548736: malformed PONG responses cause spurious server timeouts with the bip IRC proxy
Package: tircd
Version: 0.7-1
Severity: normal
Tags: patch
bip (an IRC proxy) drops tircd connections after roughly 10 minutes.
bip logs show that bip is closing the connections because tircd's ping
responses have lagged out.
bip uses PONG replies (and only PONG replies) from IRC servers to
determine whether bip's connection to the server has lagged out.
bip's definition of a valid PONG reply is an IRC line containing three
IRCwords, which has been satisfied by every IRC server I have seen so far,
until tircd. tircd's PONG response contains only two IRCwords.
This patch inserts a server hostname argument ('tircd') into PONG
responses, which keeps bip (and any other software that actually cares
about the syntax of PONG responses) happy.
commit a1106de44fc28ff8c22b92c8d8874f434e269e8a
Author: Zygo Blaxell vs3gb...@mailtoo.hungrycats.org
Date: Sat Sep 12 02:54:40 2009 -0400
Make tircd's PONG reply look like other servers
diff --git a/usr/bin/tircd b/usr/bin/tircd
index 8b4e677..a493209 100644
--- a/usr/bin/tircd
+++ b/usr/bin/tircd
@@ -852,7 +852,7 @@ sub irc_ping {
my ($kernel, $heap, $data) = @_[KERNEL, HEAP, ARG0];
my $target = $data-{'params'}[0];
- $kernel-yield('server_reply','PONG',$target);
+ $kernel-yield('server_reply','PONG','tircd',$target);
}
sub irc_away {
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (500, 'stable'), (189, 'testing'), (179, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.28-linode15 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages tircd depends on:
ii libnet-twitter-perl 2.10-1 Perl interface to twitter.com
ii libpoe-filter-ircd-perl 2.40-1 POE-based parser for the IRC proto
tircd recommends no packages.
tircd 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#542291: Patch
On Wed, Aug 19, 2009 at 01:38:32AM +0200, Arnaud Cornet wrote: Here is a quite hackish way to deal with the problem without rewriting much of the event system. We hack the message we want to send to the wire directly in the case of partial writes. That allows us to keep the buffer in the event system and not block in a sleep or loop. If you have a bad connection, can you please test the patch? To simulate a bad connection, open two IRC clients, point them both at the same bip proxy, connect to a big IRC network, kill -STOP one of them, and type '/list' into the other, or join a bunch of large channels and run /who #channelname on them. The STOPped client will block pretty quickly, and with unmodified bip, so does the non-STOPped client. I applied your patch and tested it. There's one bug left: when we are looping with the write(), we want the loop to repeat if the write is successful but incomplete, or if the error is EINTR; otherwise, this happens: 1. We get a partial write (count 0), so we exit the while loop with write() in it, 2. tcount size, so we enter that if statement body, 3. count 0 (errno == EAGAIN || errno == EINPROGRESS) is not true because count 0, so we (incorrectly) don't enter the if statement body with the memmove() call and return WRITE_KEEP statement, 4. cn_is_connected(cn), so we enter that if statement's body and close the connection. The symptom of all this is that a '/list' command drops client connections when connected to a large (e.g. Freenode or OFTC) IRC net when the upstream connection is faster than the downstream ones. Once the following patch is applied on top of yours, though, it works like a champ! I am a bit worried that it will run my proxy server out of RAM if there is an extended network problem; however, my server has more RAM available than all of space consumed by my IRC logs combined, so I'll probably notice the process growing well before it becomes an issue. diff --git a/src/connection.c b/src/connection.c index 2e313e5..f89a2f7 100644 --- a/src/connection.c +++ b/src/connection.c @@ -243,7 +243,7 @@ static int _write_socket(connection_t *cn, char *message) if (tcount == size) break; } - } while (count 0 errno == EINTR); + } while (count 0 || errno == EINTR); #if 0 if (count = 0 tcount 0) signature.asc Description: Digital signature
Bug#542291: bip: Patch to handle disruptively slow clients
Package: bip
Version: 0.8.1-1
Severity: normal
Tags: patch
commit 94d6a02407f260f78f4f9276080e8413ff77ff89
Author: Zygo Blaxell zygo.blax...@xandros.com
Date: Tue Aug 18 12:56:43 2009 -0400
We can't loop forever waiting for a slow client because the upstream
IRC server will drop our connection.
We can't send a partial message because it will corrupt the data stream.
We can't defer a partial message easily. This could be done by passing
an extra return value from _write_sock() to its caller, or by letting
_write_sock() manipulate the connection's outgoing message queue directly.
If a downstream client is on the wrong end of a slow connection which
is just good enough to prevent TCP connections from resetting but not
good enough to keep up with the bandwidth demands of IRC, we can end up
in a situation where that downstream client causes failure of the proxied
IRC session.
So, if write() returns EAGAIN or similar errors, retry 10 times, once
per second. If the downstream client consumes a complete line of text
during those 10 seconds, we let them keep their connection--otherwise,
we drop the client. Currently this is done within the _write_socket
function, so if multiple clients are having this problem we might block
too long and the upstream server will drop us.
Note that downstream client connection dropping can only happen if the
TCP socket to the downstream client is blocking, which means we have
already sent somewhere between 128K and 4096K of data to the client (the
TCP buffer size range on Linux), and the downstream client is consuming
less than one line (512 bytes max) per 10 seconds.
It would be nice to send an error message explaining why we are doing this
to the client, but that requires us to send even more data toward a client
that is causing problems for us by not keeping up with data already sent.
There is probably a similar issue with the SSL code, but I don't use
SSL so I don't know how bip behaves in those cases.
---
diff --git a/src/connection.c b/src/connection.c
index 77edd05..1c3d163 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -234,6 +234,7 @@ static int _write_socket(connection_t *cn, char *message)
size_t tcount = 0;
size_t p_tcount = 0;
ssize_t count;
+ int error_count = 0;
size = strlen(message);
do {
@@ -250,8 +251,16 @@ static int _write_socket(connection_t *cn, char *message)
}
p_tcount = tcount;
}
+ if (count 0
+ (errno == EAGAIN || errno == EINTR || errno ==
EINPROGRESS)) {
+ ++error_count;
+ mylog(LOG_DEBUGVERB, write(fd %d) : %s - try #%d,
cn-handle,
+ strerror(errno), error_count);
+ sleep(1);
+ }
} while (count 0
- (errno == EAGAIN || errno == EINTR || errno == EINPROGRESS));
+ (errno == EAGAIN || errno == EINTR || errno == EINPROGRESS)
+ error_count 10);
#if 0
if (count = 0 tcount 0)
@@ -272,6 +281,7 @@ static int _write_socket(connection_t *cn, char *message)
if (cn_is_connected(cn)) {
mylog(LOG_DEBUGVERB, write(fd %d) : %s, cn-handle,
strerror(errno));
+ connection_close(cn);
cn-connected = CONN_ERROR;
}
mylog(LOG_DEBUGVERB, write : %s, strerror(errno));
-- System Information:
Debian Release: 5.0.2
APT prefers stable
APT policy: (500, 'stable'), (189, 'testing'), (179, 'unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30.1-zb64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526398: /etc/init.d/checkroot.sh: can cause serious data corruption if booting on, battery power
On Fri, May 01, 2009 at 06:35:03PM +0100, peter green wrote: Would a compromise be possible? Something along the lines of doing urgent stuff (journal replays, checks of unclean unjournaled filesystems) but skipping the n days/mounts since last check- check forced checks when on battery? Does fsck have and options that would allow this or would they have to be added? That would be nice, but out of scope of this bug. I'd like the data-loss issues fixed first, then worry about enhancing life for ext3 users with disks that are too big for their batteries. ;-) AFAICT the exceptional case is ext3, because all the other filesystems I've used on Linux either have journals (and they work, so they don't need fsck), or they don't (so they do need fsck). Only ext3 (or more precisely e2fsck) has this strange mode where it does fsck's at random even though it has no evidence to believe they're necessary. A simple solution to the ext3-specific part of the problem is to have the Debian installer use 'tune2fs -c0 -i0' after 'mke2fs -j' when installing on laptops. This eliminates ext3's fscking-at-random-and-inconvenient-times behavior. Users who are concerned about running fsck on battery power should be directed to run this command, instead of breaking initscripts for everyone else. This solution would be a bug for the installer and/or the documentation of rcS, and implementing the ext3-specific solution doesn't remove the need to fix this bug (#526398) on initscripts. There are some valid points in the ext3 documentation about the need to do fsck's at regular intervals to check for past failures to maintain data integrity in the filesystem; however, those apply equally to all filesystems, and arguably should be implemented by the initscripts for all local read/write filesystem types that have fsck tools--not buried in the ext3-specific tools themselves. Also, fsck only makes the filesystem usable to store new data--it doesn't restore any of the data you've probably lost if your storage subsystem has these sorts of problems. I don't think this is a problem that initscripts should try to solve beyond alerting the user to the fact that their storage subsystem is lossy and needs serious debugging. Ideally there should be a fsck-detection tool (possibly a flag supported by modified versions of the existing fsck tools) which can, given a filesystem, tell initscripts which of three states the filesystem is in: 1. The filesystem is known to have errors, or lacks journalling and was not cleanly umounted, and *must* be checked. When initscripts detects the machine is on battery power, it could prompt the user for various options: a. check the filesystem and boot normally b. power off immediately c. (with root password) boot without checking filesystem d. run sulogin e. after a timeout, proceed with one of the above options chosen by a config file (e.g. /etc/default/rcS). 2. The filesystem is not known to have errors, but a policy limit (mount count or days since last fsck) has been reached. initscripts would not check the filesystem if on battery power in this case, based on the assumption that the user will reboot later on battery power to perform the advised fsck. 3. The filesystem is known to be cleanly umounted (or recoverable from journal) and no fsck is recommended. initscripts may always run fsck in this case, since fsck should exit quickly (if it doesn't, that's either a bug in the fsck package or the fsck-detection tool). Some filesystems may not be able to determine quickly if they were cleanly umounted, so maybe initscripts might skip fsck entirely for those filesystems. Of course, if /fastboot or /forcefsck are present, initscripts would honor those as it does now. Note that the above proposal requires work to either modify the various filesystem-specific fsck tools packages so that initscripts can use them, or initscripts could implement the currently ext3-specific maximum mounts/days behavior itself. Both of those are wishlist items, but this bug (#526398) is a critical bug. signature.asc Description: Digital signature
Bug#526398: /etc/init.d/checkroot.sh: can cause serious data corruption if booting on battery power
Package: initscripts Version: 2.86.ds1-61 Severity: critical File: /etc/init.d/checkroot.sh Justification: causes serious data loss I was rather horrified to watch my laptop boot with a dirty root filesystem mounted read/write. Upon further investigation, I discovered that checkroot.sh and checkfs.sh are hardcoded to bypass filesystem checks if AC power is not present. This makes no sense. If a journalling filesystem has errors, it should not be mounted read/write until those errors are corrected. Non-journalling filesystems always need fsck if they are umounted uncleanly, so they shouldn't be mounted read/write without checking and possible correction either. Both cases require fsck before mounting regardless of the power source. Failing to fsck in either case can cause serious data loss, especially if the filesystem's metadata falsely indicates occupied space is free and the system is used for some time. This can lead to duplicate allocations between filesystem metadata and user data, which leads to data loss, security problems, unintentional data disclosure, and worse. Recovery from errors of this kind is nearly impossible without a good set of backups handy. Serious problems can remain undetected for sufficently long periods of time that backups get corrupted as well. The problem is even worse for laptops that are only rebooted due to crashes, and only crash in the field while running on battery power. Such machines may never run fsck until the corruption is sufficiently bad that the machine is unusable. I would propose that the battery power status should only be tested in checkroot.sh and checkfs.sh if a configuration setting explicitly permits it. For example, a variable FSCKONBATTERY might be added to /etc/default/rcS with these options: yes - check filesystems regardless of battery status (ignore on_ac_power entirely). This should be the default. no - don't check filesystems when on_ac_power returns false. This is the current behavior. The system should not corrupt data by default, which is why the default I propose above is different from the current behavior. Installed systems which are upgrading from legacy versions of initscripts might preserve the old behavior in accordance with the principle of least surprise, but all new systems should be installed with the default set as above. I would argue that unexpected data corruption is a much bigger surprise than fscks on battery, but other bugs filed against this package suggest people actually prefer the broken behavior, and these people would probably complain if we fixed it for them. -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable'), (189, 'testing'), (179, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28.4-zb64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages initscripts depends on: ii debianutils 2.30Miscellaneous utilities specific t ii e2fsprogs1.41.3-1ext2/ext3/ext4 file system utiliti ii libc62.9-4 GNU C Library: Shared libraries ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii mount2.13.1.1-1 Tools for mounting and manipulatin ii sysvinit-utils 2.86.ds1-61 System-V-like utilities Versions of packages initscripts recommends: ii psmisc22.6-1 Utilities that use the proc filesy initscripts 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#525493: libopenobex: Build-Depends on cmake 2.6, but package won't build with cmake 2.6.0
Package: libopenobex Version: 1.5-1 Severity: serious Justification: no longer builds from source I attempted to build libopenobex on a system running Lenny (plus a few bits and pieces from testing and unstable). The documentation failed to build, complaining about being unable to find ../../doc/ircp.1. After upgrading to cmake 2.6.3 (from testing), the package seems to finish building without error, and it even contains an ircp man page. commit 654630ea0e46a9a7028ed5eb999eaba4cb4e1aae Author: Zygo Blaxell zygo.blax...@xandros.com Date: Fri Apr 24 18:08:34 2009 -0400 cmake 2.6.0 can't build this package. 2.6.3 can. Don't know about any intermediate versions. diff --git a/debian/control b/debian/control index 3c30f2b..9b70bcd 100644 --- a/debian/control +++ b/debian/control @@ -3,7 +3,7 @@ Priority: optional Section: comm Maintainer: Hendrik Sattler deb...@hendrik-sattler.de Homepage: http://www.openobex.org -Build-Depends: debhelper (= 7.0.0), cmake (= 2.6), libbluetooth-dev [!kfreebsd-i386 !kfreebsd-amd64], libusb-dev (= 2:0.1.11), pkg-config, doxygen, docbook, docbook-utils, quilt (= 0.45) +Build-Depends: debhelper (= 7.0.0), cmake (= 2.6.3), libbluetooth-dev [!kfreebsd-i386 !kfreebsd-amd64], libusb-dev (= 2:0.1.11), pkg-config, doxygen, docbook, docbook-utils, quilt (= 0.45) Standards-Version: 3.8.0.0 Package: libopenobex1-dev -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable'), (189, 'testing'), (179, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28.4-zb64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#312744: closed by martin f krafft madd...@madduck.net (closing wontfix bugs)
No argument from me--the --grow option allows disks to be added or removed at will, so this bug is irrelevant now. On Mon, Feb 16, 2009 at 11:00:03AM +, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the mdadm package: #312744: mdadm has raidtools2 bug #263974 (spurious DegradedArray warnings) It has been closed by martin f krafft madd...@madduck.net. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact martin f krafft madd...@madduck.net by replying to this email. -- 312744: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=312744 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rietz.debian.org X-Spam-Level: X-Spam-Bayes: score:0. Tokens: new, 31; hammy, 84; neutral, 48; spammy, 3. spammytokens:0.997-+--exquisite, 0.975-+--pleasure, 0.933-+--perfect hammytokens:0.000-+--H*c:protocol, 0.000-+--H*c:micalg, 0.000-+--H*c:signed, 0.000-+--H*c:pgp-signature, 0.000-+--H*rp:U*madduck X-Spam-Status: No, score=-5.7 required=4.0 tests=AWL,BAYES_00, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Date: Mon, 16 Feb 2009 11:58:30 +0100 From: martin f krafft madd...@madduck.net To: 396159-d...@bugs.debian.org, 384611-d...@bugs.debian.org, 422554-d...@bugs.debian.org, 312744-d...@bugs.debian.org, 440712-d...@bugs.debian.org, 369180-d...@bugs.debian.org, 394193-d...@bugs.debian.org Subject: closing wontfix bugs X-Motto: Keep the good times rollin' X-OS: Debian GNU/Linux 5.0 kernel 2.6.26-1-amd64 x86_64 X-Spamtrap: madduck.bo...@madduck.net X-Subliminal-Message: debian/rules! X-Virus-Scanned: ClamAV 0.94.2/8995/Mon Feb 16 04:40:05 2009 on clegg.madduck.net X-Virus-Status: Clean These bugs have been around for a while and I will not fix them. Thus, to clean up the BTS, I am now closing them. If you disagree, please reopen the bug and provide detailed information about how to move on in the issue. Patches have a far larger chance than mere arguments. :) -- martin | http://madduck.net/ | http://two.sentenc.es/ a cigarette is the perfect type of pleasure. it is exquisite, and it leaves one unsatisfied. -- oscar wilde spamtraps: madduck.bo...@madduck.net From: Zygo Blaxell zblax...@chako.furryterror.org To: Debian Bug Tracking System sub...@bugs.debian.org Subject: mdadm has raidtools2 bug #263974 (spurious DegradedArray warnings) Date: Thu, 09 Jun 2005 22:13:06 -0400 X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Package: mdadm Version: 1.9.0-4 Severity: normal I'm getting reports like this: From: mdadm monitoring r...@chako.furryterror.org To: r...@chako.furryterror.org Subject: DegradedArray event on /dev/md1:chako Date: Thu, 09 Jun 2005 20:35:25 -0400 This is an automatically generated mail message from mdadm running on chako A DegradedArray event had been detected on md device /dev/md1. Faithfully yours, etc. when /proc/mdstat looks like this: chako:~# cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid5] [multipath] [raid6] [raid10] md1 : active raid1 hda1[1] hdc1[0] 2048192 blocks [3/2] [UU_] md3 : active raid1 hda3[1] hdc3[0] 131392 blocks [3/2] [UU_] md0 : active raid1 hda2[0] hdc2[1] 117880960 blocks [3/2] [UU_] unused devices: none The missing disks in these RAID1 arrays are by design, to allow extra mirrors to be hot added to the array without reconfiguring. The usual purpose for this is to clone the first two disks onto e.g. a USB external drive--I attach the USB drive, do raidhotadd (now mdadm -a), let the drive sync, then setfaulty/hotremove (mdadm -f/-r) the USB drive and repeat if necessary. It would be nice to not have the emails in this particular case. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (102, 'testing'), (101, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-zb5s Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages mdadm depends on: ii debconf 1.4.30.13Debian configuration management sy ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii makedev 2.3.1-77 creates device
Bug#465457: /usr/lib/gnome-applets/battstat-applet-2: battstat-applet battery low warning does not go away when battery replaced
Package: gnome-applets Version: 2.14.3-4 Severity: normal File: /usr/lib/gnome-applets/battstat-applet-2 When my laptop battery gets low, the battstat-applet displays a warning dialog according to its configuration. When AC power is connected, this dialog is automatically dismissed; however, when the depleted battery is replaced with a fresh one (e.g. by initiating a TuxOnIce suspend cycle, replacing the battery, and resuming from TuxOnIce), the battstat-applet warning dialog remains on the screen. The warning text predicts battery failure more than an hour in the future and a charge level of 100%. The battstat-applet warning dialog should disappear automatically if the battery capacity or remaining charge increase to the extent that the conditions for displaying the warning dialog are no longer true. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (189, 'testing'), (179, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.23.12-zb5s-toi (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-applets depends on: ii debconf [debconf-2.0] 1.5.11etch1 Debian configuration management sy ii gconf2 2.16.1-1 GNOME configuration database syste ii gnome-applets-data 2.14.3-4 Various applets for GNOME 2 panel ii gnome-icon-theme2.14.2-2 GNOME Desktop icon theme pn gnome-panel none (no description available) ii gstreamer0.10-alsa 0.10.10-4GStreamer plugin for ALSA ii gstreamer0.10-plugins-good 0.10.4-4 GStreamer plugins from the good ii libapm1 3.2.2-8.1Library for interacting with APM d ii libatk1.0-0 1.20.0-1 The ATK accessibility toolkit ii libbonobo2-02.20.2-1 Bonobo CORBA interfaces library ii libbonoboui2-0 2.20.0-1 The Bonobo UI library ii libc6 2.7-6GNU C Library: Shared libraries pn libcairo2 none (no description available) ii libdbus-1-3 1.1.2-1 simple interprocess messaging syst ii libdbus-glib-1-20.74-1 simple interprocess messaging syst ii libfontconfig1 2.4.2-1.2generic font configuration library ii libgconf2-4 2.16.1-1 GNOME configuration database syste ii libglade2-0 1:2.6.2-1library to load .glade files at ru ii libglib2.0-02.14.3-1 The GLib library of C routines ii libgnome-desktop-2 2.14.3-2 Utility library for loading .deskt ii libgnome2-0 2.20.1.1-1 The GNOME 2 library - runtime file ii libgnomeui-02.18.1-2 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 1:2.20.1-1 GNOME Virtual File System (runtime ii libgstreamer-plugins-base0. 0.10.10-4GStreamer libraries from the base pn libgstreamer0.10-0 none (no description available) ii libgtk2.0-0 2.10.13-1The GTK+ graphical user interface ii libgtop2-7 2.14.4-3 gtop system monitoring library ii libgucharmap4 1:1.6.0-1Unicode browser widget library (sh ii libhal1 0.5.10-5 Hardware Abstraction Layer - share ii libnotify1 0.4.3-1 sends desktop notifications to a n ii liborbit2 1:2.14.3-0.2 libraries for ORBit2 - a CORBA ORB pn libpanel-applet2-0 none (no description available) pn libpango1.0-0 none (no description available) ii libwnck18 2.14.3-1 Window Navigator Construction Kit ii libx11-62:1.0.3-7X11 client-side library ii libxcursor1 1.1.7-4 X cursor management library ii libxext61:1.0.1-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.1-5X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.1-4X11 Input extension library ii libxinerama11:1.0.1-4.1 X11 Xinerama extension library ii libxklavier10 2.2-5X Keyboard Extension high-level AP pn libxml2 none (no description available) ii libxrandr2 2:1.2.2-1X11 RandR extension library ii libxrender1 1:0.9.1-3X Rendering Extension client libra Versions of packages gnome-applets recommends: ii deskbar-applet 2.14.2-4.2 universal search and navigation ba ii gnome-media 2.14.2-4 GNOME media utilities ii gnome-netstatus-app 2.12.0-5+b2 Network status applet for GNOME 2 ii gnome-system-monito 2.14.5-1 Process viewer and system resource ii imagemagick 7:6.2.4.5.dfsg1-0.14 Image manipulation programs -- debconf information excluded --
Bug#457736: nbd-client does really nasty things when root is an nbd device
Package: nbd-client Version: 1:2.9.9-1 Severity: normal Somewhere during the installation process of nbd-client the maintainer scripts invoke /etc/init.d/nbd-client stop, which not only shuts down all nbd clients known to the nbd-client package, but also all other nbd devices which were set up by other means (such as ad-hoc commands and/or initrd), whether such devices are currently in use or not. In my problem case, the root filesystem is on a network block device, so installation of the nbd-client package proceeds no further than this point. A final amusing twist: after rebooting, the system comes back up, and 'dpkg --configure -a' simply brings it back down again. dpkg can't possibly remember that it has tried and failed to do this before, since its only persistent filesystem goes away before it can store this information anywhere. Note that the filesystem in question is actually md RAID1 of nbd devices. e.g. if you set up /dev/nbd11 and /dev/nbd21 on separate machines, then run 'mdadm --create --level=1 --raid-disks=2 /dev/md1 /dev/nbd[12]1' you will have a similar configuration. This issue may be specific to the use of an md-RAID1 system, or use of recent kernel versions, or some combination of these with NBD. 2.6.23 seems to have different definitions of busy devices relative to previous kernels; however, I still think tearing down NBD devices that are otherwise unknown to debconf or in any 'nbd-client' Debian package configuration file from nbd-client's init script is not a good idea. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (189, 'testing'), (179, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.23.12-zb5s (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages nbd-client depends on: ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii libc6 2.7-3 GNU C Library: Shared libraries nbd-client recommends no packages. -- debconf information: * nbd-client/host: nbd-client/no-auto-config: * nbd-client/port: * nbd-client/number: 0 * nbd-client/device: * nbd-client/type: raw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445090: 445090: subprocess post-installation script returned error exit status 255
I've just seen similar symptoms to this bug on an upgrade of libssl0.9.8. One difference is that I see 'exit status 128' instead of 255, but like this bug there is no indication in the output as to cause, and the upgrade would not complete despite restarting it several times from aptitude. I've seen this problem only once despite performing the same upgrade on 10 similarly configured machines. I then tried tracing the postinst script manually, but when I did so the problem did not occur and I wasn't able to reproduce it afterwards. My guess is that something is behaving differently depending on whether it is run from /usr/share/debconf/frontend or not. I've had a number of problems with some packages in the past that set up environment variables that cause Perl to crash or cause dpkg utilities to change their behavior. dpkg-cross was the culprit in the most recent case, but dpkg-cross has been purged from my system for some time now. This is the (successful) output: satsuki:~# bash -x /var/lib/dpkg/info/libssl0.9.8.postinst configure 0.9.8e-6 + . /usr/share/debconf/confmodule ++ '[' '!' '' ']' ++ PERL_DL_NONLAZY=1 ++ export PERL_DL_NONLAZY ++ '[' '' ']' ++ exec /usr/share/debconf/frontend /var/lib/dpkg/info/libssl0.9.8.postinst configure 0.9.8e-6 Checking for services that may need to be restarted...done. Checking init scripts... Configuring libssl0.9.8 --- This release of OpenSSL fixes some security issues. Services will not use these fixes until they are restarted. Please note that restarting the SSH server (sshd) should not affect any existing connections. Please check the list of detected services that need to be restarted and correct it, if needed. The services names must be identical to the initialization script names in /etc/init.d and separated by spaces. No services will be restarted if the list is empty. Any service that later fails unexpectedly after this upgrade should be restarted. It is recommended to reboot this host to avoid any SSL-related trouble. am ntp racoon postgresql-8.1 postgresql-7.4 spamassassin openvpn apache ssh Restarting services possibly affected by the upgrade: fetchmail: stopping...starting...done. clamav-freshclam: stopping...starting...done. ntp: stopping...starting...done. racoon: stopping...starting...done. postgresql-8.1: stopping...starting...done. postgresql-7.4: stopping...starting...done. spamassassin: stopping...starting...done. openvpn: stopping...starting...done. apache: stopping...starting...done. ssh: stopping...starting...done. Services restarted successfully. -- Zygo Blaxell (Laptop) [EMAIL PROTECTED] GPG = B203 9402 B0E7 0F20 3B74 B13C DFBC C916 4395 FD03 signature.asc Description: Digital signature
Bug#443269: schedutils: Patch to fix problems with ionice command execution
Package: schedutils
Version: 1.5.0-1
Severity: normal
Tags: patch
I have a patch which fixes some problems when ionice is asked to execute
a command:
1. When execvp'ing the command, check that the execvp actually succeeds
(actually it doesn't check, it just assumes that if execvp returns then
the exec must have failed). If the execvp fails, report the errno value
and exit with a non-zero exit status. The old code would simply exit with
successful status if asked to execute a command that did not exist or
otherwise failed to start executing, which wreaks all kinds of havoc in
shell scripts.
2. Before exec, do setuid(getuid()), dropping privileges if ionice
happens to be setuid. Also report errors while attempting to do this,
and exit without executing anything if the setuid call fails.
I'm not sure if it's a good idea to make ionice setuid by default (or
at all), but unfortunately the kernel interface seems to insist on root
privileges even if you want to select a lower I/O priority, so I find it
quite helpful to have a setuid binary of ionice around.
--- ionice.c-schedutils-1.5.0 2007-09-20 01:23:44.0 -0400
+++ ionice.c2007-09-20 01:30:07.0 -0400
@@ -143,8 +143,16 @@
return 1;
}
- if (argv[optind])
- execvp(argv[optind], argv[optind]);
+ if (argv[optind]) {
+ if (setuid(getuid())) {
+ perror(setuid(getuid()));
+ return 1;
+ } else {
+ execvp(argv[optind], argv[optind]);
+ perror(execvp);
+ return 1;
+ }
+ }
}
return 0;
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable'), (102, 'testing'), (101, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.22.1-zb5s (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages schedutils depends on:
ii libc6 2.6.1-1+b1 GNU C Library: Shared libraries
schedutils recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404528: dvd+rw-tools: growisofs uses _SC_AVPHYS_PAGES instead of _SC_PHYS_PAGES to determine limit of bufsize
Package: dvd+rw-tools
Version: 7.0-4
Severity: normal
The undocumented '-use-the-force-luke=bufsize=nnnM' option fails to
be useful because of the way growisofs determines the limitations of
available physical memory.
The offending code is (near growisofs.c:3100):
#if defined(_SC_PAGESIZE) defined(_SC_AVPHYS_PAGES)
{ size_t phys_mem = (size_t)sysconf(_SC_AVPHYS_PAGES) *
(size_t)sysconf(_SC_PAGESIZE);
if (phys_mem)
{ phys_mem /= 2; /* normally AVPHYS is a bit smaller, so
* we commonly land on 1/4 RAM */
while (the_buffer_size phys_mem) the_buffer_size /= 2;
}
}
#endif
The problem is that _SC_AVPHYS_PAGES is the number of free pages of RAM.
On a typical Linux system that number is about 10MB regardless of actual
RAM size, because all available memory except for that margin is typically
used for cache and buffers, which are not available according to the
definition that _SC_AVPHYS_PAGES uses.
This bug makes it practically impossible to increase the ring buffer size
of growisofs, since typical values for _SC_AVPHYS_PAGES are much lower
than even the default 32MB ring buffer size.
It would be better to use _SC_PHYS_PAGES instead of _SC_AVPHYS_PAGES
in the above code. This will limit growisofs size to 1/2 of the real
physical memory, which is typically available (possibly after a bit
of swapping). Of course it is ultimately up to the user to determine
what a reasonable ring buffer size is, since only the user knows what
other demands on the system RAM there might be.
-- System Information:
Debian Release: 3.1
APT prefers stable
APT policy: (500, 'stable'), (102, 'testing'), (101, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18.4-zb5s-s2-nf
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages dvd+rw-tools depends on:
ii libc62.3.6.ds1-8 GNU C Library: Shared libraries
ii libgcc1 1:4.1.1-19 GCC support library
ii libstdc++6 4.1.1-19The GNU Standard C++ Library v3
ii mkisofs 9:1.1.0-1 Dummy transition package for genis
dvd+rw-tools recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#77025: Is this bug still present?
On Wed, Jun 07, 2006 at 12:52:04AM -0400, Nathanael Nerode wrote: The X server has changed radically in recent years. Is this bug still present in the X server in a current version of Debian (sarge, etch, or sid)? Please reply to the bug trail. (If you don't reply, we will eventually assume that the bug is fixed.) The hardware that this occurs on would have gone to the Great Land of Lease Expiration in the Sky at least four years ago. I have seen similar problems from time to time over the years on various chipsets (both ATI and non-ATI) usually arising from having the wrong clock rate set either on memory, GPU, or LCD panel driver outputs. All of these problems were fixed in later X server versions so far. It's likely that this one is too, but I don't have the hardware any more so I can't find out for certain. There are lots of newer, more exciting bugs on ATI chipsets now. ;-) I recommend you close this bug and move on. signature.asc Description: Digital signature
Bug#90260: closed by Thibaut VARENE [EMAIL PROTECTED] (too old)
On Mon, Jun 05, 2006 at 11:04:42AM -0700, Debian Bug Tracking System wrote:
This is an automatic notification regarding your Bug report
#90260: uptimed keeps forgetting uptimes,
which was filed against the uptimed package.
It has been closed by Thibaut VARENE [EMAIL PROTECTED].
Their explanation is attached below. If this explanation is
unsatisfactory and you have not received a better one in a separate
message then please contact Thibaut VARENE [EMAIL PROTECTED] by replying
to this email.
Debian bug tracking system administrator
(administrator, Debian Bugs database)
Date: Mon, 5 Jun 2006 19:34:55 +0200
From: Thibaut VARENE [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: too old
Organization: Debian
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-2.0 required=4.0 tests=BAYES_00,RCVD_IN_SORBS
autolearn=no version=2.60-bugs.debian.org_2005_01_02
closing this bug as it probably no longer exists
T-Bone
Nope, the bug is still there.
The function save_records needs to check ferror(f) after fflush(f) (which is
missing) and before fclose(f). If ferror() returns true then it must
not rename the (damaged) temporary file over the (good) existing file.
Sort of like this:
--- ./libuptimed/urec.c.orig2006-06-05 16:34:08.0 -0400
+++ ./libuptimed/urec.c 2006-06-05 16:39:19.0 -0400
@@ -245,6 +245,7 @@
FILE *f;
Urec *u;
int i=0;
+ int err;
f=fopen(FILE_RECORDS.tmp, w);
if (!f)
@@ -264,8 +265,18 @@
break;
}
}
+ /* Push buffers out to filesystem */
+ fflush(f);
+ /* Check error status on stream just before closing */
+ err=ferror(f);
fclose(f);
- rename(FILE_RECORDS.tmp, FILE_RECORDS);
+ /* Don't keep the temporary file if there was an error while writing it
*/
+ if (ferror(f)) {
+ printf(uptimed: error while writing to %s\n,
FILE_RECORDS.tmp);
+ unlink(FILE_RECORDS.tmp);
+ } else {
+ rename(FILE_RECORDS.tmp, FILE_RECORDS);
+ }
}
#ifdef PLATFORM_LINUX
signature.asc
Description: Digital signature
Bug#370412: x11-common: /bin/ls: argument list too long
Package: x11-common Version: 6.9.0.dfsg.1-4etch2 Severity: important x11-common.postinst dies in several places in the function find_culprits with argument list too long. It appears to be trying to expand glob patterns that look like this: /var/lib/dpkg/info/*.list as in: ls -1 $_dpkg_info_dir/*.list This of course fails if you have a lot of packages installed, preventing pretty much anything that even thinks about X11 from installing. Fixing this problem by replacing the code with the following: find $_dpkg_info_dir/. -name '*.list' simply causes the problem to recur on the following lines, which have similar scaling issues. Something like this code to generate $_smoking_guns would be better: find $_dpkg_info_dir/. -name '*.list' -print0 | egrep -zv '(xbase-clients|x11-common|xfs|xlibs)' | xargs -0 grep -l $1 although there are some error cases that are caught by the existing code in the package that aren't caught by the above code. It would at least be able to process an unlimited number of packages. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (102, 'testing'), (101, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.16.19-zb5s-s2-nf Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages x11-common depends on: ii debconf [debconf-2.0] 1.4.30.13 Debian configuration management sy ii debianutils 2.8.4 Miscellaneous utilities specific t ii lsb-base 3.1-5 Linux Standard Base 3.1 init scrip -- debconf information: x11-common/experimental_packages: x11-common/xwrapper/actual_allowed_users: rootonly x11-common/xwrapper/nice_value/error: * x11-common/upgrade_issues: * x11-common/x11r6_bin_not_empty: * x11-common/xwrapper/allowed_users: Root Only * x11-common/xwrapper/nice_value: 0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355772: k3b continually raises its window to top (restoring it if mimized) and grabs keyboard focus while reading audio files
On Tue, Mar 07, 2006 at 03:30:05PM -0500, Francois Marier wrote:
Can you describe under what circumstances K3b steals the keyboard focus?
When you create a new audio cd project and then start trying to drag and
drop files into it?
I open two existing audio CD projects from the command line
('k3b cdrw1.k3b cdrw2.k3b').
k3b seems to start grabbing keyboard focus and raising itself a second or
two after starting up. It doesn't ever stop until killed (which is sometimes
complicated because it obscures its own Save/Discard/Cancel dialogs in some
window managers).
The status bar says Opening File... but there doesn't seem to be any
legitimate work for it to do. strace and ltrace indicate that k3b is
in a loop doing a number of tasks, one of which is re-reading the .k3b
input files every second.
If I try to close the project files individually, they simply open again.
If I start k3b without command-line arguments, then open the files,
there seem to be no problems.
Hmmm, maybe I'm on to something here...if I start k3b with *one*
command-line argument ('k3b cdrw1.k3b') then it all works properly.
The breakage starts when I add the second command-line argument.
I have tested K3b using Ion2 and Metacity and do not have these problems...
I have the problem with Sawfish (Version: 1:1.3+cvs20050709-6), metacity
(Version: 1:2.8.8-1) and kwin (Version: 4:3.5.1-1). If it works with
*any* window manager, I'd expect it to work with kwin. ;-)
I do not have the problem with twm (Version: 4.3.0.dfsg.1-14sarge1),
but I suspect twm blithely ignores focus messages from applications.
--
Zygo Blaxell (Laptop) [EMAIL PROTECTED]
GPG = B203 9402 B0E7 0F20 3B74 B13C DFBC C916 4395 FD03
signature.asc
Description: Digital signature
Bug#355772: k3b continually raises its window to top (restoring it if mimized) and grabs keyboard focus while reading audio files
Never mind my previous message, I have found the problem: k3b now forks itself into the background, exiting almost immediately. If k3b is invoked from the command line while another k3b is running, the arguments are passed to the existing process, which raises and focuses itself. My X session script runs k3b processes in an infinite loop due to the chronic crashing bugs in previous versions (I would routinely drag a file, save project, drag another file, crash, restart k3b automatically, drag the file again, save project...about 10 times per CD). With the new version of k3b, the script invokes k3b about once per second, which causes the first k3b instance to keep focusing itself (I guess the assumption is that I actually want to open a new k3b project every time). This also adds the projects on the command line into k3b's open projects list if they are not present, which gives the other odd behaviors I was observing when trying to close a project. The good news is that restarting k3b in an infinite loop doesn't seem to be necessary any more--k3b no longer crashes on every 10th audio file. OK, so it's not really a bug any more, but a feature request: some command-line option that gets back the previous non-exiting behavior! I have some other not-yet-upgraded systems which produce CD's and DVD's with automated scripts that do various verification, bookkeeping and data organization tasks. The UI is almost entirely headless--an operator inserts a disc into a drive, it is burned and verified, an appropriate matching label is printed (no label if the verification failed), the disc is ejected, and the script waits for another disc to be inserted. The scripts support custom or manual operation by having an entry type in the work queue database that means invoke k3b on the console X display and wait for it to exit. If I were to upgrade k3b on these systems, they would probably have k3b running at the same time as the scripts are trying to take control of the drive to process the next disc image in the queue...not good. signature.asc Description: Digital signature
Bug#355772: k3b continually raises its window to top (restoring it if mimized) and grabs keyboard focus while reading audio files
Package: k3b Version: 0.12.12-1 Severity: normal Filling a CD with audio data can be relatively time consuming. It would be nice to lower or minimize the k3b window, or simply move it out of the way, and do other tasks, but this is not possible since k3b will keep pushing itself back into the foreground. Even with a window manager in focus strictly under mouse mode, k3b repeatedly grabs the keyboard focus, so interaction with any other application (for more than a few milliseconds) is not possible. I have to switch out of X into a VT and killall k3b, or invoke the kill-client window manager command to terminate k3b's X connection. I am using sawfish Version: 1:1.3+cvs20050709-6 as window manager. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (102, 'testing'), (101, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.15.5-zb5s-s2-nf Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages k3b depends on: ii cdparanoia 3a9.8-11 An audio extraction tool for sampl ii cdrecord 4:2.01+01a03-5command line CD writing tool ii kcontrol 4:3.5.1-1 control center for KDE ii kdebase-bin4:3.5.1-1 core binaries for the KDE base mod ii kdelibs-data 4:3.5.1-3 core shared data for all KDE appli ii kdelibs4c2a4:3.5.1-3 core libraries for all KDE applica ii libacl12.2.23-1 Access control list shared library ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libattr1 2.4.16-1 Extended attribute shared library ii libaudio2 1.7-2 The Network Audio System (NAS). (s ii libc6 2.3.5-13 GNU C Library: Shared libraries an ii libdbus-1-20.61-3simple interprocess messaging syst ii libdbus-qt-1-1c2 0.61-3simple interprocess messaging syst ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii libfam02.7.0-9 Client library to control the FAM ii libfontconfig1 2.3.2-1.1 generic font configuration library ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib ii libgcc11:4.0.2-9 GCC support library ii libhal10.5.6-4 Hardware Abstraction Layer - share ii libice64.3.0.dfsg.1-14sarge1 Inter-Client Exchange library ii libidn11 0.5.18-1 GNU libidn library, implementation ii libjpeg62 6b-10 The Independent JPEG Group's JPEG ii libk3b20.12.12-1 The KDE cd burning application lib ii libmusicbrainz4c2a 2.1.2-2 Second generation incarnation of t ii libpng12-0 1.2.8rel-5PNG library - runtime ii libqt3-mt 3:3.3.5-4 Qt GUI Library (Threaded runtime v ii libresmgr1 1.0-3 resource manager library ii libsm6 4.3.0.dfsg.1-14sarge1 X Window System Session Management ii libstdc++6 4.0.2-9 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-14sarge1 X Window System protocol client li ii libxcursor11.1.3-1 X cursor management library ii libxext6 4.3.0.dfsg.1-14sarge1 X Window System miscellaneous exte ii libxft22.1.7-1 FreeType-based font drawing librar ii libxi6 4.3.0.dfsg.1-14sarge1 X Window System Input extension li ii libxinerama1 6.9.0.dfsg.1-4X Window System multi-head display ii libxrandr2 4.3.0.dfsg.1-14sarge1 X Window System Resize, Rotate and ii libxrender11:0.9.0.2-1 X Rendering Extension client libra ii libxt6 4.3.0.dfsg.1-14sarge1 X Toolkit Intrinsics ii mkisofs4:2.01+01a03-5Creates ISO-9660 CD-ROM filesystem ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355611: fglrx-driver is not installable due to dependency on xserver-org 6.8.x, which is no longer available
Package: fglrx-driver Version: 8.20.8-1.1 Severity: grave The fglrx-driver package in the Debian archive declares a dependency on xserver-xorg = 6.8.0 and = 6.8.99, but the only version of xserver-xorg in the archive at the moment (as far as I can tell) is 6.9.0. This makes the fglrx-driver package uninstallable unless you happened to previously have 6.8.2 installed; however, apt now wants to remove fglrx-driver to upgrade xserver-xorg. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (102, 'testing'), (101, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.15.5-zb5s-s2-nf Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages fglrx-driver depends on: ii libc6 2.3.5-13 GNU C Library: Shared libraries an ii libstdc++5 1:3.3.5-13The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-14sarge1 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-14sarge1 X Window System miscellaneous exte hi xserver-xorg 6.8.2.dfsg.1-11 the X.Org X server -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343622: /usr/bin/pg_upgradecluster: pg_upgradecluster fails to handle users and groups with the same name
On Thu, Dec 29, 2005 at 11:26:11PM +0100, Martin Pitt wrote: I haven't checked thoroughly, but I suspect that pg_upgradecluster is not executing the operations on the new database within a single transaction. The upgrade of a database is done with a pg_dump/pg_restore pipeline; there aren't any options to influence the speed or transactional behavior, do you know how it can be improved? Adding -e to pg_restore (if it isn't there already) should prevent command errors during the restore from going undetected, even without transactions. It might be something that needs to be turned off for a lot of people for the inevitable corner cases that new PostgreSQL versions deprecate, but it would be a good safe default. On closer investigation the lack of a single big enclosing transaction might not the big problem after all. The row data for each table is loaded in a single transaction (one COPY command), and indexes are recreated after the tables are populated, so the only transaction overhead is in the schema updates. Unfortunately this doesn't explain why one of my pg_upgradecluster sessions took so many hours to run. I'll have to take a look at what is happening in more depth, when it bubbles up to the top of my priority queue again. I have a pair of clusters on different machines which are set up such that the second machine does a pg_dump/pg_restore session from the first to the second each day. I used to do this with pg_dump -h first ... | sed ... | psql -h second ... where the sed script mangled a few commands and inserted \set ON_ERROR_STOP 1 and begin work; at the first line and commit; at the end. That worked for 7.4 and 8.0 (including the case where first ran 7.4 and second ran 8.0), but it gets a lot more messy around 8.1, mostly because pg_dump no longer emits nice non-error-generating SQL code to purge and reload the users table. An option to ignore non-existent users in the DROP USER command would be nice. Also, pg_dump in SQL mode doesn't back up large objects at all until 8.1--not a problem for me since I don't have any, but probably someone out there is using them. ;-) -- Opinions expressed are my own, I don't speak for my employer, and all that. Encrypted email preferred. Go ahead, you know you want to. ;-) OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D signature.asc Description: Digital signature
Bug#343622: /usr/bin/pg_upgradecluster: pg_upgradecluster fails to handle users and groups with the same name
Package: postgresql-common Version: 36 Severity: normal File: /usr/bin/pg_upgradecluster I have upgraded a number of 8.0 databases to 8.1 successfully so far, but one in particular failed pretty badly. There is a rather severe problem if there is a user and a group in the 8.0 database with the same name. pg_upgradecluster makes a mess of the translation from users/groups to roles, and as a result any privileges which were granted to the group seem to be missing from the new database. Worst of all, pg_upgradecluster reports a successful upgrade afterwards. If a group and user have the same name in 8.0, and the user is a member of the group, then nothing needs to be done since in 8.1 these are now the same object in the same namespace. If a user and group have the same name in 8.0, and the user is *not* a member of the group, then there is no equivalent in 8.1 and pg_upgradecluster should stop and ask the user to rename either the user or the group. I haven't checked thoroughly, but I suspect that pg_upgradecluster is not executing the operations on the new database within a single transaction. Apart from the severe performance penalty (my databases typically contain gigabytes of 50-byte rows, and even a small test subset took hours to upgrade on my fastest machine), this allows all kinds of error cases to proceed through the upgrade uncaught. -- System Information: Debian Release: 3.1 APT prefers stable APT policy: (500, 'stable'), (102, 'testing'), (101, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.3-zb5s-s2-nf Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages postgresql-common depends on: ii adduser 3.63 Add and remove users and groups ii debconf [debconf-2.0] 1.4.30.13 Debian configuration management sy ii lsb-base 3.0-12 Linux Standard Base 3.0 init scrip Versions of packages postgresql-common recommends: ii openssl 0.9.7e-3sarge1 Secure Socket Layer (SSL) binary a -- debconf information: * postgresql-common/obsolete-major: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336675: /usr/share/postgresql-common/PgCommon.pm: pg_ctlcluster can't cope with fractional scale values in autovacuum.conf
Package: postgresql-common
Version: 28
Severity: normal
File: /usr/share/postgresql-common/PgCommon.pm
I have a database which contains tables consisting of millions of rows
which are inserted, then updated once, then left unmodified forever.
The default avac_vac_scale of 2 results in huge amounts of wasted space:
the table has to more than triple in size (live + dead tuple count)
within a single, uninterrupted autovacuum daemon process lifetime,
to meet the default VacuumThreshold. In some tables the rows are on
average 1000 bytes long when inserted and 20 bytes long after update.
The size of the database on disk doubles if only 1% of it is unvacuumed,
so a reasonable value for avac_vac_scale is somewhere around 0.01.
I tried to put the following into /etc/.../autovacuum.conf:
avac_vac_scale=0.01
Unfortunately, this doesn't work. There is a problem with pg_ctlcluster's
get_conf_value routine:
sub get_conf_value {
return 0 unless $_[0] $_[1];
my $fname = $confroot/$_[0]/$_[1]/$_[2];
-e $fname or $fname = $common_confdir/$_[2];
if (open F, $fname) {
while (F) {
return $1 if /^\s*$_[3]\s*=\s*(\w+)\b/; # simple value
return $1 if /^\s*$_[3]\s*=\s*'([^']*)'/; # string value
}
close F;
}
return undef;
}
The problem is that floating-point numbers don't match \w+, so they are
silently ignored and the defaults used instead.
Please do one of the following:
1. Use [\w.]+ instead of \w+ (or maybe -?[\w.]+ for negative cases), or
2. Put a comment in autovacuum.conf that says floating-point numbers
(or anything not matching \w+) must be surrounded by ticks (as in
avac_vac_scale='0.01').
Thanks in advance.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (102, 'testing'), (101, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.12.6-zb5s-s2-nf
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages postgresql-common depends on:
ii adduser 3.63 Add and remove users and groups
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312744: mdadm has raidtools2 bug #263974 (spurious DegradedArray warnings)
Package: mdadm Version: 1.9.0-4 Severity: normal I'm getting reports like this: From: mdadm monitoring [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: DegradedArray event on /dev/md1:chako Date: Thu, 09 Jun 2005 20:35:25 -0400 This is an automatically generated mail message from mdadm running on chako A DegradedArray event had been detected on md device /dev/md1. Faithfully yours, etc. when /proc/mdstat looks like this: chako:~# cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid5] [multipath] [raid6] [raid10] md1 : active raid1 hda1[1] hdc1[0] 2048192 blocks [3/2] [UU_] md3 : active raid1 hda3[1] hdc3[0] 131392 blocks [3/2] [UU_] md0 : active raid1 hda2[0] hdc2[1] 117880960 blocks [3/2] [UU_] unused devices: none The missing disks in these RAID1 arrays are by design, to allow extra mirrors to be hot added to the array without reconfiguring. The usual purpose for this is to clone the first two disks onto e.g. a USB external drive--I attach the USB drive, do raidhotadd (now mdadm -a), let the drive sync, then setfaulty/hotremove (mdadm -f/-r) the USB drive and repeat if necessary. It would be nice to not have the emails in this particular case. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (102, 'testing'), (101, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-zb5s Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages mdadm depends on: ii debconf 1.4.30.13Debian configuration management sy ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii makedev 2.3.1-77 creates device files in /dev -- debconf information: * mdadm/autostart: false * mdadm/mail_to: root * mdadm/warning: * mdadm/start_daemon: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305782: /usr/bin/rl: rl does no output error checking
Package: randomize-lines Version: 0.2.3 Severity: normal File: /usr/bin/rl I would expect the following to generate an error message and exit with status 1 (shell convention for an error): rl .newsrc /dev/full; echo $? Instead, rl blithely ignores all the write errors on stdout and exits with status 0: $ rl .newsrc /dev/full; echo $? 0 Of course this makes it difficult to reliably use rl in a shell script where write errors (e.g. disk full) might occur. A workaround is to use the 'cat' program in a pipe: $ rl .newsrc | cat /dev/full; echo $? cat: write error: No space left on device 1 however this workaround doesn't cope with read failures on .newsrc, and the shell code which does cope with that case isn't trivial. The real fix is to simply check for (and report) errors on read and write system calls within rl itself. -- System Information: Debian Release: 3.0 APT prefers testing APT policy: (102, 'testing'), (101, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.28-zb5s Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages randomize-lines depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
