Re: Confirmation for subscribe amanda-users
I am getting the following error from amdump: FAILURE AND STRANGE DUMP SUMMARY: wookie.int /boot lev 0 FAILED [disk /boot offline on wookie.internal.americom.com?] On wookie, the file sendsize.20020124035422.debug says: *** sendsize: debug 1 pid 10396 ruid 33 euid 33 start time Thu Jan 24 03:54:22 2002 /usr/local/libexec/sendsize: version 2.4.2p2 calculating for amname '/boot', dirname '/boot' sendsize: getting size via dump for /boot level 0 sendsize: running "/sbin/dump 0Ssf 1048576 - /dev/sda2" running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot /dev/sda2: Permission denied while opening filesystem . (no size line match in above dump output) . asking killpgrp to terminate sendsize: pid 10396 finish time Thu Jan 24 03:54:23 2002 ** However, when I run dump manually on wookie, it runs with no problem and: /sbin/dump 0Ssf 1048576 - /dev/sda2 displays: 9334784 I have read the FAQ and the question regarding this issue did not seem to apply. The filesystem is very small and I didn't really understand the rest. I am in the testing phase and this is the only filesystem I am attempting to dump in an attempt to isolate the problem. I am running Red Hat Linux 7.2 and amanda-2.4.2p2 on the client and host. Can anyone help? I can post any files needed to help diagnose the problem. Thanks, Dick
Re: Confirmation for subscribe amanda-users
On 24 Jan 2002 at 11:10am, [EMAIL PROTECTED] wrote > I am getting the following error from amdump: > > FAILURE AND STRANGE DUMP SUMMARY: > wookie.int /boot lev 0 FAILED [disk /boot offline on wookie.internal.americom.com?] > > On wookie, the file sendsize.20020124035422.debug says: > > running /usr/local/libexec/killpgrp > DUMP: Warning: unable to translate LABEL=/ > DUMP: Warning: unable to translate LABEL=/boot > /dev/sda2: Permission denied while opening filesystem > . I see two problems above. First, you need to apply the advfs patch from the patches page at amanda.org -- it fixes the 'unable to translate LABEL' errors above. Second, dump isn't being run with the proper permissions. What group is the amanda user in? And what does 'ls -l /dev/sda2' say? > However, when I run dump manually on wookie, it runs with no problem > and: > Running dump as which user? If the amanda user, then what does your /etc/xinetd entry for amanda look like? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Confirmation for subscribe amanda-users
> > I am getting the following error from amdump: > > > > FAILURE AND STRANGE DUMP SUMMARY: > > wookie.int /boot lev 0 FAILED [disk /boot offline on wookie.internal.americom.com?] > > > > On wookie, the file sendsize.20020124035422.debug says: > > > > running /usr/local/libexec/killpgrp > > DUMP: Warning: unable to translate LABEL=/ > > DUMP: Warning: unable to translate LABEL=/boot > > /dev/sda2: Permission denied while opening filesystem > > . > > I see two problems above. First, you need to apply the advfs patch from > the patches page at amanda.org -- it fixes the 'unable to translate LABEL' > errors above. Will do. > Second, dump isn't being run with the proper permissions. > What group is the amanda user in? >From /etc/group: disk:x:6:root,rwk,amanda > And what does 'ls -l /dev/sda2' say? brw-rw1 root disk 8, 2 Aug 24 2000 /dev/sda2 Also, amcheck *does* run successfully. Please advise and thank you for your help! Dick > > However, when I run dump manually on wookie, it runs with no problem > > and: > > > > Running dump as which user? If the amanda user, then what does your > /etc/xinetd entry for amanda look like? > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University >
Re: Confirmation for subscribe amanda-users
I installed advfs.diff on the client (wookie) and reran the test dump but the sendsize*dump file still says: ** sendsize: debug 1 pid 8615 ruid 33 euid 33 start time Thu Jan 24 17:13:43 2002 /usr/local/libexec/sendsize: version 2.4.2p2 calculating for amname '/boot', dirname '/boot' sendsize: getting size via dump for /boot level 0 sendsize: running "/sbin/dump 0Ssf 1048576 - /dev/sda2" running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot /dev/sda2: Permission denied while opening filesystem . (no size line match in above dump output) . asking killpgrp to terminate sendsize: pid 8615 finish time Thu Jan 24 17:13:44 2002 ** amandad*debug says: ** amandad: debug 1 pid 8614 ruid 33 euid 33 start time Thu Jan 24 17:13:43 2002 amandad: version 2.4.2p2 amandad: build: VERSION="Amanda-2.4.2p2" amandad:BUILT_DATE="Thu Jan 24 16:50:09 MST 2002" amandad:BUILT_MACH="Linux wookie.americom.com 2.2.16-22enterprise #1 SMP Tue Aug 22 16:29:32 EDT 2000 i686 unknown" amandad:CC="gcc" amandad: paths: bindir="/usr/local/bin" sbindir="/usr/local/sbin" amandad:libexecdir="/usr/local/libexec" mandir="/usr/local/man" amandad:AMANDA_TMPDIR="/tmp/amanda" AMANDA_DBGDIR="/tmp/amanda" amandad:CONFIG_DIR="/usr/local/etc/amanda" DEV_PREFIX="/dev/" amandad:RDEV_PREFIX="/dev/" DUMP="/sbin/dump" amandad:RESTORE="/sbin/restore" SAMBA_CLIENT="/usr/bin/smbclient" amandad:GNUTAR="/bin/gtar" COMPRESS_PATH="/usr/bin/gzip" amandad:UNCOMPRESS_PATH="/usr/bin/gzip" MAILER="/usr/bin/Mail" amandad:listed_incr_dir="/usr/local/var/amanda/gnutar-lists" amandad: defs: DEFAULT_SERVER="wookie.americom.com" amandad:DEFAULT_CONFIG="DailySet1" amandad:DEFAULT_TAPE_SERVER="wookie.americom.com" amandad:DEFAULT_TAPE_DEVICE="/dev/null" HAVE_MMAP HAVE_SYSVSHM amandad:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE amandad:AMANDA_DEBUG_DAYS=4 BSD_SECURITY USE_AMANDAHOSTS amandad:CLIENT_LOGIN="amanda" FORCE_USERID HAVE_GZIP amandad:COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast" amandad:COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc" got packet: Amanda 2.4 REQ HANDLE 000-20720708 SEQ 1011917624 SECURITY USER amanda SERVICE sendsize OPTIONS maxdumps=1;hostname=wookie.internal.americom.com; DUMP /boot 0 1970:1:1:0:0:0 -1 sending ack: Amanda 2.4 ACK HANDLE 000-20720708 SEQ 1011917624 bsd security: remote host gorn.americom.com user amanda local user amanda amandahosts security check passed amandad: running service "/usr/local/libexec/sendsize" amandad: sending REP packet: Amanda 2.4 REP HANDLE 000-20720708 SEQ 1011917624 OPTIONS maxdumps=1; /boot 0 SIZE -1 amandad: got packet: Amanda 2.4 ACK HANDLE 000-20720708 SEQ 1011917624 amandad: pid 8614 finish time Thu Jan 24 17:13:44 2002 ** killpgrp*debug says: ** killpgrp: debug 1 pid 8616 ruid 33 euid 0 start time Thu Jan 24 17:13:43 2002 /usr/local/libexec/killpgrp: version 2.4.2p2 sending SIGTERM to process group 8616 child process exited with status 1 ** The amcheck program succeeds. Is there anything I can run on the client to indicate why it is failing? Thanks, Dick > > > I am getting the following error from amdump: > > > > > > FAILURE AND STRANGE DUMP SUMMARY: > > > wookie.int /boot lev 0 FAILED [disk /boot offline on >wookie.internal.americom.com?] > > > > > > On wookie, the file sendsize.20020124035422.debug says: > > > > > > running /usr/local/libexec/killpgrp > > > DUMP: Warning: unable to translate LABEL=/ > > > DUMP: Warning: unable to translate LABEL=/boot > > > /dev/sda2: Permission denied while opening filesystem > > > . > > > > I see two problems above. First, you need to apply the advfs patch from > > the patches page at amanda.org -- it fixes the 'unable to translate LABEL' > > errors above. > > Will do. > > > Second, dump isn't being run with the proper permissions. > > What group is the amanda user in? > > >From /etc/group: > > disk:x:6:root,rwk,amanda > > > And what does 'ls -l /dev/sda2' say? > > brw-rw1 root disk 8, 2 Aug 24 2000 /dev/sda2 > > Also, amcheck *does* run successfully. > > Please advise and thank you for your help! > > Dick > > > > However, when I run dump manually on wookie, it runs with no problem > > > and: > > > > > > > Running dump as which user? If the amanda user, then what does your > > /etc/x
Re: Confirmation for subscribe amanda-users
[EMAIL PROTECTED] wrote: > > I installed advfs.diff on the client (wookie) and reran the test dump > but the sendsize*dump file still says: > > ** > sendsize: debug 1 pid 8615 ruid 33 euid 33 start time Thu Jan 24 17:13:43 2002 > /usr/local/libexec/sendsize: version 2.4.2p2 > calculating for amname '/boot', dirname '/boot' > sendsize: getting size via dump for /boot level 0 > sendsize: running "/sbin/dump 0Ssf 1048576 - /dev/sda2" > running /usr/local/libexec/killpgrp > DUMP: Warning: unable to translate LABEL=/ > DUMP: Warning: unable to translate LABEL=/boot > /dev/sda2: Permission denied while opening filesystem > . > (no size line match in above dump output) > . > asking killpgrp to terminate > sendsize: pid 8615 finish time Thu Jan 24 17:13:44 2002 > ** The only *problem* is that dump can't open /dev/sda2 for reading. Try: su -c amanda id If that doesn't tell you that amanda is in whatever group owns the disk, that's your problem, and you need to verify that the (numeric) group id used in /etc/passwd is the group that owns the disk. Marty -- Marty Shannon, RHCE, Independent Computing Consultant mailto:[EMAIL PROTECTED]
Re: Confirmation for subscribe amanda-users
# su -c amanda id uid=33(amanda) gid=6(disk) groups=6(disk) # ls -l /dev/sda2 brw-rw1 root disk 8, 2 Aug 24 2000 /dev/sda2 # ls -ln /dev/sda2 brw-rw1 06 8, 2 Aug 24 2000 /dev/sda2 # grep disk /etc/group disk:x:6:root,rwk,amanda # grep amanda /etc/passwd amanda:x:33:6:Amanda user:/var/lib/amanda:/bin/bash Also, I can run dump manually (on the client) as the amanda user and it runs with no problem: # sys su amanda -c '/sbin/dump 0Ssf 1048576 - /dev/sda2' 9334784 What do you make of it? > The only *problem* is that dump can't open /dev/sda2 for reading. Try: > > su -c amanda id > > If that doesn't tell you that amanda is in whatever group owns the disk, > that's your problem, and you need to verify that the (numeric) group id > used in /etc/passwd is the group that owns the disk. > [EMAIL PROTECTED] wrote: > > > > I installed advfs.diff on the client (wookie) and reran the test dump > > but the sendsize*dump file still says: > > > > ** > > sendsize: debug 1 pid 8615 ruid 33 euid 33 start time Thu Jan 24 17:13:43 2002 > > /usr/local/libexec/sendsize: version 2.4.2p2 > > calculating for amname '/boot', dirname '/boot' > > sendsize: getting size via dump for /boot level 0 > > sendsize: running "/sbin/dump 0Ssf 1048576 - /dev/sda2" > > running /usr/local/libexec/killpgrp > > DUMP: Warning: unable to translate LABEL=/ > > DUMP: Warning: unable to translate LABEL=/boot > > /dev/sda2: Permission denied while opening filesystem > > . > > (no size line match in above dump output) > > . > > asking killpgrp to terminate > > sendsize: pid 8615 finish time Thu Jan 24 17:13:44 2002 > > ** > > The only *problem* is that dump can't open /dev/sda2 for reading. Try: > > su -c amanda id > > If that doesn't tell you that amanda is in whatever group owns the disk, > that's your problem, and you need to verify that the (numeric) group id > used in /etc/passwd is the group that owns the disk. > > Marty > -- > Marty Shannon, RHCE, Independent Computing Consultant > mailto:[EMAIL PROTECTED] >
Re: Confirmation for subscribe amanda-users
>I installed advfs.diff on the client (wookie) and reran the test dump >but the sendsize*dump file still says: >... >sendsize: running "/sbin/dump 0Ssf 1048576 - /dev/sda2" >running /usr/local/libexec/killpgrp > DUMP: Warning: unable to translate LABEL=/ > DUMP: Warning: unable to translate LABEL=/boot Note that it's not sendsize whining about "LABEL=", it's dump itself. My guess is your version of dump needs to be updated, and it wouldn't surprise me to hear that that also fixes the permission denied problem. >Dick John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Confirmation for subscribe amanda-users
One other thing. Joshua asked what your amandad xinetd entry looked like. In particular, you need "groups yes" (or something like that) to make xinetd put amandad in all the alternate groups (why they didn't make this the default is beyond me). Without that, amandad will only be run in its primary group, which is not "disk" and thus has no access. When you use "su", you get all the alternate groups, so that's why it works from there. I have a TODO list item to log the alternate groups in the debug file, which would help diagnose this problem, but it's harder than you might think (it used to be a non-standard system call, so portability is a problem). John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Confirmation for subscribe amanda-users
I am running the dump which was installed with redhat 7.0: dump-0.4b19-4.rpm Also, how would that explain that I am able to run: /sbin/dump 0Ssf 1048576 - /dev/sda2 manually with no problem, even as the amanda user? > cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > Reply-to: [EMAIL PROTECTED] > Date: Thu, 24 Jan 2002 20:40:32 -0500 > From: "John R. Jackson" <[EMAIL PROTECTED]> > > >I installed advfs.diff on the client (wookie) and reran the test dump > >but the sendsize*dump file still says: > >... > >sendsize: running "/sbin/dump 0Ssf 1048576 - /dev/sda2" > >running /usr/local/libexec/killpgrp > > DUMP: Warning: unable to translate LABEL=/ > > DUMP: Warning: unable to translate LABEL=/boot > > Note that it's not sendsize whining about "LABEL=", it's dump itself. > My guess is your version of dump needs to be updated, and it wouldn't > surprise me to hear that that also fixes the permission denied problem. > > >Dick > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] >
Re: Confirmation for subscribe amanda-users
That was it. It only happened on the RH7.0 system. RH7.2 doesn't seem to need: groups = yes Thanks to all who helped very much! I would never have know this one. Dick > One other thing. Joshua asked what your amandad xinetd entry looked like. > In particular, you need "groups yes" (or something like that) to make > xinetd put amandad in all the alternate groups (why they didn't make > this the default is beyond me). Without that, amandad will only be run > in its primary group, which is not "disk" and thus has no access. > > When you use "su", you get all the alternate groups, so that's why it > works from there. > > I have a TODO list item to log the alternate groups in the debug file, > which would help diagnose this problem, but it's harder than you might > think (it used to be a non-standard system call, so portability is > a problem). > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] >
Re: Confirmation for subscribe amanda-users
On 25 Jan 2002 at 2:25am, [EMAIL PROTECTED] wrote > I am running the dump which was installed with redhat 7.0: > > dump-0.4b19-4.rpm As an aside (well, as two asides): 1) You want to update that. dump picked up a new maintainer around the time of RedHat6.2/7.0, and has been progressing quite a bit since then, but... 2) You may want to consider using tar. Many on this list (myself included) have run into random 'data timeouts' using dump on 2.4 kernels. Moving to tar gets rid of those issues. Of course, now that you've got it working (thanks for stepping in John) this probably isn't what you want to hear. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Confirmation for subscribe amanda-users
Joshua, My experience with tar (and perhaps things have changed with gnutar) is that is is not as judicious as dump when it comes to a complete restore. Things like block devices, modes, ownership and so on were not always restored exactly. Has this changed? That is, in the event of a disk crash, can one restore a complete file-system exactly as it was before the crash using gnutar (including file-systems with /dev fifo's and so on)? I have always had a good experience doing this with dump, but historically tar did not get it exactly right. Dick > On 25 Jan 2002 at 2:25am, [EMAIL PROTECTED] wrote > > > I am running the dump which was installed with redhat 7.0: > > > > dump-0.4b19-4.rpm > > As an aside (well, as two asides): > > 1) You want to update that. dump picked up a new maintainer around the > time of RedHat6.2/7.0, and has been progressing quite a bit since then, > but... > > 2) You may want to consider using tar. Many on this list (myself > included) have run into random 'data timeouts' using dump on 2.4 kernels. > Moving to tar gets rid of those issues. > > Of course, now that you've got it working (thanks for stepping in John) > this probably isn't what you want to hear. > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University >
Re: Confirmation for subscribe amanda-users
On 25 Jan 2002 at 10:37pm, [EMAIL PROTECTED] wrote > My experience with tar (and perhaps things have changed with gnutar) is > that is is not as judicious as dump when it comes to a complete > restore. Things like block devices, modes, ownership and so on were not > always restored exactly. > > Has this changed? That is, in the event of a disk crash, can one > restore a complete file-system exactly as it was before the crash using > gnutar (including file-systems with /dev fifo's and so on)? > > I have always had a good experience doing this with dump, but > historically tar did not get it exactly right. tar will definitely get the data, modes, and ownership right. Things aren't going to be on the same inode (as they would be with dump), and I'm not sure about stuff like /dev -- it probably won't get that right. But, for my needs, all I care about *is* the data, modes, and ownership. All I back up is user data (for obvious reasons), config files (for reinstalls should a whole disk go), and logs (for security). With kickstart and a local distro mirror, I can have a system (re)installed and fully configured in <30 minutes (plus however long it takes to put the user data back). For me, that's quicker and easier than restoring the entire OS from tape. YMMV, of course. But that's my philosophy when it comes to Linux clients. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Confirmation for subscribe amanda-users
>... Things >aren't going to be on the same inode (as they would be with dump) ... Not sure if I'm reading this right, but if you're implying that a restore from a backup image created with "dump" will bring things back with the same inode number, that's not right. The "restore" program that goes along with "dump" is just a user level program with no magic. It does normal file system "open" and "write" calls, then resets the various attributes like modification time (again, with normal OS calls). So files come back to whatever inode is handed out by the OS. >and I'm >not sure about stuff like /dev -- it probably won't get that right. I'm not getting into this argument again (been there, done that :-), but this was the very thing Dick was concerned about. I *thought* the combination of the way Amanda runs GNU tar and extra features of GNU tar itself brought most everything back properly. The important point here, of course, is that with **any** backup system you should test, test, test and then test some more. Amanda+gtar will either do what you want or it won't. If it won't, figure out what you need and adjust the procedures until you're covered. >Joshua Baker-LePain John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Confirmation for subscribe amanda-users
On Sat, 26 Jan 2002 at 10:56am, John R. Jackson wrote > >... Things > >aren't going to be on the same inode (as they would be with dump) ... > > Not sure if I'm reading this right, but if you're implying that a > restore from a backup image created with "dump" will bring things back > with the same inode number, that's not right. The "restore" program > that goes along with "dump" is just a user level program with no magic. > It does normal file system "open" and "write" calls, then resets the > various attributes like modification time (again, with normal OS calls). > So files come back to whatever inode is handed out by the OS. Yeah, that's what I was saying, and apparently I was talking out of my a$$ -- sorry about that. I thought I recalled a discussion about dump reading at a lower level than tar (now that I think about it, maybe it was referncing xfsdump/tar vs. EAs), and went from there. You know, they say that the memory is the second thing to go. The first is, uh, something else. > >and I'm > >not sure about stuff like /dev -- it probably won't get that right. > > I'm not getting into this argument again (been there, done that :-), > but this was the very thing Dick was concerned about. I *thought* > the combination of the way Amanda runs GNU tar and extra features of > GNU tar itself brought most everything back properly. Once again, I sit corrected. > The important point here, of course, is that with **any** backup system > you should test, test, test and then test some more. Amanda+gtar will > either do what you want or it won't. If it won't, figure out what you > need and adjust the procedures until you're covered. > Amen. Thanks for setting me straight, John. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Confirmation for subscribe amanda-users
I have been using dump for over 20 years now and it has always been very reliable. In fact, it was because amanda uses dump that I felt comfortable enough to try it out in the first place. Up until now I have been keeping track manually of what filesystems and dump levels I keep on what tapes. I occasionally make changes to the /dev directory or install named pipes (eg, hylafax) which if they are not restored properly will cause something to break. I don't think I can think of all the cases to test gnutar on, so I wouldn't know how to do an exhaustive test of gnutar. What was it exactly that the complaint was regarding dump? Dick > >... Things > >aren't going to be on the same inode (as they would be with dump) ... > > Not sure if I'm reading this right, but if you're implying that a > restore from a backup image created with "dump" will bring things back > with the same inode number, that's not right. The "restore" program > that goes along with "dump" is just a user level program with no magic. > It does normal file system "open" and "write" calls, then resets the > various attributes like modification time (again, with normal OS calls). > So files come back to whatever inode is handed out by the OS. > > >and I'm > >not sure about stuff like /dev -- it probably won't get that right. > > I'm not getting into this argument again (been there, done that :-), > but this was the very thing Dick was concerned about. I *thought* > the combination of the way Amanda runs GNU tar and extra features of > GNU tar itself brought most everything back properly. > > The important point here, of course, is that with **any** backup system > you should test, test, test and then test some more. Amanda+gtar will > either do what you want or it won't. If it won't, figure out what you > need and adjust the procedures until you're covered. > > >Joshua Baker-LePain > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] >
Re: Confirmation for subscribe amanda-users
>What was it exactly that the complaint was regarding dump? Please, please, please, I'm **begging** all you nice folks on this list. Don't start this thread up again :-) :-) :-). This topic comes up here every once in a while. I won't go back into it (although I might try writing up something for the FAQ), but suggest you check out the mailing list archives for the details. Basically, both dump and tar do both good and bad things. You just decide which you're comfortable with. >Dick John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
