Problems and Solutions

Crash logs

Crash logs are generated during a system crash, also known as a GSOD (green screen of death). The log can give insight to the probable cause of the crash. If you want help with the content of the file, you can post it on our forum. The crash log file is named like in the example below:

enigma2_crash_3891289128.log

The location of the crash log file when there is a HDD (Harddisk) present

Normally the crash.log file is stored in the root of the HDD so in

/media/hdd

The location of the crash.log file without any HDD (Harddisk) present

Normally the crash log file is stored in the

/home/root

Debugging Enigma

If you want to debug and want to know what is happening in Enigma, you can start your receiver in debug mode with the following command:

root@<receiver>: init 4
root@<receiver>: ENIGMA_DEBUG_LVL=4 /usr/bin/enigma2.sh

To stop: Press CRTL-C. Enigma will halt. Then start enigma with:

root@<receiver>: init 3

Or reboot the receiver with:

root@<receiver>: reboot

Note: For debugging gstreamer with read actions stuff use: ENIGMA_DEBUG_LVL=4 GST_DEBUG=*soup*:6,*dvb*:6 enigma2

For easier reading (Less logging) use:

ENIGMA_DEBUG_LVL=4 GST_DEBUG=*soup*:4,*dvb*:4 enigma2

Writing debug log to a USB stick

If for some reason your receiver reboots your debug log might be gone. Then plugin a USB stick in your receiver and use the command below, which writes the debug log to and USB stick

ENIGMA_DEBUG_LVL=4 enigma2 | tee /media/usb/enigma.log

Mountmanager Problems

Here are some solutions when you run into problems with mounting\sharing a medium (HDD) in your network.

Older vs newer Kernel

When your box uses a kernel 3.x (Menu-Information-About) and you want to mount something that has a kernel 4.x your CIFS share might fail, even though you entered the data carefully, but there is a solution.

The solution is simple, you can try the following; If you make a mount with Mountmanager, change the "mount options" from "rw" to "rw, sec=ntlm", this will lower the security standard from ntlmv2 (default with kernel 4.x and up) to ntlm.

Now exit and re-mount or Reboot your box and if this was the cause, you can now access your share.

Older vs newer SMB Protocol

There is a similar issue regarding the version of the SMB protocol used.

There are several versions of the SMB protocol, v1, v2.0, v2.1 and v3. (see https://blogs.technet.microsoft.com/josebda/2013/10/02/windows-server-2012-r2-which-version-of-the-smb-protocol-smb-1-0-smb-2-0-smb-2-1-smb-3-0-or-smb-3-02-are-you-using/ for more in-depth information).

Recently, due to several security issues, an action has been ongoing to disable the unsafe SMBv1, not only in Windows, but also in NAS systems like Synology for example. Windows has the option to cycle through all available and allowed protocols when you want to connect to a share, so you as a user don't notice anything and don't know which protocol is used. But the Linux kernel driver doesn't. It connects using the version it has been programmed with, and if you as a user need a different version, you need to specify this in the mount options.

Up to kernel v4.13 (at the moment of writing all supported receivers), the default was SMBv1, after that, the default has been upgraded to SMBv3. So if your box has a kernel older than 4.13, and your "server" doesn't support SMBv1, you need to specify the version on the mount. Likewise, if your box runs 4.13 or higher, and your "server" doesn't support SMBv3, you also need to specify the version on the mount.

The solution is to change the SMB version used to mount, to do this in Mountmanager change the "mount options" from "rw" to "rw, vers=3.0" (or whatever version you want to mount). You might have to try a few, if you don't know which one your server supports, but always start with the highest version.

This is a good overview on this subject: https://www.happyassassin.net/2017/11/03/linux-kernel-4-13-and-smb-protocol-version-fun/

The same is true for the authentication mechanism. This used to be NTLM, but in Kernel 3.8 the default has changed to NTLMv2, as Windows no longer supports NTLM (also because of security issues). But depending on the version and configuration of Windows (especially Windows Server), you might need to specify an alternative mechanism on the commandline too.

Reset lost password

In case you have lost your box password or someone else has been so 'funny' to create a password without having informed you, there are several ways to solve this issue.

I assume that you still have access via Explorer with \\boxname or \\ipaddressbox. If not, then the only 'solution' to get access again is to flash your box which is actually not a solution.

1. Go to the map \etc where you find the file shadow.
2. If you owe another Enigma2 box then go to the map \etc and copy there that file 'shadow'.
3. Go to the box with the unknown password and paste the just copied file from the other box over your present version of shadow.

There is a second scenario to solve this.

1. Go to the map \etc where you also find the file passwd.
2. Select and edit the file passwd with right mouse button and select a proper editer. I use Notepad ++
3. In this file the line: root: x: 0: 0: root: / root: / bin / sh or something as root: EIfidfjeSAEFKEOlasdf5ewr3rWEW: 0: 0: root: / root: / bin / sh is the actual PW. The Password field is x or the encrypted string EIfidfjeSAEFKEOlasdf5ewr3rWEW
4. Delete the x or the string The line is now following: root :: 0: 0: root: / root: / bin / sh
5. Save / overwrite this file and exit Notepad ++.

Splash screen replacement

The splashscreen is written in a limited reserved space of flash. We believe that the splash screen is not intended to be image specific, it should just show the manufacturer and/or box type information. The dimensions and type of splash file supported by the bootloader, differ per brand, and possibly even per box. We advice to stay away from that, leave the splash screen to the bootloader, and the manufacturer.

If by some reason, let's say another image, has changed it, you can restore it to the one from the manufacturer. Do a search on the OpenPLi site using Google

splash screen site:openpli.org

USB memory sticks working or not

When you want to use an USB memory stick, lets say for flashing your box with OpenPLi, there is no way of telling your stick might work, it's trial and error! As the USB detection system in the bootloader of your receiver is very simple, there are 2 things to consider:

1. It has a short device detection time, which is as it should be, because a long device detection time could result in an annoying long booting procedure. This (short device detection) causes devices whose detection takes (too) long (usb3 devices, large sticks) not to be seen in time.
2. It takes the first device that is found and if you've connected multiple devices, chances are that it's not the device you want to use.

Generally speaking, small old USB sticks with less than 1Gb have a bigger change to work.