first of all, thanks a lot for the great work on openhabian!
Since the newest release 1.4 i have a big problem with openhabian. If I do a fresh installation of openhabian and then doing the following steps, nothing works anymore:
start upgrade system
install optional components:
edit the interfaces file to get a static ip
openhabian is broken, because i can’t start an upgrade system (point 3) anymore and i get the following error:
The following packages will be upgraded:
bind9-host cpp-4.9 curl g++-4.9 gcc-4.9 gcc-4.9-base homegear homegear-homematicbidcos homegear-homematicwired libasan1 libatomic1 libbind9-90 libcups2 libcurl3 libcurl3-gnutls libdb5.3 libdns-export100 libdns100 libgcc-4.9-dev
libgcc1 libgomp1 libgssapi-krb5-2 libhomegear-base libhomegear-node libicu52 libirs-export91 libisc-export95 libisc95 libisccc90 libisccfg-export90 libisccfg90 libk5crypto3 libkrb5-3 libkrb5support0 liblwres90 libmysqlclient18
libncurses5 libncursesw5 libssl1.0.0 libstdc++-4.9-dev libstdc++6 libtinfo5 libubsan0 libwbclient0 libx11-6 libx11-data libxi6 libxml2 libxtst6 mysql-common ncurses-base ncurses-bin ncurses-term openhab2 openssh-client
openssh-server openssh-sftp-server openssl p7zip-full rsync sensible-utils ssh sudo tzdata zulu-embedded-8
65 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/234 MB of archives.
After this operation, 175 MB of additional disk space will be used.
fatal: unable to read tree ecb31bff091888105076334ab0bd08fa3099f05b
dpkg-deb (subprocess): decompressing archive member: lzma error: compressed data is corrupt
dpkg-deb: error: subprocess <decompress> returned error exit status 2
dpkg-deb (subprocess): decompressing archive member: internal gzip read error: '<fd:4>: invalid distance too far back'
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
dpkg-deb: error: subprocess tar returned error exit status 2
Traceback (most recent call last):
File "/usr/bin/apt-listchanges", line 250, in <module>
File "/usr/bin/apt-listchanges", line 108, in main
pkg = DebianFiles.Package(deb)
File "/usr/share/apt-listchanges/DebianFiles.py", line 134, in __init__
self.binary = pkgdata.Package
AttributeError: ControlStanza instance has no attribute 'Package'
E: Corrupted archive
E: Prior errors apply to /var/cache/apt/archives/libncurses5_5.9+20140913-1+deb8u2_armhf.deb
fatal: unable to read tree ecb31bff091888105076334ab0bd08fa3099f05b; assuming package has no files currently installed
Updating FireMotD available updates count ... es/libatomic1_4.9.2-10+deb8u1_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (2)
I don’t know what to do to avoid this error. I tried the installation for several times and I always get this error.
You might think “that’s well hidden!” but from the perspective of a developer, this (release information document) is the one and only place to give detailed informations. Why repeating informations over and over again, when you can simply set a link to it?
I don’t want to be too hard on the good people here since I really appreciate everything they do but I do think the upgrade instructions could be improved to avoid the difficulty I (and others) have encountered.
The upgrade instructions are:
If you are working with an openHABian setup, the upgrade is quite easy. Regardless of if you are currently using the openHAB 2.1 stable release or one of the latest 2.2 SNAPSHOT builds, switching to openHAB 2.2.0 stable is done in just a few steps:
Connect to the SSH command line and execute: sudo openhabian-config
Select the "Update" option
Wait for the openHABian update to finish, reenter the openHABian configuration tool
Select the "openHAB 2.2.0 stable" option
It would be good to include instructions here to NOT accept the default reply to the messages which appear during the upgrade for certain files. The default option keeps the old configuration and this is not the correct response for some of the files. (It would be useful to know which files should use the old configuration and which the new.)
The “Breaking Changes” section talks about what to do if you have made changes to the configuration file but should also include the above advice about upgrading to NOT accept the default response to that file which is to keep the old file. It should instruct to use the new file.
Again, I really appreciate all of the effort everyone has put into this project and my intention is to improve it, not criticize.
See /etc/fstab. The first column is the real location. The second is a directory loopback mount of the same dir to allow for Samba to easily share it (you can remove it from /etc/fstab if you don’t want it, also IIRC it’s a reversible config option in openHABian). So no, you do not want to move /srv/.
I have a NAS, too, and chose to mount logs (var/log/openhab2) and /var/lib/openhab2 (to contain persistence data etc). I chose to however NOT mount /etc/openhab2 so in case of trouble with the NAS or connection openhab still has access to the config.
Thank you @mstormi for this detailed information and for sharing your experience about using a NAS.
Before my update to openhabian, the entire (manual) openhab installation was located on a mounted nfs folder. But the setup is completely different now. I think I will now also keep everything on the sd card and make regular backups instead (maybe even executed by rules via the exec binding).
I’d still strongly suggest to put logs and persistence data on the NAS mount. They account for the vast majority of writes, and once you move these, you’ll be ‘reasonably’ safe from SD card corruption.
You’ll still have to do backups, of course. Check out the Amanda backup system install option in openHABian.