Re: Newly upgraded -CURRENT box does not boot
On 8/20/2018 7:09 PM, Warner Losh wrote:
On Mon, Aug 20, 2018 at 4:50 PM, Brett
wrote:
Hi Kevin,
Thanks for your help.
Should I be doing "make LOADER_DEFAULT_INTERP=4th buildkernel && make
LOADER_DEFAULT_INTERP=4th installkernel"?
Nope. Kernel has nothing to do with it. That won't work.
I had also previously tried " make clean all install
WITHOUT_LUA_LOADER=yes" in /usr/src/stand which did not help.
You could just do "ln -sf /boot/loader_4th /boot/loader" and reboot if
that's the issue. Or at the boot2 prompt, you could type in
/boot/loader_4th if you haven't booted yet.
You could also do a simple 'make install LOADER_DEFAULT_INTERP=4th" which
does approximately the same thing.
Though why you'd get loader.lua not found is kinda crazy
Warner
Hi Warner,
I've tried those things, unfortunately none of them worked. With forth,
things are slightly different (no more lua error), but ultimately the
same result: - the kernel doesn't load ("can't load 'kernel'").
I lastly tried "ln -sf /boot/loader_4th /boot/loader", now I get "No
/boot/loader" and a boot: prompt. I can do "boot/loader_4th" which will
use the forth loader with the results the same as the above.
Any help is appreciated - this is a very important box unfortunately. :(
Thanks,
-Brett
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Newly upgraded -CURRENT box does not boot
Hi Kevin, Thanks for your help. Should I be doing "make LOADER_DEFAULT_INTERP=4th buildkernel && make LOADER_DEFAULT_INTERP=4th installkernel"? I had also previously tried " make clean all install WITHOUT_LUA_LOADER=yes" in /usr/src/stand which did not help. Thanks! -Brett On 8/20/2018 6:31 PM, Kevin Oberman wrote: Check the archive of this list for the past 24 hours. The default bot was just converted to the lua boot today and there have been some issues. The "one liner" to switch back to the FORTH boot was posted to use to work around this and I believe that the change will be rolled back until the "corner cases" can be fixed. http://lists.freebsd.org/pipermail/freebsd-current/ -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com <mailto:rkober...@gmail.com> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Mon, Aug 20, 2018 at 2:28 PM Brett Gmoser <mailto:freebsdcurr...@codexterous.com>> wrote: Hi there, I was told to e-mail these addresses with this. I did an `svn update` on /usr/src last night, build world and kernel as usual. This morning I installed the kernel, booted into single user, installed world and did mergemaster -Ui as usual. The new kernel had booted fine. Upon reboot, the machine will no longer boot: Startup error in /boot/lua/loader.lua: LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory can't load 'kernel' Many things in the bootloader do not work, including "boot kernel.old", "ls /boot", and various other things (most if not all just result in "Command failed"). Interestingly, "ls /mnt" works, other directories do not. That's the only clue I have. I'm able to reboot in an installer image and mount the drive just fine. Everything is there and is as expected, including /boot/lua/loader.lua. I re-installed everything in /usr/src/stand (chroot'd on the installer image, and "cd /usr/src/stand && make clean all install"). This did not fix the problem. Does anybody happen to have any ideas? Thanks, -Brett ___ freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org <mailto:freebsd-current-unsubscr...@freebsd.org>" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Newly upgraded -CURRENT box does not boot
Hi there, I was told to e-mail these addresses with this. I did an `svn update` on /usr/src last night, build world and kernel as usual. This morning I installed the kernel, booted into single user, installed world and did mergemaster -Ui as usual. The new kernel had booted fine. Upon reboot, the machine will no longer boot: Startup error in /boot/lua/loader.lua: LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory can't load 'kernel' Many things in the bootloader do not work, including "boot kernel.old", "ls /boot", and various other things (most if not all just result in "Command failed"). Interestingly, "ls /mnt" works, other directories do not. That's the only clue I have. I'm able to reboot in an installer image and mount the drive just fine. Everything is there and is as expected, including /boot/lua/loader.lua. I re-installed everything in /usr/src/stand (chroot'd on the installer image, and "cd /usr/src/stand && make clean all install"). This did not fix the problem. Does anybody happen to have any ideas? Thanks, -Brett ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: crash on writing usbstick
Greeting- So can others duplicate my results, or should I give some kernel dev access to my console server and my BeagleBone? -Brett -- wynk...@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 929-272- Amendment IV The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no warrants shall issue, but upon probable cause, supported by oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Can not build world
Greeting- Thanks to both you and gonzo for the fast informed responses! On Thu, 14 Feb 2013 22:03:16 -0800 Steve Kargl s...@troutmask.apl.washington.edu wrote: SNIIP compile_et /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/asn1_err.et compile_et: No such file or directory *** [asn1_err.h] Error code 1 Stop in /usr/src/kerberos5/lib/libasn1. *** [buildincludes] Error code 1 Easy button: Add WITHOUT_KERBEROS to /etc/make.conf. After this past week I appreciate the easy button! See email archive for long story. The short story. You did not have kerberos on your system, which means that compile_et is not present in /usr/bin. Now, you want kerberos and kerberos does not build compile_et as a bootstrap tool. So, now you need to manually install compile_et. The fun really begins because you need some header/library from kerberos to build compile_et. So, once you figure out which header/library you need, you build and install it. Then build and install compile_et. And, finally, you can make world. I appreciate the short story. I like to understand the how/why of things. I am giving this a try, but it still begs the question that since I never changed make.conf before and never made any choices about building or not building kerberos why it broke all of the sudden. What changed? I am also going to test Gonzo's solution. I will report back what I find. -Brett -- wynk...@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 April 19, 1775 An English attempt to confiscate guns from Americans triggered a successful revolution.. Dear Congress, that's a hint. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Can not build world
Greeting- For the past week I have been unable to build world for arm on my Raspberry Pi. The process broke just after I updated /usr/src. Several updates in the intervening week have done nothing to change the results. It always bombs trying to build kerberos. Please no suggestions to cross build world. If that is the answer you must be thinking of the wrong question. At the moment consider my only working FreeBSD boxes are a Raspberry Pi with 512Meg of ram and 16 G of disk and a BeagleBone with 256 M of ram and 8G of disk. Needless to say I have not updated /usr/src on the BeagleBone, and will not until the issue on the Pi is resolved. FYI I am not subscribed to freebsd-current, only freebsd-arm, so if you reply to current please keep freebsd-arm in the cc list as well. I always do a make clean before trying the make buildworld. I am really stuck here. I also know others in the arm world had this problem in the recent past, but it started to work for them after another update to /usr/src. That has not happened for me. root@fbsd-pi:~ # uname -a FreeBSD fbsd-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #1: Mon Feb 11 18:03:38 EST 2013 root@fbsd-pi:/sys/arm/compile/RPI-B-TMPFS arm === include/rpc (installincludes) sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 /usr/src/include/rpc/auth.h /usr/src/include/rpc/auth_unix.h /usr/src/include/rpc/clnt.h /usr/src/include/rpc/clnt_soc.h /usr/src/include/rpc/clnt_stat.h /usr/src/include/rpc/nettype.h /usr/src/include/rpc/pmap_clnt.h /usr/src/include/rpc/pmap_prot.h /usr/src/include/rpc/pmap_rmt.h /usr/src/include/rpc/raw.h /usr/src/include/rpc/rpc.h /usr/src/include/rpc/rpc_msg.h /usr/src/include/rpc/rpcb_clnt.h /usr/src/include/rpc/rpcent.h /usr/src/include/rpc/rpc_com.h /usr/src/include/rpc/rpcsec_gss.h /usr/src/include/rpc/svc.h /usr/src/include/rpc/svc_auth.h /usr/src/include/rpc/svc_soc.h /usr/src/include/rpc/svc_dg.h /usr/src/include/rpc/xdr.h /usr/src/include/rpc/auth_des.h /usr/src/include/rpc/des.h /usr/src/include/rpc/des_crypt.h /usr/src/include/rpc/auth_kerb.h /usr/src/include/rpc/rpcb_prot.x rpcb_prot.h /usr/obj/usr/src/tmp/usr/include/rpc === include/xlocale (installincludes) sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 _ctype.h _inttypes.h _langinfo.h _locale.h _monetary.h _stdio.h _stdlib.h _string.h _time.h _wchar.h /usr/obj/usr/src/tmp/usr/include/xlocale === kerberos5 (includes) set -e; cd /usr/src/kerberos5; /usr/obj/usr/src/make.arm/make buildincludes; /usr/obj/usr/src/make.arm/make installincludes === kerberos5/doc (buildincludes) === kerberos5/lib (buildincludes) === kerberos5/lib/libasn1 (buildincludes) compile_et /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/asn1_err.et compile_et: No such file or directory *** [asn1_err.h] Error code 1 Stop in /usr/src/kerberos5/lib/libasn1. *** [buildincludes] Error code 1 Stop in /usr/src/kerberos5/lib. *** [buildincludes] Error code 1 Stop in /usr/src/kerberos5. *** [includes] Error code 1 Stop in /usr/src/kerberos5. *** [kerberos5.includes__D] Error code 1 Stop in /usr/src. *** [_includes] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. Help! Thanks! -Brett -- wynk...@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 The strongest reason for the people to retain the right to keep and bear arms is, as a last resort, to protect themselves against tyranny in government - Thomas Jefferson. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CFT: Overhauled CPSW driver for BeagleBone
On Tue, 1 Jan 2013 10:55:58 -0800 Tim Kientzle kient...@freebsd.org wrote: On Jan 1, 2013, at 8:12 AM, Brett Wynkoop wrote: Greeting- The driver is working much better than the driver currently in head. I have maintained an ssh connection to the BeagleBone for more than 24 hours! Just committed this to -CURRENT r244939. Tim Ok time to cvsup then rebuild the kernel followed by a buildworld! Thanks Tim! -- wynk...@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6924 718-717-5435 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CFT: Overhauled CPSW driver for BeagleBone
Greeting- This is a follow up to my previous private message about how your driver is working on my BeagleBone. wynkoop@beaglebone:~ % w 8:15PM up 15:17, 2 users, load averages: 0.05, 0.01, 0.00 USER TTY FROM LOGIN@ IDLE WHAT root u0 - 5:00AM 3:36 -csh (csh) wynkooppts/0cherry.wynn.com 2:05PM - w wynkoop@beaglebone:~ % date Mon Dec 31 20:15:13 EST 2012 wynkoop@beaglebone:~ % As you can see I am logged in on pts/0 since 2:05PM. I was never able to keep an ssh connection alive more than 30-40 min with the driver that is in head. I think you should check it into head now so people setting up new BBs get the benefit. As discussed off list there is still room for improvement, but I think that can be better handled if this much more stable driver goes into the tree sooner rather than later. It will allow for more testing and feedback to assist with the next round of improvements. This thing is running so well now that I am about to put a web server on the box and give it a static IP address. Once we have USB I think the BB will become my primary mail and web server..Think of the power I will save! -Brett -- wynk...@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6924 718-717-5435 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CFT: Overhauled CPSW driver for BeagleBone
On Mon, 31 Dec 2012 15:25:15 -0800 Tim Kientzle kient...@freebsd.org wrote: I've made some progress reworking the CPSW driver for BeagleBone and would appreciate any feedback: https://github.com/kientzle/cpsw Greeting- The driver is working much better than the driver currently in head. I have maintained an ssh connection to the BeagleBone for more than 24 hours! Thanks so much Tim! -Brett -- wynk...@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6924 718-717-5435 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on arm/arm
NetBSD is hit-or-miss to build successfully, more miss than hit. NetBSD supports GPT awkwardly but has no support for USB 3.0. NetBSD is rather unstable. I think I'd trust FreeBSD-current over a stable or release version of NetBSD. How does OpenBSD compare in that regard? I think DragonFlyBSD just introduced USB 3.0 support in 3.2.1, but that is off by default. There are live USB images available for DragonflyBSD from www.dragonflybsd.org, and live USB images available for OpenBSD at liveusb-openbsd.sourceforge.net . I'd like to try, just to see what they look like and how or if they support my hardware. Tom I haven't used NetBSD for a while. OpenBSD (both current and release) are very stable and predictable. Totally trustworthy. The six month release cycle seems to encourage incremental change. The lack of multiple branches means its a lot easier for developers and porters to stay on top of things. FreeBSD has more new features (such as the USB 3.0 you mentioned), also more support for other hardware tweakables (e.g. more Intel CPU power saving modes). I've only briefly used DragonflyBSD but plan to get it cranking again on one of my machines soon. The release version I tried before seemed pretty solid and gave good (desktop) performance. Its interesting to look at the relative strengths and weaknesses of each, how they've evolved, and hopefully learn some more. Brett. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on arm/arm
On Sat, 10 Nov 2012 23:34:24 +1100 Peter Jeremy pe...@rulingia.com wrote: On 2012-Nov-10 09:16:32 +1100, Brett brett.ma...@gmx.com wrote: Just an observation: a few years ago when I got sick of Linux's headlong rush development model, I subscribed to various BSD mailing lists to see what else was out there. I considered FreeBSD at the time - there was a neverending avalanche of [head tinderbox] failure messages. The Project tries to avoid it but occasional build failures on the development branch are very likely to occur. As a new user, you would be much better off starting with a release branch. I used 9.0 and release candidates for a couple of months beforehand so i would know what usually works and doesn't work before, trying current out. Compared to many of the old timers out there I guess this makes me very new still, though! This told me that I would be more likely to be running code written by people who knew what they were doing if I went with Open, Net, or DragonflyBSD. I think that's being unfair. Do Open, Net or DFly have an equivalent to the tinderboxes that do automated test builds and report failures? And, since you have replied to an ARM failure, DragonflyBSD would not be an option since it doesn't support ARM. The point I was trying to make (context lost in the partial quote above) was not that it is better or worse than the other BSDs, but that at the time (maybe 3 years ago) when I was looking around to alternatives to Linux and reading the various mailing lists, this was the impression I got. I am sure other people must see these daily failures and get the same impression. Whether this is fair or not has nothing to do with what impressions people form, and what OS they subsequently decide to install. As I recall reading, the tinderbox was established due to the high incidence of build failures. In my original post on this thread, I was commenting not on the failure of ARM build in particular, but chiming in after Doug Brewer's request for the code to be tested before being committed. If anyone else had backed him up I would not have felt the need to write. Cheers, Brett. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on arm/arm
Message: 11 Date: Fri, 9 Nov 2012 23:34:58 +0800 From: Doug Brewer brewer.d...@gmail.com To: Adrian Chadd adr...@freebsd.org Cc: a...@freebsd.org, FreeBSD Tinderbox tinder...@freebsd.org, curr...@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm Message-ID: cag0v13tpalmdpg-8rifcjjroxz948mqzjnn1yvqz4teybjz...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 No offence, but how many times did you break the build? Could you please compile your code before committing next time? Thanks a lot! Just an observation: a few years ago when I got sick of Linux's headlong rush development model, I subscribed to various BSD mailing lists to see what else was out there. I considered FreeBSD at the time - there was a neverending avalanche of [head tinderbox] failure messages. This told me that I would be more likely to be running code written by people who knew what they were doing if I went with Open, Net, or DragonflyBSD. I safely run OpenBSD-current on my main computer and it always works (I think I have had 2-3 build problems in about 3 years, and they were all my fault). At the moment, I only feel confident enough with FreeBSD-current to run it on my unimportant torrent computer. This is 80% due to constant build failures, and 20% due to invasive changes being introduced with documentation/instructions scattered over many different pages and mailing lists, e.g: http://wiki.freebsd.org/FrontPage?action=fullsearchcontext=180value=xorgtitlesearch=Titles http://wiki.freebsd.org/FrontPage?action=fullsearchcontext=180value=pkgngtitlesearch=Titles Hypothetical user: Is it WITHOUT_PKGNG= or WITHOUT_PKGNG=yes or WITH_PKGNG=no today? I wonder how many other people that you never hear from feel the same, and if some sort of x weeks commit freezeout should apply to the build breakers. Cute pointy hats or whatever obviously have no effect. Rant over! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on arm/arm
No offence, but how many times did you break the build? Could you please compile your code before committing next time? Thanks a lot! Just an observation: a few years ago when I got sick of Linux's headlong rush development model, I subscribed to various BSD mailing lists to see what else was out there. I considered FreeBSD at the time - there was a neverending avalanche of [head tinderbox] failure messages. This told me that I would be more likely to be running code written by people who knew what they were doing if I went with Open, Net, or DragonflyBSD. Quite honestly, the head/current branch is going to have build failures.. It's the test bed.. Stick with the release system unless you want cutting edge.. just remember.. cutting edge cuts sometimes... In the context of this thread, 'test bed' could mean anything. To clarify, are you saying: a) You think it is ok for commits to be made to the head source code, that cause it to not compile. b) Anyone who disagrees with this should be running release, not current. The head branch is distributed around the world by a network of mirror sites, and then downloaded and compiled by a large number of people. It seems a very inefficient use of resources for this infrastructure to be used to see if some code will build. Would it not be more useful for current to be a test bed of bugfixes and new features, rather than directing users to a release and having current as a test bed for will this compile? Or I suppose we could all just wait 6 months for a release candidate to see if today's current has introduced any regressions on our hardware. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: removal of share/doc/{papers,psd,smm,usd} in 2 months
those roff sources have been very naughty and will be removed from the tree by the end of the year. ... Should people feel strongly about them, we might be able to move them over to the doc repository. This does not seem a RFC -- this sounds more like you or a cabal already made the decision. you or a cabal already made the decision ... that sounds exactly like an RFC to me. :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Trying current
Hi list, I'm getting and old core2duo today to install FreeBSD (hopefully current) on it. Looking in the ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ folder for the last week or so, there have been no snapshots in there. Do they still come out roughly monthly and/or is one likely to appear soon? Looking at the instructions at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html , it does not specifically mention a starting point to build from. If not snapshots are expected soon, am I likely to experience much grief in getting from 9.0 or 9.1rc1 to current? Thanks, Brett. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] OpenSSL 1.0.1c merge in progress
Will port also be MFCed to 9-RELENG and 9.1-RELEASE? Do not want to have to go to -CURRENT to get latest OpenSSL. --Brett Glass ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Error building kernel in 9.0-BETA3: use of uninitialized variable in ipfw
Just tried to build a new kernel in 9.0-BETA3 with the IPFIREWALL option, and found that the build halts with a compiler error. The error occurs at netinet/ipfw/ip_fw_pfil.c, line 185, where the compiler complains that the variable len is used before intialization. Problem occurs on both i386 and amd64 platforms. Sample kernel config follows: cpu HAMMER ident BETA #makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking #optionsINET6 # IPv6 communications protocols #optionsSCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support #optionsUFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories #optionsUFS_GJOURNAL# Enable gjournal-based UFS journaling #optionsMD_ROOT # MD is a potential root device #optionsNFSCL # New Network Filesystem Client #optionsNFSD# New Network Filesystem Server #optionsNFSLOCKD# Network Lock Manager #optionsNFS_ROOT# NFS usable as /, requires NFSCL #optionsMSDOSFS # MSDOS Filesystem #optionsCD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization #optionsCOMPAT_FREEBSD32# Compatible with i386 binaries #optionsCOMPAT_FREEBSD4 # Compatible with FreeBSD4 #optionsCOMPAT_FREEBSD5 # Compatible with FreeBSD5 #optionsCOMPAT_FREEBSD6 # Compatible with FreeBSD6 #optionsCOMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI #optionsKTRACE # ktrace(1) support #optionsSTACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. options KBD_INSTALL_CDEV# install a CDEV entry in /dev #optionsHWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) #optionsAUDIT # Security event auditing #optionsMAC # TrustedBSD MAC Framework ##options KDTRACE_FRAME # Ensure frames are compiled in ##options KDTRACE_HOOKS # Kernel DTrace hooks #optionsINCLUDE_CONFIG_FILE # Include this file in kernel # Debugging for use in -current #optionsKDB # Enable kernel debugger support. #optionsDDB # Support DDB. #optionsGDB # Support remote GDB. #optionsDEADLKRES # Enable the deadlock resolver #optionsINVARIANTS # Enable calls of extra sanity checking #optionsINVARIANT_SUPPORT # Extra sanity checks of internal structures, required by IN VARIANTS #optionsWITNESS # Enable checks to detect deadlocks and cycles #optionsWITNESS_SKIPSPIN# Don't run witness on spinlocks for speed #optionsMALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci # Floppy drives #device fdc # ATA controllers device ahci# AHCI-compatible SATA controllers device ata # Legacy ATA/SATA controllers options ATA_CAM # Handle legacy controllers with CAM options ATA_STATIC_ID # Static device numbering #device mvs # Marvell 88SX50XX/88SX60XX/88SX70XX/SoC SATA #device siis# SiliconImage SiI3124/SiI3132/SiI3531 SATA # SCSI Controllers #device ahc # AHA2940 and onboard AIC7xxx devices #optionsAHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver.
Re: Experiences with FreeBSD 9.0-BETA2
At 05:02 AM 10/7/2011, Ed Schouten wrote: It should be xterm, since syscons now uses an xterm-style terminal emulator. Interesting. Apparently, the xterm termcap does not work properly for it. I have never used jove before, so what should I do to reproduce this? Have you ever used EMACS? jove is just one implementation of it (but without the huge overhead imposed by the LISP interpreter in GNU EMACS). In any event, build and install the port, and then try to edit a file. Just simple stuff, like moving the cursor, backspacing over characters to delete them, inserting characters in the middle of lines. Among other things, you'll see portions of lines vanish from the screen while you're editing, until you hit ^L (the EMACS command to refresh the screen) a couple of times. The older syscons driver worked very well with the cons25 termcap entry, but the one in 9.0-BETA2 and 9.0-BETA3 does NOT work well with the xterm termcap entry. Many artifacts. You almost can't edit. I have had to log in via SSH and use vt100 rather than using the console. --Brett Glass ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Experiences with FreeBSD 9.0-BETA2
Ed: The patch is an improvement. Not assuming that tabs blank the underlying cells is definitely a help. But it does not fix all of the artifacts. It might be a good idea to review the xterm termcap entry, capability by capability, to make sure that syscons conforms to each one. As the author of a very exacting vt100 emulator (I wrote Borland's Turbo Terminal back in the 80s), I know just how quirky, poorly documented, and buggy some terminals can be. I had to emulate every strange behavior and bug in the vt100 without access to the source code that the embedded CPU was running. In general, the behaviors that cause the most problems are wrapping and unwrapping text, writing past the edges of the screen, positioning near the edges of the screen, and manipulating the top and bottom lines. The vt100, for example, would not scroll when you wrote the last character on a line, but would then scroll if you entered one character after that without executing a command that repositioned the cursor. It would also ignore linefeeds after automatic scrolling (due to DEC's convention that text files have both a CR and an LF at the end of each line rather than just an LF as in UNIX). If you'd like, I can try to come up to speed on the code and help to debug, but I do not use X and so have no experience with its default terminal emulator; I'd have to study that as well. --Brett Glass At 06:25 AM 10/7/2011, Ed Schouten wrote: * Ed Schouten e...@80386.nl, 20111007 13:02: It should be xterm, since syscons now uses an xterm-style terminal emulator. I have never used jove before, so what should I do to reproduce this? After some tinkering, I think I know why it breaks. I thought that when xterm processes a tab, it blanks the underlying cells. This doesn't seem to be the case, so I've fixed that in r226099. Would it be possible for you to test HEAD r226099 or apply this patch to your source tree? http://svnweb.freebsd.org/base/head/sys/teken/teken_subr.h?r1=223574r2=226099view=patch If so, there's a fair chance I can get it squeezed into 9.0. Thanks! -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Experiences with FreeBSD 9.0-BETA2
At 12:03 PM 9/26/2011, Benjamin Kaduk wrote: On Mon, 26 Sep 2011, John Baldwin wrote: I can't speak to the one-big-fs bit (there was another thread long ago about that). However, as to the partitioning bit, bsdinstall is defaulting to using The question of how to layout and split filesystems was discussed at the filesystems working group of the devsummit at BSDCan this may. (http://wiki.freebsd.org/201105DevSummit/FileSystems down to Filesystem Layout near the bottom) Though one big root did not garner a huge amount of support, neither were there particularly compelling arguments against it (if I remember correctly). It's certainly easier to write an autopartitioner for, so I don't really blame Nathan for having chosen it initially. My personal preference would be to place portions of the directory tree which contain critical configuration information and are not written in normal use -- e.g. /etc and /boot -- in one or more separate partitions. This would make it possible to mount them read-only unless the system configuration was being changed, new software was being installed, or a new kernel was being generated. This would protect them not only from malicious tampering but also from being scrambled by buggy userland software. And since it would not be written during normal operation, it would survive 100% intact even if journaling and/or serialization of metadata updates (e.g. softupdates) were to fail. Unfortunately, due to past history, /usr is mixed-use. It normally contains both configuration information -- e.g. /usr/local/etc -- and more volatile data such as users' home directories. This prevents /usr/local/etc, which also contains mission-critical configuration information, from being protected if you just protect /. Some proprietary Unices have fixed this historical flaw in the traditional hierarchy by moving /usr/local/etc to another location and them symlinking it back to where seasoned administrators expect it to be, thus honoring POLA. The three open source, old school BSDs (Free, Net, Open) have not done this to date, but it's something that should be considered in the long run. It would certainly make the creation of embedded systems easier, as well as enhancing security in multi-user systems! If I wrote an installer, my preference would be to have it create one partition that contained critical configuration information and software (and could be mounted read-only) and one that contained the rest of the usual directory tree (and could be mounted read-write). It could do the symlinking trick mentioned above to bring parts of /usr over to the read-only administrative partition. The only cleanup task that would remain would be to make sure that no ports were configured to place their logs, pid files, etc. in directories such as /usr/local/etc. (Most already do not.) --Brett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Experiences with FreeBSD 9.0-BETA2
At 04:38 PM 9/26/2011, Benjamin Kaduk wrote: There was also general sentiment that the rise of ZFS would allow just this sort of fine-grained partitioning, which is a huge advantage of its ability to create datasets on the fly. This perception that ZFS is most of the future probably contributed to the lack of strong opinions regarding the default UFS partition scheme. Unfortunately, because ZFS is licensed under a viral license (not the GPL, but nonetheless one that isn't compatible with the BSD philosophy), I wouldn't want to see this happen. I'd rather see Hammer backported from Dragonfly. --Brett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Experiences with FreeBSD 9.0-BETA2
, instead of just using a direct ATA driver, was assembling a complex, memory-intensive, and compute-intensive layer cake of shims -- including the ata, ahci, da, and scbus drivers, not to mention GEOM -- to get to the SATA disk. Since the system I was trying to build has only one mass storage device -- a simple SSD -- and is tight on RAM, I'd rather go without bloating the kernel, slowing the system, or exposing myself to SCSI bugs by simply using an ATA driver. With all due respect for the hard work of the people who went to the trouble to create all of those shims, I hope that it remains possible to do this. Other oddities: 1) The jove editor worked strangely because, in /etc/ttys, the terminal type was set to xterm instead of cons25 by default. (I do not run a GUI on servers, so of course there will not be an xterm.) As a result, parts of lines kept vanishing from under my cursor. However, even after I modified /etc/ttys, I still saw some screen artifacts. The maintainer of the console driver should probably check it to see whether its termcap entry needs changing. 2) I saw many warnings of lock order reversals under the GENERIC kernel, in particular in the file system code. These obviously should be fixed before release. 3) The installer offered to enable the TRIM command for the SSD, but the SSD I was using did not support it; I got a warning when I tried to use tunefs to turn it on. 4) The installer still used the old syntax for Internet addresses in /etc/rc.conf instead of the newer one (e.g. ifconfig_fxp0=inet 192.168.1.1 netmask 255.255.255.0 instead of ipv4_addrs_fxp0=192.168.1.1/24) For the most part, though, I was able to work around everything and produce a system that seems stable. Will be stress-testing it for the next several days to see how it holds up. --Brett Glass ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ia64 tinderbox failure
* To: Cyberpunk [EMAIL PROTECTED] * Subject: Re: its a joke * From: Bill Fumerola [EMAIL PROTECTED] * Date: Tue, 9 Dec 1997 19:47:26 -0500 (EST) * cc: [EMAIL PROTECTED] [EMAIL PROTECTED] * In-Reply-To: [EMAIL PROTECTED] * Sender: [EMAIL PROTECTED] On Tue, 9 Dec 1997, Cyberpunk wrote: Silence == bot. I don't think so. There are (proven) ways of detecting a If that were the case then I guess the opers should be k-lined too after all I've seen some with long idle times. Note the sarcastic I don't think so. after my first sentence. Learn to read before you respond you clueless fuck. -. Bill Fumerola (NIC:BF1560) | Internet 123, Ltd. | email:[EMAIL PROTECTED] or pager:[EMAIL PROTECTED] | Computer Horizons Corp. Programmer (NASDAQ:CHRZ) | -/ ps. don't even start that 'uworld' thing you were saying two messages back because it only turns into a penis war. _ gifts, travel, e-cards, free e-mail, and more! .. http://www.egypt7000.com .. _ Select your own custom email address for FREE! Get [EMAIL PROTECTED] w/No Ads, 6MB, POP more! http://www.everyone.net/selectmail?campaign=tag To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD-SA-01:19.local
On Thu, 01 Feb 2001 19:02:36 PST, "Matthew Jacob" wrote: Isn't it early for april fool's? Well c'mon, Matt. Given the lack of interesting content (geez, it wasn't even a Good Spoof), do you really think the perps are smart enough to know the difference 'tween 2/1 and 4/1? :) Yawn. Brett --- Brett Rabe [EMAIL PROTECTED] / 612.664.3078 Senior Systems Engineer Qwest - Internet Services Una salus victus nullam sperare salutem To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current.freebsd.org
Jordan: I can probably help you out. 612.664.3078. Brett On Fri, 01 Dec 2000 12:56:32 PST, "Jordan Hubbard" wrote: Not sure if this the right place to complain or not, but current.freebsd.org does not appear to be on the net. traceroutes to both current.freebsd.org and usw2.freebsd.org (its alterego) fail. I did find that ftp7.de.freebsd.o r g has the 27 November 2000 snapshot of current on it .. was this the last time current.freebsd.org was alive? About 3 days ago; I'm unable to contact anyone at USWest but am working on it. Sigh. Also, for some reason the remote console to usw2 just doesn't work so the remote debugging option is out too. --- Brett Rabe [EMAIL PROTECTED] / 612.664.3078 Senior Systems Engineer Qwest - Internet Services So what's the speed of dark? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
auth 6df833c4 unsubscribe freebsd-current [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
4.0-19991012-CURRENT
Has anyone tried using the 4.0-19991012-CURRENT snapshot? I need to confirm that this snapshot is a "good one" before I update my 3.3R installation to it in a last ditch effort to compile USB modem support into the kernel. Thanks, -- Brett White [EMAIL PROTECTED] Duty Programmer, CS130 tutor, 4thYr D/Degree SSCC CQAT rep. "Like the naked leads the blind. I know I'm selfish, I'm unkind." -Placebo 'Every You, Every Me' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
USB Modem??
Hey there, Has anyone managed to get USB modem support compiled into the 4.0 kernel using the patches from the projects site?? Or can it be done another way?? Unfortunately my 33.6K internal has rolled over and died and now I just have a 56.6K external USB modem which I haven't been able to get the support for yet (hence I can't cvsup to 4.0 like most ppl have suggested, but thanks for the responses anyway!!). See Ya! -- Brett White [EMAIL PROTECTED] How many Tux could the Daemon Chuck slay if the Daemon Chuck could slay Tux? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KDE programs won't compile
Hi, every small kde program i try to install (right now i tried Knewmail and Kover) i get : checking for kde headers installed... configure: error: your system is not able to compile a small KDE application! Check, if you installed the KDE header files correctly. i'm using a current machine as if last night, installed kde from ports (yes, kde-libs was compiled with -CURRENT and EGCS) I can only assume that we install our KDE headers somewhere different than the developers (primarily on Linux machines). Dig around and figure out where the headers are on the FreeBSD machines and then you'll have to probably add a configure argument like: --with_kde_includes= /some/dir/where/kde/includes/are Dig through the knewmail configure script at the top and look for an option like this. Brett *** Brett Taylorbr...@peloton.physics.montana.edu * br...@daemonnews.org * * http://www.daemonnews.org/* *** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ack! LaTeX?
Hi, The latex installed by the teTex port complained about not being able to find default settings, or some such. Did you run texconfig? I'm having no trouble at all on my -current machine; well I guess it's a -STABLE machine now but... :-) Brett ** Brett Taylorbr...@peloton.physics.montana.edu http://peloton.physics.montana.edu/brett/ love isn't someplace that we fall, it's something that we do To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ack! LaTeX?
Hi, I tried latex, teTeX, and teTeX-beta... each had one problem or another. latex can't be fetched, teTeX-beta can't build, and teTeX doesn't work after being installed. How is teTeX not working? I'm using a month or so old version of -current (back in the 3.0 days) on my home machine and teTeX works fine there. Brett ** Brett Taylorbr...@peloton.physics.montana.edu http://peloton.physics.montana.edu/brett/ love isn't someplace that we fall, it's something that we do To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
