2.1-release [Update - Success]
-
Type pkg_info/pbi_info into shell… pkg_delete/pbi_delete to remove.
After using pbi_info and pbi_delete you can also look in:
a) /usr/local/pkg
b) /usr/local/etc/rc.d
and get rid of the scripts starting with the package name, or obviously related to the package.
If you are reinstalling straight away, those things will get overwritten anyway by the install, so you don't really have to clean them out.
There will still be the menu options that the package added into the config. Those are in config.xml and will appear in your webGUI menus, but clicking them will give an error. Again, if you are reinstalling the package those will all become valid.
The cleanest way to "clean up" a package is- uninstall (or clean it out as above if the uninstall won't go),
- install properly from the GUI,
- uninstall (which should now uninstall cleanly).
I haven't had to start from a fresh CF card for a long time now - it should be quite possible to recover gracefully from package installs that die part way through.
-
Type pkg_info/pbi_info into shell… pkg_delete/pbi_delete to remove.
After using pbi_info and pbi_delete you can also look in:
a) /usr/local/pkg
b) /usr/local/etc/rc.d
and get rid of the scripts starting with the package name, or obviously related to the package.
If you are reinstalling straight away, those things will get overwritten anyway by the install, so you don't really have to clean them out.
There will still be the menu options that the package added into the config. Those are in config.xml and will appear in your webGUI menus, but clicking them will give an error. Again, if you are reinstalling the package those will all become valid.
The cleanest way to "clean up" a package is- uninstall (or clean it out as above if the uninstall won't go),
- install properly from the GUI,
- uninstall (which should now uninstall cleanly).
I haven't had to start from a fresh CF card for a long time now - it should be quite possible to recover gracefully from package installs that die part way through.
Excellent news ! I know the Alix is underpowered but it is small, uses no power and is a nice little red steel case :D
-
I know the Alix is underpowered but it is small, uses no power and is a nice little red steel case
Yours will run faster in a red case. I only have black cases :(
Once you get it up and running with links stable and "a decent bit" of free memory after installing and configuring "42 packages", it should run fine. The challenges so far for me are the boot, where lots of stuff gets going together and the poor little thing struggles, and link (hardware or gateway or VPN) down/up events that need a bit of memory headroom for check_reload_status to do all the stuff it wants. -
Last night I updated my Alix 2d13 from 2.1RC2 to 2.1 Release without issues. All packages reintalled.
-
Last night I updated my Alix 2d13 from 2.1RC2 to 2.1 Release without issues. All packages reintalled.
Did you have to re-install them or were they there after the reboot ?
-
Last night I updated my Alix 2d13 from 2.1RC2 to 2.1 Release without issues. All packages reintalled.
Did you have to re-install them or were they there after the reboot ?
5 updated Alixes here, no manual reinstall required. Incl. this abused testbed overloaded with packages.
-
My issues seem to be fixed now. Removed Avahi and re-installed other packages (LED pkg for Alix board and OpenVPN client exporter).
Thanks for your help guys :D
-
My issues seem to be fixed now. Removed Avahi and re-installed other packages (LED pkg for Alix board and OpenVPN client exporter).
Well, all good then. Still leaves the question why stuff like avahi, snort or squid are even offered on nanobsd.
-
Not sure - but now I need a new way to get my mDNS packets across VLANs. I have a separate 'internal' wifi network to secure traffic from the internal ethernet. I also have a 'guest' wifi network that is even more restricted but without Avahi / mDNS I can't get traffic across the VLANs to allow things such as Apple Remote (control music / Apple TV etc).
First world problems I know :D
-
An alternate way to get around the mDNS problem is to configure the IGMP proxy.
I'm not really sure what avahi actually does (i know it's an mDNS implementation, but that's about it).
What i do know is to allow mDNS devices to communicate over a router, you need to route 224.0.0.251 (which the igmp proxy should be able to do). -
An alternate way to get around the mDNS problem is to configure the IGMP proxy.
I'm not really sure what avahi actually does (i know it's an mDNS implementation, but that's about it).
What i do know is to allow mDNS devices to communicate over a router, you need to route 224.0.0.251 (which the igmp proxy does).OK - cool. I'll look into this some more !
-
success..mostly from 2.0.3 to 2.1 Release. Thanks :-)
It seems IPSEC though has some issues. Clients using Shrewsoft VPN can't connect any longer. Any pointers here?
-
99% Success on two Alix-Boards
Only problem: I had some OpenVPN-Server setup with tunnle-network "x.x.x.1/24" that worked since 2.0 but 2.1 needs it as "10.x.x.0/24" otherwise you find a message like this "Options error: –server directive network/netmask combination is invalid" at the log.
But now I have to get to the other side of the tunnel and change it there, too :-(
Bye,
eweriP.S. pfsense is really great! ;-)
P.P.S. Just found out, that my OpenVPN-Server got a new WAN-IP because of the reboot after upgrade but forgot to update DynDNS - updated DynDNS by hand, now every VPN tunnle is up and running
-
I did two 2.0.3 CARP boxes today (full installs). No issues with the upgrade but twice I had issues with the primary box locking up when I hit "Disable CARP", requiring a reboot and then a second disable (I did a dry run first, the real upgrade did the same thing). Maybe it's a hardware thing, maybe it's a software thing, I don't know. The boxes will be replaced withing the next few months though so it likely won't matter.
-
Did an upgrade from console with full update AMD64 release. Effortless and 100% successful! First time Snort updated and started and ran without errors. Been running for 36 hours with no issues whatsoever.
Great job, guys.
-
P.P.S. Just found out, that my OpenVPN-Server got a new WAN-IP because of the reboot after upgrade but forgot to update DynDNS - updated DynDNS by hand, now every VPN tunnle is up and running
Between DynDNS trying to disable free service [for those who signed up long ago when that existed at Dyn] and their failure to update the address with an updater running, I had to shift my dynamic DNS service to another provider that actually worked (as in, autoupdated correctly.) Failure to update correctly was not exactly an inducement to start paying for Dyn's [evidently degraded] service, from what I could tell. It was one of the mysterious problems about getting my VPN to work in the first place, and it's been working fine and auto-updating correctly since I moved to a better free service (afraid.org) that isn't trying to get rid of me for not buying other services.
I have concerns about updating 2.0.3 to 2.1 in case it messes with my OpenVPN, as that will get me harassed by users. Seamless would be good…I suspect I won't rush in just yet, despite this hopeful report.
-
One last thing - To me, it seems people with Alix have so far been far more willing to spend 3 hours or more in forums than to do a clean wipe and reinstall of all services, so I STILL have no idea if avahi will work after a fresh re-install. Don't think anyone has done it. (But I do fresh install at the first sign of a snag - I don't like beating my head against walls)
The RRD upgrade process leaves too much junk in /tmp for the Alix to handle which causes a lot of other parts of the upgrade process to fail. And if you have more than ~6 interfaces (vlans, or whathave you) the default 60mb /var is too small during backups of the RRD graphs.
-
Yep - I've been working under the assumption that there is alot of data being left on the disk causing failures.
Lots of people are shy to reimage their systems, but some seem to have moved in that direction with good results. -
@Xon:
if you have more than ~6 interfaces (vlans, or whathave you) the default 60mb /var is too small during backups of the RRD graphs.
You recommend a /var size? The 10 interfaces in my home box proved your point. ::)
Steve
-
@Xon:
if you have more than ~6 interfaces (vlans, or whathave you) the default 60mb /var is too small during backups of the RRD graphs.
You recommend a /var size? The 10 interfaces in my home box proved your point. ::)
Steve
Applying this patch, will mean you don't need to touch /tmp. The real problem is it is about ~3.6mb per RRD graph with 2 years of stats, or 1.5mb new. The XML dump is ~4.5mb per RRD.
And the backup process requires dumping every RRD graph to XML, then compressing it. So maybe 90-100mb for /var should let you do the upgrade sucessfully?
Doing that on an Alix platform and getting it to boot would be hard. And if you ever decrease /var's size the RRD backup process would fail next shutdown/backup cycle, and thus cause RRD data lose on the next reboot.
The alternative solution which I'm poking at, is to update ./rc.backup_rrd.sh, /etc/inc/rrd.inc, /etc/inc/upgrade_config.inc to compress each file one by one, and then tarball it up.
So instead of dumping all the files to XML, then processing them dump 1 to xml, gzip it, then after tarball all the gzip'ed files. This is less efficient, both in time and over all compression of the final archive. But it fits in the memory constrains.
I'm bashed up a changed backup script and have the restore parts looking right. It is just a matter of testing and ensuring the restore process handles if you give it a .tgz or a gz.tgz
