Unable to boot encrypted box after stretch upgrade

Hello Yunohosters.

Today I rebooted my Yunohost box (olimex lime2) for the first time since the “stretch” upgrade some two weeks ago.

Unfortunately I can no longer access the decryption page (the one with the Capricorn) to unlock and boot the box.

Upon boot, I do see the box showing up in my router, let’s say with ip

With an attached monitor I also see the “healthy” u-boot messages before the screen goes into “blank-with-only-cursor-blinking” mode. This is a normal behaviour I also saw before the upgrade to “stretch”.

When I then try to access https:/// via Firefox (either 52.9.0 or 61.0) I get

Firefox can’t establish a connection to the server at

The site could be temporarily unavailable or too busy. ...

The expectation would have been that I get a “self-signed” certificate exception instead, which I then manually have to grant permission for to continue.

Likewise a curl command fails with

$ curl -k -L -v
* Rebuilt URL to:
*   Trying
* connect to port 443 failed: Connection refused
* Failed to connect to port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to port 443: Connection refused


  1. Has anybody tested to boot “stretch” upgrated encrypted box? Did it work?
  2. What has changed in stretch upgrade that might have broken internetcube decrypted boot process?
  3. How can we further debug the internetcube decrypted boot process? (for example, avoid the blank screen to see what’s going on, use serial console to see logging?)


  1. Is this a “modern” browser problem that is to strict on the self-signed certificate? --> does not seem to be the case, see answer/example with self-signed certificate below

Notice / Warning:

For the people who have an encrypted box …

  • … and are still on “jessie”: maybe you should wait with the upgrade to “stretch” …
  • … and are on “stretch”: maybe you should try not to reboot your box …

… until this issue is resolved.

Any help is highly appreciated.



1 Like

I tested self-signed certifcate using lighthttpd on my local machine.

With Firefox browser I get the expected “Add Exception” prompt.

With curl it also works:

$ curl -k -v
* Rebuilt URL to:
*   Trying
* Connected to ( port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=AU; ST=Some-State; O=Internet Widgits Pty Ltd
*  start date: Jul  8 17:58:42 2018 GMT
*  expire date: Jul  8 17:58:42 2019 GMT
*  issuer: C=AU; ST=Some-State; O=Internet Widgits Pty Ltd
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET / HTTP/1.1
> Host:
> User-Agent: curl/7.60.0
> Accept: */*
< HTTP/1.1 200 OK
< Content-Type: text/html
< Accept-Ranges: bytes
< ETag: "2793406362"
< Last-Modified: Sun, 08 Jul 2018 15:57:06 GMT
< Content-Length: 6
< Date: Sun, 08 Jul 2018 18:02:35 GMT
< Server: lighttpd/1.4.45
* Connection #0 to host left intact

So what could be the issue here?

I managed to get the verbose output of the kernel boot.
Looks like a kernel panic. Any ideas?


PS: uploading picture file to this forum failed multiple times.

I could NOT reproduce the kernel panic.

Kernel boot now halts with the following error:

suni7i-dwmac; 1c50000.ethernet eth0: fail to nit PTP.
IPv6: ADDRECONF(NETDEV_UP): eth0: link is not ready

My current kernel bootargs in adjusted boot.scr look like this:

setenv bootargs  ${bootargs} \
 hdmi.audio=EDID:0 \
 disp.screen0_output_mode=EDID:1280x720p60 \
 root=/dev/mapper/root \
 cryptopts=target=root,source=/dev/mmcblk0p2,cipher=aes-xts-plain64,size=256,hash=sha1 \
 rootwait \
 sunxi_ve_mem_reserve=0 \
 sunxi_g2d_mem_reserve=0 \
 sunxi_no_mali_mem_reservesunxi_fb_mem_reserve=0 \
 panic=10 \
 oglevel=8 \
 consoleblank=0 \

I now managed to boot the old kernel 3.16.0-6-armmp and my system is back online.

This brings some relief. :sweat_smile:

However, we should still continue to debug this issue and find a solution.

I wonder how many other Yunohosters are having this issue.

1 Like

A bug report has been filed: https://dev.yunohost.org/issues/1136

1 Like


I have the same issue since migration. How did you do to boot the kernel 3.16.0-6-armmp ?

Similar problem here:
1.1. Successfully install an encrypted brique internet
1.2. command-line upgrade to stretch
-> ping ok
-> ssh server offer (but I don’t have the required key)
-> no decryption unicorn (no web server)

2.1. Successfully install an encrypted brique internet
2.2. Web upgrade to stretch
-> ping ok
-> ssh server offer (but I don’t have the required key)
-> no decryption unicorn (no web server)

I’m interested please in:

  • a workaround to decrypt the box (from the network) after the faulty upgrade
  • an fix for the upgrade
  • testimonies of successful upgrades of encrypted boxes (brique internet or not)

I experienced the same issue a while ago, and because of it I’m still stuck on Yunohost 2.7. For installation I used an encrypted image from the internetcu.be project, but it looks like Yunohost itself does not support encrypted storage.

So I’m planning to re-install Yunohost at some point, without encrypted storage. Unless there are any workarounds available?