Bug#661494: xfsrestore of xfsdump with inaccessible files fails. corrupt extent header
Package: xfsdump Version: 3.0.4 Severity: normal Problem exists in xfsdump version up to 3.0.6, it looks like this: time nice ionice -c 3 xfsdump - /device | xfsrestore - ./ xfsrestore: using file dump (drive_simple) strategy xfsrestore: version 3.0.6 (dump format 3.0) - Running single-threaded xfsdump: using file dump (drive_simple) strategy xfsdump: version 3.0.6 (dump format 3.0) - Running single-threaded xfsdump: WARNING: most recent level 0 dump was interrupted, but not resuming that dump since resume (-R) option not specified xfsdump: level 0 dump of pokurcz:/home xfsdump: dump date: Mon Feb 27 14:47:47 2012 xfsdump: session label: xfsrestore: searching media for dump xfsdump: ino map phase 1: constructing initial dump list xfsdump: ino map phase 2: skipping (no pruning necessary) xfsdump: ino map phase 3: skipping (only one dump stream) xfsdump: ino map construction complete xfsdump: estimated dump size: 41947280896 bytes xfsdump: creating dump session media file 0 (media 0, file 0) xfsdump: dumping ino map xfsdump: dumping directories xfsrestore: examining media file 0 xfsrestore: dump description: xfsrestore: mount point: /home xfsrestore: session time: Mon Feb 27 14:47:47 2012 xfsrestore: level: 0 xfsrestore: session label: xfsrestore: media label: xfsrestore: file system id: 9c620277-a63d-4a5b-bb82-64df562b6ddd xfsrestore: session id: 7bb62f13-dfd9-40ea-a0c4-43dcca7d7897 xfsrestore: media id: 1dd3dc69-4ef5-4fe5-8f5b-d8c4aeb7761f xfsrestore: searching media for directory dump xfsrestore: reading directories xfsdump: dumping non-directory files xfsrestore: 98210 directories and 645968 entries processed xfsrestore: directory post-processing xfsrestore: restoring non-directory files xfsdump: WARNING: could not open regular file ino 109308 mode 0x8180: Stale NFS file handle: not dumped xfsdump: WARNING: could not get list of non-root attributes for nondir ino 109308: Stale NFS file handle (116) xfsdump: WARNING: could not get list of root attributes for nondir ino 109308: Stale NFS file handle (116) xfsdump: WARNING: could not get list of secure attributes for nondir ino 109308: Stale NFS file handle (116) xfsrestore: WARNING: corrupt extent header xfsrestore: WARNING: unable to resync media file: some portion of dump will NOT be restored xfsrestore: restore complete: 27 seconds elapsed xfsrestore: Restore Status: SUCCESS xfsdump: ending media file xfsdump: media file size 198770688 bytes xfsdump: dump size (non-dir files) : 97237608 bytes xfsdump: NOTE: dump interrupted: 27 seconds elapsed: may resume later using -R option xfsdump: Dump Status: INTERRUPT after applying patch from http://www.spinics.net/lists/xfs/msg09707.html xfsdump works correctly ( produces files restorable with xfsrestore ) time nice ionice -c 3 xfsdump - /dev/s/home | xfsrestore - ./ xfsrestore: using file dump (drive_simple) strategy xfsrestore: version 3.0.6 (dump format 3.0) - Running single-threaded xfsdump: using file dump (drive_simple) strategy xfsdump: version 3.0.6 (dump format 3.0) - Running single-threaded xfsdump: WARNING: most recent level 0 dump was interrupted, but not resuming that dump since resume (-R) option not specified xfsdump: dump date: Mon Feb 27 15:41:58 2012 xfsdump: session id: e6ecdc0c-3173-4828-86a0-5e8df2a7f69c xfsdump: session label: xfsrestore: searching media for dump xfsdump: ino map phase 1: constructing initial dump list xfsdump: ino map phase 2: skipping (no pruning necessary) xfsdump: ino map phase 3: skipping (only one dump stream) xfsdump: ino map construction complete xfsdump: estimated dump size: 41947529920 bytes xfsdump: creating dump session media file 0 (media 0, file 0) xfsdump: dumping ino map xfsrestore: examining media file 0 xfsdump: dumping directories xfsrestore: dump description: xfsrestore: hostname: pokurcz xfsrestore: mount point: /home xfsrestore: session time: Mon Feb 27 15:41:58 2012 xfsrestore: level: 0 xfsrestore: session label: xfsrestore: media label: xfsrestore: file system id: 9c620277-a63d-4a5b-bb82-64df562b6ddd xfsrestore: session id: e6ecdc0c-3173-4828-86a0-5e8df2a7f69c xfsrestore: media id: 82113274-d47c-4504-a376-8107557f9068 xfsrestore: searching media for directory dump xfsrestore: reading directories xfsdump: dumping non-directory files xfsrestore: 98210 directories and 645992 entries processed xfsrestore: directory post-processing xfsrestore: restoring non-directory files xfsrestore: NOTE: ino 49280 gen 2421386218 not referenced: placing in orphanage xfsrestore: NOTE: ino 12297587 gen 2810501049 not referenced: placing in orphanage xfsrestore: NOTE: ino 13327059 gen 2649609090 not referenced: placing in orphanage xfsrestore: NOTE: ino 13328402 gen 3735435282 not referenced: placing in orphanage xfsrestore: NOTE: ino 13328403 gen 3735435348 not referenced: placing in orphanage xfsrestore: NOTE: ino 13328406 gen 3735435291 not referenced: placing in orphanage xfsrestore: NOTE: ino 36898991 gen 821504621 not referenced:
Bug#510188: [Pkg-samba-maint] Bug#510188: samba: Failed to set uid privileges to (-1, 2589) now set to (0, 0) in smbd log
on active production server it happens fairly often (~50 times a day), it started after upgrade. After what upgrade? Etch's samba hasn't been updated since months. Maybe you were upgrading a sarge server to etch? My etch servers has been using sarge's samba, because of this bug: - Erroneous permissions checks after 3.0.10 - 3.0.14a (upstream #2591). Closes: #307626 I'm fairly lost as to how should I proceed with trying to debug this, so any suggestions are welcome Can you send back the output of testparm /etc/samba/smb.conf ? [global] workgroup = AD realm = MYAD.PL server string = Server %v interfaces = 192.168.10.10/255.255.255.0 security = ADS password server = ad1.myad.pl ad2.myad.pl log file = /var/log/samba/log.%m max log size = 50 debug uid = Yes socket options = TCP_NODELAY SO_SNDBUF=8192 SO_RCVBUF=8192 load printers = No dns proxy = No wins server = 192.168.10.12, 192.168.10.13 hosts allow = 127.0.0.1, 192.168.101.0/24, 192.168.100.0/24, 172.17.0.0/22 max connections = 21 [ebic_samba] comment = Samba.Test Directory path = /fs/samba/test valid users = user1, user2, @GROUP1, @GROUP2, user3, user4, user5, user6, @GROUP3 force group = GROUP2 read only = No force create mode = 0664 vfs objects = audit (better than sending the raw smb.cofn file as this will hide options that have the default values I'm starting to think that it might be client-dependant, as I wasn't able to cause the problem from any linux client, only from Windows 2000 -- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 Total Existance Failure -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495778: dovecot-pop3d: auth_debug_passwords = yes logs passwords even when they are correct.
Package: dovecot-pop3d Version: 1.0.rc15-2etch4 Severity: minor auth_debug_password is described as such: # In case of password mismatches, log the passwords and used scheme so the # problem can be debugged. Requires auth_debug=yes to be set. This means that only bad/erroneous authentications should be logged, however when auth_debug_password is set to 'yes', all conversations are logged -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18.bsd40x Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages dovecot-pop3d depends on: ii dovecot-common 1.0.rc15-2etch4 secure mail server that supports m ii libc6 2.3.6.ds1-13etch7 GNU C Library: Shared libraries ii libssl0.9.80.9.8c-4etch3 SSL shared libraries dovecot-pop3d recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460310: vzctl: upgrade from older versions looses --name settings
for n in $(find /etc/vz/names -maxdepth 1 -name *.conf); do VEID= m=`echo $n|sed -e s/.conf//` . $n echo $VEID if [ -n $VEID ] ; then ln -s /etc/vz/conf/$VEID.conf $m fi rm -f $n done The /etc/vz/names/.conf file should be removed or? I would venture a guess that removing is fine, there shouldn't be any valuable data in that conf, only VEID number (which is preserved as symlink, so there is no risk of data loss). Is there a good way to detect the change of config scheme? I'm only aware of testing using existance of *.conf settings in names/. Sorry for the long delay, I mistakenly marked this conversation as finished. -- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 Total Existance Failure -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460310: vzctl: upgrade from older versions looses --name settings
Hello, Exactly what did you need to do to solve the problem? cd /etc/vz/names for n in *; do echo $n; m=`echo $n|sed -e s/.conf//`; v=`cat $n|sed -e s/VEID=.//|sed -e s/.$//`; echo $m;ln -s /etc/vz/conf/$v.conf $m; done did the trick for me, I guess something logically equivalent wouldn't hurt much when old-style config is detected. -- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 Total Existance Failure -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400103: closed by Jose Parrella [EMAIL PROTECTED] (Bug#400103: fixed in nginx 0.4.13-2)
upgrading with this fixed nginx version removes your carefully re-created Dariush: Do you mean that the bug is still present in 0.4.13-2? Here [1] is a As far as I know, 0.4.13-2 is OK, however, when I upgrade from 0.4.13-1 (which overwrote my index.html) to -2, the process removes those files from /var/www: index.html 50x.html, which is kind of bad..., this is just a note to those caught by this buglet, for anyone else, this is irrelevent. -- Dariush Pietrzak, Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400103: closed by Jose Parrella [EMAIL PROTECTED] (Bug#400103: fixed in nginx 0.4.13-2)
Just a little followup as a warning for people caught in this: upgrading with this fixed nginx version removes your carefully re-created /var/www/index.html ;) -- Dariush Pietrzak, Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354186: ignores hwrngdevice settings in /etc/default/.., typo in /etc/init.d/rng-tools
Package: rng-tools
Version: 2-unofficial-mt.10-1
Severity: normal
Tags: patch
This should fix it:
26c26
[ -c ${HWRNGDEVICE} ] return 0
---
[ -c ${HRNGDEVICE} ] return 0
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.32-bsd32e
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages rng-tools depends on:
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii makedev 2.3.1-77 creates device files in /dev
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329773: cpqarrayd: Severely leaks memory ( 1G after few months of working )
Which version of cpqarrayd are you using? (the bug report doesn't say) latest stable - 2.0-3, Some memory changes to clean things up were added in the 2.0-4 version, if I am testing 2.0-4 right now, no signs of leakage yet, I do believe that this change should be commited to stable, I was very surprised to find my servers die, while there are known fixes available. -- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 Total Existance Failure -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329773: cpqarrayd: Severely leaks memory ( 1G after few months of working )
Package: cpqarrayd Severity: normal All cpqarrayds running on Proliant 380 G2+ are leaking memory, slower on machines with only one builtin controller (0.5G after few months), and scarily fast on machines with more then one controller. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.28-bsd25d Locale: LANG=C, LC_CTYPE=pl_PL (charmap=ISO-8859-2) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#195408: acknowledged by developer (libio-socket-ssl-perl: I'd like to be able to switch ssl on on existing IO::Socket::INET object)
the solution Peter posted seems to do what you want. Therefor I close this bug now. Correct, this method was added in 0.93, and as 0.96 is already in debian, it's all good. Thanks. -- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 Total Existance Failure -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307626: samba: Erroneous permissions checks after 3.0.10 - 3.0.14a
Package: samba Version: 3.0.14a-1 Severity: important The situation: Samba share with 'force group' directive, directories with write access for that group. After upgrade to 3.0.14a strange things start happening: mv Dir1/file Dir2/ - access denied! mkdir Dir1/tmp - OK touch Dir1/tmp/file1 - OK mv Dir1/tmp/file1 Dir1/ - OK mv Dir1/file1 Dir1/tmp/ - access denied! downgrading to 3.0.10 brings situation back to normal. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i586) Kernel: Linux 2.4.30-bsd29a Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages samba depends on: ii debconf [debconf-2.0] 1.4.30.13Debian configuration management sy ii libacl1 2.2.23-1 Access control list shared library ii libattr12.4.16-1 Extended attribute shared library ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libcomerr2 1.37-2 common error description library ii libcupsys2-gnutls10 1.1.23-10Common UNIX Printing System(tm) - ii libkrb531.3.6-2 MIT Kerberos runtime libraries ii libldap22.1.30-3 OpenLDAP libraries ii libpam-modules 0.76-22 Pluggable Authentication Modules f ii libpam-runtime 0.76-22 Runtime support for the PAM librar ii libpam0g0.76-22 Pluggable Authentication Modules l ii libpopt01.7-5lib for parsing cmdline parameters ii logrotate 3.7-2Log rotation utility ii netbase 4.21 Basic TCP/IP networking system ii samba-common3.0.14a-1Samba common files used by both th -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#147280: Assigning UIDs over 65536 should not be a bug anymore
tags 147280 wontfix retitle 147280 [TO CLOSE 20050405] passwd: newusers finds max userid as base - on debian there is nobody user with 65534 uid thanks As far as I know, assigning UIDs over 65534 is no more a problem, so I suppose that the bug you reported should now be closed. Do you have any objection to this? I think that the original problem, with treating max userid as base, should be fixed. One can easily imagine someone creating uid==2**32, besides such behaviour is a bit unelegant. It should search for lowest available userid, or at least this behaviour should be configurable. regards, Eyck -- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 We're giving you a new chance in life, and an opportunity to screw it up in a new, original way. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#234526: munin-node: cpu graph draws very strange values on HT-enabled cpus
on dual-cpu ( actually HT-enabled p4 ), I get very strange results from Sorry that I forgot about this bug. Does this still happen with the 1.2.2 version? I have lots of servers with HT works just fine, see. I'll have to return to you on that in few days, I created my own cpu probe so I haven't seen if anything changed. -- Dariush Pietrzak, Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
