NanoBSD version installs are not flexible enough…
-
I wonder if there aren't some options to make the embedded disk images more universally useful
e.g.
a) why disable screen and keyboard instead of testing if screen and keyboard are present?
b) why assume a certain type of NIC instead of using whatever NIC is found, i.e. whatever driver is successfully loaded?Right now, it seems all centered around some ALIX board or whatever. I have e.g. a http://www.lannerinc.com/Network_Application_Platforms/x86_Network_Appliance/Desktop-Fanless_Appliances/FW-7535 device, and after starting the device with a 4GB CF card that I populated like this:
root# dd bs=8192 if=~/Downloads/pfSense/amd64/pfSense-2.0-RC1-4g-amd64-20110326-0121-nanobsd.img of=/dev/disk14 489230+1 records in 489230+1 records out 4007775744 bytes transferred in 433.982375 secs (9234881 bytes/sec)
the system is stuck at a blank screen. Console terminal? None of my computers even have a serial port, maybe with some effort I might be able to get one of the out-of-production USB-serial adapters, and with some luck I might even find a cable somewhere for a price that doesn't reflect "person desperate to buy some legacy technology part".
In short, the idea to configure a device like that over a serial port is about as modern as asking someone to write configuration data to a 5.25" floppy disk.
With a tiny bit of smarts after an initial boot of an un-configured system it should be easy to get it going.
Right now, for a local system I'll dare putting a regular OS on a CF card, regardless of limited read/write cycles, because I have enough RAM (4GB) that swap will not be used except in exceedingly rare cases, configurations are easy to back up, and it's if need be quick to reinstall things from scratch onto a new CF card.
But the other unit is going to be a remote unit, and I can't risk anything there, because a failure will mean down-time of close to a week or a very expensive last-minute same-day flight to another location plus hotel, airport transfers, etc.So I need to get nanoBSD running somehow, but it's not quite clear to me how that's going to happen…
...I don't even know if the thing boots properly or not. So I have no idea if the disk image was written correctly, etc.NanoBSD is a great idea, but if it's so inflexible that it works only with very few devices, it becomes a non-option for most people.
Maybe there could be a way to have the NanoBSD image on the LiveCD. Then one could save a config on a USB stick, and an installer could first dump the disk image onto one USB drive, and then copy the configuration from another USB drive.
It would also solve the issue of how to write the NanoBSD images, because the LiveCD would know how to do that, and so the LiveCD would be the only thing that needs to be distributed aside from system upgrades on the server. -
Well just use supported hardware like the Alix boards or as you've said try using an usb to serial adapter…
-
You could also just mount the disk in another computer after you've written it to the CF and then moddify the config.xml to whatever hardware you use.
-
Well just use supported hardware like the Alix boards or as you've said try using an usb to serial adapter…
Let me rephrase then: the supported hardware is not powerful enough.
There's a nice little sweet spot in the price/performance/power-consumption tradeoff, and it changes rapidly as technology advances.
The supported hardware has been the same for at least the two years I've been following the project a bit. That's an eternity in computing. They likely consume about the same amount of power (since my Lanner can run fanless), but I get a 1.6GHz dual-core 64-bit chip with hyperthreading and 4GB RAM and six NICs in a tiny box.The supported boards aren't even near that league from what I can tell.
So either the supported hardware should see some upgrades to more current performance levels, or the initial setup should be given some extra smarts to make it more universal, which is a better, and longer-term solution.
Checking what drivers successfully load and base behavior on that, should not be that difficult, I hope, and it would solve this issue for many years to come and for platforms not even conceived yet.Anyway, don't get me wrong, I'm not being unthankful, I'm just pointing out what I consider a strategic improvement. Now, the number of uses of the nanoBSD version is limited, yet significant engineering time is likely invested in maintaining that branch. With a few minor changes, the field of platforms and users benefitting from that engineering investment could be greatly expanded.
-
If you want more power why not go with the full install? The embedded version is - like the name tells you - for small embedded devices…
-
If you want more power why not go with the full install? The embedded version is - like the name tells you - for small embedded devices…
The device I'm using is for embedded use. It has an on-board video, but you have to plug in a flat-ribbon break-out cable to use it, it's meant for setting things up, not for permanent use.
Similarly, it has an on-board CF card slot, so all the limits on how often CF memory should/can be rewritten still apply.
Just because the CPUs got more powerful over the last few years doesn't mean a system isn't designed for embedded use.
It's fanless, diskless, low-power. It just so happens to be a 1.6GHz, dual-core, hyperthreading 64-bit CPU with up to 4GB RAM. It's still an embedded networking device, that comes with 6 Gigabit ethernet ports.Powerful: yes
Low-power: yes
Fan-less: yes
Multicore: yes
64-bit: yes
Embedded: yesThese are no longer contradictions in terms. I still remember the first time a printer was using a 16-bit CPU as a printer controler, at a time when a lot of computers were still 8-bit machines with 64Kb RAM. The reviewers liked the printer, but were going on how wasteful it is to have a 16-bit CPU in a printer, when "nobody ever may even need a 16-bit CPU in their desktop."
Times change, but in this specific regards, pfSense hasn't kept up with the changes.
-
If you want more power why not go with the full install? The embedded version is - like the name tells you - for small embedded devices…
Safe to put full install on CF? (Still looking for specifics on what all is different/changed in nano to reduce writes to know how big of a deal it is)
I was sort of in the same boat as rcfa as the 'embedded' hardware was not enough so went the PC route but still wanted to use CF for storage and I used embedded version of pfsense to avoid writing too much to the flash card & wearing it out any faster than necessary. Although the board I used happened to have a serial port (not given these days), I had lappy w/ serial port (again not a given these days) & luckily had a null cable handy (happened to come across it while organizing basement recently), and it only took me a few minutes extra over installing from CD, I can see there is some overlap in needs between embedded & full.
I am not familiar with all of the details on what is actually different between the full vs embedded version of pfsense (besides obvious of freebsd vs nanobsd & it appears no swap part is used on nano) I can definitely relate to both sides. I too grumbled a bit about hassles of running through motions to do embedded (for starters the new reader on my main computer has no CF slot & writing IMG from Windows is PITFA to say the least and essentially foreign to doze world) it seems someone with a special setup can likely spare the effort to do the extra steps for installing embedded or possibly make changes to use full (like I considered using lappy hdd instead of CF). From what I can tell the main reason to use embedded version of pfsense is if the system has no way to run install cd (ie embedded) and secondary is fear of too many writes to flash drives/devices otherwise seems to make sense to use the installer.. (I will say I love the dual partition aspect of the embedded version! Just wish the boot delay wasn't so long but luckily don't reboot router too often.)
I will admit I swore a few times saying "WTF can't the installer do nano too?" and "WTH can't it just F'n assign some private IP(s) to the NIC's upon 1st boot when no config file is found like a router so I can setup via web/telnet/ssh instead of serial? I don't care WHICH one just give me an IP to connect to!!" but a few minutes later I had assigned nic's, assigned an ip to the lan card & was done with serial & did the rest via http and since I hope to not have to do initial setup very often life was good. :)
Bill -
I'm using Nano on embedded hardware with no problems at all. Of course I do have a laptop with a serial port so setup is no problem for me.
I would say though that most embedded hardware has a serial port (if not all) and that it expects to use it. Most rackmount stuff has a front serial port for this purpose.
On the other hand I can't really see why we can't have both. The Hacom images have both serial and VGA console output.It's worth pointing out that the NanoBSD install is not the same as embedded install from the CD. It sounds like that may be what you're looking for.
I don't really understand your NIC comment as I've used at least three different types as LAN no problem.
Steve
Edit: USB-RS232 leads are not expensive. ebay example
-
@Steve: If you were referring to my comment I mean it would be nice if nano/embedded didn't get vga/kb support to at least consider acting like most soho routers where pfsense uses detected NIC's rather than sit there waiting for setup via serial console.. (I realize that with particular hardware it does just that but I mean for everyone else without that particular hardware..) If it can detect at least 1 NIC it should be able to assign 192.168.1.1 (or such) to it & enable dhcp. Then maybe 99% of the time one does not need serial console (ports/cable/terminal sw) to do initial setup. There could be a published list of the order they are tried or one could simply plug in patch cord & see if they get an IP & if so they are good to go otherwise plug into the next NIC jack, rinse & repeat. (My earlier comment was to assign each a different private IP but I wonder if that is more trouble than worth)
And yeah one can buy parts up the wazoo to make things work (like usb to serial adapters) but to me ideally one should be able to use what they have on hand (Nic's & patch cords which we all have) & not need to worry about having things that are kind of rare these days or need to buy more stuff. (Ok many could argue the same could be said about almost any piece of hardware such as CF->IDE adapter etc but I am looking at it as how common the item is and how likely that item can be used for other things now & into the future. Serial has been pretty much dead for years other than rare oddball stuff. Back in the day serial ports were on all computers & we all had serial cables & adapters in our kit but it's 2011! lol)
Anyway, I for one don't really find it a big deal because as I said, it seems if one does embedded they likely have the stuff & know how to do it & everyone else will likely use installer cd & not worry about embedded but at the same time I can see the argument to try & make it simpler or at least more convenient too. Impossible to please everyone but sometimes there is a happy middle ground still. :)
Cheers!
Bill -
I was refering to question b) in the original post but I see what you mean now. If you're using dd-wrt or openwrt it boots up to a web interface by default and you only need serial access if something goes wrong or you have unusual hardware.
I guess it's just not a problem I've had so I didn't realise I might be a problem.
Probably more of a background thing. If you're used to rack mounted switches and routers, using a serial console for setup is not going to seem unusual. If you're a home user, however, then trying to find a null-modem cable and computer with a serial port is like working with antiques.You could always modify the config file on the CF card in advance so that the interfaces are pre-configured. Not that I've tried that. :-\
Steve
-
I was refering to question b) in the original post but I see what you mean now. If you're using dd-wrt or openwrt it boots up to a web interface by default and you only need serial access if something goes wrong or you have unusual hardware.
Are you suggesting that most standard NICs are automatically recognized and used in the embedded system? I was under the assumption that only the specific configuration of Alix and a couple of other boards as tested for, and everything else had to be configured manually from the serial console.
Well, maybe something went wrong with the writing in the CF card, but in my case nothing booted to a web interface, and I have rather common intel Pro networking (em0 - em5) so if that driver is supposed to be auto-detected, then the image must have been written wrong.
But if there's no issue with the CF card's file system, then it means even something as unexotic as intel Pro NICs aren't recognized without manual configuration.
-
@Steve: Yup pretty much boils down to what people are used to. I'm used to both camps so neither is foreign to me but I'd definitely rather plug in lappy via network cord, get assigned an IP & enter gateway IP into browser than deal with serial cable any day. :D Btw afaik the CF card is not fat/fat32/ntfs so very tough to edit the config file for the average Joe with doze. ;)
@rcfa: Based on watching the serial console info during bootup nanoBSD definitely detects supported nics (I have a realtek onboard & 3 Intel gigabits on daughterboard that are all detected & assigned interface names) but the problem is except for SPECIFIC hardware/nics those 'unrecognized' nics are just not CONFIGURED automatically so it is sitting there waiting for you to answer questions via serial console for the initial setup (the same you see when you boot the install cd on system with video/kb) rather than just loading some default private-ip setup like most/many routers do to let you do initial setup via ethernet.
-
Are you suggesting that most standard NICs are automatically recognized and used in the embedded system? I was under the assumption that only the specific configuration of Alix and a couple of other boards as tested for, and everything else had to be configured manually from the serial console.
What Bill said above! :)
All the NICs that are supported in the full install (mostly whatever FreeBSD supports) are supported under NanoBSD install it's just that you have to select one to be LAN from the serial console at first boot.Is there a possible security issue with having a web setup? At the moment you have to have physical access to the box to set it up, that could be seen as a good thing.
Steve
-
Is there a possible security issue with having a web setup? At the moment you have to have physical access to the box to set it up, that could be seen as a good thing.
Frankly, I could care less about the security issue. Here's why:
a) the chance of someone hacking my box in the few minutes between it being first booted and me getting into the web interface is pretty darn small.
b) if someone configures accounts, etc. before I get a chance to do so, there's a good chance I'll discover, and
c) most importantly: it's rather unlikely that the box will be hooked up to the public internet the first time around anyway, because it'll be hooked up to the laptop to do the configuration, so there'll be the famous air-gap to the public net until I'm done with the initial configuration.So, if the interfaces are recognized, I don't see why they are not all configured to grab an address through DHCP. Then whichever one is hooked up to the LAN will get an IP address, I can get in with the laptop, and a few minutes later I'd be good.
-
There's nothing antiquated about serial consoles, if you do much work with networks at all, you have what's needed (or you should). Every worthwhile managed switch and most all commercial routers require serial consoles. Hook up the serial console, assign the interfaces, done. At some point we may automatically assign interfaces, until then, a serial console isn't uncommon at all, don't act like it's a 5.25" floppy, go tell Cisco, HP, Juniper, etc. as they all require serial consoles.
-
@cmb:
There's nothing antiquated about serial consoles, if you do much work with networks at all, you have what's needed (or you should). Every worthwhile managed switch and most all commercial routers require serial consoles. Hook up the serial console, assign the interfaces, done. At some point we may automatically assign interfaces, until then, a serial console isn't uncommon at all, don't act like it's a 5.25" floppy, go tell Cisco, HP, Juniper, etc. as they all require serial consoles.
Well…
...it depends whom you're targeting. If I were to install pfSense for a large organization, I'd get a 1U rack-mount server, and even though in that environment there would likely be terminals etc. floating around, I wouldn't need them, because even if I want to go the solid-state storage route, I'd just put in a 2.5" SSD drive, install the full version, and call it a day.Only in an environment with wimpy enough networking demands, such as home use, would I even consider going with the embedded version. I want my hardware to be a bit beefier, such that's future proof, and also because I want to try to run freeSwitch on one of the two boxes (that one will have the full version of pfSense, but it will be local, so if the CF card wears out, I can within hours be back up and running again).
So the environment in which the embedded version is most likely going to be used is a branch-office, home-office or plain home use.I'm fairly involved with computers on a daily basis, this being my job, but outside my own private net, I'm not a network admin or working in a data center. Despite that, the last time I dealt with a terminal was when I installed as a gag a VT100 terminal in my bathroom, and hooked it up to my NeXT computer so I could joke with some friends about from where I just sent them the e-mail. That was when I was still in college, some 20 years ago. The last time I still used a serial connection for anything else was with a fax modem hooked up to the NeXT, too, which is also at least 15 years ago. Since then, everything has been USB, or network+ssh; I neither have UUCP nor kermit installed on any of my computers, even though they used to be some of the first things I put on any hardware after it came out of the box.
So in a home/office environment, particularly in a Mac OS X setup, serial communications are truly about as antiquated as 5.25" floppy disks. I know, in a data center that's very different, but why anyone in a data center would bother with the embedded version instead of running the full-featured version on a 1U server, would be beyond me.
Bottom line as far as I can see: without the network based OR console setup, a large segment of most likely nanoBSD users are going to have a much harder time than necessary. The network aspect isn't even the worst. If only the system could check for the presence of a video and keyboard device and not just blindly disable the console if these are present, that would solve all my issues, because my embedded device has a break-out cable to hook up screen and keyboard, exactly to make it possible to do initial setup, change BIOS settings, etc.
To use anything with a serial connection, I probably would have to spend as much money on USB-serial adapters, cables, etc. that I might be cheaper just replacing the CF card with a small e.g. 32GB SSD drive and installing the full version.
My point: if we're making using the the embedded version that difficult/expensive, then why even bother supporting it? Might just as well tell people to get a cheap SSD drive and run the full version.
-
You can still install the embedded version from the install CD which I believe has VGA console. You don't get the advantage of NanoBSD's backup slices.
You have to be able to boot from CD or USB which, for me, would be far more of a problem than using serial! ::)Steve
-
@cmb:
There's nothing antiquated about serial consoles, if you do much work with networks at all, you have what's needed (or you should). Every worthwhile managed switch and most all commercial routers require serial consoles. Hook up the serial console, assign the interfaces, done. At some point we may automatically assign interfaces, until then, a serial console isn't uncommon at all, don't act like it's a 5.25" floppy, go tell Cisco, HP, Juniper, etc. as they all require serial consoles.
Pfft, you must run with the big dogs then! :D Other than a freak thing last month where my cousin who sets up cell towers needed help with his USB->serial adapter working with some oddball programming utility, I hadn't touched serial since mucking with Tivo 1's to connect via PPP over the headphone serial port because the internal modem was borked! Anyway let's just say it isn't very often & when it has been has always been obscure equipment. I realize in some circles serial might be used daily still but the average Joe does not and many think you mean USB when you mention serial IF they even make that connection. And average computer person setting up a router likely knows what serial is but either doesn't have serial port, null cable, terminal sw (Win vista/7 don't even have hyperterminal anymore but then again almost need a 2k lappy to still have serial port lol), or has to big thru boxes tucked in the basement which was what happened in my case.
A big part is thanks to the Legacy Free PC 'standard' from like around 2000 (hard to believe that was 11 years ago!) which Dell in particular took a liking too, likely because it saved them money. And you know serial stuff has gone way of 5.25" floppies when stores don't carry the adapters/cables. Heck even rat shack site says web only for almost everything serial, and that is a whopping 5 things they happen to still sell. lol
Anyway as I said earlier, personally it ended up not being a big deal for me since I had the stuff but had I had not I would have swore a few times & installed the full version from CD & got over it. Of course hoping that my CF card didn't get wore out too quickly. My comments were meant merely to agree it would be helpful if the embedded/nano version could be more user friendly in initial setup not to debate if serial was dead or not. ;)
Bill -
@cmb:
There's nothing antiquated about serial consoles
It could just be me that's antiquated! :(
It never fails to amaze me that some people have actually stopped using email entirely in favour of facebook. Those same people probably don't use serial that often. :PIs there some big problem to having both serial and CGA console? Perhaps a boot time parameter could be used to switch consoles?
Steve
Edit: Ironic typo left in for effect. :D
-
RS-232 ports are getting a bit harder to find these days. I kept an old laptop with a built-in COM port around for years, but finally gave up when its battery became useless and I couldn't read the screen very well due to CCFL aging.
It does seem like some sort of compromise between a full install and the existing Embedded build would be useful. Maybe a full-featured build based on NanoBSD would work.
-
@cmb:
There's nothing antiquated about serial consoles
It could just be me that's antiquated! :(
It never fails to amaze me that some people have actually stopped using email entirely in favour of facebook. Those same people probably don't use serial that often. :PIs there some big problem to having both serial and CGA console? Perhaps a boot time parameter could be used to switch consoles?
Steve
Edit: Ironic typo left in for effect. :D
LOL! Wait I check my facebook via 300 baud serial modem don't you? :D
But I got the biggest chuckle over CGA. Compressed Gas Association? LMAO! Not sure if that was intentional (since CGA is long long LONG extinct except apparently in some IT departments who still use serial daily cuz Cisco says so) but it had been so long since I even seen CGA written out it took me a minute to register what it was. Now that is sad on my part & shows those brain cells have undergone garbage collection long ago. hehe
Anyway all in good fun. No offense to anyone.
Bill -
Did we ever get to the underlying question? Does pfSense work on this box? Was any attempt made? Or does the lack of a VGA, DVI, DisplayPort, or HDMI connector disqualify the box as "not modern" or "not home friendly"?
4GB of RAM, Intel ethernet, Atom D510 (dual core). If this box performs the way the specifications suggest, and the price is reasonable, I would say this is an ALIX killer for sure.
Forgive me, but since pfSense is a group effort, is it reasonable to ask what the output was on the serial console at boot time?
EDIT: Found this post: http://forum.pfsense.org/index.php/topic,27780.msg144750.html#msg144750
All kinds of serial goodness in there ;D
-
Did we ever get to the underlying question? Does pfSense work on this box? Was any attempt made? Or does the lack of a VGA, DVI, DisplayPort, or HDMI connector disqualify the box as "not modern" or "not home friendly"?
4GB of RAM, Intel ethernet, Atom D510 (dual core). If this box performs the way the specifications suggest, and the price is reasonable, I would say this is an ALIX killer for sure.
Forgive me, but since pfSense is a group effort, is it reasonable to ask what the output was on the serial console at boot time?
If it helps I built new pfsense box last week with:
JetWay JNC92-330-LF Mini ITX Motherboard & Intel Atom 330 CPU (Onboard Realtek RTL8111C gigabit)
Jetway 3x Intel Gigabit LAN Module AD3INLANG (82541PI x 3)
512MB DDR2
4GB Kingston CF card with CF->IDE adapter
120W PSU in mini itx caseUsing USB CF reader I put put on pfSense-2.0-RC1-2g-i386-20110226-1633-nanobsd.img
I had to turn off DMA & UDMA in bios & force LBA mode to get it to boot.
I attached DB9-DB9 null modem cable to lappy & opened hyperterminal set to 9600,N,8,1
Once it started to boot it looked like it wasn't working because there was just a blinking cursor in upper left of VGA screen but eventually 1 line of text appears.
In hyperterminal it was ready immediately, asking me to choose partition 1 or 2 & the delay was that waiting.
You can watch it detect hardware & it does indeed detect all 4 NIC's.
Eventually it gets to screen asking if I wanted to setup VLAN's & then the normal wizard for setting up LAN/WAN/OPTx interfaces
Once i assigned LAN & setup a different private IP range I did the rest of the setup on via the web interface.So far it works great. I have 3 wans & 1 lan and playing with load balancing & failover. It shows 18% mem use, 16% space used & CPU stays at 0 unless I enable all 3 traffic graphs then it spikes to 6-8%. (From looks of top output php is the culprit but not sure why it'd use so much with 10 second updates. I don't recall the full install version doing that on the 3Ghz P4 Dell I had tested.) The only real issue I had were bugs in the code causing headaches setting up PPPoE, a different bug causing system to no longer boot when I chose wrong interface on PPPoE and for some reason browsing internet has big delays when I have multiwan group set as default vs WAN (even when I have WAN as tier 1 & others as tier 2) so I still need to figure that out.
Anyway this setup is definitely an ALIX killer even with the lowly 512 stick! 1.6Ghz Dual core with hyperthreading Atom is actually very snappy & I doubt I'll be able to load it down. Btw it measures 42W. Most of that is the old crap chipset used on that motherboard but I couldn't justify $80 more for the updated one to save 18W of power. (I paid $99 for the mb & $77 for the 3 port nic daughterboard. I had the rest of the parts on hand already so killer router for $176 which was almost $20 less than what I was quoted for a shipped ALIX.2D13 & that only had 256M & 3 NIC's & what I gather a much slower processor :D )
Anyway sorry not the same system but similar enough hopefully that was useful.
Bill -
Thanks
Lots of us are looking for a fanless, embedded, low power solution with GigE and enough processing horsepower to sustain 100s of Mb/sec over the Ethernet ports. I can't find a price or a source for the Lanner box(es) anywhere. But it's a good sign that we're starting to see these :)
-
gloomrider,
From what I could tell all of the Jetway Atom boards are fanless except the 330 & I believe it is the CHIPSET that has a fan not the CPU itself. The Jetway has the daughtboard sockets where you plug in board, 3 of which are 3 port NIC options: Intel gigabit, realtek gigabit & realtek 100mbit. I opted for the intel one even though it was $30 more than the realtek because it supposedly performs better & has better driver support & so far both appear to be be true based on my testing.So if you went for the D510 or D525 or based board it should be like 8-10W less & have about the same power as the 330 yet no fans. Or the N270 was like 18W less but 1/2 the processing speed too (based on cpubenchmark.net values). I'm content with 42W (measure at plug with kill-a-watt meter) & the essentially silent fan that is on the board I chose. :)
Bill -
The N550 board will use even less power as it supports speedstep and the desktop Atom CPUs don't.
Steve
-
Just to clarify: the Lanner has a serial port, but I have nothing that I can hook up as a terminal to it.
Also: the Lanner with the CF card will happily run the full version, however
a) in a device located on the other side of the continent I don't want to risk wearing out the CF cards memory cells and then have to do an emergency plane trip to service the unit
b) I would like to have the backup slice, such that if an OS upgrade gets screwed up, or anything like that, I have something to fall back on without expensive plane trip to service the unit.
I have a second Lanner box, on which I have already the full version of pfSense installed. Locally I don't mind the full version, because CF cards are cheap, and should it ever wear out, I just re-install from scratch, load a configuration backup, and am done with it.
Also, since I want to run freeSwitch locally, I have to use the full version here anyway.The issue thus is not if the Lanner can run the full or embedded version; it should be able to run either just fine.
The issue is, how do I get this thing configured.If nanoBSD-pfSense wouldn't BLINDLY turn off VGA and keyboard support, but would test if the drivers load, then I could configure it with screen and keyboard attached, instead of using a serial console.
If nanoBSD-pfSense would enable DHCP on the first NIC found, regardless of the driver used, then that should work, too. Right now, from what I gather, it only does that with certain types of hardware it's familiar with, and for everything else you have to do initial setup over a serial console, and that's the stumbling block.I'll try to edit the config file directly somehow, by mounting the CF card on the other pfSense box with a USB card reader, but few people will have a second pfSense box handy for that.
-
A standard FreeBSD in a virtualbox is sufficient.
You can use this guide:
http://doc.pfsense.org/index.php/Modifying_Embedded -
Just to clarify: the Lanner has a serial port, but I have nothing that I can hook up as a terminal to it.
Also: the Lanner with the CF card will happily run the full version, however
a) in a device located on the other side of the continent I don't want to risk wearing out the CF cards memory cells and then have to do an emergency plane trip to service the unit
b) I would like to have the backup slice, such that if an OS upgrade gets screwed up, or anything like that, I have something to fall back on without expensive plane trip to service the unit.
I have a second Lanner box, on which I have already the full version of pfSense installed. Locally I don't mind the full version, because CF cards are cheap, and should it ever wear out, I just re-install from scratch, load a configuration backup, and am done with it.
Also, since I want to run freeSwitch locally, I have to use the full version here anyway.The issue thus is not if the Lanner can run the full or embedded version; it should be able to run either just fine.
The issue is, how do I get this thing configured.If nanoBSD-pfSense wouldn't BLINDLY turn off VGA and keyboard support, but would test if the drivers load, then I could configure it with screen and keyboard attached, instead of using a serial console.
If nanoBSD-pfSense would enable DHCP on the first NIC found, regardless of the driver used, then that should work, too. Right now, from what I gather, it only does that with certain types of hardware it's familiar with, and for everything else you have to do initial setup over a serial console, and that's the stumbling block.I'll try to edit the config file directly somehow, by mounting the CF card on the other pfSense box with a USB card reader, but few people will have a second pfSense box handy for that.
A Prolific USB/serial converter is less that $15US. Serial console is not a "stumbling block". You can install PC-BSD on a laptop (make it dual boot with existing Windows) and you'll be able to mount the CF card right on your laptop.
Being able to see boot time messages when working with beta software is a must, IMHO.
-
A Prolific USB/serial converter is less that $15US. Serial console is not a "stumbling block". You can install PC-BSD on a laptop (make it dual boot with existing Windows) and you'll be able to mount the CF card right on your laptop.
Being able to see boot time messages when working with beta software is a must, IMHO.
I'm using a Mac, not a PC :P
Anyway, the point is, if nanoBSD wouldn't BLINDLY turn off console (VGA+keyboard) support in systems that offer video and keyboard support (like the Lanner device I'm using), we wouldn't have that issue.
I have a screen and a keyboard attached to my "embedded" device, with a break-out cable that I can remove when everything is working smoothly.In the age of plug-and-play drivers, it really shouldn't be that hard to see if keyboard and video drivers load successfully and to ONLY DISABLE VIDEO AND KEYBOARD IF THESE DRIVERS DO NOT LOAD properly.
That should amount to a few lines of code plus a conditional, yet it would solve a lot of headache.Why is it, that a simple suggestion for improvement meets that much resistance? Aren't we here to try in whatever way we can to make this a better system? Or are we here to defend he status quo and prove that we're "right"?
-
In the age of plug-and-play drivers, it really shouldn't be that hard to see if keyboard and video drivers load successfully and to ONLY DISABLE VIDEO AND KEYBOARD IF THESE DRIVERS DO NOT LOAD properly.
That should amount to a few lines of code plus a conditional, yet it would solve a lot of headache.I'm not familiar with a wide variety of embedded devices. With graphics so commonly included in chipsets and serial interfaces having such a long history of use, it possible there are some "embedded" devices with graphics hardware unconnected and using a serial port as the console. Its not clear to me that your suggestion would be a good thing to do for such hardware.
Why is it, that a simple suggestion for improvement meets that much resistance? Aren't we here to try in whatever way we can to make this a better system? Or are we here to defend he status quo and prove that we're "right"?
Its quite easy to turn this around and ask why such a simple suggestion (spend about US$15 on a USB to serial adapter) meets such resistance.
I think a variant of Murphy's Law is Everything takes longer than you first thought it would. Your suggestion might not be as easy to implement as you first thought and might have significant consequences for systems other than yours. I have worked on a number of "embedded" systems though I don't currently have any that I could even contemplate running pfSense on. Many of those embedded systems have been at least a little bit quirky. That would lead me to be cautious about assuming that the presence of recognisable graphics hardware in a system means there is a connector for a monitor and that the specification of that roles of the pins on that connector can be readily obtained (and that there is a similarly well doumented interface for a keyboard and that the BIOS supports both monitor and keyboard). I understand that implementing your suggestion would be useful to you but it might severely disadvantage a number of other pfSense users. There does come a time when it can be important to say that certain systems need to be "left behind" (e.g. they don't have enough memory, they aren't fast enough, the cost of supporting their quirks is becoming too high, …) but its often not an easy call.
-
I'm using a Mac, not a PC :P
We'll, assuming you're running OSX which is BSD based, it should be even easier then! :P
I have to agree with a lot of what you're saying. I was surprised when I first realised that there was no VGA console on Nano. I hadn't realised, however, since I'd never tried to use it, using the serial console was what I expected to do.
Perhaps one of the developers could comment on why this is. I imagine it's simply that whatever boxes they were using for development didn't have VGA. Is there some huge problem with offering both VGA and serial console access?
Steve
-
In the age of plug-and-play drivers, it really shouldn't be that hard to see if keyboard and video drivers load successfully and to ONLY DISABLE VIDEO AND KEYBOARD IF THESE DRIVERS DO NOT LOAD properly.
That should amount to a few lines of code plus a conditional, yet it would solve a lot of headache.I'm not familiar with a wide variety of embedded devices. With graphics so commonly included in chipsets and serial interfaces having such a long history of use, it possible there are some "embedded" devices with graphics hardware unconnected and using a serial port as the console. Its not clear to me that your suggestion would be a good thing to do for such hardware.
Assuming it's not possible to run the console on more than one device, isn't there a way to detect if the serial port is connected?
In that case, one could give the serial port priority, provided it's connected, and the graphics/keyboard if there's such hardware and nothing connected to the serial port.
Why is it, that a simple suggestion for improvement meets that much resistance? Aren't we here to try in whatever way we can to make this a better system? Or are we here to defend he status quo and prove that we're "right"?
Its quite easy to turn this around and ask why such a simple suggestion (spend about US$15 on a USB to serial adapter) meets such resistance.
Money and time aside, there is already an abundance of electronic trash and wasted resources.
The promise of software is to replace dedicated hardware with flexible code, so whenever that's a possibility, it's clearly the preferable route from a resource allocation and environmental POV.Ronald
-
A Prolific USB/serial converter is less that $15US. Serial console is not a "stumbling block". You can install PC-BSD on a laptop (make it dual boot with existing Windows) and you'll be able to mount the CF card right on your laptop.
Being able to see boot time messages when working with beta software is a must, IMHO.
I'm using a Mac, not a PC :P
Anyway, the point is, if nanoBSD wouldn't BLINDLY turn off console (VGA+keyboard) support in systems that offer video and keyboard support (like the Lanner device I'm using), we wouldn't have that issue.
I have a screen and a keyboard attached to my "embedded" device, with a break-out cable that I can remove when everything is working smoothly.In the age of plug-and-play drivers, it really shouldn't be that hard to see if keyboard and video drivers load successfully and to ONLY DISABLE VIDEO AND KEYBOARD IF THESE DRIVERS DO NOT LOAD properly.
That should amount to a few lines of code plus a conditional, yet it would solve a lot of headache.Why is it, that a simple suggestion for improvement meets that much resistance? Aren't we here to try in whatever way we can to make this a better system? Or are we here to defend he status quo and prove that we're "right"?
Perhaps the central issue here is the target user group for pfSense. It's probably much more than the average home user needs. We agree that the average home user wouldn't have a clue about Prolific dongles and terminal emulators. But pfSense is really for the small to medium size enterprise space. As others in this thread have pointed out, serial console ports are common on ethernet switch gear. Usually the serial port is used for initial setup only. Those of us that have to go on site and setup instances of pfSense would hate to have to schlep a monitor, keyboard & mouse into a comm closet.
Regarding UFS access with your mac, you might want to look here: http://osxbook.com/software/unixfs
Keep in mind that FreeBSD is a server OS. Those that deal with server-class operating systems are used to terminal emulation and command-line. It's how we get things done.
If I understand everything that I've read here about the Lanner gear and pfSense, the serial console works and can be used to initially configure pfSense. It's probably not useful to debate the topic, "but this is 2011, serial is so 20th century, why should I have to deal with it?" I'm certain that on-board video is not being disabled just to foist serial communication upon those who dislike it. For lightweight, embedded boxes whose primary purpose is moving packets in and out of ethernet interfaces, on-board video is superfluous and a waste of valuable system resources IMHO.
The issues that you're having with initial configuration can be easily solved with a Prolific serial/USB adapter and free terminal software (look for the program "screen" on your mac. It's CLI, sorry). I suspect the linkage between nanobsd and initial serial setup will be around for some time to come. But I (and no doubt many others) would be curious to know if your setup was successful once you perform the initial setup through serial and CLI.
Good luck!