And now the app is broken after latest Manjaro Pahvlo update #1531
Comments
|
Same problem here |
Well for now there's a workaround that's just to downgrade GTK3.0... |
|
@neurodiverseEsoteric Here is roughly containerized version for latest To setup, extract archive into directory and at Tested with Void/Gentoo/Arch, but should work as long as you can use X server forwarding and docker daemon. |
Sounds a bit much for such a light application, and it assumes I know how to use docker and/or forward X servers |
It also doesn't work because of file permission errors |
|
It should work granted you are part of docker group and As for first comment, you are right about this solution being overkill for average user, but I would say it's still better than setting separate VM just for mail client, which would be the other feasible way right now (if you can't afford to have your whole system version frozen). As for X server forward/docker knowledge you don't need to do anything extra as long as you have installed docker and docker-compose packages - that was just a note for more exotic setups (and possible wayland issues, though I didn't get any testing). |
|
I think chmodding anything in /opt/ would break manjaro, especially with sudo |
|
I also probably need to delete the container to show you what happens with your original script(s), since I tried re-naming directories and usernames in those files in hopes that it would fix the permissions issues.... |
|
@namaenonaimumei Okay I didn't reinstall docker or the original container, but I did try to run a vanilla version of your code. Here's what happened: And that is with both Criptext-latest.AppImage and Criptext.AppImage (same file basically) copied to /opt/criptext with /opt/criptext having chmod a+rx permissions... |
To replicate your error criptext appimage path would have to be detected as a directory by docker (either on host or container side). To me it looks like when you first run To fix you could try (for vanilla version as provided) docker container ls -as # lists all built containers
docker rm $CONTAINER_ID # removes container, $CONTAINER_ID being CONTAINER ID from command above for NAME "criptext-react-latest"
# make sure `/opt/criptext/Criptext-latest.AppImage` is valid path to criptext appimage file here
./criptext_container # Start main script unpacked from criptext-container.tar.gz which will build and then launch new containerAlso note you can chmod single subdirectories you created yourself inside Sorry for late answer as well - somehow missed notification before. |
|
Thanks for getting back to me. I appear to have a ton of containers for reasons I can't recall or that which are completely unknown to me... |
|
Other than If you don't use any docker images/containers yourself, you can mass remove them and cleanup docker in one go with (this will remove all containers that aren't currently running and old/unused images) docker system pruneIf log you sent shows entire output of |
|
Sadly still NG: |
|
I can't really replicate this one, but it seems like - /opt/criptext/Criptext-latest.AppImage:/opt/criptext/Criptext.AppImage # adjust Criptext-latest.AppImage path by updating VAL1 in VAL1:VAL2If that's right and it still happens, there may be some issues with previous docker image cache or some mounting permissions inside container. Here are few things you could try. Try removing container again (as in cd /path/to/criptext_container/directory
docker compose build --no-cache # rebuilds from scratch in case of cache issues
./criptext_container # runs criptext (won't build twice)If it's still the same, first check whether this version makes a difference, again for first time run (remember to cd to separate dir you unpacked archive to) cd /path/to/criptext_container/directory
docker compose build --no-cache
./criptext_containerThis loosens permissions inside container itself, if it's some kind of silent mount failure. If above still does nothing try this version, applying same setup steps as above. |
|
Never mind, it was a VPN's fault |
|
Did any solution work after that or does it still error somewhere down the way - as mentioned, last solution should work if all the others would be to fail, unless docker itself is misconfigured in some way. Also don't change VAL2 inside - /home/user/.local/share/criptext/Criptext-latest.AppImage:/opt/criptext/Criptext.AppImageTry making it launch with default configs first though (if your container still fails build/launch). |
|
Okay, looked into accessing Docker and tried that and it shows that the dir/file /opt/Criptext/Criptext.AppImage DOES exist (can spew out the binary via |
Not really sure what you mean by this, but docker container works independently from system dependencies - that means you don't really have to worry about your system being "too minimalistic". As for requirements, to run these containers all you need is system capable of running docker daemon + working network + X11 server (wayland should work, but may not out of box) - from what I understand you are using manjaro, which is more than enough to satisfy these requirements, granted you installed docker through package manager (pamac/pacman). Other than that all dependencies should have been pulled already - just in case you can send output of
I don't know whether you just mistyped path in reply above, but remember most things in unix are case-sensitive (including paths, meaning That being said, did you already try last resort version (criptext-container_fix02.tar.gz), since that version - as long as you run it with steps written above - will download criptext binary directly inside container. I can't really tell for sure without seeing your exact system configuration, but from all logs/replies it seems you have issue with paths not being valid (on host, for container as long as you keep doing |
|
Sorry I was super drowsy when I wrote all that. So I guess the file was there in the container the whole time (why can't I browse docker containers in Dolphin?), and my adding anything to Manjaro's /opt directories didn't make any difference like you were saying. The problem is Ubuntu seems to be unable to executing AppImages, which is why I suspect that the container is lacking libraries and other system files that a full-fledged desktop ISO would have (I mean, it doesn't even have |
|
Just tried a different random appimage, and the same thing happened: The fact that the container has no internet connection while I'm using a VPN also reinforces my feeling that the Ubuntu OS in the container is too minimal an installation... |
AppImages - as opposed to flatpaks or snaps - don't require any additional dependencies or setup to run them. It not having basic gnu utils like Either way for attempt of troubleshoting all these, can you send file /bin/cat
file /opt/criptext/Criptext.AppImage
md5sum /lib64/ld-linux-x86-64.so.2
md5sum /opt/criptext/Criptext.AppImage
ls -al /opt/criptext/Also manjaro ships with ext4 by default, but in case you use btrfs is optional package
Since you meant base docker image, there are - but - it also has to be based on version release distribution that provides such images (so not ones considered rolling) and if distribution uses different package manager than apt (say fedora dnf), it would require you to rewrite all calls to apt inside |
|
My Manjaro is normal (ext4), but everyone in both the Arch and Majaro forums are constantly saying "Manjaro is not Arch," and I've been trying to suppress the fear that the differences might actually having something to do with this issue, but I don't know if I could have kept going without mentioning it for much longer... Anyway here is my output: The permissions on ep and Criptext.AppImage might be because I tried added |
It's the same analogy as Ubuntu not being Debian - while there are various customization steps preadded for user friendliness to those compared to their base (like slight kernel patches, using dedicated servers to provide packages and so on), it still uses (for most) packages same as arch repository, builds directly ones from AUR, main parts of system remain unchanged as well. To add on top of that that, docker is a virtualization software, which aims to make running software host agnostic - at least the software part of it. To rest you assured though, I tested with a separate clean VM using Manjaro KDE Plasma Minimal and there were no issues. # After running Manjaro installer with all defaults
sudo pacman -Syu docker docker-compose
systemctl enable docker.service
systemctl start docker.service
sudo usermod -a -G docker $USER
sudo reboot # to apply group permissions
# This is just deploying criptext-container_fix02.tar.gz version onto vm
mkdir ~/deploy-criptext
cd ~/deploy-criptext
wget 127.0.0.1:8080/shared/manjaro-docker/criptext-container_fix02.tar.gz
tar xf criptext-container_fix02.tar.gz --one-top-level
cd criptext-container_fix02
mkdir -p ~/.config/Criptext # This is just here in case ~/.config/Criptext doesn't exist (like in case of new machine) so docker doesn't create one as root
# ends here
./criptext-container # builds with no issues and launches criptext welcome window as expected
That's actually correct permissions set in Getting back to your issues, entire output on your side seems as expected (same sums, no architecture inconsistencies). For now, since I can't replicate that docker rm -f $(docker ps -a -q)
docker system prune --volumes -a -f
sudo pacman -Rsn docker docker-compose
rm -rf ~/.docker/
sudo rm -rf /etc/docker/
# should probably reboot
sudo pacman -S docker docker-compose
sudo systemctl enable docker.service
sudo systemctl start docker.service
sudo usermod -a -G docker $USER
# reboot to apply usermod changes |
|
If it's a botched docker setup it'll take a while for me to feel up to fixing it. However I do have a laptop I recently replaced the HDD and therefore have a fresh, clean Manjaro running on it, so maybe I'll try these steps there first... |
|
Whelp I had to reboot anyway because I discovered via genymotion/virtualbox that I didn't have virtualization enabled in the BIOS (which gave it a weird acronym so it would be easy for me to miss). So re-installing docker and adding my I didn't have a Now I need to reboot again since I made the group change. Hopefully this gets criptext-container fully working. Otherwise, I might just add the working version of |
|
Even after all that... |
That service doesn't need to be enabled (also d in these cases usually stands for daemon, e.g. systemd=system daemon).
I am pretty sure Docker requires virtualization enabled to run, so not really sure how it worked until now without it (unless you had to enable some additional virtualization features, since depending on your system configuration looks different)
This may work temporary, but it may break again on some different libraries next - in that case your best bet would be to get all dependencies version frozen - you can get around to that by using Arch archive for getting specific package versions and adding Granted, if possible it's safer to run apps like that at least partially separated from main system, which docker solution does (since otherwise you are effectively running outdated version of libraries directly on your system, when starting the program, which may have some vulnerabilities/exploits found already - not saying you have to worry about that, just a notice if you care about such things). As for main issue I don't have any other idea at the moment as for what could be causing this other than this being typically an error, when trying to run binaries with mismatched architecture, but as it's a pretty generic message it may be something entirely different in which case it's probably specific to your machine - if you try on your separate notebook (remember to create |
|
I followed all of the steps, |
|
If you get it working inside firejail - then yes. As for notebook, if it's really still the same file error - since I take you just installed fresh system on it - can you send me link to manjaro iso version you used, if it's any different than what I tested with (KDE minimal). I'll check again just in case some package provided in version you used could be causing that. |
|
|
This happens whenever I try to login by pin/recovery key/password:
The text was updated successfully, but these errors were encountered: