Re: No SMP on Compaq ML350 with FBSD 5.3-RE
Justin Hopper wrote: I just picked up a Compaq ML350 for free from a liquidator, runs fine it seems, and has dual P-II 600MHz CPUs. The BIOS post shows the two CPUs, as does the BIOS System Info function. However, a fresh install of FreeBSD 5.3-RE shows only a single CPU, and utilities like top reflect this as well. Attached is the dmesg output. Since this is such old hardware, I'm really surprised that it doesn't just simply work. Thoughts? I would certainly start by installing the latest and greatest BIOS that is available for the machine. You don't mention exactly which version of the ML350 you have -- there apparently were several. If the machine is old, chances are good that a newer BIOS exists, and probably fixes all sorts of problems. I found the following site, which might be helpful: http://h18023.www1.hp.com/support/files/server/us/romtabl.html Good luck. Oh, and I'd try 5.4 instead of 5.3 -- can't hurt ;-) -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BDB corrupt
Garrett Cooper wrote: On May 12, 2008, at 1:38 AM, Anthony Pankov wrote: Please, can anybody explain what is the problem with BDB (1.86). Is there known caveats of using BDB? Is there some rules which guarantee from curruption or it is fully undesirable to use BDB under high load? It is important for me because of using BDB in my project. On Fri, May 09, 2008 at 01:52:46PM +0200, Joerg Sonnenberger wrote: As one of the persons hacking on pkg_install in pkgsrc/NetBSD, I would *strongly* advisy you against storing the files only in a bdb file. The change of major and complete corruption with bdb185 is high, consider pulling the plug in the middle of a long update. Sunday, May 11, 2008, 5:38:25 PM, you wrote: GC +1. BDB is quite easy to corrupt... BDB isn't ATOMic, like SQL or other DB backends. You mean ACID probably. And there are plenty of SQL databases that aren't ACID either. (e.g. Mysql 4.x, Mysql 5.x w/o the right kind of backing store) -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: thoughts on sorting files into sub-folders by access date?
Steve Franks wrote: I can't find anything close googling, so I d/l a bunch of perl examples. Before I figure this out in python (I'm a hardware developer by trade, so that seems most sensible [libc doesn't seem to have any os-agnostic way of playing with file times, no?])... man utimes -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: UFS Snapshots and iowait
On Tue, Nov 23, 2010 at 10:38:31AM -0800, Chris St Denis wrote: Is this just due to the very high io bandwidth usage associated with making a snapshot, or does the creation of this snapshot completely block IO writes for around 5 minutes? It blocks updates to the filesystem while during part of the snapshot process. See the comments in /usr/src/sys/ufs/ffs/ffs_snapshot.c I found using UFS snapshots on a production fileserver untenable during normal working hours. I have a backup fileserver that I rsync the files to, and then use the UFS snapshots there. Any suggested workarounds? I already bumped up the number of Apache slots to 166% but it looks like I would have to increase the number much more to use that as a primary solution. Use ZFS. The way snapshots work there, they are nearly instantanous to create, and you are not limited to 20 snapshots per filesystem. -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [GSoC] About the idea: Unicode support in vi
On Wed, Mar 23, 2011 at 08:20:07PM -0500, Zhihao Yuan wrote: On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan lich...@gmail.com wrote: Among *all* the GNU/Linux distributions I used, they include a vim compiled in tiny mode (ln -s it to vi), which doubles the size of nvi, in their base systems. A vim.tiny contains much more features compared with nvi, but it's not compatible with POSIX vi. Let's compare the comparable, I don't really care if PCbsd ship vim as its default, but FreeBSD as the base is not only aimed at desktop specifically. So you should take into account that I may want to run FreeBSD on an adm5120 board with 32MB of RAM, without having a text editor consuming too much disk-space/ram. ??- Arnaud If you really want to use vi in a 32MB mem environment, the ex-vi may make sense. It consumes 1600KB memory while nvi consumes 2000KB. Note that the ee editor uses same amount memory as ex-vi. So basically, if no one disagree that we can drop the infinite undo, multiple buffer, multiple window and some other potential missing features, we can replace the nvi in the base system with ex-vi. Please don't do this. I use nvi every day on FreeBSD. I use the multi-level undo daily, and the multiple window feature, if not daily, at least weekly. -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [GSoC] About the idea: Unicode support in vi
On Fri, Mar 25, 2011 at 10:40:44AM +0100, Johan van Selst wrote: Zhihao Yuan wrote: Could you please eleborate on the nvi-devel problems? I'm the current maintainer of this port, and as far as I know it's fully functional. 1. It does not support non-Unicode encodings. Actually, these encodings are mainstream in multi-byte encodings world. A proper iconv-awared implementation should be able to handle all of the encodings in `iconv -l`; 2. It depends on DB3/4. We won't accept DB3/4 in base system and we won't accept nvi-devel. 3. It's not 100% compatible with nvi 1.79. Thank you for explaining. Indeed, all valid points and I fully agree that nvi-devel is not fit for inclusion in base as it is. In fact, the nvi from base is probably a better starting point (than nvi-devel) to create an editor that is fully compatible with nvi 1.79 and supports all multi-byte encodings. And when you, or someone, else creates such an editor, I will be pleased to remove the obsoleted port of nvi-devel. Has anyone looked at the nvi work that has taken place in NetBSD in the last year or so? I think they've put in a bunch of wide character support. I'm not sure if their DB code relies on bdb newer than what is in libc or not. -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Jails: Setting different times in jails
On Sat, Jul 09, 2011 at 11:19:23PM -0600, Warner Losh wrote: Why on earth would you want this? Oh, it's not hard to imagine why you want to do this. Say you're testing a particular date rollover event, and want to make sure your software is up to snuff. Doing it in a jail would make it easy to do it. I hacked over a unix kernel to do this for Y2K testing, along with the company's mandatory 9/9/99 testing (and we extended it through to 1-Mar-2000 just to be thorough). In that case, not only did I just start the systems with a clock value of 9/8/99, I hacked it so the time was incremented by one second at each hardclock, rather than 1/100 of a second. So my applications saw every second of every day between 9/8/99 and 3/1/00. (Remember that 28-Feb-2000 went straight through to 1-Mar-2000 -- 2000 was NOT a leap year!) Heck, maybe if this got put in, Apple would pick it up and finally make the calandering stuff in OS X not fail every daylight savings time. Nah, I'm just dreaming now... -Kurt On Jul 7, 2011, at 2:31 AM, grarpamp wrote: possibly achievable in libc? I don't know. Where else would it be done? stat, utimes, gettimeofday, clock_gettime, adjtime, etc and their variations. I've not checked what currently happens, but I don't think root in a jail should be able to set any kernel time parameters, absent a syscall that says it should. in any case file this idea somewhere.. :-) Don't know here either. I looked at the lists and hackers seemed closest. I'll bcc current. Someone could maybe todo-wiki this thread as low hanging fruit. Cheers. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [GSoC]I want to remove everything perl/tcl/gtags in the new nvi
On Thu, Jul 14, 2011 at 01:22:49AM -0500, Zhihao Yuan wrote: Second, the perl/tcl interpreter support; you can apply a perl/tcl command to the file whiling you are editing. I beg no one here used this feature before. Bzzt. I've used the perl interpreter before on a project. In that case, we were using vi as an editor for some very large text fields that were handled via perl to retrieve/store them into a database, done through a DBI proxy daemon. We could do multiple edits this way, without having to capture the field to a scratch file, invoke vi on it, again and again. One persistant vi... At the time, the speed mattered. If the logic is simple, you can use subst; if it's not, you'd better write a script and run perl/tcl outside. I regard it as feature creep, and I don't like it. Any comments? I don't really care that the perl/tcl integration stays or goes, but it's certainly not never been used. -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: BeagleBone?
On Sun, Jan 15, 2012 at 05:44:31PM -0700, Ian Lepore wrote: On Sun, 2012-01-15 at 16:05 -0800, Tim Kientzle wrote: Just got a BeagleBone in the mail and so far, it seems like fun: * Under $100 * Relatively modern Cortex-A8 ARM CPU (TI AM3358) * Built-in Ethernet, USB console, etc. So far, I've gotten console access from my FreeBSD laptop and am starting to tinker with a nanobsd-like script to build a bootable SD image. (By copying the MLO and u-boot.img files; nothing FreeBSD-specific yet.) Next step: Compile the arm/uboot boot loader and see if I can get that to load and run. Anyone else tinkering with one of these? Any hints? ;-) Tim The freebsd-arm list would be the place for info. There's still work to do to get FreeBSD running on a Cortex-A8, last I heard. There's this: http://code.google.com/p/beagleboard-freebsd/ Which has a status from January, and a pointer to a newer code drop, and a couple of wiki entries saying to build it and boot it. (The gitorious link just has code, no wiki or other useful information, at least that I saw when browsing.) The long and short of it (as I understand, since I just happened to have read through this stuff the other day), is that there's a kernel that compiles and has a bunch of drivers. But the pmap routines for that ARM varient are just stubbed, so there's no userland going on at all. Good luck -- it looks like a cool little board on which to run FreeBSD. -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Graphical Terminal Environment
On Tue, Mar 06, 2012 at 08:05:40AM -0800, per...@pluto.rain.com wrote: Brandon Falk bfalk_...@brandonfa.lk wrote: I havent tried tmux yet, but on my system im only able to get 80x40 with vidcontrol on one monitor. But with xterm in xorg i can get 319x89 per monitor ... To get higher resolution than what vidcontrol provides, you'll most likely need to run the display in graphic mode (which is what X11 does) rather than in text mode. That means that you will need to either use, or reinvent, the lowest levels of X (display driver, window mapping) and at least part of the xterm/rxvt application (terminal emulation, font rasterizing, perhaps scrolling). You could, however, eliminate the X practice of using the network to connect the terminal emulator to the display; this would give you an architecture resembling SunView (and its predecessor, SunTools). I _think_ SunTools/SunView were proprietary, although it's possible that Sun released the source code at some point. You could try doing some research with Google and/or the Internet Archive. I don't think they ever released that code. If you want re-use the lowest levels of the X11 drivers, you ought to check out the Wayland project. http://wayland.freedesktop.org -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
criteria for patch inclusion in patch release?
What determines the patch worthiness of particular fixes that have gone into a the source tree for inclusion into the next patch release of a given -RELEASE branch? As an example, there are two patches that improve life for those of us who use fxp ethernet adaptors (r233158, r233585). Both of these came out after the branch of 8.3-RELEASE, I believe. Neither of these patches are in 8.3-STABLE, as far as I can tell. I think they ought to be in at least 8-STABLE or 9-STABLE, based on their change dates and the MFC after: 1 week/MFC after: 2 weeks notations in the SVN entries. In my ideal world, these two patches would wind up in the first patch release of 8.3-RELEASE, but that's my ideal world. Is there some way to nominate these changes for inclusion in what will be the p1 release of 8.3? Thanks for any insight... -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, Sep 13, 2012 at 11:14:49AM -0500, Mark Felder wrote: On Thu, 13 Sep 2012 10:11:28 -0500, Andriy Gapon a...@freebsd.org wrote: Just curious - does VMWare provide a remote debugger support (gdb stub)? I'm not aware of one. What I have been able to successfully do is break into the debugger during the hang but the info I've posted so far has not been relevant to anyone. I'm hoping someone on the core team will eventually be able to follow my guide and figure out what went wrong. Isn't this what you want? http://stackframe.blogspot.com/2007/04/debugging-linux-kernels-with.html -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SMP Version of tar
On Tue, Oct 09, 2012 at 09:54:03PM -0700, Tim Kientzle wrote: On Oct 8, 2012, at 3:21 AM, Wojciech Puchar wrote: Not necessarily. If I understand correctly what Tim means, he's talking about an in-memory compression of several blocks by several separate threads, and then - after all the threads have compressed their but gzip format is single stream. dictionary IMHO is not reset every X kilobytes. parallel gzip is possible but not with same data format. Yes, it is. The following creates a compressed file that is completely compatible with the standard gzip/gunzip tools: * Break file into blocks * Compress each block into a gzip file (with gzip header and trailer information) * Concatenate the result. This can be correctly decoded by gunzip. In theory, you get slightly worse compression. In practice, if your blocks are reasonably large (a megabyte or so each), the difference is negligible. I am not sure, but I think this conversation might have a slight misunderstanding due to imprecisely specified language, while the technical part is in agreement. Tim is correct in that gzip datastream allows for concatenation of compressed blocks of data, so you might break the input stream into a bunch of blocks [A, B, C, etc], and then can append those together into [A.gz, B.gz, C.gz, etc], and when uncompressed, you will get the original input stream. I think that Wojciech's point is that the compressed data stream for for the single datastream is different than the compressed data stream of [A.gz, B.gz, C.gz, etc]. Both will decompress to the same thing, but the intermediate compressed representation will be different. -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC] Make crunched compatible with external linkers
On Tue, Dec 04, 2012 at 11:06:56AM +0100, Erik Cederstrand wrote: Hello hackers, The following PR patches crunchide(1) to accept object files produced by the gold and mclinker linkers: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin%2F174011 On behalf of the submitter, I'd like to request a review of the patch, and testing of crunchide/crunchgen especially on SPARC and ARM. I applied this patch to a 9/stable source tree, and was able to buildworld with it in place, on my sparc64 machine. I know that's not a great test case, but the patched binary is good enough to generate the objects that are needed for the 'rescue' binary. And that binary runs at least a trivial test of '/usr/obj/usr/src/rescue/rescue/rescue ifconfig -a' and produces correct output. -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC] Make crunched compatible with external linkers
On Thu, Dec 06, 2012 at 10:39:27AM +0800, pete wrote: On Wed, Dec 5, 2012 at 3:11 AM, Kurt Lidl l...@pix.net wrote: On Tue, Dec 04, 2012 at 11:06:56AM +0100, Erik Cederstrand wrote: Hello hackers, The following PR patches crunchide(1) to accept object files produced by the gold and mclinker linkers: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin%2F174011 On behalf of the submitter, I'd like to request a review of the patch, and testing of crunchide/crunchgen especially on SPARC and ARM. I applied this patch to a 9/stable source tree, and was able to buildworld with it in place, on my sparc64 machine. I know that's not a great test case, but the patched binary is good enough to generate the objects that are needed for the 'rescue' binary. And that binary runs at least a trivial test of '/usr/obj/usr/src/rescue/rescue/rescue ifconfig -a' and produces correct output. -Kurt Really thanks for your help! This patch is for crunchide to handle ELF object file in a more general way, but not be limited to the custom section layout (i.e., section headers, .symtab, and then .strtab are @EOF). And if we are still using ld(1), I think the patched crunchide should produce exactly the same output as before. Then the rescue binary would also be the same. I checked and verified the intermediate object files and rescue binary (via binary diff) on X86 FreeBSD 9.0. If you can also kindly help check this on different archs and feedback, I think the result will be very helpful. Well, I updated my sparc64 machine's source tree to the latest stable/9 code, and then did two complete buildworld runs, one without the changes to the crunchide code, and second with the crunchide changes. Diffing the obj tree (selectively) shows: root@spork-143: diff -r usr.modified/src/rescue usr/src/rescue Files usr.modified/src/rescue/librescue/librescue.a and usr/src/rescue/librescue/librescue.a differ root@spork-144: md5 usr.modified/src/rescue/rescue/rescue usr/src/rescue/rescue/rescue MD5 (usr.modified/src/rescue/rescue/rescue) = 75fc2a1b06ae38df2be668eff7cec72e MD5 (usr/src/rescue/rescue/rescue) = 75fc2a1b06ae38df2be668eff7cec72e And: root@spork-143: diff -r usr.modified/src/usr.sbin/crunch usr/src/usr.sbin/crunch diff -r usr.modified/src/usr.sbin/crunch/crunchide/.depend usr/src/usr.sbin/crunch/crunchide/.depend 65,68d64 /usr/obj/usr/src/tmp/usr/include/limits.h \ /usr/obj/usr/src/tmp/usr/include/sys/limits.h \ /usr/obj/usr/src/tmp/usr/include/machine/_limits.h \ /usr/obj/usr/src/tmp/usr/include/sys/syslimits.h \ Files usr.modified/src/usr.sbin/crunch/crunchide/crunchide and usr/src/usr.sbin/crunch/crunchide/crunchide differ Files usr.modified/src/usr.sbin/crunch/crunchide/exec_elf64.o and usr/src/usr.sbin/crunch/crunchide/exec_elf64.o differ So, the crunchide binaries are different (as expected) and the resulting 'rescue' binary is identical. -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
building select ports for packaging on install media
Greetings. I'm looking for a little guidance in building a small (one to two dozen) packages for inclusion on a locally generated install CDROM. (I'm doing this on for sparc64 machines, but I don't think that matters tremendously.) I have successfully generated bootable cd-rom media by doing: cd /usr/src/release make release After grinding around alot, I get a viable sparc64 bootable cdrom. What I'd like to do is augement that CD-ROM image with several binary packages, so I can just install them via 'sysinstall', rather than having to maintain a /usr/ports tree on every host and compile the same software again and again... I've found: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng-packages/article.html and http://www.freebsd.org/doc/en/articles/portbuild/article.html But those seem to revolve around building *all* the ports. I just want to do a couple of dozen of them, but I'd like to end up with something that will generate binary packages that 'pkg install' can deal with. Thanks for any tips. -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: building select ports for packaging on install media
On Tue, Feb 12, 2013 at 04:29:45PM +0100, Wojciech Puchar wrote: cdrom. What I'd like to do is augement that CD-ROM image with several binary packages, so I can just install them via 'sysinstall', rather than having to maintain a /usr/ports tree on every host and compile the same software again and again... why not just use pkg_add? Because there do not seem to be any packages available for 9.1-sparc64: root@host-75: uname -a FreeBSD host.pix.net 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Tue Feb 5 00:35:59 EST 2013 l...@host.pix.net:/usr/obj/usr/src/sys/V120 sparc64 root@host-76: pkg install nettop Updating repository catalogue pkg: http://pkg.freebsd.org/freebsd:9:sparc64:64/latest/repo.txz: Not Found -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sparc64 zfsroot/gmirror?
On Tue, Feb 19, 2013 at 04:03:09PM -0800, Sean Bruno wrote: I'm restoring some of the sparc64 machines for freebsd.org and had a question with regards to what to do about the / Since it wasn't obvious how to setup zfs root things I setup something that looks like this: = 0 71087625 da0 VTOC8 (33G) 03855601 freebsd-ufs (188M) 385560 707020652 freebsd-zfs (33G) = 0 71087625 da1 VTOC8 (33G) 03855601 freebsd-ufs (188M) 385560 707020652 freebsd-zfs (33G) Where everything *except* /boot is in the mirrored zpool. I can reinstall the system trivially, and am looking for suggestions. I wrote up a script to do the heavy lifting for installing a completely zfs system on a sparc64 machine. http://www.pix.net/ftp/pub/freebsd/sparc_zfs_setup.txt The 12GB space for zfs is appropriate for a 18Gb disk, and allows the remainder of the disk space to accommodate a 4Gb-ish swap space, for crash dumps. The swap is placed at the end of the disk, since that's the slowest part to access. -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
find -delete broken, or just used improperly?
OK, maybe I'm missing something obvious, but...
find(1) says:
-delete
Delete found files and/or directories. Always returns true.
This executes from the current working directory as find recurses
down the tree. It will not attempt to delete a filename with a
``/'' character in its pathname relative to ``.'' for security
reasons. Depth-first traversal processing is implied by this
option. Following symlinks is incompatible with this option.
However, it fails even when the path is absolute:
bhyve9# mkdir /tmp/foo
bhyve9# find /tmp/foo -empty -delete
find: -delete: /tmp/foo: relative path potentially not safe
Shouldn't this work?
I ran into this during a build of stable/9 with WITHOUT_SHAREDOCS
set, which ultimately triggers this bit of /usr/src/Makefile.inc1:
.for dist in ${EXTRA_DISTRIBUTIONS}
find ${DESTDIR}/${DISTDIR}/${dist} -empty -delete
.endfor
The actual observed failure is this:
=== etc/sendmail (distribute)
cd /usr/src/etc/sendmail; make install -DNO_SUBDIR
DESTDIR=/usr/obj/usr/src/release/dist/base SHARED=copies
find //usr/obj/usr/src/release/dist/doc -empty -delete
find: -delete: //usr/obj/usr/src/release/dist/doc: relative path potentially
not safe
*** [distributeworld] Error code 1
Stop in /usr/src.
*** [distributeworld] Error code 1
Stop in /usr/src.
*** [base.txz] Error code 1
Stop in /usr/src/release.
*** [release] Error code 1
Stop in /usr/src/release.
Thanks for any insight.
-Kurt
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: find -delete broken, or just used improperly?
On 5/21/13 11:06 AM, John Baldwin wrote:
On Monday, May 20, 2013 5:47:31 pm Jilles Tjoelker wrote:
On Mon, May 20, 2013 at 03:23:16PM -0400, Kurt Lidl wrote:
OK, maybe I'm missing something obvious, but...
find(1) says:
-delete
Delete found files and/or directories. Always returns true.
This executes from the current working directory as find recurses
down the tree. It will not attempt to delete a filename with a
``/'' character in its pathname relative to ``.'' for security
reasons. Depth-first traversal processing is implied by this
option. Following symlinks is incompatible with this option.
However, it fails even when the path is absolute:
bhyve9# mkdir /tmp/foo
bhyve9# find /tmp/foo -empty -delete
find: -delete: /tmp/foo: relative path potentially not safe
Shouldn't this work?
The relative path refers to a pathname that contains a slash other
than at the beginning or end and may therefore refer to somewhere else
if a directory is concurrently replaced by a symlink.
When -L is not specified and . can be opened, the fts(3) code
underlying find(1) is careful to avoid following symlinks or being
dropped in different locations by moving the directory fts is currently
traversing. If a problematic concurrent modification is detected, fts
will not enter the directory or abort. Files found in the search are
returned via the current working directory and a pathname not containing
a slash.
For paranoia, find(1) verifies this when -delete is used. However, it is
too paranoid about the root of the traversal. It is already assumed that
the initial pathname does not refer to directories or symlinks that
might be replaced by untrusted users; otherwise, the whole traversal
would be unsafe. Therefore, it is not necessary to do the check for
fts_level == FTS_ROOTLEVEL.
The below patch allows deleting the pathname given to find itself:
Index: usr.bin/find/function.c
===
--- usr.bin/find/function.c (revision 250661)
+++ usr.bin/find/function.c (working copy)
@@ -442,7 +442,8 @@
errx(1, -delete: forbidden when symlinks are followed);
/* Potentially unsafe - do not accept relative paths whatsoever */
- if (strchr(entry-fts_accpath, '/') != NULL)
+ if (entry-fts_level FTS_ROOTLEVEL
+ strchr(entry-fts_accpath, '/') != NULL)
errx(1, -delete: %s: relative path potentially not safe,
entry-fts_accpath);
I'm curious, how would you instruct a patched find to avoid deleteing the
/tmp/foo directory (e.g. if you wanted this to be a job that pruned empty
dirs from /tmp/foo but never pruned the directory itself). Would -mindepth 1
do it? (Just asking. I have also found this message annoying but most of
the jobs I have seen it on probably don't want to delete the root path,
just descendants.)
Using -mindepth 1 does indeed preserve the target directory.
Without it, the target directory is removed if all the children
files/directories are empty.
I've just finished a complete build of a recent stable/9:
make buildworld make buildkernel cd release make release
With WITHOUT_SHAREDOCS= set in my src.conf, and Jilles' patch to
find, and the following patch to Makefile.inc1, it now builds a
release properly.
bhyve9# hg diff Makefile.inc1
diff -r ca8ef48b4ba6 Makefile.inc1
--- a/Makefile.inc1 Thu May 16 10:21:04 2013 -0400
+++ b/Makefile.inc1 Tue May 21 13:58:13 2013 -0400
@@ -754,7 +754,7 @@
${IMAKEENV} rm -rf ${INSTALLTMP}
.if make(distributeworld)
.for dist in ${EXTRA_DISTRIBUTIONS}
- find ${DESTDIR}/${DISTDIR}/${dist} -empty -delete
+ find ${DESTDIR}/${DISTDIR}/${dist} -mindepth 1 -empty -delete
.endfor
.if defined(NO_ROOT)
.for dist in base ${EXTRA_DISTRIBUTIONS}
If one doesn't have the -mindepth 1 in the find command, it will
remove the usr/share/doc directory entirely, which will cause a failure
later in the 'make release' target code...
-Kurt
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
complicated dependency file generation and make depend
Greetings all - I've come across a problem that I do not know how to solve. (one of many, I'm sure) In a project that I am working on, there is a tool used to generate a few header files that are used when compiling parts of the entire project. This tool, itself, relies on some of the libraries built in the project. These libraries must exist before the tool can be created. I'm struggling with how to build the libraries and then the header generating tool, as part of the 'make depend' phase of the entire project. I'd like to be able to just do make obj depend make all and end up with all the binaries, libraries, etc built and ready to be installed. make obj make all works... I mean, from a certain point of view, I know that I ought to be able to hook into the beforedepend: target in an individual Makefile, but I don't see how I'm supposed to do that at the top level Makefile, which uses bsd.subdir.mk. The top level Makefile drives the compilation of the libraries, then the tools, then some more libraries that require the tools, and finally the binaries that make up the project (which require both the libraries and the tools). Thanks for any insight! -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: best way to make dvd appear to me a .iso file to the FS
On 9/30/13 9:46 PM, Aryeh Friedman wrote: bhyveload(8) only let's you use .ISO's for install media and I want to make it so I can just insert a DVD (/dev/cd0) and bhyve can read it as if it was a just a normal file and not a device... short of copying it to the hard drive is there any other solution anyone can think of? Well, you can create a zvol to hold the bootable UFS filesystem, and just mount the cd-image, and extract the /usr/freebsd-dist/* tarfiles directly into the freshly created filesystem... -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
