Happy new year all, On Wed, 31 Dec 2025 10:54:16 -0500, Brandon Applegate <vom513%gmail.com@localhost> wrote: > Not intending to hijack this thread - but I see talk of the st driver and > block devices etc. I submitted a PR a while ago about problems using > physical tape drives (not for booting but just general use): > > https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=59570 > > Could there be some relation or intersection between that and this thread ? > > tl;dr - Physical tape drives give errors on reads in NetBSD. Going back to > NetBSD 7.2 seems to have things work without errors. Same hardware when > connected to Solaris or Linux works error-free / as expected. I think this may be essentially the same st(4) problem. Perhaps st(4) has been changed after NetBSD 7.2 so that st(4) has somehow strange behavior. I tried reading/writing real tape device with tar and dd in some ways: # tar cvf /dev/st0 /usr/pkg --> write success reading with # tar tvf /dev/st0 causes "damaged archive" errors. # dd if=/dev/st0 bs=512 | tar tvf - causes "damaged archive" errors. # dd if=/dev/nrst0 bs=512 | tar tvf - caused "dd: /dev/nrst0: Input/output error" In this case, data on the tape itself damaged. # tar cvf /dev/nrst0 /usr/pkg --> write success reading with # tar tvf /dev/st0 causes tar: Error opening archive: Error reading '/dev/st0' # dd if=/dev/st0 bs=512 | tar tvf - causes dd: /dev/st0: Input/output error # dd if=/dev/nrst0 bs=512 | tar tvf - causes dd: /dev/st0: Input/output error In this case, data on the tape itself damaged too or could not be written into the tape. # tar cvf - /usr/pkg | dd of=/dev/st0 bs=512 --> causes write error # tar cvf - /usr/pkg | dd of=/dev/nrst0 bs=512 --> write success. reading tape with # tar tvf /dev/st0 causes "damaged archive" errors. # dd if=/dev/st0 bs=512 | tar tvf - causes "damaged archive" errors. # dd if=/dev/nrst0 bs=512 | tar tvf - read success without error. In this case, data on the tape is OK, but reading through /dev/nrst0 and using dd always required. Handling of /dev/st0 may be corrupted after NetBSD 7.2. Also, I noticed reading/writing real tape device when dd is not used is two or three times faster than dd is used. So back to tape boot installation, I think modifying a tar reading sh script on src/distrib/sparc/ramdisk/dot.profile from: echo "Extracting installation utilities... " (cd $INSTFS_MP && tar $bsa -z -x -p -f $dev) || return 1 to (I hope this works fine, according to gzip's source): echo "Extracting installation utilities... " (cd $INSTFS_MP && gzip -dc $dev | tar -x -p -f -) || return 1 or (add dd in ramdiskbin needed but reliable): echo "Extracting installation utilities... " (cd $INSTFS_MP && dd if=$dev bs=$bsa | tar -z -x -p -f -) || return 1 is realistic way to keep port sparc tape installation working. I'm creating installation tape images in both way above now. And I will test tape images in a real tape after I will return to physical console of MY SS20 in my university. It will be Jan 5 or 6. > On Wed, Dec 31, 2025 at 9:32 AM Nobuyoshi SATO <nobu-s%iwate-pu.ac.jp@localhost> > wrote: > >> If tape device had raw device such like disks (ex. /dev/rsd0 for >> /dev/sd0), solution would be very easy. >> >> According to manpage st(4), /dev/rst0 is "Mode 0, Rewind on close", >> however, in manpage mtio(4) describes: >> The raw device name is the block device name with an "r" prepended, >> e.g. >> /dev/rst0. >> >> Hmm... This inconsistency that all device files of st(4) work >> as only block device seems to be introduced some tens years >> ago. Fixing st(4) so that it work with raw devices is correct way, >> but quick and dirty fix above might be realistic solution >> because capacities of tape cartridges might not be a problem >> since they are at least 150MB for old Sun QIC tape drives. >> (More older QIC-11 or QIC-24? size of base.tgz goes over the >> capacity!) Lecturer / Faculty of Software & Info. Sci., Iwate Prefectural Univ. Nobuyoshi Sato, Ph.D / nobu-s%iwate-pu.ac.jp@localhost / +81-19-694-2612