DietPi-Software | Mosquitto unresolved dependency. RPi3

Created on 15 Dec 2017  ·  24Comments  ·  Source: MichaIng/DietPi

Creating a bug report/issue:

Mosquitto fails to install fromDietPi-Software because of unresolved dependency of libwebsockets3.

Required Information:

  • DietPi Version | cat /DietPi/dietpi/.version?
    159
  • SBC Device (EG: RPi 3)?
    RPi 3
  • Power supply used (EG: 5v 1A RAVpower)?
  • SD card used (EG: Sandisk ultra)?
    Transcend UHS-I 16 Gb
  • Distro (EG: Jessie) | uname -a?
    Linux DietPi 4.9.62-v7+ #2 SMP Fri Nov 17 23:52:26 GMT 2017 armv7l GNU/Linux

    Additional Information (if applicable):

  • Software title?
    Mosquitto

  • Can this issue be replicated on a fresh installation of DietPi?
    Yes

Expected behaviour:

Actual behaviour:

Steps to reproduce:

Did you submit a dietpi-bugreport?


No

Extra details:


Manual installing libwebsoccket3:
wget http://ftp.nz.debian.org/debian/pool/main/libw/libwebsockets/libwebsockets3_1.2.2-1_armhf.deb
dpkg -i libwebsockets3_1.2.2-1_armhf.deb
apt-get install mosquitto

Bug Debian Stretch

All 24 comments

@yuret

Thanks for the report 👍 , i'll try to replicate.

Notes:

 mosquitto : Depends: libssl1.0.0 (>= 1.0.1) but it is not installable
             Depends: libwebsockets3 (>= 1.2) but it is not installable
  • Appears libwebsockets3 no longer available in Stretch, we'll need to "jimmy riddle" package download/install: https://packages.debian.org/jessie/libwebsockets3
  • 🈯️ INSTALL_URL_ADDRESS="http://repo.mosquitto.org/debian/mosquitto-$DISTRO_NAME.list". Repo is set but lacks libwebsockets3 aswell

Quick fix for now, we'll pull in required packages from our webserver.
I count 3 libssl1.0.0 depends on stretch so far. We may need to rethink it, or, create a software/global install for it.

@yuret

[Ok] mosquitto active (running) since Sat 2017-12-16 07:34:47 GMT; 1min 21s ago

Will be fixed for v160, in the mean time, you can fix install with following commands:

wget http://dietpi.com/downloads/binaries/all/libwebsockets3_1.2.2-1_armhf.deb
wget http://dietpi.com/downloads/binaries/all/libssl1.0.0_1.0.1t-1+deb8u7_armhf.deb
dpkg -i lib*.deb
rm lib*.deb

dietpi-software install 123

Reference https://github.com/eclipse/mosquitto/issues/529#issuecomment-324885355

Completed.

Hi Fourdee, It installs fine but does not seem to run on Pi Zero W.

Dec 16 14:28:43 BPS systemd[1]: mosquitto.service: Failed with result 'signal'.
Dec 16 14:28:43 BPS systemd[1]: mosquitto.service: Service hold-off time over, scheduling restart.
Dec 16 14:28:43 BPS systemd[1]: Stopped Mosquitto MQTT Broker.
Dec 16 14:28:43 BPS systemd[1]: Started Mosquitto MQTT Broker.

@9H5G

Thanks, i'll try to replicate on my RPi Zero.

Notes:

  • ARMv7 binary by the looks of it
root@DietPi:~# /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf
Illegal instruction

Reference https://github.com/home-assistant/hassbian-scripts/issues/75

@9H5G

Appears to be a known issue with the Mosquito repo at this time, lacking ARMv6 binary and Jessie deps in use on the Mosq Stretch repo:
https://github.com/Fourdee/DietPi/issues/1306#issuecomment-352229271

We'll need to wait for a fix from their end.

The only thing I can suggest is, if this worked on Jessie, try the Jessie image (which we still support):

http://dietpi.com/downloads/images/DietPi_RPi-armv6-(Jessie).7z

I'll re-mark this as closed. Please re-open if required.

Thanks Dan. I tries the Jesse image yesterday but on intallation, it updates to 159 and we have the same problem. How do I 'hold' the installation of upgrades on first boot at a particular level? Thanks

@9H5G

Thanks Dan. I tries the Jesse image yesterday but on intallation, it updates to 159 and we have the same problem. How do I 'hold' the installation of upgrades on first boot at a particular level? Thanks

If it doesn't work on Jessie (Illegal instruction), this confirms the issue is with their repo, and the most likely use of ARMv7 binary only, which will not work with ARMv6 (RPi Zero).
Theres nothing we can do our end about that currently, as our installations are installed on demand and relies on the state of the mosq repo during that time.

The only solution for now is to find a ARMv6 binary of mosq (or possibly compile), or, wait for the repo maintainers to resolve the issue.

@Fourdee Dan, we've still got version mismatch problems here. I hit this when trying out a test install of your Stretch image. I tried your workaround based on a wget from http://dietpi.com/downloads/binaries/all/ but this still barfs on a

E: Failed to fetch http://repo.mosquitto.org/debian/pool/main/m/mosquitto/mosquitto_1.4.12-0mosquitto1_armhf.deb  404  Not Found [IP: 85.119.83.194 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
 [Failed] The apt cache may be corrupt, apt mirror offline, or you have held broken packages. DietPi-Software will now exit.

Looking at the repo the current version is 1.4.14; doing a showpkg on the the mosquitto package lists its dependencies on 1.4.12 hence the error message.

So back to Jessie for me :disappointed:

@TerryE

Thanks for the report 👍

Confirmed, appears to be an issue with the repo itself. We'll need to wait for the mosq repo maintainers to resolve the header/links.

Ok, seems repo wont be fixed any time soon. I'll reopen and see if we can create a workaround fix (eg: host deb on dietpi.com)

Hosting mosquitto_1.4.14-0mosquitto1_nows1_armhf.deb on dietpi.com, no longer using the mosq repo.
Tested installs for:

  • 🈯️ Odroid C2 Jessie
  • 🈯️ RPi 3 Stretch

This issue still appears to show the same problem on armv6l (Pi Zero W) on the latest version of DietPi.

uname -a:
Linux DietPi 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l GNU/Linux

cat /DietPi/dietpi/.version
6 1

dpkg -s mosquitto:

Package: mosquitto
Status: install ok installed
Priority: optional
Section: net
Installed-Size: 331
Maintainer: Roger A. Light <[email protected]>
Architecture: armhf
Multi-Arch: foreign
Version: 1.4.14-0mosquitto~nows1
Depends: adduser (>= 3.10), libuuid1 (>= 2.16), lsb-base (>= 4.1+Debian3), libc6 (>= 2.13-28), libssl1.0.0 (>= 1.0.1), libwrap0 (>= 7.6-4~)
Suggests: apparmor
--- snip ----

systemctl status mosquitto:

● mosquitto.service - LSB: mosquitto MQTT v3.1 message broker
   Loaded: loaded (/etc/init.d/mosquitto; generated; vendor preset: enabled)
   Active: active (exited) since Fri 2018-02-16 04:17:40 GMT; 3h 58min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1258 ExecStart=/etc/init.d/mosquitto start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/mosquitto.service

Feb 16 04:17:39 DietPi systemd[1]: Starting LSB: mosquitto MQTT v3.1 message broker...
Feb 16 04:17:40 DietPi mosquitto[1258]: Starting network daemon:: mosquitto.
Feb 16 04:17:40 DietPi systemd[1]: Started LSB: mosquitto MQTT v3.1 message broker.

That looks fine so far but any command results in Illegal instruction:
root@DietPi:/etc/mosquitto# mosquitto -v
Illegal instruction

Also (probably) helpful, there is this weird exited status when i call dietpi-services status:
[ OK ] mosquitto active (exited) since Fri 2018-02-16 04:17:40 GMT; 4h 8min ago

@narfel

Thanks for the report 👍

It appears the only available armhf binary is compiled with ARMv7 instruction set/features. Lacking the backwards support for ARMv6 (Pi 0/1):
http://repo.mosquitto.org/debian/pool/main/m/mosquitto/

mosquito available in RPi repos.

Or we'll need to compile it for ARMv6:
https://github.com/eclipse/mosquitto

Leave it with me.

ARMv6 RPi repo:

root@DietPi:~# mosquitto -v
1518785890: mosquitto version 1.4.10 (build date Mon, 29 May 2017 13:43:29 +0100) starting

Outdated by our current 1.4.14 .deb install

@narfel

Fixed for v6.2 on ARMv6, will be released end of this week:

root@DietPi:~# mosquitto -v
1518791022: mosquitto version 1.4.14 (build date Tue, 26 Dec 2017 22:03:57 +0000) starting
1518791022: Using default config.
1518791022: Opening ipv4 listen socket on port 1883.
1518791022: Opening ipv6 listen socket on port 1883.
^C1518791023: mosquitto version 1.4.14 terminating

Completed.

Update for 6.2: Now it works like a charm. One little thing, though. I had to stop and remove mosquitto via dietpi-software and reinstall to make this working after upgrading to 6.2 to finally getting rid of "Illegal instruction".

root@DietPi:~# mosquitto -v
1519033829: mosquitto version 1.4.14 (build date Tue, 26 Dec 2017 22:03:57 +0000) starting
1519033829: Using default config.
1519033829: Opening ipv4 listen socket on port 1883.
1519033829: Opening ipv6 listen socket on port 1883.

@Fourdee I'm not sure if this is this issue again, but I think it may be. I'm working through installing this on a Rock64 using the latest 6.8. I just noticed upon trying a second time, that there are unmet dependency errors coming up while trying to install. The odd part is, in checking the dependencies, they're all met. I backed out the install, removed the leftover files, and then just did an apt install mosquito and it completed with no issues.

I believe there WAS an issue in the past with the default? Or perhaps this hosted package was only intended for certain versions? In this case it seems the standard OS based install worked fine, while the package provided was not working.

Obviously this "workaround" works - I just like to be able to ensure everything is managed by the DietPi system, so it would be preferential to have DietPi know it has mosquitto installed so in processing other requests it can properly handle/control the service.

Relevant logs:

[  OK  ] DietPi-Software | Connection test: http://dietpi.com/downloads/binaries/all/mosquitto_1.4.14-0mosquitto1_nows1_armhf.deb
--2018-05-14 21:21:24--  http://dietpi.com/downloads/binaries/all/mosquitto_1.4.14-0mosquitto1_nows1_armhf.deb
Resolving dietpi.com (dietpi.com)... 185.101.93.93
Connecting to dietpi.com (dietpi.com)|185.101.93.93|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://dietpi.com/downloads/binaries/all/mosquitto_1.4.14-0mosquitto1_nows1_armhf.deb [following]
--2018-05-14 21:21:24--  https://dietpi.com/downloads/binaries/all/mosquitto_1.4.14-0mosquitto1_nows1_armhf.deb
Connecting to dietpi.com (dietpi.com)|185.101.93.93|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 138678 (135K) [application/x-debian-package]
Saving to: ‘package.deb’

package.deb                                                 100%[=========================================================================================================================================>] 135.43K   442KB/s    in 0.3s    

2018-05-14 21:21:25 (442 KB/s) - ‘package.deb’ saved [138678/138678]

Selecting previously unselected package mosquitto:armhf.
(Reading database ... 78884 files and directories currently installed.)
Preparing to unpack package.deb ...
Unpacking mosquitto:armhf (1.4.14-0mosquitto1~nows1) ...
dpkg: dependency problems prevent configuration of mosquitto:armhf:
 mosquitto:armhf depends on libuuid1 (>= 2.16).
 mosquitto:armhf depends on libc6 (>= 2.13-28).
 mosquitto:armhf depends on libssl1.0.0 (>= 1.0.1).
 mosquitto:armhf depends on libwrap0 (>= 7.6-4~).

dpkg: error processing package mosquitto:armhf (--install):
 dependency problems - leaving unconfigured
Processing triggers for systemd (232-25+deb9u3) ...
Errors were encountered while processing:
 mosquitto:armhf
[  OK  ] DietPi-Software | APT fix, please wait...
Reading package lists...

@1activegeek
We chose to offer a self hosted package, as especially the Debian APT repo version on Jessie it quite outdated: https://packages.debian.org/de/jessie/mosquitto

  • 1.4.14 vs. 1.3.4 (Jessie) / 1.4.10 (Stretch)

libssl1.0.0 should be installed via dietpi-software as well as a separate pre-req before the mosquitto installation starts. Did this went fine without errors?

The dpkg dependency error you face is expected. Maybe we have to hide those logs, to not confuse users. We let dpkg run into these error to allow apt-get -f install install all needed dependencies automatically: [ OK ] DietPi-Software | APT fix, please wait...
Please check if this went fine through then.

This is a ugly (output wise) but practically best working solution for manually installing .deb packages:

  • APT installs dependencies by itself, but dpkg doesn't.
  • As dependencies of packages can change, it is a huge maintenance task to keep track and update the dep list for all our software titles, especially since also the underlying system differs and changes.
  • But APT handles and automatically solves dependency errors that occurred on the dpkg level, thus as long as all dependencies are available within the APT repo (all besides libssl1.0.0 on Stretch and above), we can leave this to APT just the same as we would install the main package from APT repo.
  • This also has some benefit for package clean-up: The automatically installed packages are marked as this and as fast as all dependants are removed, the dependencies can be apt-get autoremoved as well, leaving a cleaner system without a growing amount of obsolete library and dependency packages.

@MichaIng - I probably should have mentioned that I wasn't just including the logs as they looked erroneous, the install was not successful either. I was left with some odd behavior if I left it as "installed". Specifically the service was not registered or available in the system, the mosquito application was not registered to the system, and the actual mosquito folder had odd naming - something like the config file was labeled as mosquitto.conf.dpkg.new. I found the "attempted" service file in init.d I believe with a similar unexpected extension dpkg.new. So this was not successful, I just took note of that specific set of logs that look erroneous in the install process. The logs following outlined the removal of the app, but obviously that didn't fully take properly as it had leftover components.

The only main thing I will say I can tell in the difference of installs at the moment, is that it attempted to install an armhf package it would appear, while installing manually with apt provided an arm64 based install. I'm not an expert here with differences in that nature, but my install worked with this manually while it failed attempting to use the DP install method.

Unfortunately this is my home automation system that relies on mqtt functioning, so I'm not able to test running through this again (I'd be dead if I turn off voice control of the home! 😛 ) but I'm happy to help if there are other logs of any sort that I can provide.

Was this page helpful?
0 / 5 - 0 ratings