(That previous message should have had this subject; sorry, mail client troubles)
Hello list I just compiled amanda on a SCO Unix machine (uname -a shows "SCO_SV shcorp 3.2 5.0.6 i386") and tried to follow instructions to install it, instructing amanda to back up both of its disks. Everything appears successful, and the machine passes amcheck tests. When I run amdump at night, my other linux, freebsd, and windows machines dump successfully. However on my SCO machine, I get the message: shcorp.shc /stand lev FAILED [disk /stand offline on shcorp.shcorp.com?] shcorp.shc / lev FAILED [disk / offline on shcorp.shcorp.com?] I've looked in google, and found the following suggestions: (from faq-o-matic, http://amanda.sourceforge.net/fom-serve/cache/10.html) is disk really offline? Answer appears to be no. After all, I'm using this machine throughout the day. So I'd assume it should be available for backup, since no-one touches the machine at night. filesystem error? Well, I suppose there *could* be. But the fact that it happens on both disks seems to indicate that this is not the problem. (I also installed the same compiled version on a separate sco machine, and it does the exact same thing). filesystem too large? Does not seem to be. /stand is only 15 megabytes, but still fails. conflicting user name? Doesn't seem to be it. I configured with user "backup". This only shows up once in the passwd file, and this box does not have any external sources for authentication (no nis, ldap, etc) don't have dump installed? This isn't it. I compiled by hand, and the config.log shows that amanda found the dump program. I suppose it could conceivably be something that amanda doesn't like about SCO's dump program though. How can I check if this might be the problem? (from an archived post: http://groups.yahoo.com/group/amanda-users/message/40200) permissions on /etc/fstab ok? On SCO, the file seems to be /etc/mnttab. It is unix mode 644, so this shouldn't be a problem. So, I looked at the logs in /tmp/amanda. For the last failed dump, I see these logs: -rw------- 1 root backup 231 Jul 22 00:30 killpgrp.20030722043007.debug -rw------- 1 root backup 231 Jul 22 00:30 killpgrp.20030722043009.debug -rw------- 1 root sys 2108 Jul 22 00:30 sendsize.20030722003007.debug -rw------- 1 root sys 2275 Jul 22 00:30 amandad.20030722003005.debug (strange that these are owned by root instead of backup; is this a problem?) sendsize ends with ---------------------------------------------------------------- sendsize[1383]: time 2.300: child 1388 terminated normally sendsize: time 2.300: pid 1383 finish time Tue Jul 22 00:30:10 2003 ---------------------------------------------------------------- Looks ok to me amandad ends with ---------------------------------------------------------------- amandad: time 4.281: got packet: ---- Amanda 2.4 ACK HANDLE 00E-00A00608 SEQ 1058848217 ---- amandad: time 4.281: pid 1382 finish time Tue Jul 22 00:30:10 2003 ---------------------------------------------------------------- seems fine, or? first killpgrp ---------------------------------------------------------------- killpgrp: debug 1 pid 1386 ruid 19 euid 0: start at Tue Jul 22 04:30:07 2003 /usr/local/libexec/killpgrp: version 2.4.4 killpgrp: error [cannot find user root in passwd file] killpgrp: pid 1386 finish time Tue Jul 22 04:30:07 2003 ---------------------------------------------------------------- second killpgrp ---------------------------------------------------------------- killpgrp: debug 1 pid 1389 ruid 19 euid 0: start at Tue Jul 22 04:30:09 2003 /usr/local/libexec/killpgrp: version 2.4.4 killpgrp: error [cannot find user root in passwd file] killpgrp: pid 1389 finish time Tue Jul 22 04:30:09 2003 ---------------------------------------------------------------- Weird errors here. The root user is definitely in the passwd file. Could this be part of the problem? Thanks for any ideas on fixing this... -- Kurt Yoder Sport & Health network administrator