[LCDProc] - Could not read config file
-
64bit.
-
Same here. latest 2.2 beta i386. Same error. recreated LCDd.conf by hand using vi. permission are ok. LCDd cannot read config file. Very weird.
-
Using the dev package?
Steve
-
Yup.
Need dev to drive the firebox display. Having said that, I tried the non dev version of the package. LCDd is same version and it cannot read the config file too. not in the /usr/local/etc directory or doesn't matter if I create the config anywhere else. Tried with the config created by pfsense and also recreated it from scratch using vi. even chmod 777 the file just to make sure it did not need write privileges on the file. My pfsense is i386 since it is on a firebox x-core-e.
This is too bad as I have the firebox all tweaked up on 2.2. NICs blinking right, your fan control and status light program working like a charm and even IPV6 with 6RD now working. A working LCD is what is missing now.
I read on a previous post of yours that it is working for you. Was it a new install? My is an upgrade from 2.1. It shouldn't matter though. I wonder if LCDd is using some weird library that is screwing things up.PS a big THANKS for the work you did to make a firebox an excellent pfsense platform for all of us
-
Hmm. I updated my xtm5 today and after a couple of reboots the LCD came back up. It's running 64bit though.
I have the filesystem set to permanent read-write. I can't really see what bearing that might have here but it's an easy test.
I'll have to fire up my test x550e and put 2.2 on it.Steve
-
If you have time, let me know how it goes. I am curious. I think it is a problem with the LCDd executable. Wonder if a fresh install would help. Although a fresh install vs update should not make any difference.
-
Ok, I upgraded my test X550e to todays snapshot (32bit obviously) 1G NanoBSD.
[2.2-BETA][root@pfSense.localdomain]/root: uname -a FreeBSD pfSense.localdomain 10.1-RELEASE FreeBSD 10.1-RELEASE #0 29f4af5(releng/10.1)-dirty: Thu Nov 27 01:06:40 CST 2014 root@pfsense-22-i386-builder:/usr/obj.i386/usr/pfSensesrc/src/sys/pfSense_wrap.10.i386 i386After the upgrade the lcdproc-dev package was not re-installed installed because it's not signed. I set the allow unsigned packages check and installed lcdproc-dev and rebooted. It came back up no problem. I did nothing else. That's suing the same LCDd.conf file and Shellcmd instructions that were carried across the upgrade from 2.1.5.
It's working fine for me both 32 and 64bit.
Are you still seeing this problem?
Steve
-
Still having the problem. In my case the package was reinstalled after upgrade from 2.1 (after that deleted and reinstalled numerous times). Where do you set to allow unsigned packages? I didn't have to do that and maybe this is the problem.
I am upgrading to Nov 27 snapshot so we are on the same version -
It's in System: Advanced: Miscellaneous:
If you don't have that checked it should fail the install in a pretty obvious way with authentication errors. The fact that yours didn't must surely be clue, or maybe that mine did. Perhaps you have a cached pbi? That shouldn't be possible on Nano though. Are you running Nano?Steve
Edit: an obvious fail
-
Yes, I had the install unsigned package already checked. I guess it carried over from the upgrade.
I am running nano 4gb i386.
At this point I guess the only thing left is to try a fresh install. Don't know if it is going to help. My understanding is that all of the freebsd comes with the new nano image, configuration file get upgraded to the new version and packages get reinstalled during upgrade. No system software other than what is in cf/media get carried over. I am puzzled to say the least. -
Where do you set to allow unsigned packages? I didn't have to do that and maybe this is the problem.
Don't change that, the packages are signed. The installation would completely fail with a signature error if that were the issue.
There is definitely some kind of issue with that package. I'm getting the same error that it can't find the config file, though it's there and permissions are such that it's readable by that process. I don't have anything with a LCD, not something I use.
-
Hmm, something very odd happening here. It definitely failed to install with an authentication error and then installed fine after I allowed unsigned packages. That was a few days ago though.
It's definitely running fine now using whatever binary was installed by the update process when I went to todays snapshot.
Both the machines I've tested this on were upgraded from 2.1.X so I don't know if I've got some hangover. I've never set a different package server but I guess that would do it.
Further investigation required. :-\Steve
-
Oh, some time back it could have. All PBIs were rebuilt within the past 3-4 days, there were some stragglers that hadn't been updated recently until then, and hence weren't signed. At this point, every PBI should be signed. I haven't found any that aren't.
-
lcdproc-dev is not signed. Maybe since it is a dev version it will never be.
-
Oh, sorry, indeed the dev version isn't signed.
Is there a reason the dev version is an older lcdproc than the stable version? Seems odd.
-
When the dev version was created it was to add new drivers and update the lcdproc base version. At the time the existing package hadn't been updated for a while and was way behind the current lcdproc.
If the original package has been updated it may be time to consolidate the two. The sdeclcd driver has been included upstream so it may already be in the original package. There were some changes made in the -dev package which seemed like a good idea at the time but in retrospect may not have helped.Steve
-
Well, did a fresh reinstall using today snapshot of nano 1gb on the x-core-e 550. setup lcdproc screen to use parallel interface, whatcguard sdeclcd driver, 2x20char line, lpt 4 bit wiring, setup a few screens, rebooted and service will not start. from command line same error. cannot read config file which is present and has correct permissions.
I am scratching my head here.
Stephenw10 did you do have any ideas? yours is working and I tried to duplicate your setup, down to the same size nano image.On a different note as I reinstalled fresh, the nano image does not have a config.xml in /conf and pf sense web gui will not start. I had to use the serial console, and manually copy config frpm /config.default to /config
-
Left the box at what passes for an office. ;) So I can't check right now. I'll get the md5 sum on the binaries tomorrow.
The only thing I can think is that on my 64bit box I have the filesystem set to permanently read-write. This was a hang over from a much earlier snapshot where remounting it RO was causing a huge delay. However i'd dismissed that as a cause because the 32bit box is not set to RW. However whilst checking something else out I found that it's actually leaving the filesystem mounted RW for some reason. Now I don't know why it should make any difference. LCDd shouldn't be writing anything. I could just about imagine it's trying to copy the config file but I don't know why. Anyway it's easy to test it by setting the filesystem permanently RW in Diagnostics: Nanobsd:Steve
-
Tryied filesystem rw permanent does not make any difference. I am about to give up on this.
-
SOLVED (sort of)
lcdproc-dev needs to be updated.
installed lcdproc 0.5.7_1 on top of lcdproc-dev and now it works flawlessly.For whoever is interested in a step by step temporary solution until lcdproc-dev is up to date:
- Install lcdproc-dev 0.5.6 from pakages
- drop to freebsd console
- mount -uw /
- pkg install sysutils/lcdproc
- go to GUI status/services and start lcdproc
it should work
In /usr/local/sbin and /usr/loca/bin there are symbolic links to /usr/pbi/lcdproc/sbin and bin pointing to LCDd, lcdexec and lcdproc. installing the freebsd package overwrite these links with the downloaded executables. The php file handling lcdproc fortunately refers to the standard location in /usr/local/… so it is pointing to the new files. So just installing the freebsd package on top of the old pfsense lcdproc-dev pakage works flawlessly.
Yeah! Working firebox with PFSense 2.2, IPV6 and working LCD. Cant be happier.
Now time to learn the intricacies of ipv6.
