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?
Jul 28 2020
Jun 25 2019
Jun 18 2019
Could we look into this soon(ish)? Unfortunatly I am not able to upgrade my kernel right now.
May 7 2019
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.
May 6 2019
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?
May 4 2019
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.
May 3 2019
Hi @ZVNexus, I did as advised in the tutorial (+ decrypting my drive before mounting of course).
May 2 2019
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
Apr 24 2019
thank you for your recommendation. Sadly I can't seem to find any oddity in the output:
Apr 23 2019
Jun 10 2018
changed license to meet SPDX standard
Jun 9 2018
have you tried geany?
Jun 6 2018
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.
Jun 4 2018
Hey, sorry, I'm a bit slow today, what do you want me to do? Just create a new diff with "arc diff"?
May 28 2018
changed order of dependencies, added icon and updated license
May 26 2018
should we patch nbxmpp with the provided patch?
May 19 2018
May 3 2018
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.
May 2 2018
Apr 26 2018
@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 ?