Hi, the problem discribed above still persists. I'm currently running Solus in Legacy Boot mode and tried to install it in UEFI the other day. I get the same errors as before. Could you give me an update on what "more info" you need to analyze this issue?

Could we look into this soon(ish)? Unfortunatly I am not able to upgrade my kernel right now.

never checked. My guess is that the problem is somewhere in CLR-Boot-Manager in connection with the Acer EFI Firmware. AFAIK clr-boot-manager is not used in any other distro.
If someone from the core team needs me to test it with another distro, I will, but right now I don't think that it would be helping. But still I appreciate your efforts Alex.

I'm sorry if it was not clear until now: This happens to me after every new installation. I tried it twice now. Once with 4.0 Fortitude and another time with 3.9999 (first time boot: OK; after sudo eopkg up: not working)

Correct me if I'm wrong, but if

sudo clr-boot-manager update

gives me another bus error after formatting my EFI partition, i won't be able to boot, or am I missing something?

I'm kinda lost with your Suggestion, i mean, if the Boot Manager wont Update after formatting, i lost my Installation iirc. Only the root should be crypted as i followed the normal solus install Routine.

Hi @ZVNexus, I did as advised in the tutorial (+ decrypting my drive before mounting of course).

Hi, Bryan thank you for looking into this.
├── [ 4096] EFI
│   ├── [ 4096] Boot
│   │   └── [ 87642] BOOTX64.EFI
│   ├── [ 4096] com.solus-project
│   │   ├── [ 27453855] initrd-com.solus-project.current.4.20.16-112
│   │   ├── [ 27455992] initrd-com.solus-project.current.5.0.5-113
│   │   ├── [ 25279846] initrd-com.solus-project.lts.4.9.166-128
│   │   ├── [ 10355872] kernel-com.solus-project.current.4.20.16-112
│   │   ├── [ 10433696] kernel-com.solus-project.current.5.0.5-113
│   │   └── [ 7914592] kernel-com.solus-project.lts.4.9.166-128
│   └── [ 4096] systemd
│   └── [ 87642] systemd-bootx64.efi
└── [ 4096] loader
├── [ 4096] entries
│   ├── [ 464] Solus-current-4.20.16-112.conf
│   ├── [ 460] Solus-current-5.0.5-113.conf
│   └── [ 374] Solus-lts-4.9.166-128.conf
└── [ 32] loader.conf

thank you for your recommendation. Sadly I can't seem to find any oddity in the output:

changed license to meet SPDX standard

have you tried geany?

Sure. No problem, it was my mistake anyway.

is this still WIP? Because i got a working package.yml for version 0.3.11 here.
I started it because you didn't claim the task.

re-initialized repository

Hey, sorry, I'm a bit slow today, what do you want me to do? Just create a new diff with "arc diff"?

changed order of dependencies, added icon and updated license

should we patch nbxmpp with the provided patch?

Hi @JoshStrobl could we speak about the task I created after I realized that something doesn't work while adding servers T6317?

On then that's cool we can just cherry-pick the commit and apply the patch.

Could you please provide the link where you saw that an error was seemingly fixed by the gajim devs before the release ?

after my diffusion mess yesterday (sorry...) i was about to change the things you told me to.
After i did that, I found out about the problems you had with the Update to 1.0.X (https://dev.solus-project.com/feed/6545371174190833720/).
I looked into it a bit and it seems like an error that was seemingly fixed by the gajim devs before the release. After a bit of more digging I found out, there are some non ascii characters in our /etc/ssl/certs/*, that nbxmpp does not like

did what kyrios123 said.

@JoshStrobl. sorry. won't do it again. I promise.

We got a package request task already for Robomongo T1188

Could you please check the suggested solution on the blender Task50961 https://developer.blender.org/T50961 ?

correct me if i'm wrong, but isn't this a duplicate of T5251?