Specific problem raises generic issue: after upgrade stuck at installing package
-
As I posted previously, I had for testing purposes installed almost all packages, so the configuration is fairly loaded. After an upgrade back then the system was stuck and unusable because some sort of library went missing. The only solution was to re-install from scratch, which I did. However, since I had backed up the configuration before the upgrade that resulted in a corrupted system, I tried to restore that configuration after the re-installing the system from scratch.
That worked, but after the restore the system seemed stuck in the installing packages phase, for over a day, with no obvious changes. I have since let the system autoupgrade itself for test purposes: but the result is always the same: the system upgrades, reboots, and then is forever stuck at the upgrading packages phase, during which the web interface with the exception of the packages section is seemingly fully accessible. (which allows me to do things like run the autoupgrade when I get tired of waiting….)
So here's the problem:
a) there is no way of seeing which package the system is stuck at trying to install
b) there seems to be no way of removing the offending package from the configuration, and then try to rerun the package installation process.If one of the developers wants to try to see what's going on, I can try to send the configuration backup file, and you should be able to recreate the situation...
(This is on an amd64 configuration....)
PS: It's a bit difficult to compare which packages are not installed, without getting access in the web interface to the packages section. But I did notice that snort is missing on the dashboard page in the web interface. So it might be an issue with the snort installation.
-
You can go to Diagnostics > Command, and in the PHP box, put in:
clear_subsystem_dirty('packagelock');
That will reset the package warning.
If a package reinstall dies, it may be halting the whole package reinstall process and the flag won't be cleared.
-
Thanks this fixed my issue as well. it was stuck with the hard drive jpg saying packages were being installed.
-
this happened again when i updated to the latest shapshot today.
FreeBSD 8.1-RELEASE-p2 #1 Mon Jan 31 22:53 -
It probably has more to do with the packages you have installed than the snapshot you are on. One of them is failing to reinstall properly. If you check the console, you can probably see which one. Either way, find out what package it is and then start a thread specific to that package.
-
So it might be an issue with the snort installation.
Quite possibly; after every pfSense2.0 snapshot update I have to install snort manually (as described in issue 1080 - see http://redmine.pfsense.org/issues/1080)
-
Then yeah, it's probably (yet another) snort issue. :-)
Once that gets ironed out, it should go back to normal.
-
Thanks for the various hints. I'll try with a deinstalled snort and see how it goes.
In general, though, from my limited experience, the lack of QA in packages is currently the biggest issue with pfSense. If I interpret the messages flashing by during installs, it would also seem that various packages install the same stuff, not sure if they install same or different versions, if they install in the same or different places, step on each other's toes, etc.
It would be better if dependencies were handled at a more granular level than it has the appearance.
Maybe under the hood, that's the case, which would be good.Basically, there should be a test system that just has all packages installed, single WAN interface, nothing configured other than default. If such a system can't simply be upgraded reliably, then whatever package is causing this needs to be removed from the repo.
For something in RC-1, it should be a given that I should be able to blindly download and install all packages and keep updating the system without any issues, particularly if the packages haven't been configured in any way that could cause trouble.Currently that doesn't seem to be the case, and I don't even have all packages installed…
Key thing: the system has to be in a state prior to release where no physical or console-level interaction is required to keep it going. e.g. one of my systems will end up in a colocation provider half way across the country, so if I can't do it with ssh or the web interface, it means very expensive FedEx overnight roundtrip shipping and a few days worth of down-time, or it means hopping into an airplane and making a visit at great expense.
-
Because most of the packages are maintained by the community, that isn't really feasible. Plus, there are packages that conflict with each other, so it wouldn't just be one test system, but many.
And no matter how we rig up any single test system, people in the field are going to have configuration combinations we haven't (and can't conceivably have) tested for.
-
Well, the kind of testing I'm talking about isn't about the functionality of the packages, but simply about the packages not bringing down the system, such that that one can get in with the web configurator and delete/reinstall/update things. I'm not expecting all permutations of functionality to be tested, but e.g. as you say that some packages are conflicting, that's something that needs to be taken care of on a fundamental level.
e.g. if package A is installed, conflicting package B should be grayed out on the available package list.Now, after de-installing snort, and updating to the latest snapshot, the upgrade finished, seemingly, but on the console I have this beautiful message as part of the screen:
/libexec/ld-elf.so.1: /usr/local/lib/libiconv.so.3: unsupported file format
and the web config interface can no longer be started. Looks like I will have to re-install from scratch yet once more… So even without snort installed, there are issues with a working system being upgraded to another version of the system.
Needless to say, I have no idea what installs this library and/or depends on it, if it's some package or the main system, etc.
If I e.g. compare this with Cydia on my jailbroken iPhone: conflicting packages can't be installed or cause the deinstallation of the conflicting packages, dependencies are automatically selected (e.g. if this were pfSense, installing the Snort dashboard widget would also install Snort itself)
Obviously this isn't going to happen for the 2.0 release, but I think it should find its way onto the road map, because it's key to a wider adoption of the system.
At the very least, known package conflicts should be listed as text on the packages page. Some things are obvious, e.g. that the FreeSwitch and FreeSwitchDev packages are mutually exclusive, or Squid and Squid3, but beyond that it becomes a voodoo of trial and error...
To have one test system with all non-conflicting packages installed, and have it updated every so often, and disabling packages that prevent a successful upgrade shouldn't be that much work. All I'm hoping for of such testing is the prevention of being locked out of the system by not being able to get into the web configuration tool and making changes to bring the system back to sanity in the case of an incompatibility.
