Re: Installing packages from 9.2 Release DVD
On Oct 7, 2013, at 11:35 PM, Mehmet Erol Sanliturk wrote: > Dear All , > > In sysinstall , there are menu items to install packages from release DVD . > > In bsdinstall , there is NO such package installation menu items . > You've got the wrong tool. s/bsdinstall/bsdconfig/ > Another problem is there is no any available information about this subject > in the Handbook installation pages ( at least I could not find any one one > ) . > bsdconfig was just born in 9.2-R. Nobody has gotten around to documenting it. I'll be doing the first presentation on it at the vBSDcon [un]Conference coming up in a couple weeks (Oct 25-27th in Reston, VA; hosted by Verisign). > Is there any such available information link , and is there any possibility > to include such information into Handbook pages and Release Notes templates > ? > bsdconfig(8) was announced in the quarterly announcements and release highlights for FreeBSD 9.2-R. As for the handbook... it will take time for doc folks to assimilate it. > When there is no such information , people will use > > pkg_add -r ... > > statement although many packages are already in the release DVD which means > a large waste of band width . > Only media type that bsdconfig(8) doesn't support is TAPE. However, bsdconfig supports a couple new types of media for accessing packages. Other than that, your old friends of CD/DVD, FTP, HTTP, FTP via Proxy, NFS, and some new ones are all there. > ( Please consider less experienced people : Each year , many persons are > entering into an age to try FreeBSD without prior experience about FreeBSD > . Lack of necessary information about install is an important obstacle for > such new entries . ) > I appreciate your feedback. Rest assured, less experienced peoples *were* considered. That's why I started work on bsdconfig(8) 3 years ago shortly after the deprecation of sysinstall in base. The curses-UI-loving folks were not forgotten (less experienced or otherwise; a fancy TUI/GUI doesn't necessarily mean it has to be only usable to less skilled folks... take "bsdconfig startup" for example -- something not normally possible with any other tool regardless of your skill level). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Device timeout from mfi(9) while booting 9.2-RELEASE
On Oct 4, 2013, at 8:59 AM, Sean Bruno wrote:
> On Fri, 2013-10-04 at 18:27 +1000, Jan Mikkelsen wrote:
>>> mfi0: 14299 (boot + 4s/0x0020/info) - Firmware version 3.190.05-1669
>>> mfi0: 14300 (boot + 5s/0x0020/info) - Package version 23.7.0-0029
>>> mfi0: 14301 (boot + 5s/0x0020/info) - Board Revision
>
> Does it make sense then, to take a survey and add a recommended minium
> f/w for cards that we know about to the man page?
>
Sounds like a great idea.
I can provide the following *good* firmware infos:
===
In order:
1. (as root) mfiutil show adapter | grep Name
2. grep 'mfi[[:digit:]]\{1,\}:.*\(vers\|Board\)' /var/run/dmesg.boot
3. (as root) mfiutil show firmware | grep Pack # only required on older cards
===
Machine 1 (older):
Product Name: Intel(R) RAID Controller SROMBSAS18E
mfi0: 3736 (boot + 0s/0x0020/info) - Firmware version 1.12.280-0826
mfi0: 3740 (boot + 14s/0x0020/info) - Board Revision
mfi0 Firmware Package Version: 7.0.1-0075
===
Machine 2 (newer):
Product Name: LSI MegaRAID SAS 9264-8i
mfi0: 3270 (boot + 3s/0x0020/info) - Firmware version 2.130.383-2315
mfi0: 3272 (boot + 46s/0x0020/info) - Package version 12.13.0-0154
mfi0: 3273 (boot + 46s/0x0020/info) - Board Revision 62A
===
Machine 3 (newest):
Product Name: LSI MegaRAID SAS 9267-8i
mfi0: 4535 (boot + 8s/0x0020/info) - Firmware version 3.140.95-1967
mfi0: 4538 (boot + 20s/0x0020/info) - Package version 23.1.1-0017
mfi0: 4539 (boot + 20s/0x0020/info) - Board Revision 04B
===
Your mileage may vary, as I'm told that these product versions (9267-8i) may
not exist outside of VICOR (but rather were custom models that can handle
either SAS or SATA using internal MiniSAS break-out cables).
--
Devin
_
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates"
On Sep 30, 2013, at 3:01 PM, Phil Regnauld wrote: > Teske, Devin (Devin.Teske) writes: >>> >>> Nice, but how does it handle if a Makefile contains a love target? >> >> Right, bmake gives us all the chance to implement love in our own >> unuque way ;D > ^^ > > Is that halfway between eunuch and unique love ? > You got it ;D -- Devin > Yes, it's off topic at this point, but heck, I think it's important > to underline that humor doesn't have an absolute metric, and as long > as it doesn't interfere with the functionality or the integrity of > the OS, it has its place :) _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates"
On Sep 30, 2013, at 1:13 PM, David Demelier wrote: > My apologies for being rude the few days ago. > > I don't know what happened to me, I'm usually not naughty like that. > Bapt who knows me IRL would also say that. My personal life is not at > its best state currently and everything that upset me get me nervous > and rude.. > > I've been using FreeBSD for 5 years and developed some patches / > improvements which honoured an entry to the additional contributors > and I don't really want my name to be removed :-). > > Seriously, I feel really embarrassed for what I've said.To really > explain why I got angry like that (but that does not excuse my words) > is the following situation: > > 1. I've first stambled accross the new boot graphical Nakatomi > Socrates art. I've been afraid of being hacked or something gone wrong > in the SVN branches. Fortunately, quickly, some of the developers told > me that it was a joke / tribute for the 9.2 RELEASE, then I just said > "I would not recommend to set it as default" but with very clean > words. And then I disabled it using loader_logo="orb" as they said. > > 2. More than one month later, I upgraded to 9.2-RELEASE and then I saw > the "Nakatomi Socrates" version shown in the right bottom and that's > why I first thought that it was reenabled again (even in orb logo, I > didn't know the existence of loader_version before!). So that's why I > felt so angry.. Nevertheless this does not excuse my behavior. > > I love FreeBSD and still hack, develop it and don't want to get in > troubles with *you* so please agree to my apologies. > Smiles. Agreed and forgiven. In hindsight, it would be those who've added loader_logo=orb in the beginning that didn't notice that this is once-again default. You can remove it (keeping only the loader_version="" entry). -- Devin > PS: I'm not a dinosaur as you may have thought, I like the "small > jokes" that you can see for example in the syscons screen savers, the > jokes in the man pages and such. But these things are more "hidden" > and you need some research to get them which provides more excitement > when you see them, on the other hand the "Nakatomi Socrates" art / > version were *for me* a bit too intense as you see them by default, > without enabling something. > > Again, sorry for that noise. > > Love, regards. > > David. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates"
On Sep 30, 2013, at 11:23 AM, David Demelier wrote: > On 30.09.2013 15:50, Matthieu Volat wrote: >> >> Le 30 sept. 2013 à 01:54, Ricardo Ferreira >> a écrit : >> >>> Em 29-09-2013 19:11, Charles Sprickman escreveu: >>>> On Sep 29, 2013, at 3:28 PM, C. P. Ghost wrote: >>>> >>>>> On 28.09.2013 11:32, Phil Regnauld wrote: >>>>>> Teske, Devin (Devin.Teske) writes: >>>>>>> If you work seriously on serious issues long enough... you'll become >>>>>>> burned- >>>>>>> out. Let me just come right out and say it... >>>>>>> >>>>>>> I coded it. >>>>>> And thanks, you got me chuckling - nice to see some humor once in a >>>>>> while. >>>>>> >>>>>> To the offended poster: read the last line of tunefs(8) - there's >>>>>> probably >>>>>> many more places you could use serious time looking for deviations from >>>>>> corporate correctnes. >>>>> Humor can even be etched in silicon, like e.g. on an IC created by >>>>> Siemens: >>>>> >>>>> http://micro.magnet.fsu.edu/creatures/pages/bunny.html >>>> Cisco too, besides weird Star Wars ROM messages, you have stuff like the >>>> "BFR" (Big F*cking Router, after Big F*cking Gun in Doom) screened on the >>>> PCB: >>>> >>>> https://www.kumari.net/gallery/index.php/Technology/Networking/BFR_2_001 >>>> https://www.kumari.net/gallery/index.php/Technology/Networking/BFR_2 >>>> >>>> I have no idea what Sluggo and Nancy are doing on this board: >>>> >>>> https://www.kumari.net/gallery/index.php/Technology/Networking/CIMG0988 >>>> >>>> Charles >>>> >>>>> ;-) >>>>> >>>>> -cpghost. >>>>> >>>>> -- >>>>> Cordula's Web. http://www.cordula.ws/ >>>>> >>>>> ___ >>>>> freebsd-stable@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >>>> ___ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >>>> >>> keep it cool u have others like: >>> >>> >>> >>> man chmod... >>> >>> BUGS >>>There is no perm option for the naughty bits of a horse. >>> >>> and so many others. So... >>> >> >> I find strange nobody mentioned the one in make :) >> >> % make love >> Not War. >> > > Nice, but how does it handle if a Makefile contains a love target? > Right, bmake gives us all the chance to implement love in our own unuque way ;D making love in each port can now be a different experience. OK OK, I digress. (Grinz) -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates"
On Sep 27, 2013, at 3:57 PM, David Demelier wrote: > On 28.09.2013 00:12, Teske, Devin wrote: >> >> On Sep 27, 2013, at 3:06 PM, David Demelier wrote: >> >>> On 21.09.2013 12:40, Matthew Seaman wrote: >>>> On 21/09/2013 11:31, O. Hartmann wrote: >>>>> I'd like to switch off this silly "Nakatomi Socrates" message which >>>>> reminds me on Linux and their childish naming schemes. >>>>> >>>>> It is only cosmetics, but it bothers me whenever I switch on the laptop. >>>>> >>>>> I guess there is a switch already prsent to have in the bootloader >>>>> config? >>>> >>>> It's turned off by default in more recent 9.2-STABLE >>>> >>>> Otherwise: >>>> >>>> loader_logo="orb" >>>> >>>> in /boot/loader.conf -- see loader.conf(5) >>>> >>>>Cheers, >>>> >>>>Matthew >>>> >>> >>> Hi, >>> >>> I have loader_logo="orb" and I still have a message at the right bottom >>> with that stupid joke. >>> >> >> I already responded to this once. >> >> loader_version="" >> >> See version.4th(8). >> >> >>> It's really pisses me off *now*. >> >> Why *now*? I already answered this... (link to archives below) >> >> https://urldefense.proofpoint.com/v1/url?u=http://lists.freebsd.org/pipermail/freebsd-stable/2013-September/075260.html&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=z7tFMIIWxpbu4NUJ6O%2BFBM29y7x%2BpF%2Bsj9kfA1f0JxU%3D%0A&s=f2e6eb61a04c40db454a365487d050393168dfb0d53318972e79c38283de3a50 >> >> If you say that you tried this and it didn't work, then by all means... >> come back (pissed off or not) and we'll debug the situation. >> > > I already asked a few weeks ago what was this strange artwork on my boot > loader and I was told to use loader_logo to completely disable it. > > I've first said that it's funny but I would not recommend to enable it > by default because it's really not serious and the artwork was really > immature in the scope of the FreeBSD project. > > Then I was "happy" because I get my orb as usual. And today, I've > updated to 9.2-RELEASE SVN tag and saw there was again a message about > this stupid "Nakatomi Socrates" version in green. So I needed to check > again *why* this has been enabled by default and that's why it was > starting to get my nerves. > The artwork and the name are separate. The artwork is an RC/Beta easter-egg that disappears at release time. The ability to display a loader_version however stays. > I personally think (but you may totally disagree with) that an operating > system *is* an operating system. And I really hate easter eggs or > anything else not serious being integrated into the system. I think > about a new user installing FreeBSD 9.2, I would not imagine his > reaction front of this kind of "tribute" or whatever you call that. For > me it stands for "that's not serious, it looks like a toy". > Only people downloading an RC or a BETA will see the artwork. This very well could: 1. Drive more people to test RC/BETA cycles 2. Not be an impact to anybody because serious people don't deploy RC or BETA builds to an enterprise. 3. It makes it very clear when you're using an RC or a BETA versus final > Fortunately now it's just a "version" but I would really not imagine > when the screen was looking with the "tribute" loader_logo. > Some folks have told me that they've permanently enabled the artwork. Not everybody that uses FreeBSD uses it in a corporate setting. Naturally, those in a corporate setting will be thankful that final releases won't ever enable a tribute artwork by-default. > Seriously, I don't understand why people waste time to create jokes like > that instead of working on serious issues. > Actually... I flip that on its head. If you work seriously on serious issues long enough... you'll become burned- out. Let me just come right out and say it... I coded it. And after 8 years of "always serious" coding on "always serious" projects has made me a dull boy. This little mini-project gave me something to work on that lifted my spirits. > You may think I'm putting to much significance on this kind of matter > but I like (and I'm not the only one) serious, clean things. > Well, maybe the mid
Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates"
On Sep 27, 2013, at 3:06 PM, David Demelier wrote: > On 21.09.2013 12:40, Matthew Seaman wrote: >> On 21/09/2013 11:31, O. Hartmann wrote: >>> I'd like to switch off this silly "Nakatomi Socrates" message which >>> reminds me on Linux and their childish naming schemes. >>> >>> It is only cosmetics, but it bothers me whenever I switch on the laptop. >>> >>> I guess there is a switch already prsent to have in the bootloader >>> config? >> >> It's turned off by default in more recent 9.2-STABLE >> >> Otherwise: >> >> loader_logo="orb" >> >> in /boot/loader.conf -- see loader.conf(5) >> >> Cheers, >> >> Matthew >> > > Hi, > > I have loader_logo="orb" and I still have a message at the right bottom > with that stupid joke. > "Named Releases" is far from a joke. Maybe you'd like something a bit more boring like "9.2-RELEASE" The fact is... there is (and only ever will be) one iteration of FreeBSD 9.2. I assume that you have had no clue up until this point that there was yet another BSD 9.2. A fictitious version of BSD in a 1980's film, named... Nakatomi Socrates Yeah, we could have decided to let the opportunity pass; to show that we're the first BSD to ever hit 9.2 out of all the flavors, producing the first ever non-fictitious BSD 9.2... But where would the fun be in that? Rest assured... I've not seen *any* hollywood films with a number higher than 9.2... so our future looks pretty darn boring. The "name" for 10.0-RELEASE could very well be NULL or boring ol' 10.0-RELEASE But one thing is clear. There is a real tangible benefit to seeing the version on the boot screen. As we move to integrate BE's into the Forth boot screen, it may become paramount to know what version of loader(8) you're using. So please try not to be so judge-mental about these things. This is a real tangible improvement and simply because you've heard that those crazy people in Linux-land are naming their releases... That had zero bearing on why we did it. We may never name another release ever again. I personally would like to see loader(8) set the value to include an SVN revision so that everytime you rebuild loader(8), the version info updates; displayed prominently in the bottom right corner (which of course... you'll again be free to override it if you don't like it... just as you are free to completely disable the entire menu by adding beastie_disable=YES to loader.conf(8)). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates"
On Sep 27, 2013, at 3:06 PM, David Demelier wrote: > On 21.09.2013 12:40, Matthew Seaman wrote: >> On 21/09/2013 11:31, O. Hartmann wrote: >>> I'd like to switch off this silly "Nakatomi Socrates" message which >>> reminds me on Linux and their childish naming schemes. >>> >>> It is only cosmetics, but it bothers me whenever I switch on the laptop. >>> >>> I guess there is a switch already prsent to have in the bootloader >>> config? >> >> It's turned off by default in more recent 9.2-STABLE >> >> Otherwise: >> >> loader_logo="orb" >> >> in /boot/loader.conf -- see loader.conf(5) >> >> Cheers, >> >> Matthew >> > > Hi, > > I have loader_logo="orb" and I still have a message at the right bottom > with that stupid joke. > I already responded to this once. loader_version="" See version.4th(8). > It's really pisses me off *now*. Why *now*? I already answered this... (link to archives below) http://lists.freebsd.org/pipermail/freebsd-stable/2013-September/075260.html If you say that you tried this and it didn't work, then by all means... come back (pissed off or not) and we'll debug the situation. The person that recommended loader_logo was incorrectly thinking you were talking about the ARTWORK that you get by default in RC1-RC3 which is now non-default (requiring loader_logo="tribute" to enable beyond RC3). The "named releases" however are staying enabled by default. And as I answered in the archives... loader_version="whatever you want to name your release" or loader_version="" is how you customize the text which seems to piss you off so much. > I already said it was okay to add a new > logo for that stupid joke. But now, I have orb set and I still see that > in my bootloader. > > How can I disable this forever ?! > http://lists.freebsd.org/pipermail/freebsd-stable/2013-September/075260.html > Also in the future you can just forgot that crappy ideas as you can see, > nobody liked it. > Uh... I'm ignoring that. -- Devin P.S. You're not winning any friends here. We answered your question and you came back hostile. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates"
On Sep 21, 2013, at 3:40 AM, Matthew Seaman wrote: > On 21/09/2013 11:31, O. Hartmann wrote: >> I'd like to switch off this silly "Nakatomi Socrates" message which >> reminds me on Linux and their childish naming schemes. >> >> It is only cosmetics, but it bothers me whenever I switch on the laptop. >> >> I guess there is a switch already prsent to have in the bootloader >> config? > > It's turned off by default in more recent 9.2-STABLE > > Otherwise: > > loader_logo="orb" > > in /boot/loader.conf -- see loader.conf(5) > Maybe he meant the name associated with named-releases now. To kill that, put into loader.conf(5): loader_version="" See version.4th(8) for additional details. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Installer on serial-console-only-embedded system
sysinstall had the ability to allow you to muck with /etc/ttys before rebooting to your installed OS. This functionality is coming back slowly. In 9.2-R you will be able to (somehow) bow out of the installation process after it's complete (e.g., "Ctrl-C" ??) and then run bsdconfig -- invoking the "TTYs" module, giving you a chance to change the settings before you reboot from your newly installed system. Tighter Integration will follow in the years to come... but replacing a tool that had a 15-year run which did _all_ of this stuff, is/was not an overnight project. Rather, it's a journey! -- Devin On Aug 12, 2013, at 5:56 AM, Michael Sierchio wrote: > You need to change /etc/ttys to turn off the virtual consoles and turn > on a serial terminal. > E.g., > > ttyv0 "/usr/libexec/getty Pc" xterm off secure > # Virtual terminals > ttyv1 "/usr/libexec/getty Pc" xterm off secure > ttyv2 "/usr/libexec/getty Pc" xterm off secure > ttyv3 "/usr/libexec/getty Pc" xterm off secure > ttyv4 "/usr/libexec/getty Pc" xterm off secure > ttyv5 "/usr/libexec/getty Pc" xterm off secure > ttyv6 "/usr/libexec/getty Pc" xterm off secure > ttyv7 "/usr/libexec/getty Pc" xterm off secure > ttyv8 "/usr/local/bin/xdm -nodaemon" xterm off secure > # Serial terminals > # The 'dialup' keyword identifies dialin lines to login, fingerd etc. > ttyu0 "/usr/libexec/getty std.9600" dialup on secure > ttyu1 "/usr/libexec/getty std.9600" dialup off secure > ttyu2 "/usr/libexec/getty std.9600" dialup off secure > ttyu3 "/usr/libexec/getty std.9600" dialup off secure > # Dumb console > dcons "/usr/libexec/getty std.9600" vt100 off secure > > On Mon, Aug 12, 2013 at 8:34 AM, CeDeROM wrote: >> Hello :-) >> >> With my friend Jacek we have tried to perform PXE installation of >> FreeBSD 9 on an i386 embedded system for one project. This required >> adding "-h" or "comconsole" to the /boot/loader.conf so the >> input-output is done with serial console port, not video console. >> However, after installation, on this embedded system with no video >> console, system seems to be configured to use videoconsole by >> default... >> >> Is it possible to add this nice feature to the new installer that >> would recognise if installation is done with serial-port-console and >> then setup the installed system to work with serial-port-console by >> default not the videoconsole? We could try it out on 9.2-RC2 if >> possible :-) >> >> Best regards! :-) >> Tomek >> >> -- >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >> ___ >> freebsd-embed...@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-embedded >> To unsubscribe, send any mail to "freebsd-embedded-unsubscr...@freebsd.org" > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [SOLVED] Re: missing /boot/menusets.4th
On Aug 9, 2013, at 7:11 AM, Teske, Devin wrote: > > On Aug 9, 2013, at 2:55 AM, Henrik Lidström wrote: > >> On 08/09/13 10:28, Daniel Braniss wrote: >>> as of now (sorry have no rev#) the file >>> sys/boot/forth/menusets.4th Again, apologies... Patched stable/9 with forgotten MFC of r242688 (see recent SVN r254146). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[SOLVED] Re: missing /boot/menusets.4th
On Aug 9, 2013, at 2:55 AM, Henrik Lidström wrote: > On 08/09/13 10:28, Daniel Braniss wrote: >> as of now (sorry have no rev#) the file >> sys/boot/forth/menusets.4th >> is not being installed, so boot failes! >> >> danny >> >> >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > Yep, I just recovered from it using fixit and copying the file from src to > /boot. > > FreeBSD 14HELI 9.2-BETA2 FreeBSD 9.2-BETA2 #7: Fri Aug 9 10:43:22 CEST > 2013 root@14HELI:/usr/obj/usr/src/sys/JOBBD2 amd64 > (raises hand) My fault! I committed SVN r254109/r254113. ... and forgot to merge r242688. And I know why I missed it... Learned a valuable lessen today... *** I did my "mergeinfo --show-revs=eligible" in sys/boot/forth *** NOTE: Despite the fact that I did "svn merge" in the proper location, the "show-revs" was influenced by the fact that I was in a sub-directory ... thus I never caught r242688 because at that sub-directory level, the revision didn't apply (show-revs=eligible didn't list it; and that's the list I was processing). It's not that I wasn't paying close attention to... http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.html It's that I didn't know that the rule of getting the list of eligible revs was quite as important as the actual act of merging. I'm very aware now that when you go to synchronize branches... it's imperative that even the show-revs step be done at the right level (but to be fair... I wasn't expecting something like r242688 ... and it had been a _long_ time since I had last broke the build [albeit with the same problem in HEAD]). Much apologies. Merging r242688 immediately to stable/9 to fix the missing file issue. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS in jails 9.2-RC1 permission denied
On Aug 8, 2013, at 9:04 AM, George Kontostanos wrote: > On Thu, Aug 8, 2013 at 2:59 PM, Mark Felder wrote: > >> On Thu, Aug 8, 2013, at 6:53, George Kontostanos wrote: >>> >>> Anybody? >>> >> >> Can you provide your jail configuration? I think 9.2 introduces the new >> /etc/jail.conf functionality and perhaps it somehow it broke the way you >> were doing it previously? If so, the old method is supposed to be work >> as well... >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > > jail_enable="YES" > jail_list="jail1" > jail_jail1_rootdir="/tank/jails/jail1" > jail_jail1_hostname="jail1" > jail_jail1_interface="em0" > jail_jail1_ip="172.16.154.32" > jail_jail1_devfs_enable="YES" > > Do you see anything wrong here? > Nope... though possible optimization... jail_jail1_ip="em0|172.16.154.32" # no need for jail_jail1_interface -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Booting FreeBSD with Syslinux
On Jul 31, 2013, at 6:38 AM, Daniel O'Connor wrote: > Hi, > I am trying to make a FreeBSD 9.2 hybrid image (ie ISO & USB from the same > file) and as part of that I need to use syslinux. Unfortunately I can't get > Syslinux's mboot.c32 to run the kernel or loader as suggested at > http://www.syslinux.org/wiki/index.php/Mboot.c32 - it reports "Invalid > Multiboot image: neither ELF header nor a.out kludge found". > > I suspect I would be able to use memdisk as I have used that in the past with > syslinux (for 7.x) however this was seems a lot cleaner and easier to > generate. > > Has anyone had any success with this? > Absolutely. You can download and dissect the following to show you how it's done... http://druidbsd.sourceforge.net/download.shtml#FreeBSD_Druid It uses syslinux, as you can see here: http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druid/src/boot/freebsd/isolinux.cfg?revision=1.1&view=markup As you can see, I use the memdisk.c32 module. Notice that I append "iso raw" as options to memdisk.c32. You may then be asking yourself... if the thing to do is to use memdisk with an ISO... what's in said ISO? http://druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druid/mdroot/ Basically... 1. Kernel 2. Boot Forth 3. mfsroot All that goes into an ISO. When memdisk initiates the ISO, "/boot/cdboot" then gets invoked. >From there, /boot/loader gets invoked. >From there, the /boot/loader.rc is loaded. >From there, loader.4th is loaded. >From there, loader.conf is loaded. In a normal FreeBSD boot process, then the kernel gets loaded (I've modified that to not load the kernel until later -- because my Forth boot menu presents a kernel selection option) >From there, beastie.4th is loaded. >From there, beastie-start is called and then the beastie menu is drawn. NOTE: I've skipped a whole bunch of other Forth modules that were loaded "at-once" indirectly >From there, the user makes any boot option choices, and presses ENTER to boot. >From there, mfsroot.gz is loaded. >From there, /stand/sysinstall gets invoked. >From there, /install.cfg gets invoked. >From there, /stand/fis gets invoked. >From there, /dev/iso9660/druid gets mounted onto /cdrom (this ISO9660 volume >is actually _not_ the ISO that memdisk booted, but rather this is the actual >CDROM (or DVD) that you booted from (which contains both the syslinux boot >loader *and* the ISO it booted *and* anything else you want to access). At this point, /cdrom is your ticket to freedom, busting out of the double-encapsulation (first encapsulation is wrapping the kernel+forth+mfsroot into an ISO, second level of encapsulation is from within the mfsroot; from within the mfsroot, the GEOM provided /dev/iso9660/ is an escape hatch to the level *above* the ISO the mfsroot was embedded within). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SunFire X2200 ilo's bge1 DOWN/UP
On May 27, 2013, at 12:59 AM, Daniel Braniss wrote: On Fri, May 24, 2013 at 05:31:13PM +0300, Daniel Braniss wrote: hi, after upgrading to 9.1-stable, this particular hardware - SunFire X2200, If you're truly running stable/9, and it's up-to-date, you should have have already SVN revisions 248858 and 250650. Both of which have significant impact for (a) the SunFire X2200 (r248858) and (b) the DOWN/UP problem (r250650). Show me dmesg(bge(4) and brgphy(4) only) and 'ifconfig bge1' output. bge0: mem 0xfdff-0xfdff,0xfdfe-0xfdfe irq 17 at device 4.0 on pci6 bge0: CHIP ID 0x9003; ASIC REV 0x09; CHIP REV 0x90; PCI-X 133 MHz miibus2: on bge0 brgphy0: PHY 1 on miibus2 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:1b:24:5d:5b:bd bge1: mem 0xfdfc-0xfdfc,0xfdfb-0xfdfb irq 18 at device 4.1 on pci6 bge1: CHIP ID 0x9003; ASIC REV 0x09; CHIP REV 0x90; PCI-X 133 MHz miibus3: on bge1 brgphy1: PHY 1 on miibus3 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: Ethernet address: 00:1b:24:5d:5b:be sf-10> ifconfig bge1 bge1: flags=8802 metric 0 mtu 1500 options=8009b ether 00:1b:24:5d:5b:be nd6 options=21 media: Ethernet autoselect (100baseTX ) status: active Saw similar things happening over here with different broadcom chipset, and the above revisions helped significantly (URLs below): http://svnweb.freebsd.org/base?view=revision&revision=248858 http://svnweb.freebsd.org/base?view=revision&revision=250650 is toggeling bge1 DOWN/UP every few hours, this port is being used by the ILO. To check, I upgraded another identical host, and the same problem appears. What is the last known working revision? I have no idea, but I have older versions, and ill start from the oldets (9.1-prerelease), but it will take time, since it takes hours till it happens. There are ways you can speed up the replication time. I tend to flood a server with TCP while I've heard of it happening under UDP flood too. Here's a nice way to flood a server with TCP (assuming you have SSH access to the system via keys): sh -c 'while :;do dd if=/dev/urandom of=/dev/stdout bs=1m count=1024 | ssh HOST2KILL /sbin/md5; done' Run that about 16 times in separate screen sessions from various other hosts on your network, taking care to replace "HOST2KILL" with the hostname or IP of the box with the SunFire X2200. Let that run for a while, and then when you think you've had a reset (if you weren't standing there watching for one)… grep 'bge.*DOWN' /var/log/messages On a system that has booted and stayed up-and-running, there shouldn't be any messages like this: bge0: link state changed to DOWN When you actually get this message (if your experience is like ours), you'll be down for 90 seconds while the NIC resets. However, since you say you have some older 9.1 releases… I'd start by first trying to bring the replication time of the problem down by using TCP and/or UDP floods. That way you'll be able to test for resolution of the problem as you progress up to stable/9 (where the problem should be fixed by the aforementioned SVN revisions -- specific to your hardware). There is not correlation with time, since they happend at totaly different times. I rebooted both hosts at almost the same time. one host : uptime: 5:24PM up 6:15, 0 users, load averages: 0.00, 0.00, 0.00 May 24 12:53:52 sf-04 kernel: bge1: link state changed to DOWN May 24 12:53:55 sf-04 kernel: bge1: link state changed to UP May 24 15:34:25 sf-04 kernel: bge1: link state changed to DOWN May 24 15:34:28 sf-04 kernel: bge1: link state changed to UP and uptime: 5:24PM up 6:14, 0 users, load averages: 0.00, 0.00, 0.00 May 24 16:30:44 sf-10 kernel: bge1: link state changed to DOWN May 24 16:30:44 sf-10 kernel: bge1: link state changed to UP this is not serious, the ilo (ssh) connection is ok, but it's anoying, we have more than 10 of this hosts, and if I upgrade all of them, the logs will fill up with this :-) any ideas? Well, you say the connection is OK… so it doesn't sound like a full reset as it was in our case (we have a different chipset). But I agree that a log full of those would be annoying. Try getting up to stable/9 in its current state (note: stable/8 also has all the aforementioned revisions too). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. __
RE: some issues with /usr/sbin/service
(sorry for top-post ... dumb client software) Am I missing something in this entire thread or... Why not utilize the oft-neglected "/etc/rc.conf.d" directory? Example? My own "vimage" package which installs: /etc/rc.conf.d/vimage /etc/rc.d/vimage The /etc/rc.conf.d file is a segment of what should appear in /etc/defaults/rc.conf.d and is loaded whenever a service is loaded. The /etc/rc.conf.d acts as a set of underrides just like /etc/defaults/rc.conf does for the rest of the rc system. -- Devin From: owner-freebsd-sta...@freebsd.org [owner-freebsd-sta...@freebsd.org] on behalf of Gary Palmer [gpal...@freebsd.org] Sent: Saturday, February 16, 2013 10:08 AM To: Chris Rees Cc: Jeremy Chadwick; FreeBSD; Boris Samorodov Subject: Re: some issues with /usr/sbin/service On Sat, Feb 16, 2013 at 05:38:56PM +, Chris Rees wrote: > On 16 February 2013 17:05, Paul Mather wrote: > > On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote: > > > >> On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: > >>> 16.02.2013 01:32, Jeremy Chadwick ??: > >>> > Follow up -- I read Alfred's most recent mail. Lo and behold, I find > this in /var/log/messages (but such did not come to my terminal): > > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable > is not set properly - see rc.conf(5). > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable > is not set properly - see rc.conf(5). > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable > is not set properly - see rc.conf(5). > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: > $htcacheclean_enable is not set properly - see rc.conf(5). > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: > $fetchmail_enable is not set properly - see rc.conf(5). > > Cute. Agreed -- this is unacceptable on two levels (as I see it): > > 1) These messages should be going to stdout or stderr in some way, so > honestly logger(8) should be called with the "-s" flag (IMO). > >>> > >>> Fully agreed here. > >> > >> It turns out logger -s has no effect, just like how the echo 1>&2 > >> statements in warn() and err() have no effect either (these should be > >> outputting the warnings in question to stderr) -- see rc.subr's source > >> for what I'm referring to. > >> > >> Gary and I have been discussing this off-list and the reason has been > >> found: service(8) has this code in it: > >> > >> checkyesno $rcvar 2>/dev/null && echo $file > >> > >> This explains why there's no warn() or err() output on the terminal -- > >> it's being redirected to /dev/null prior. > >> > >> I do not know who maintains the rc(8) and rc.subr(8) framework, but > >> they've got their work cut out for them. > >> > >> (Note: the echo statements in warn() and err() could be replaced with > >> "logger -s" as I said; this would allow the "echo 1>&2" to be removed) > >> > 2) These messages should not be displayed at all (i.e. lack of an > xxx_enable variable should imply xxx_enable="no"). > >>> > >>> I see this message as one more level of supervision. > >>> > >>> If undefined at /etc/make.conf the value of xxx_enable is "no" from the > >>> system's POV (i.e. the service is not strarted). From the > >>> admininstrators's POV the port was installed BUT is not used. It's up > >>> to admininstrator whether it's OK or not -- just let him remind. > >> > >> I believe the point you're trying to make is that the warning in > >> question should 'act as a reminder to the administrator that they need > >> to set xxx_enable="yes" in rc.conf'. > >> > >> If not: please explain if you could what you mean, because I don't > >> understand. > >> > >> If so: I strongly disagree with this method of approach, as what you've > >> proposed is a borderline straw man argument. > >> > >> Reminding the admin to set xxx_enable is presently done inside most > >> ports' pkg-message. IMO, this should really be done inside bsd.port.mk > >> when USE_RC_SUBR is used, emitting a message during install that says > >> something like: > >> > >> To enable the xxx service, please add the following to /etc/rc.conf: > >> xxx_enable="yes" > >> > >> Of course, I don't know if this would work for packages. > >> > >> The current message for is this: > >> > >> WARNING: $xxx_enable is not set properly - see rc.conf(5). > >> > >> The message is entirely misleading for this specific situation; it isn't > >> "reminding" an administrator -- if anything it's confusing them (thread > >> is case in point). If we're going to cater to ignorance, then the > >> message should reflect the situation. > >> > >> Thus IMO, this is what ***should*** happen: > >> > >> Definition in rc.confBehaviour/result > >> --- --- > >> myprog_enable="yes" emit no warnings, service should run >
RE: ix? / Intel(R) PRO/10GbE
On Tue, 12 Feb 2013, Daniel Braniss wrote: > > On Tue, 12 Feb 2013, Daniel Braniss wrote: > > > > > I finally got a 10G card that is recognized by FreeBSD (9.1-stable): > > > ... > > > ix0: port > > > 0xecc0-0xecdf mem 0xd9e8-0xd9ef,0xd9ff8000-0xd9ffbfff irq 40 at > > > d=evice > > > 0.0 on pci4 > > > ix0: Using MSIX interrupts with 9 vectors > > > ix0: RX Descriptors exceed system mbuf max, using default instead! > > > > From reading sys/dev/ixgbe/README: > > > > echo "kern.ipc.nmbclusters=262144" >> /etc/sysctl.conf > > echo "kern.ipc.nmbjumbop=262144" >> /etc/sysctl.conf > > reboot > > but this only works if the driver is loaded after > the sysctl is executed! > it's better to put it in /boot/loader.conf Not necessarily, it depends when the driver grabs the mbufs. In the case of the igb/ixgb/ixgbe drivers, this happens when the interface is brought up (not when the driver is loaded, nor when the driver probes/attaches a PHY). In other words, you don't have to worry about mbuf exhaustion until you say "ifconfig ix0 up" (in the case of ixgbe, bringing up even a single interface is enough through the default mbufs and require more). Since sysctl.conf is processed before the network is brought up, putting the parameters in sysctl.conf will be perfectly suitable for most needs (unless for some strange reason you need to "up" an interface before sysctl.conf is processed). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: ix? / Intel(R) PRO/10GbE
On Tue, 12 Feb 2013, Daniel Braniss wrote: > I finally got a 10G card that is recognized by FreeBSD (9.1-stable): > ... > ix0: port > 0xecc0-0xecdf mem 0xd9e8-0xd9ef,0xd9ff8000-0xd9ffbfff irq 40 at device > 0.0 on pci4 > ix0: Using MSIX interrupts with 9 vectors > ix0: RX Descriptors exceed system mbuf max, using default instead! > ix0: Ethernet address: 90:e2:ba:29:c0:54 > ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 > ... > but it apperas as ix0/ix1, manuals only mention ixgb/e, > and ifconfig: > > ix0: flags=8802 metric 0 mtu 1500 > > options=401bb UM,TSO4,VLAN_HWTSO> > ether 90:e2:ba:29:c0:54 > nd6 options=21 > media: Ethernet autoselect > status: no carrier > ix1: flags=8802 metric 0 mtu 1500 > > options=401bb UM,TSO4,VLAN_HWTSO> > ether 90:e2:ba:29:c0:55 > nd6 options=21 > media: Ethernet autoselect > status: no carrier > > and pciconf: > ix0@pci0:4:0:0: class=0x02 card=0x7a118086 chip=0x10fb8086 rev=0x01 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' > class = network > subclass = ethernet > > Secondly how is this fixable: > RX Descriptors exceed system mbuf max, using default instead! > >From reading sys/dev/ixgbe/README: echo "kern.ipc.nmbclusters=262144" >> /etc/sysctl.conf echo "kern.ipc.nmbjumbop=262144" >> /etc/sysctl.conf reboot -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: natd in a jail
On Nov 22, 2012, at 2:43 AM, wrote: >> I've not used it myself, but this sound like something VIMAGE may be good >> for, basically it's a virtual tcp stack per jail, there's some docs at >> http://wiki.freebsd.org/Image but I seem to remember a more up to date one >> elsewhere but can't find it at the moment! I have created a boot script for managing vimages (downloadable as a FreeBSD package) and made a little write-up on how to use it... http://druidbsd.sf.net/vimage.shtml Note that I use netgraph for bridging (not if_bridge+epair method which seems to be popular in some other setups -- we've benchmarked netgraph and it scales well). Not to mention that "ngctl dot | dot -Tsvg -o network.svg" can produce nice pretty graphs of your vimage structure when using my setup. > AFAIK, VIMAGE is still experimental feature. Works great, tho, seriously! We're multiplexing hardware 20:1 and could probably push it further (but have conservatively kept things at about 2-3x the number of logical CPUs for number-of-vimages (tho, we have benchmarked up to 65530 nodes on a single bridged network connection before netgraph would refuse to make another (impressive -- but not nearly as impressive as the ~90 minutes it took ifconfig to list all the interfaces lol?). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: less and vi fail on file whose name begins with +
On Jul 15, 2012, at 10:03 PM, Thomas Mueller wrote:
> I notice in my latest build of FreeBSD 9.0-STABLE (#11), a problem with less
> and vi with files whose name begins with +.
>
> These files occur in /var/db/pkg/(pkg-name)/
>
> For instance, if I cd /var/db/pkg/png-1.4.8
> and type
> less +DESC
> I get
>
> Missing filename ("less --help" for help)
>
> but if I type the filename with full path, or even
> less ./+DESC
> it works OK
>
> I also tried going to /tmp and
> echo abcdefg > +junk1.txt
> and the same bug with less showed up (no problem with echo).
>
> I tried vi instead of less, not really wanting to edit the file,
> and vi tried to open a temporary file on /tmp with a strange name.
>
> Has anybody noticed this bug? It affects i386 and amd64 at least.
>
> I have no access to test on other architectures.
>
> If this bug is found, we no doubt want it to be squashed before 9.1-RELEASE.
>
Neither of these are "bugs" and I assure you they are as old as the hills
(maybe not vi but always vim -- did you recently alias vi to vim?)
For less, try this:
less +/wheel < /etc/group
The + precedes an initial command. Similar with vi[m].
Simple way 'round is to use "--", e.g. below:
vi -- +DESC
--
Devin
_
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
