> On Sep 25, 2016, at 12:13 AM, Russell Haley wrote:
>
>> We can't easily do away with ubldr if we want to support tunables, kernel
>> modules loaded at boot time and a few other nifty features like nextboot.
>
> Are these things not in standard loader? Should they be?
"ubldr" *is* the standar
It would be nice if "cd /usr/src/lib/liblzma && make && make install"
just worked on an existing system that didn't already have
/usr/include/lzma, but I can't find anything in the
standard BSD makefiles to support this.
I think you can use:
make hierarchy
to ensure that all the directories are
David Wolfskill wrote:
Running an 8-core RELENG_7_1/i386 system (updated this morning), trying
to tar up a directory hierarchy rooted at a directory nnamed "sb2" in a
file system that is NFS-mounted (exported from a NetApp Filer); I have
the following logged:
@ 1227662967 [Tue Nov 25 17:29:27 20
David Wolfskill wrote:
Running an 8-core RELENG_7_1/i386 system (updated this morning), trying
to tar up a directory hierarchy rooted at a directory nnamed "sb2" in a
file system that is NFS-mounted (exported from a NetApp Filer); I have
the following logged:
@ 1227662967 [Tue Nov 25 17:29:27 20
I've just noticed a regression in tar from 6.2 to 6.3:
Running this on 6.2 produces no output:
#!/bin/sh
mkdir -p a b output
touch a/file1 b/file2
tar cf test.tar a b
tar -x -C output --strip-components 1 -f test.tar
On 6.3, it produces this output:
: Invalid empty pathname
: Invalid empty pat
On Jan 10, 2008, at 4:41 PM, Kris Kennaway wrote:
Not that I'm aware of. gtar works but libarchive tar fails on
the file it created.
Indeed. Trying to create a tarball using a non-existent list of files
returns an error and generates a 0-byte tgz; as previously shown, BSD
tar in 6.3 treats
of libarchive
and bsdtar, with the attached patch.
This simply disables the skip optimization when
reading archives from character or block
devices.
Tim Kientzle
Index: archive_read_open_filename.c
I suppose I could make 'tar' never
try to seek if it's talking directly to a device.
That would penalize devices that can seek, so I'd
rather find an alternate solution.
Tim Kientzle
P.S. In the meantime, of course, tar from 6.1 and
gtar shou
After that I try to read/list the tar from tape with tar -t:
$ sudo tar -tf /dev/sa0
archive.dmp
tar: Unrecognized archive format: Inappropriate file type or format
But when I extract the archive from tape, it works perfectly:
$ sudo tar -xvf /dev/sa0
Using dd to feed tar does work though. (I t
lines from dmesg might be helpful.
Tim Kientzle
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
lease send me details of the problem
you're having?
Thanks,
Tim Kientzle
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Patrick M. Hausen wrote:
I have narrowed the problem to a specific subdirectory and I think I
have the explanation:
-rw-r--r-- 1 jmz jmz4312 Apr 16 1947 supclkrd.prg
Yes, libarchive in 6.1 has a broken assertion in
the tar-writing code that causes it to
(erroneously) reject files with v
Poul-Henning Kamp compares two different ways of resizing a
buffer (edited slightly):
for (;;) {
if (buffer too small)
p = realloc(p, l += 80);
[...]
}
versus
for (;;) {
if (buffer too small)
p = realloc(p, l *= 16);
0Mbps or 1Gbps
Ethernet.)
Like I said, you should test very carefully before
using this approach in production.
Tim Kientzle
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
14 matches
Mail list logo
