bug: AppImage Cert issue which causes model download failed

[zWhdmB5T]

Jan version

jan-linux-x86_64-0.5.14.AppImage and jan-beta-linux-x86_64-0.5.15-rc4-beta.AppImage

Describe the Bug

My System:

• openSUSE Leap 15.6 (latest patch level)
• jan-linux-x86_64-0.5.14.AppImage
• jan-beta-linux-x86_64-0.5.15-rc4-beta.AppImage

Bug:

This bug applies to both stated releases. I run the AppImages without sudo (just usual user). It is: download of models always fails (whichever model I choose…) I get (e.g.) Download Failed Model llama3.2-1b-instruct download failed: undefined An other AppImage application does have internet access and uses it.

Steps to Reproduce

No response

Screenshots / Logs

No response

What is your OS?

• [ ] MacOS
• [ ] Windows
• [x] Linux

[ux-han]

@zWhdmB5T Can you send us app logs to investigate, here's how to get app logs: https://jan.ai/docs/troubleshooting#how-to-get-error-logs

[zWhdmB5T]

Dear @imtuyethan

here you are:

jan-linux-x86_64-0.5.14.AppImage

app.log cortex.log

jan-beta-linux-x86_64-0.5.15-rc5-beta.AppImage

cortex.log

Please note

• update from jan-beta-linux-x86_64-0.5.15-rc4-beta.AppImage to jan-beta-linux-x86_64-0.5.15-rc5-beta.AppImage recently
• This does not work on current jan-beta-linux-x86_64-0.5.15-rc5-beta.AppImage :

@zWhdmB5T Can you send us app logs to investigate, here's how to get app logs: https://jan.ai/docs/troubleshooting#how-to-get-error-logs

• I just have the cortex.log — but no app.log on current jan-beta-linux-x86_64-0.5.15-rc5-beta.AppImage .
• In the cortex.log it says something like Error: Problem with the SSL CA cert (path? access rights?) — but I currently don't have network (internet) issues on my system generally (many applications like Mozilla Firefox and Thunderbird, NTP service, running system updates (zypper on openSUSE) or FlatPak updates or Snap updates do work!) and I also have another AppImage which uses network (internet) and does.

[tleveille]

Hi,

I have the same problem on current stable 0.5.14 on Linux using the appimage. Not that I am running it on an immutable bluefin distro.

However I have a different error than the user above in cortex.log, it says Out of memory for the download_service:

20250206 08:32:19.007318 UTC 7189 ERROR Transfer failed for URL: https://huggingface.co/bartowski/Llama-3.2-1B-Instruct-GGUF/resolve/main/Llama-3.2-1B-Instruct-Q8_0.gguf Error: Out of memory - download_service.cc:33

However I have plenty of memory with only 4GB of use out of 32GB.

❯ free
               total        used        free      shared  buff/cache   available
Mem:        32533020     4075408    23573368      809040     6126512    28457612
Swap:        8388604           0     8388604

On beta 0.5.15 I get the same error at startup and then when I click to show all models I have "Not enough Ram" flag on all models.

[tleveille]

I think you can ignore my comment above, I had that error because I was running the wrong image of bluefin and was missing the full cuda drivers.

[shadowcjm35]

Hello, i have the same problem. When i'm trying to download a model i have a popup with this message inside: Download Failed Model llama3.2-1b-instruct download failed: undefined

This my two files

app.log cortex.log

Jan version: jan-linux-x86_64-0.5.14.AppImage

[moraesmv]

I have a similar problem where I download models, and after a restart, the models are shown as not downloaded. when clicking to download again, it provides the message Download Failed please delete the model before downloading again.

System Windows.

app.log cortex.log

[zWhdmB5T]

I now use jan-beta-linux-x86_64-0.5.15-rc11-beta.AppImage as beta and I am still having this issue.

[zWhdmB5T]

@imtuyethan

Currently, I now use jan-linux-x86_64-0.5.15.AppImage … so the most recent and even a stable release.

For what I can see so far, this release does work properly and well for me — but this issue still persists! Help!

Do you need further info I should provide? When I know what you actually need, I can serve you.

[zWhdmB5T]

so, now providing logs for jan-linux-x86_64-0.5.15.AppImage:

1. first install of this release jan-linux-x86_64-0.5.15.AppImage, it was a replace on the old stable jan-linux-x86_64-0.5.14.AppImage app.log cortex.log
2. second install of the same current stable, after a complete delete app.log cortex.log
3. third install of the same current stable, after a complete delete app.log cortex.log

[vithiri]

I've got the same issue on Fedora Silverblue (immutable, like in one of the previous posts).

Usually I will get the error message that the download failed, and the logs will show "out of memory". Sometimes the download will start without an error message, but the progress bar will be stuck at 0%. Sometimes (usually after 5 clicks) the download will actually succeed, and the model will download properly and can be used.

[zWhdmB5T]

@vithiri I am not fully sure if Fedora Silverblue may have its own issues on this ~~because it's a "hardened system" (with many specific security related settings)~~. I actually had Fedora secureblue in mind.

But this bug is obvious, any way.

I don't get Jan to work properly. I have used a few complete deletions and full re-installs of Jan: no improvement.

[vithiri]

@vithiri I am not fully sure if Fedora Silverblue may have its own issues on this because it's a "hardened system" (with many specific security related settings).

But this bug is obvious, any way.

I don't get Jan to work properly. I have used a few complete deletions and full re-installs of Jan: no improvement.

If anything it could be problematic that my /tmp from the default installation is only 7.8gb, if models are stored there at some point in the process.

For this bug I can confirm that I continue to be able to click exactly five times on the download button, on the fifth attempt the download will begin (and succeed).

[fcrozat]

The issue is related to misconfigured SSL CA certificates which are expected by the AppImage wrapping.

Recent distributions are storing SSL CA bundle in a different location than /etc/ssl/certs/ca-certificates.crt. It should be possible to override (see https://stackoverflow.com/questions/3160909/how-do-i-deal-with-certificates-using-curl-while-trying-to-access-an-https-url ) but it seems environment variables don't have any effect on AppImage

[zWhdmB5T]

@fcrozat

The issue is related to misconfigured SSL CA certificates which are expected by the AppImage wrapping.

Recent distributions are storing SSL CA bundle in a different location than /etc/ssl/certs/ca-certificates.crt.

gunnersson@tulicube:~> myls /var/lib/ca-certificates/
insgesamt 440K
drwxr-xr-x  4 root root 4,0K 27. Feb 18:26 ./
drwxr-xr-x 61 root root 4,0K 11. Dez 09:17 ../
dr-xr-xr-x  2 root root  24K 27. Feb 18:26 openssl/
dr-xr-xr-x  2 root root  20K 27. Feb 18:26 pem/
-r--r--r--  1 root root 218K 27. Feb 18:26 ca-bundle.pem
-r--r--r--  1 root root 162K 27. Feb 18:26 java-cacerts

Here are mine…

My entire system works properly — except for this application Jan. What do you mean by "misconfigured"? About "in a different location than": this is obviously the case here — was it your way often before?

To understand better: does AppImage, i.e. Jan, expect /etc/ssl/certs/ca-certificates.crt? Couldn't the maintainers set it to /var/lib/ca-certificates/ (or whatever recent distributions use)? — I remember a slightly similar problem with a totally different application: it expected a helper program on system, some proper paths have been included (coping some distributions) — some proper paths haven't (not coping some other distributions). I gave a note to the maintainer and there soon an update was out there.

[fcrozat]

@zWhdmB5T this is a deficiency of AppImage which doesn't shield enough the application from the underlying system. It means Jan AppImage should embed default CA and not rely on the system ones (or try the various alternatives path).

[zWhdmB5T]

@fcrozat Thank you for your expertise and your information!

[zWhdmB5T]

@david-menloai Can you, please, work on this. Thank you!

[zWhdmB5T]

@fcrozat Do you know if there is any work-around for this? (Something that I can apply at all and further more quite easily?)

[david-menloai]

hi @zWhdmB5T may I request your help to try it again on our latest build? https://github.com/menloresearch/jan/releases/tag/v0.5.16 we made some updates which may resolve your problem. let us know if the issue is gone 🤞

[zWhdmB5T]

Dear @david-menloai Thank you for your help!

No success on my side so far.

app.log cortex.log

[fcrozat]

it is still broken with 0.5.16

[david-menloai]

oh sorry guys, let us take a look at this issue

[zWhdmB5T]

@david-menloai Still broken on v0.5.17.

[r5r3]

I'm not using the AppImage, but I'm converting the deb-Package to an rpm-package. To make it work on AlmaLinux, I have to add a link: /etc/pki/tls/certs/ca-certificates.crt -> ca-bundle.crt

[zWhdmB5T]

Here on my openSUSE Leap (15.6):

/var/lib/ca-certificates # myls
total 440K
drwxr-xr-x  4 root root 4.0K May 29 01:32 ./
drwxr-xr-x 61 root root 4.0K Dec 11 09:17 ../
dr-xr-xr-x  2 root root  24K May 29 01:32 openssl/
dr-xr-xr-x  2 root root  20K May 29 01:32 pem/
-r--r--r--  1 root root 220K May 29 01:32 ca-bundle.pem
-r--r--r--  1 root root 163K May 29 01:32 java-cacerts

/etc/pki # myls
total 32K
drwxr-xr-x   6 root root 4.0K Mar  5 16:59 ./
drwxr-xr-x 140 root root  12K May 16 00:15 ../
drwxr-xr-x   2 root root 4.0K Jun  3  2024 fwupd/
drwxr-xr-x   2 root root 4.0K Jun  3  2024 fwupd-metadata/
drwxr-xr-x   2 root root 4.0K Mar 15 00:26 nssdb/
drwxr-xr-x   4 root root 4.0K Apr 17  2024 trust/

/etc/ca-certificates # myls
total 20K
drwxr-xr-x   3 root root 4.0K Apr 17  2024 ./
drwxr-xr-x 140 root root  12K May 16 00:15 ../
drwxr-xr-x   2 root root 4.0K Apr 17  2024 update.d/

/usr/lib/ca-certificates # myls
total 20K
drwxr-xr-x  3 root root 4.0K Apr 17  2024 ./
drwxr-xr-x 97 root root  12K May 16 00:15 ../
drwxr-xr-x  2 root root 4.0K Apr 27  2024 update.d/

[woiwoiwoiwoi]

I'm getting the same issue on openSUSE Tumbleweed using the AppImage. Is there a way to verify the issue really is with certs on my system or not related to #4951 or some other issue?

Is there a workaround?

[zWhdmB5T]

please, look at https://github.com/menloresearch/jan/issues/4582#issuecomment-2682355872

[woiwoiwoiwoi]

I tried #4582 and I can't get it to work. I'm trying it with 0.5.17, since 0.6.1 does not work on my system (see #5367). After launching Jan.ai I get a popup that an update is available. So some internet connection with correct certs is available. But I still can't download anything.

My system is open SUSE Tumbleweed and the correct path should be this, if I'm not mistaken:

/var/lib/ca-certificates> lw
total 384K
drwxr-xr-x 1 root root   70 Mai 29 08:46 .
drwxr-xr-x 1 root root  940 Jun  2 11:49 ..
-r--r--r-- 1 root root 220K Apr 28 14:09 ca-bundle.pem
-r--r--r-- 1 root root 163K Apr 28 14:09 java-cacerts
dr-xr-xr-x 1 root root  18K Mai 29 08:46 openssl
dr-xr-xr-x 1 root root  15K Apr 28 14:09 pem

That's the same path as your Leap system @zWhdmB5T. How did you get it to work?

[zWhdmB5T]

@woiwoiwoiwoi I am a bit confused… Who do you mean: me @zWhdmB5T or @r5r3 with https://github.com/menloresearch/jan/issues/4582#issuecomment-2897325819 ?

(I have 0.5.17 as recent working version, 0.6.1 does not work, and on 0.5.17 downloading models does not work for me and I haven't tried the tip mentioned above.)

[woiwoiwoiwoi]

@zWhdmB5T I did mean you since you referred me to that comment. So I thought you had applied it and it worked for you.

So do you download models manually or how do you use Jan.ai?