Package: mdadm
Version: 2.5.5-1
Severity: grave
it's dangerous to generate an mdadm.conf and start running arrays
automatically at install time! i nearly got bit by this.
i marked this grave because there's a potential for data loss with the
current install scripts.
i had 4 disks which i had
Package: mdadm
Version: 2.5.5-1
Severity: grave
even though i have INITRDSTART='none' in my /etc/default/mdadm and rebuilt
the initrd, it still goes and does array discovery at boot time.
this is marked grave because it can cause dataloss if drives with stale
superblocks are put together in an
Package: munin-node
Version: 1.2.5-1
for the exact right length of sensors name there's no spaces following the
colon... for example:
% sensors |grep Temp
CPU2_Temp:+39.25 C (low =+0 C, high = +90 C)
CPU1_Temp:+42.00 C (low =+0 C, high = +90 C)
i fixed all three regex even
seems like i figured out all the details for making a release.
except i don't run redhat/fedora anywhere, so i didn't make an rpm.
instead i placed the spec files into the release tarball, so folks can
build their own.
enjoy!
-dean
New in v1.1.6 (2006/11/11)
--
Man
and to go along with the 1.1.6 release here's a new stable 1.0.5 release.
http://savannah.nongnu.org/download/rdiff-backup/rdiff-backup-1.0.5.tar.gz
-dean
New in v1.0.5 (2006/11/11)
--
Fix a traceback due to an off-by-1 error in --remove-older-than nB.
Fix a security
this patch adds a -sparse predicate which is true iff the object is a file
and the size is greater than the number of blocks * blocksize can
represent.
it would be cool if you would consider this for inclusion in findutils.
thanks
-dean
Index: findutils-4.2.28/find/parser.c
On Wed, 8 Nov 2006, James Lee wrote:
However I'm still seeing the error messages in my dmesg (the ones I
posted earlier), and they suggest that there is some kind of hardware
fault (based on a quick Google of the error codes). So I'm a little
confused.
the fact that the error is in a
On Mon, 6 Nov 2006, Mikael Abrahamsson wrote:
On Mon, 6 Nov 2006, Neil Brown wrote:
So it looks like you machine recently crashed (power failure?) and it is
restarting.
Or upgrade some part of the OS and now it'll do resync every week or so (I
think this is debian default nowadays,
On Mon, 6 Nov 2006, Neil Brown wrote:
hey i have another related question... external bitmaps seem to pose a bit
of a chicken-and-egg problem. all of my filesystems are md devices. with
an external bitmap i need at least one of the arrays to start, then have
filesystems mounted, then
On Mon, 6 Nov 2006, James Lee wrote:
Thanks for the reply Dean. I looked through dmesg output from the
boot up, to check whether this was just an ordering issue during the
system start up (since both evms and mdadm attempt to activate the
array, which could cause things to go wrong...).
On Mon, 6 Nov 2006, Neil Brown wrote:
This creates a deep disconnect between udev and md.
udev expects a device to appear first, then it created the
device-special-file in /dev.
md expect the device-special-file to exist first, and then created the
device on the first open.
could you create
On Sun, 5 Nov 2006, Bradshaw wrote:
I've recently built a smallish RAID5 box as a storage area for my home
network, using mdadm. However, one of the drives will not remain in the array
for longer that around two days before it is removed. Readding it to the array
does not throw any errors,
On Sun, 5 Nov 2006, James Lee wrote:
Hi there,
I'm running a 5-drive software RAID5 array across two controllers.
The motherboard in that PC recently died - I sent the board back for
RMA. When I refitted the motherboard, connected up all the drives,
and booted up I found that the array
On Sun, 5 Nov 2006, Andrew Ferguson wrote:
Blair Zajac wrote:
diff -Nur rdiff-backup-cvs/rdiff_backup/rpath.py rdiff-backup-
symlink-perms/rdiff_backup/rpath.py
--- rdiff-backup-cvs/rdiff_backup/rpath.py 2006-01-13
00:29:47.0 -0500
+++
i think i've got my mdadm.conf set properly for an external bitmap -- but
it doesn't seem to work. i can assemble from the command-line fine
though:
# grep md4 /etc/mdadm/mdadm.conf
ARRAY /dev/md4 bitmap=/bitmap.md4 UUID=dbc3be0b:b5853930:a02e038c:13ba8cdc
# mdadm -A /dev/md4
mdadm: Could not
On Sat, 4 Nov 2006, martin f krafft wrote:
also sprach dean gaudet [EMAIL PROTECTED] [2006.11.03.2019 +0100]:
I cannot find authoritative information about the relation between
the RAID chunk size and the correct stride parameter to use when
creating an ext2/3 filesystem.
you know
On Sat, 4 Nov 2006, Yeroc wrote:
dean gaudet-2 wrote:
On Tue, 31 Oct 2006, Keith Edmunds wrote:
[...]
but this shouldn't stop anyone else from contributing patches.
[...]
You're right that this shouldn't stop anyone else from contributing patches
but the problem is that without
thanks... applied to both trees.
-dean
On Sat, 4 Nov 2006, Andrew Ferguson wrote:
Hi,
Some Unix systems (at least the *BSDs and Mac OS X) set the permission
bits on symbolic links to 777 - umask at link creation. This is
different from Linux, where all symbolic links are mode 777.
This
applied to cvs HEAD only.
am i right that the 1.1.x tree is the preferred tree for OSX users? (i.e.
i shouldn't bother applying OSX patches to 1.0.x tree?)
-dean
On Thu, 17 Aug 2006, Andrew Ferguson wrote:
Hi,
The attached patch against the rdiff-backup CVS adds support for
preserving
On Sat, 29 Apr 2006, Andrew Ferguson wrote:
Mac OS X 10.4 introduced generic extended attributes to the HFS+
filesystem. By using the xattr Python module from
http://undefined.org/python/ and the attached patch, rdiff-backup can
handle backing up these new attributes. The patch is against the
can you provide a patch against current cvs head?
-dean
On Sat, 2 Sep 2006, [EMAIL PROTECTED] wrote:
Good evening,
i came across http://savannah.nongnu.org/bugs/?func=detailitemitem_id=16447
today.
bug #16447: manpage not in sync w/ current options
i took a deeper look into that,
this seems reasonable -- but your mailer seems to have damaged the
patch... could you refresh against cvs head and resend?
thanks
-dean
On Tue, 16 May 2006, The Anarcat wrote:
[EMAIL PROTECTED] wrote:
Maybe we should check fail/success when looking in that directory and if
it fails,
hi... i figure it can't hurt too badly if i commit patches which i've only
read and not tested. can't be worse than the current situation.
i've committed a handful i found in my mailbox and in the bugs/patches
tracker.
if you have patches you've been using/tested for a while and would like to
On Sat, 4 Nov 2006, Andrew Ferguson wrote:
dean gaudet wrote:
hi... i figure it can't hurt too badly if i commit patches which i've only
read and not tested. can't be worse than the current situation.
i've committed a handful i found in my mailbox and in the bugs/patches
tracker
On Tue, 24 Oct 2006, martin f krafft wrote:
Hi,
I cannot find authoritative information about the relation between
the RAID chunk size and the correct stride parameter to use when
creating an ext2/3 filesystem.
you know, it's interesting -- mkfs.xfs somehow gets the right sunit/swidth
Package: ddrescue
Version: 1.10-1
there's a new upstream 1.12... which makes O_DIRECT actually work properly
amidst other things. it'd be cool if you could update the debian package.
thanks
-dean
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
On Tue, 31 Oct 2006, Keith Edmunds wrote:
Ben, are you still reading this? Dean?
i'm here...
rdiff-backup just hasn't been at the top of my list for a while. mostly
because i have a setup which works and there's a zillion other things with
higher priority right now.
i'm still using
On Wed, 1 Nov 2006, J. Norment wrote:
I'd like to clear out the repo at the end of the month and start with a fresh
one... is the best way to do this just to delete everything under the
rdiff-backup-data path?
yes, and then you have to add --force to the next invocation of
rdiff-backup so
On Mon, 30 Oct 2006, Brad Campbell wrote:
Michael Tokarev wrote:
My guess is that it's using mdrun shell script - the same as on Debian.
It's a long story, the thing is quite ugly and messy and does messy things
too, but they says it's compatibility stuff and continue shipping it.
...
On Tue, 24 Oct 2006, Bill Davidsen wrote:
My read on LVM is that (a) it's one more thing for the admin to learn, (b)
because it's seldom used the admin will be working from documentation if it
has a problem, and (c) there is no bug-free software, therefore the use of LVM
on top of RAID will
Package: geoip
Version: 1.3.17-1
the patch below has been accepted into the upstream repository, and will
appear next release... however it may be worth updating the debian package
in the interim.
-dean
- Original message -
From: dean gaudet
Date: Mon, 4 Sep 2006 18:50:28 -0700 (PDT
On Mon, 9 Oct 2006, Seather wrote:
Hi there,
When I run an rdiff-backup --list-increment-sizes, the output seems to be
reversed. Am I perhaps missing something or confused about how this works? In
my output that I have pasted below, the Cumulative size field decreases as
the date
Package: memcached
Version: 1.1.12-1
seems like the safest default install would be to run as a non-root
user... (and i was gonna say listen on 127.0.0.1 but someone beat me to
it).
thanks
-dean
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
On Wed, 4 Oct 2006, Guy Harris wrote:
I've checked in a change to do that. pcap-usb.h is now pcap/usb.h (I
didn't leave a pcap-usb.h file behind), and I also moved sll.h to
pcap/sll.h and install it (for the benefit of applications that want to know
what the DLT_LINUX_SLL cooked header looks
Package: console-tools
Version: 1:0.2.3dbs-65
the various /etc/console-tools/config settings aren't applied to the vga
device if i boot my system with console=ttyS0,115200 command-line option.
now i know... you're thinking you said the console is serial, not vga...
but then, that begs the
On Tue, 26 Sep 2006, Stephen Hemminger wrote:
The mii-tool utility seems to be abandoned and unmaintained?
Here is a version that does standard 1000baseT support.
http://developer.osdl.org/shemminger/prototypes/mii-tool.tar.bz2
cool that's bugged me for a while...
there's an off-by-1
On Tue, 26 Sep 2006, Jeff Garzik wrote:
Stephen Hemminger wrote:
The mii-tool utility seems to be abandoned and unmaintained?
Here is a version that does standard 1000baseT support.
http://developer.osdl.org/shemminger/prototypes/mii-tool.tar.bz2
Not really. I would rather leave
On Wed, 27 Sep 2006, Auke Kok wrote:
dean gaudet wrote:
On Tue, 26 Sep 2006, Jeff Garzik wrote:
Stephen Hemminger wrote:
The mii-tool utility seems to be abandoned and unmaintained?
Here is a version that does standard 1000baseT support.
http://developer.osdl.org
... thanks!
-dean
-- Forwarded message --
Date: Wed, 27 Sep 2006 12:15:08 -0700 (PDT)
From: dean gaudet [EMAIL PROTECTED]
To: Stephen Hemminger [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED], [EMAIL PROTECTED],
netdev@vger.kernel.org
Subject: Re: mii-tool gigabit support.
On Tue
if you apt-get remove bc you get this error during configure of rtorrent
source package:
checking for curl = 7.12.0... ./configure: line 13046: bc: command not
found 7.15.5
now look at the code in scripts/checks.m4:
ver=`curl-config --version | sed -e s/libcurl //g`
On Wed, 20 Sep 2006, Jose Luis Rivas Contreras wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
dean gaudet escribió:
if you apt-get remove bc you get this error during configure of rtorrent
source package:
^^
I'm sorry but I doesn't see this error:
split
paty:/home
On Tue, 19 Sep 2006, Eduardo Jacob wrote:
DEVICE /dev/raid111 /dev/raid121
ARRAY /dev/md0 level=raid1 num-devices=2
UUID=1369e13f:eb4fa45c:6d4b9c2a:8196aa1b
try using DEVICE partitions... then mdadm -As /dev/md0 will scan all
available partitions for raid components with
Package: rtorrent
Version: 0.6.1-1
scripts/checks.m4: ok=`echo ibase=16; if($hex_ver=$check_hex) $hex_ver
else 0 | bc`
needs bc installed... it's there in 0.6.2 upstream as well.
just for pedantry could you add a build-depends: bc?
thanks
-dean
--
To UNSUBSCRIBE, email to [EMAIL
On Tue, 12 Sep 2006, Dexter Filmore wrote:
Am Dienstag, 12. September 2006 16:08 schrieb Justin Piszcz:
/dev/MAKEDEV /dev/md0
also make sure the SW raid modules etc are loaded if necessary.
Won't work, MAKEDEV doesn't know how to create [/dev/]md0.
echo 'DEVICE partitions'
On Sat, 9 Sep 2006, Richard Scobie wrote:
To remove all doubt about what is assembled where, I though going to:
DEVICE partitions
MAILADDR root
ARRAY /dev/md3 UUID=xyz etc.
would be more secure.
Is this correct thinking on my part?
yup.
mdadm can generate it all for you... there's
On Tue, 5 Sep 2006, Paul Waldo wrote:
What about bitmaps? Nobody has mentioned them. It is my understanding that
you just turn them on with mdadm /dev/mdX -b internal. Any caveats for
this?
bitmaps have been working great for me on a raid5 and raid1. it makes it
that much more tolerable
On Fri, 8 Sep 2006, Michael Tokarev wrote:
Recently Dean Gaudet, in thread titled 'Feature
Request/Suggestion - Drive Linking', mentioned his
document, http://arctic.org/~dean/proactive-raid5-disk-replacement.txt
I've read it, and have some umm.. concerns. Here's why:
mdadm -Gb
On Sat, 9 Sep 2006, Richard Scobie wrote:
If I have specified an array in mdadm.conf using UUID's:
ARRAY /dev/md0 UUID=3aaa0122:29827cfa:5331ad66:ca767371
and I replace a failed drive in the array, will the new drive be given the
previous UUID, or do I need to upate the mdadm.conf
Package: gzip
Version: 1.3.5-14
please define UNALIGNED_OK when building the amd64 target... unaligneds
are very inexpensive on all intel and amd cpus.
i benchmarked gzip -9 on linux-2.6.17.tar with this define and i see a
2.5% speedup on p4, a64, and a 9% speedup on core2.
note that this
Package: zlib
Version: 1.2.3-13
please define UNALIGNED_OK when building the amd64 target... unaligneds
are very inexpensive on all intel and amd cpus.
i benchmarked gzip -9 on linux-2.6.17.tar with this define and i see a
2.5% speedup on p4, a64, and a 9% speedup on core2. the zlib source
On Mon, 4 Sep 2006, Bill Davidsen wrote:
But I think most of the logic exists, the hardest part would be deciding what
to do. The existing code looks as if it could be hooked to do this far more
easily than writing new. In fact, several suggested recovery schemes involve
stopping the RAID5,
Package: bind9
Version: 9.3.2-2.1
there's several type-punning warnings while building bind9 9.3.2-2.1... i
don't know if these are bugs or not, but it's probably best to add
-fno-strict-aliasing to CFLAGS until upstream deals with them (otherwise
there could be some subtle hard to discover
On Sun, 3 Sep 2006, Clive Messer wrote:
This leads me to a question. I understand from reading the linux-raid
archives
that the current behaviour when rebuilding with a single badblock on another
disk is for that disk to also be kicked from the array.
that's not quite the current
Package: cpuburn
Version: 1.4-23
there's another burn-in program which is based on gromacs inner loops
(such as those used in [EMAIL PROTECTED]) which tends to drive up cpu
temperatures even more than the programs already in cpuburn package. it
has the additional advantage of checking its
On Sun, 13 Aug 2006, dean gaudet wrote:
On Fri, 11 Aug 2006, David Rees wrote:
On 8/11/06, dean gaudet [EMAIL PROTECTED] wrote:
On Fri, 11 Aug 2006, David Rees wrote:
On 8/10/06, dean gaudet [EMAIL PROTECTED] wrote:
- set up smartd to run long self tests once a month
On Wed, 30 Aug 2006, Neil Bortnak wrote:
Hi Everybody,
I had this major recovery last week after a hardware failure monkeyed
things up pretty badly. About half way though I had a couple of ideas
and I thought I'd suggest/ask them.
1) Drive Linking: So let's say I have a 6 disk RAID5
On Sat, 26 Aug 2006, roland wrote:
AttributeError: RPath instance has no attribute 'inc_compressed'
The hint at
http://lists.nongnu.org/archive/html/rdiff-backup-users/2006-03/msg00038.html
has helped here.
i think last i looked at the code there i couldn't quite figure out if my
On Thu, 24 Aug 2006, Keith Edmunds wrote:
On 08/23/2006 9:18:37 PM +0100
Sebastien Maret [EMAIL PROTECTED] said:
When this occurs, the next backup fails because rdiff-backup believes
that there is still a process running, although it is not the case. Is
this a bug in the way
fyi this is the same segfault i was getting which is fixed by the patch i
included in #382841 ...
it also looks like the new upstream 0.6.1 / 0.10.1 includes the fix.
-dean
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Wed, 16 Aug 2006, Peter Greis wrote:
So, how do I change / and /boot to make the super
blocks persistent ? Is it safe to run mdadm --create
/dev/md0 --raid-devices=2 --level=1 /dev/sda1
/dev/sdb1 without loosing any data ?
boot a rescue disk
shrink the filesystems by a few MB to
On Fri, 11 Aug 2006, David Rees wrote:
On 8/11/06, dean gaudet [EMAIL PROTECTED] wrote:
On Fri, 11 Aug 2006, David Rees wrote:
On 8/10/06, dean gaudet [EMAIL PROTECTED] wrote:
- set up smartd to run long self tests once a month. (stagger it every
few days so that your disks
Package: rtorrent
Version: 0.6.0-1
this patch was extracted from upstream svn. it fixes a segfault which
occurs with libcurl 7.15.5. it tends to hit me when i have lots of
torrents going.
-dean
Index: src/core/curl_stack.cc
===
suggestions:
- set up smartd to run long self tests once a month. (stagger it every
few days so that your disks aren't doing self-tests at the same time)
- run 2.6.15 or later so md supports repairing read errors from the other
drives...
- run 2.6.16 or later so you get the check and
Package: debconf
Version: 1.5.3
apache-1.3.34-2 package can't be configured when debconf 1.5.3 is on the
box... works fine when 1.5.2 is on the box...
tail of set -x output looks like so:
+ db_set apache/server-name arctic.org
+ _db_cmd 'SET apache/server-name' arctic.org
+ printf '%s\n' 'SET
On Fri, 4 Aug 2006, Maarten Bezemer wrote:
This made me think about something related: what happens if the tree
you're backup up contains an rdiff-backup-data directory? Will it be
escaped? Will it be ignored? Will it be used and screw up the whole thing?
danger danger. you'll be unhappy if
On Thu, 3 Aug 2006, Petter Reinholdtsen wrote:
[Dean Gaudet]
/dev/shm should be mounted -o nosuid,nodev ... there's no reason to
allow suid binaries or devices in /dev/shm.
If I understand you correctly, you are proposing the change in the
patch I attach here. I'm not sure what
On Sun, 30 Jul 2006, Chris Connett wrote:
Thanks for your comments. Jumping into a new code base, I was pretty
sure I wouldn't get it right my first shot. I looked for the callers
when writing this, but I took the assert to mean temp files should
always be local, which apparently isn't the
Package: crack
Version: 5.0a-9
one of the scripts is tripping a sort warning for deprecated syntax:
# Crack -nice 19 /etc/passwd
Crack 5.0a: The Password Cracker.
(c) Alec Muffett, 1991, 1992, 1993, 1994, 1995, 1996
System: Linux twinlark.arctic.org 2.6.16.27 #1 SMP Sat Jul 22 15:56:11 PDT 2006
Package: cracklib-runtime
Version: 2.7-19
update-cracklib runs daily... and writes a new dictionary even if there's
been no change to its input sources. if you have several wordlists
installed this can take some time and cause extra churn for backups...
please consider the patch below...
Package: ntp
Version: 1:4.2.2+dfsg-1
in 4.2.0* if you specified -L you could stop ntp from listening on virtual
interfaces.
sometime since then the upstream has added -L interface to specify the
interface... but ntpd still insists on listening on every interface it
finds!
check out this
hmm... it seems that 4.2.0 opened the broadcast address anyhow... it just
avoided opening all the other interfaces when given -L. so really the
only regression here is that it's opening way more fds than it needs to...
especially if you give it -L eth0.
oh btw -- if there are more than ~512
On Thu, 27 Jul 2006, Giacomo A. Catenazzi wrote:
dean gaudet wrote:
ah yeah that's fixed only in CVS... hasn't been released.
you can grab the cvs repo if you want... only reason it hasn't been
released is because ben has been otherwise busy. i've been using it for
months
Package: dejagnu
Version: 1.4.4.cvs20060709-2
the following directories have odd permissions:
# dpkg -L dejagnu | xargs ls -ld | grep ^drw-
drw-r-xr-x5 root root 4096 Jul 25 11:42 /usr/share/dejagnu
drw-r-xr-x2 root root 4096 Jul 25 11:42 /usr/share/dejagnu/baseboards
drw-r-xr-x2
i'm hitting this bug on a file which is only 4315422720 bytes...
it'd be great if you could apply the patch before etch release... it fixes
the problem. thanks!
-dean
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Tue, 25 Jul 2006, Giacomo A. Catenazzi wrote:
Hello
For remote backup, after the normal backup, I delete the older
files, with two policies 15 days, but max. 5 changes:
echo
rdiff-backup --remove-older-than 15D
[EMAIL PROTECTED]::/home/pix-backups/orion2
echo
ah yeah that's fixed only in CVS... hasn't been released.
you can grab the cvs repo if you want... only reason it hasn't been
released is because ben has been otherwise busy. i've been using it for
months.
http://savannah.nongnu.org/cvs/?group=rdiff-backup
you want to add in a -r r1-0 option
Package: dcc
Version: 1.2.74-2
if you look at the make output while building dcc package you'll see that
none of the sub-makes have been passed the -O2 flag... so none of the cc
lines have -O2 on them. this could very well be an upstream problem...
but since the entire package is built in
the following patch fixes two bugs related to dccproc functioning when the
kernel doesn't support AF_INET6.
dcc_udp_bind is cloberring errno before using it... and is testing for the
wrong errno... it needs to test for EAFNOSUPPORT. i probably should have
dropped the EPFNOSUPPORT tests, but
On Mon, 24 Jul 2006, Jes Kasper Klittum wrote:
Den 21/07/2006 kl. 18.46 skrev dean gaudet:
On Fri, 21 Jul 2006, Jes Kasper Klittum wrote:
Attached is the last 99 lines of the v9 log, after it failed 2 hours and
39
minutes after initiation. I don't really see anything wrong
On Mon, 24 Jul 2006, Chris Connett wrote:
Hello,
http://lists.nongnu.org/archive/html/rdiff-backup-users/2006-01/msg00070.html
I saw a few archived mails that exactly describe the problem I'm
having now, but the problem doesn't seem to have gone away. There was
talk of fixing it, but
the following patch fixes two bugs related to dccproc functioning when the
kernel doesn't support AF_INET6.
dcc_udp_bind is cloberring errno before using it... and is testing for the
wrong errno... it needs to test for EAFNOSUPPORT. i probably should have
dropped the EPFNOSUPPORT tests, but
Package: mutt
Version: 1.5.12-1
please consider configuring mutt with --enable-buffy-size so that it
doesn't rely on atime updates when determining if there's new mail.
atimes are unreliable (consider a backup program -- it'll change the
atimes) and a waste of disk i/o...
mutt is the only
On Sun, 23 Jul 2006, Christoph Berg wrote:
Re: dean gaudet 2006-07-23 [EMAIL PROTECTED]
please consider configuring mutt with --enable-buffy-size so that it
doesn't rely on atime updates when determining if there's new mail.
It should be make a configuration option.
that'd be OK
On Sun, 23 Jul 2006, Charles Duffy wrote:
I'm running backups in such a way that rdiff-backup --server is being run
with uid and gid backup. I want to be able to give users who are allowed to
run restores membership in the backup group, and arrange permissions such that
this is sufficient to
Package: mysql-server-5.0
Version: 5.0.22-3
every time i do /etc/init.d/mysql start or restart it runs the
mysql_upgrade script... and even if the database has already been upgraded
it always runs this:
mysql_fix_privilege_tables --silent --user=$user --password=$password
which of course
there's several threads like this in the archive...
unfortunately there's no perfect solution... it needs improvement in the
code. (patches welcome :)
note that rdiff-backup at best is going to need 2x the storage space for a
large file -- otherwise it would be modifying the file in-place and
On Fri, 21 Jul 2006, Peter Valdemar Mørch wrote:
Karjala karjala_lists-at-karjala.org |Lists| wrote:
The last-modified date on a directory shows when there has been any change
in a file inside that directory or any of its subdirectories.
That assumption is not correct. Not with reiser-fs
On Thu, 20 Jul 2006, Jes Kasper Klittum wrote:
Den 19/07/2006 kl. 19.53 skrev dean gaudet:
assuming that you were tracing the remote rdiff-backup then it appears to
be getting an EOF on stdin... which makes me think there's something going
on in the transport layer... not sure what
On Thu, 20 Jul 2006, Jes Kasper Klittum wrote:
10:15:10.543684 IP backupserver.com.59297 remote-server.com.99: F
82592624:82592624(0) ack 39621297 win 10064 nop,nop,timestamp 1153104691
2127151431
10:15:10.583398 IP remote-server.com.99 backupserver.com.59297: F
39621297:39621297(0) ack
On Wed, 19 Jul 2006, Jes Kasper Klittum wrote:
There is a switch between the two servers. Rsync never fails though? It seems
to happen at an hour stroke - say 12.04 PM 6.08 PM and so forth. I was
wondering if this could happen in conjunction with a cron job being run. If
load is high or
On Wed, 19 Jul 2006, Jes Kasper Klittum wrote:
none of that seems very likely...
can you attach strace to the rdiff-backup process on the remote host?
strace -o tracefile -p $pid ... hopefully there'll be some hint at the
very end. if that doesn't help then also try figuring out
On Tue, 18 Jul 2006, Jes Kasper Klittum wrote:
the Nonetype stuff is misleading... it's the stuff here at the end of
the error message which has a hint.
any reason the net would drop out? is the backup over dsl? keep-alives
set too low or some other form of timeout kicking in?
On Mon, 17 Jul 2006, Christian Pernegger wrote:
The problem seems to affect only arrays that are started via an
initrd, even if they do not have the root filesystem on them.
That's all arrays if they're either managed by EVMS or the
ramdisk-creator is initramfs-tools. For yaird-generated
On Fri, 14 Jul 2006, Jes Kasper Klittum wrote:
raise ConnectionReadError(Truncated header string (problem
rdiff_backup.connection.ConnectionReadError: Truncated header string (problem
probably originated remotely)
the Nonetype stuff is misleading... it's the stuff here at the end of
the
Package: initscripts
Version: 2.86.ds1-14.1
/dev/shm should be mounted -o nosuid,nodev ... there's no reason to allow
suid binaries or devices in /dev/shm.
thanks
-dean
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
for sharing this.
I am not quite understand about these 2 commands. Why we want to add a
pre-failing disk back to md4?
mdadm --zero-superblock /dev/sde1
mdadm /dev/md4 -a /dev/sde1
Ming
On Sun, 2006-04-23 at 18:40 -0700, dean gaudet wrote:
i had a disk in a raid5 which i wanted to clone
On Wed, 7 Jun 2006, Jonas Smedegaard wrote:
Then I'll just lean back and wait for you to do the hard work :-D
ok i've got a partial solution... see below.
i say partial because the following scenario is not quite ideal:
- md initially on /dev/sda1 /dev/sdb1 ... build initrd
- another disk
for this one we'll probably need strace output... suitably trimmed to show
what it's trying to do with the problem file and possibly surrounding
directory.
can you reproduce with a small test case?
what rdiff-backup version? there have been some nfs-related fixes... in
1.0.3 for example.
rdiff-backup won't handle this cleanly. it will treat all the newly named
files as new and keep deltas deleting the old names... so yeah it'll
double your space requirements until you age the old deltas.
the inode is used for hardlink detection only... not renaming
unfortunately.
mind you
i'd try something like:
find mirror -type f -print0 | xargs -0 touch -d yesterday
that might cause rdiff-backup to recompare everything and set the
timestamps appropriately...
if that doesn't work then try uncompressing the latest mirror_metadata
file and using perl or something to set the
301 - 400 of 1643 matches
Mail list logo
