From: <bac...@li...> - 2004-09-26 08:29:12
|
A BUGNOTE has been added to this bug. ====================================================================== http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000122 ====================================================================== Reported By: bootsy52 Assigned To: ====================================================================== Project: bacula Bug ID: 122 Category: Storage Daemon Reproducibility: always Severity: feature Priority: normal Status: feedback ====================================================================== Date Submitted: 09-24-2004 15:09 PDT Last Modified: 09-26-2004 01:32 PDT ====================================================================== Summary: Make bacula server work on OpenBSD Description: I'm now trying quit a long time (from version to version again) to get Bacula on my OpenBSD box running. As Bacula runs on FreeBSD and obviously also on NetBSD I think it must basicly work OpenBSD as well. Because my main server runs OpenBSD it would be more than pleasent if bacula would run on it. The Tape is a DDS-3: HP C1537A, L907 So here is what I got so far: 1. Bacula compiles and installs just fine 2. btape test always fails either on the position test or at the append test (depends on which parameters I've set) With the following parameters it fails at the Write, rewind, position test, resulting in an infinite loop printing "Got EOF on tape." on the screen, directly after processing block 1:600. This refers as far as I found to subroutine read_again() in line 813 btape.c. My guess is that, the EOF found is followed by another EOF Device { Name = DDS-3 # Media Type = DDS-3 Archive Device = /dev/nrst0 AutomaticMount = yes; # when device opened, read it AlwaysOpen = yes; RemovableMedia = yes; RandomAccess = no; } Also setting it to a fixed blocksize with Minimum Block size = 65536 Maximum Block size = 65536 doesn't help, either with this test, nor with the append test ################################################ with the following parameters the postition test is passed, but it fails at the end on the append test with: "We should be in file 3. I am at file 0. This is NOT correct!!!!" Device { Name = DDS-3-BSD Description = "DDS-3 for FreeBSD" Media Type = DDS-3 Archive Device = /dev/nrst0 AutomaticMount = yes; # when device opened, read it AlwaysOpen = yes Offline On Unmount = no Hardware End of Medium = no BSF at EOM = yes Backward Space Record = no Fast Forward Space File = no TWO EOF = yes } ====================================================================== ---------------------------------------------------------------------- kern - 09-25-2004 02:50 PDT ---------------------------------------------------------------------- What I need to proceed is a copy of your man pages that describe the tape interface. They are usually in mtio or st (possibly both). In particular, I need to see the iotcl() calls that are supported, and if they have a description of the different tape modes they have implemented (e.g. variable block vs fixed block, ...). This is a good time to give me the info since I am just in the process of adding OS dependent ioctl()s to Bacula. ---------------------------------------------------------------------- Dan Langille - 09-25-2004 05:58 PDT ---------------------------------------------------------------------- The following URL has online man pages for FreeBSD, OpenBSD, NetBSD, Darwin, BSD386, HP-UX, Slackware, Minix, Red Hat, SuSE, SunOS, and XFree86 http://www.freebsd.org/cgi/man.cgi :) ---------------------------------------------------------------------- bootsy52 - 09-25-2004 08:59 PDT ---------------------------------------------------------------------- I've uploaded the man pages as ascii text files, all manpages are accessible through: http://www.openbsd.org/cgi-bin/man.cgi ---------------------------------------------------------------------- kern - 09-25-2004 13:00 PDT ---------------------------------------------------------------------- Please download the latest CVS 1.35.5 (25Sept04) and try it. If I made any mistakes or typos there may be a problem compiling dev.c. Then use the same parameters as for FreeBSD without the fixed block specifications. Try running btape "test" again. Thanks for the documents. I've deleted those that are not useful. The others I'll leave for possible future reference. ---------------------------------------------------------------------- bootsy52 - 09-25-2004 13:47 PDT ---------------------------------------------------------------------- No new dev.c there on cvs so far. However, I'm impressed how quick this issue resolved. I thought the whole time, that the developers got no first hand on OpenBSD and thus the issue wouldn't be resolved. But from searching, google, the mailinglist. It suddendly seemed to me that no one has tested this on OpenBSD or no one was willing to file a bug report. If I had known this before, I wouldn't have waited a half year testing from version to version seeing if this problem is resolved by chance. Also as I'm subscribed to the OpenBSD mailinglist, I will let the list know, once btape test runs successfully for me. Thanx ---------------------------------------------------------------------- Dan Langille - 09-25-2004 14:24 PDT ---------------------------------------------------------------------- It takes a while to get from the developer CVS to the public CVS. I got it via my login and you can grab it from here: http://beta.freshports.org/tmp/ Just add the file name. ---------------------------------------------------------------------- bootsy52 - 09-25-2004 15:42 PDT ---------------------------------------------------------------------- The Append test still fails with the same error, "We should be in file 3. I am at file 0. This is NOT correct!!!!" is dev.c the only new file needed or are there more ? The compilation went cleanly besides this two warnings which given during the build of section === lib ===. Don't know if they are to see on OpenBSD only. # 1 message.c: In function `void my_name_is(int, char **, const char *)': message.c:151: warning: array size (400) is smaller than minimum required (1024) message.c:153: warning: array size (400) is smaller than minimum required (1024) # 2 address_conf.c: In function `int sockaddr_to_ascii(const sockaddr *, char *, int)': address_conf.c:544: warning: sizeof(pointer) possibly incorrect in argument 4 I looked at dev.c (also I'm not yet a C Programmer) I found the comment in line 763. From past experiences I made with AFbackup, I've seen the symptom that when AFbackup ran and there was no tape in the drive. I got an I/O Error on every attempt to access the drive later on and the only resolution was to reboot the machine to have access to the tape drive again. Do I get it right, that the workaround there is meant exactly for cases like this ? ---------------------------------------------------------------------- Dan Langille - 09-25-2004 18:22 PDT ---------------------------------------------------------------------- The latest dev.c is now available via anonymous cvs. ---------------------------------------------------------------------- bootsy52 - 09-25-2004 18:34 PDT ---------------------------------------------------------------------- I've done complete checkout, but the error is still the same in the "Append" test. I've verified the version of dev.c and it is newest 1.90 I'm able to provide access to a OpenBSD box to you on next Friday. As I got a tape drive lying around here, and we got a few Pentium comuters lyning around in the company, which I could install OpenBSD on. ---------------------------------------------------------------------- kern - 09-26-2004 01:32 PDT ---------------------------------------------------------------------- Could you post the following things: 1. Your bacula-sd.conf file 2. The complete output from btape "test" showing the failure Thanks for pointing out the compile problems. I've fixed them as they were potential problems, but not in this case. In the btest case, you should start with a tape in the drive to void any secondary problems as you mention with AFBackup. As far as I know, Bacula should not hang or cause a system hang if no tape is initially in the drive, but this needs verification. The changes I've recently made are meant to put the drive in variable block mode so that it can properly forward space. I'm still in the process of implementing the improvements. The results of your above test should help me. Bug History Date Modified Username Field Change ====================================================================== 09-24-04 15:09 bootsy52 New Bug 09-24-04 15:09 bootsy52 File Added: scsi_tape.h 09-25-04 02:50 kern Bugnote Added: 0000284 09-25-04 02:50 kern Status new => feedback 09-25-04 05:58 Dan Langille Bugnote Added: 0000286 09-25-04 08:57 bootsy52 File Added: mtio.4.txt 09-25-04 08:57 bootsy52 File Added: ioctl.2.txt 09-25-04 08:57 bootsy52 File Added: scsi.4.txt 09-25-04 08:58 bootsy52 File Added: st.4.txt 09-25-04 08:58 bootsy52 File Added: mtio.h 09-25-04 08:59 bootsy52 Bugnote Added: 0000287 09-25-04 12:56 kern File Deleted: scsi_tape.h 09-25-04 12:56 kern File Deleted: mtio.4.txt 09-25-04 12:56 kern File Deleted: ioctl.2.txt 09-25-04 12:56 kern File Deleted: scsi.4.txt 09-25-04 13:00 kern Bugnote Added: 0000291 09-25-04 13:47 bootsy52 Bugnote Added: 0000292 09-25-04 14:24 Dan Langille Bugnote Added: 0000293 09-25-04 15:42 bootsy52 Bugnote Added: 0000294 09-25-04 18:22 Dan Langille Bugnote Added: 0000295 09-25-04 18:34 bootsy52 Bugnote Added: 0000296 09-26-04 01:32 kern Bugnote Added: 0000297 ====================================================================== |