Re: Installation from a tape

On Mon, 29 Dec 2025 15:06:11 +0000,
"mike.spooner.ux" <[email protected]> wrote:

> Does the NetBSD installer miniroot have 'dd'? If it does, you could try test-reading the tape with that instead (directing the output to /dev/null), and try several different read-block-sizes.Secondly, is it an HP drive? Many HP DDS-1/2/3 drives have a jumper for selecting UNIX or DOS/Win compatibility (yeah, I know such shouldn't be needed for a SCSI drive, but is due to HP's stupidly-written DOS/Win tape software). You need that jumper set for UNIX.- MikeSent from my Galaxy

Unfortunately NetBSD's ramdisk image does not have dd. Tape drive
is made by HP, But drive I purchased is Sun SG-XTAP4MM-011A,
an external drive with white/light violet enclosure.


On Mon, 29 Dec 2025 18:42:09 -0500 (EST),
Mouse <[email protected]> wrote:

>> I created bootable tape as follows:
>>     # dd if=tapefile1 of=/dev/nrst0 bs=4k conv=sync
>>     # dd if=tapefile2 of=/dev/nrst0 bs=4k conv=sync
> 
>> Then, I booted my SS20 from the tape.  Kernel is successfully loaded
>> and asked name of tape drive and place of tapefile2 and block size.
> 
>> Then I got errors as following:
> 
>> [198.2459840] st0: 4096-byte tape record too big for 4-byte user buffer
>> [198.2609645] st0(esp0:0:4:0): Sense Key 0x00, info = -4092 (decimal), data = 00
>>  00 00 00 00 00 00 00 00 00 00 00
>> gzip: can't read stdin: Input/output error
>> tar: End of archive volume 1 reached
>> tar: Sorry, unable to determine archive format.
> 
> That looks to me like a bug in tar: when running gzip, it apparently
> treats the input like an octet stream instead of a block stream,
> breaking use on real tapes.  (At a guess, based on the above, it does
> this by simply passing stdin to a forked gunzipper process.)
> 
> The _right_ fix of course is to fix that tar variant, so that it reads
> the input itself when forking gunzip, so as to preserve the
> stream-of-blocks paradigm.  But that's likely more work than you're
> interested in getting into for this.
> 
> The next thing that comes to mind is to gunzip the file before writing
> it to the tame, assuming of course that the uncompressed file fits on
> the tape:
> 
> # gunzip < tapefile2 | dd obs=4k of=/dev/nrst0
> 
> Then drop the "gunzip the input" flag from tar (z? I don't know that
> tar version; I normally use my own variant) when reading the tape.

This inference seems to be correct. It will be a bug in pax or
its variant to create ramdisk image. Following Mouse's suggestion,
I created yet another "gunzipped" tape and read it as following:
    # dd if=tapefile1 of=/dev/nrst0 bs=4k conv=sync
    # gunzip < tapefile2 | dd obs=4k of=/dev/nrst0 conv=sync
    # mt rewind
    # mt fsf 1
    # /usr/obj/distrib/sparc/ramdisk/ramdiskbin tar tf /dev/nrst0 | more
    .
    ./bin
    ./bin/cat
    ./bin/chmod
    ./bin/cp
    ./bin/dd
    ./bin/df
    ./bin/ed
    (skip many files in /bin and /dev and so on...)
    ./upgrade
    ./install.sub
    ./.profile
    ./install.md
    ./sysinst
    ./sysinstmsgs.fr
    ./sysinstmsgs.de
    ./sysinstmsgs.pl
    ./sysinstmsgs.es
It treated the tape drive as a block device correctly. Shown
files here are contents of bootfs/instfs.tgz.

>>     # /usr/obj/distrib/sparc/ramdisk/ramdiskbin tar zxf /dev/nrst0
>> This causes similar errors shown above. Also,
>>     # /usr/obj/distrib/sparc/ramdisk/ramdiskbin pax -rzvf /dev/nrst0
>> gives the same result.
> 
> I would guess that "dd if=/dev/nrst0 bs=4k | .../ramdiskbin tar zxf -"
> works fine?

It works fine on the "gzipped" tapefile2 as following:
    # /bin/dd if=/dev/nrst0 bs=4k | /usr/obj/distrib/sparc/ramdisk/ramdiskbin tar ztf -
    (Imagine lots of file list the same above here...)
    ./sysinst
    ./sysinstmsgs.fr
    ./sysinstmsgs.de
    ./sysinstmsgs.pl
    363+0 records in
    363+0 records out
    1486848 bytes transferred in 4.670 secs (318382 bytes/sec)

ramdiskbin tar and gzip worked correctly if their input are not a
_real_ block device. 

I'll leave 600km from my SS20 console for 4 or 5 days for new
year, but I keep the tape is set on the drive. So I can perform
some other tests from remote as SS20 is up.

> The _right_ fix of course is to fix that tar variant, so that it reads
> the input itself when forking gunzip, so as to preserve the
> stream-of-blocks paradigm.  But that's likely more work than you're

I'll try to read source code of pax and gzip, but someone
fixing the bug will be faster than I will find it...

I understood one of suspicious place is following, in ar_io.c of pax:
        zpid = fork();
// skip
        /* parent */
        if (zpid) {
// skip
        } else {
                if (wr) {
                        dup2(fds[0], STDIN_FILENO);
                        dup2(fd, STDOUT_FILENO);
                        gzip_flags = "-c";
                } else {
                        dup2(fds[1], STDOUT_FILENO);
                        dup2(fd, STDIN_FILENO);
                        gzip_flags = "-dc";
                }
                close(fds[0]);
		close(fds[1]);
                if (execlp(gzp, gzp, gzip_flags, NULL) < 0)
                        err(1, "could not exec");
                /* NOTREACHED */
        }



Lecturer / Faculty of Software & Info. Sci., Iwate Prefectural Univ., Japan
Nobuyoshi Sato, Ph.D / [email protected] / +81-19-694-2612