Charles Steinkuehler wrote:
>
> > > > > I haven't tried bash.lrp since pre-release. There used to be two
> (2)
> > > > > bash-related problems; now, I find one (1):
> > > > >
> > > > > Mounting local filesystems...
> > > > > ramdisk.pkg: Uncompressing archives -
> log.tgz/etc/rcS.d/S36ramdisk.pkg:
> > > > > line 33:
> > > > > 1001 Broken pipe gunzip -c "$pkgdir/$pkg"
> > > > > 1002 Done | qt tar -x
> > > > > -Finished.
> > > > >
> > > > > I'm not sure what is wrong here -- I do not see wrong with the
> scripts.
> > > > > log.tgz *does* get un-archived and bash is working.
> > > > >
> > > > > Nevertheless, this is some kind of error -- hopefully *not* to
> manifest
> > > > > itself elsewhere . . .
> > > >
> > > > P.S. I am using ramlog.lrp -- *not* ramdisk.lrp . . .
>
> I still don't know why this is happening...what happens if you run the
> script manually? (ie "svi ramdisk.pkg start"). There *was* a problem like
> this early on, reflecting differences between different busybox versions of
> gzip, if memory serves, but I haven't seen a problem like that for a
> while...
I thought that I found the cause to this problem; but ...
I have narrowed this down to a busybox issue. After complete boot, I
scp log.tgz to /tmp, then:
root@trout:/tmp
# gunzip -c /tmp/log.tgz | tar -x
Broken pipe
Of course, in /etc/init.d/ramdisk.pkg, you wrap the tar -x in qt(),
which effectively erases *all* output from that command -- so, that
error must be coming from gunzip, which is linked to busybox.
Perhaps, it is my particular log.tgz ??? It is not exactly yours. I
won't attach it here; but, if you're willing to test it, request it and
it's yours . . .
--
Best Regards,
mds
mds resource
888.250.3987
Dare to fix things before they break . . .
Our capacity for understanding is inversely proportional to how much we
think we know. The more I know, the more I know I don't know . . .
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
