Are you signed in with an account which has a L9 license?
גַּם־חֹשֶׁךְ֮ לֹֽא־יַחְשִׁ֪יךְ מִ֫מֶּ֥ךָ וְ֭לַיְלָה כַּיּ֣וֹם יָאִ֑יר כַּ֝חֲשֵׁיכָ֗ה כָּאוֹרָֽה
yes sure.
I've switched to VirtualBox for now, until Logos 9 works on Linux. I am surprised how performant it works.
Logos 9 installs using install_AppImageWine_and_Logos.sh script.
install_AppImageWine_and_Logos.sh
When Logos 9 starts it does not run long. Attached is the backtrace from Wine.
Thanks for all the work the Linux team is doing.
(Lubuntu 20.04)
1447.Wine-20201027-backtrace.txt
The terminal output is usually much more helpful than the backtrace. If you can attach the terminal output that could help. Thanks.
6330.TerminalOutputLogosWine.txt
John Goodman: The terminal output is usually much more helpful than the backtrace. If you can attach the terminal output that could help. Thanks.
John:
Please find attached the terminal output which occurs shortly after Logos 9 starts up. (Lubuntu 20.04.01 LTS).
Thanks again for all the work you Daniel, Rik and others are doing with Linux and Logos.
Indexing is running after a large update and it doesn't seem to finish. I've tried several times to rebuild via ./Logos.sh removeAllIndex followed by 'indexing' It is running but I see the attached error message. I see it if I start Logos.sh and it kicks off indexing or if I run indexing directly. Is this a normal error message? Anything else I should try?
That's exactly what I'm seeing, Rob.
I am in the same position as Rob and Nick. Indexer runs, but does not complete.
I also have the clipboard issue discussed earlier. When I run "sudo ./Logos.sh wine64 regedit" I get:
======= Running wine64 only: =======wine: '/home/USER/LogosBible_Linux_P/data/wine64_bottle' is not owned by youwineserver: /home/USER/LogosBible_Linux_P/data/wine64_bottle is not owned by you
Al Graham: Logos 9 installs using install_AppImageWine_and_Logos.sh script. When Logos 9 starts it does not run long. Attached is the backtrace from Wine. Thanks for all the work the Linux team is doing. (Lubuntu 20.04) 1447.Wine-20201027-backtrace.txt
You are being quite adventurous here. Using your native, old, wine-5.0 (vanilla), without any patches (nor the staging set), and still trying to do the installation using install_AppImageWine_and_Logos.sh.If the goal isn't the adventure, and you just want it to work, then install using the script fast_install_AppImageWine_and_Logos.sh and select the option with the AppImage.
Rob Perry: Indexing is running after a large update and it doesn't seem to finish. I've tried several times to rebuild via ./Logos.sh removeAllIndex followed by 'indexing' It is running but I see the attached error message. I see it if I start Logos.sh and it kicks off indexing or if I run indexing directly. Is this a normal error message? Anything else I should try?
This message is quite normal. And in fact at the end of the index, it seems that the LogosBible index stopped for good (in my case it was 51%). You can see this through the CPU usage by the index process. But after closing and reopening, the index was ready and working. At least that's what happened here. But we don't have much guarantee due to the recent changes.
Daniel:
Thanks for your help.
Attached is the terminal output when I use fast_install_AppImageWine_and_Logos.sh.
2110.Logos Install Terminal Output.txt
Al Graham: Daniel: Thanks for your help. Attached is the terminal output when I use fast_install_AppImageWine_and_Logos.sh. ...
...
You are getting the error message:
err:seh:segv_handler_early Got unexpected trap 6 during process initialization
This kind of error normally happens when using liveUSB and WINE cannot write to the USB, or when using liveISO in RAM and you don't have enough RAM to write all the data. But that doesn't seem to be the case here.
I saw from your previous log that you are using Ubuntu, but I don't know which version. Perhaps some incompatibility with glibc (one Ubuntu update maybe can solve it).A good try would be to install wine-staging-5.11 from winehq.org:wiki.winehq.org/Ubuntu
using something like (you can change the "bionic" to your version):sudo apt-get install winehq-staging=5.11~bionic wine-staging=5.11~bionic wine-staging-amd64=5.11~bionic wine-staging-i386=5.11~bionic
then try using the option with native WINE on fast_install_AppImageWine_and_Logos.sh
This will ensure better compatibility with glibc.
I would like to make one AppImage with all dependencies for 64 bits (including glibc), as I had done for 32 bits, but there are some technical impossibilities, like the double glibc combo for WINE WoW64 (and now a new bug too), that has been holding me back for quite a while. For only then, we could have more guarantee that all the installations would behave in the same way. Without me having to say that it works very well on the test server using Ubuntu bionic (and on my local machine using Gentoo Linux), as you can see here: github.com/ferion11/LogosLinuxInstallTests/releases/download/v2.20/videoa.mp4But for now, we will have to live with the peculiarities of each Linux distribution and its different versions too.
I'm getting the following error during a fresh install on Ubuntu 20.10. I have installed on this OS before without errors, but I see that the fast_install script was updated 2 days ago.
"./fast_install_AppImageWine_and_Logos.sh"
Returns:./fast_install_AppImageWine_and_Logos.sh: line 6: syntax error near unexpected token `newline'./fast_install_AppImageWine_and_Logos.sh: line 6: `<!DOCTYPE html>'
Any suggestions are much appreciated.
Purist: I'm getting the following error during a fresh install on Ubuntu 20.10. I have installed on this OS before without errors, but I see that the fast_install script was updated 2 days ago. "./fast_install_AppImageWine_and_Logos.sh" Returns:./fast_install_AppImageWine_and_Logos.sh: line 6: syntax error near unexpected token `newline'./fast_install_AppImageWine_and_Logos.sh: line 6: `<!DOCTYPE html>' Any suggestions are much appreciated.
You downloaded the wrong file.We can easily be fooled with the "blob" version (made to be used only by the web browser) instead of the "raw" version (the real file) in the URL. They are generally similar in size and have the same name too, but the blob format is html, and the raw, in this case it would be a bash script.The raw link for the v2.20 is:https://github.com/ferion11/LogosLinuxInstaller/releases/download/v2.20/fast_install_AppImageWine_and_Logos.sh
Daniel Ribeiro da Silva:The raw link for the v2.20 is:https://github.com/ferion11/LogosLinuxInstaller/releases/download/v2.20/fast_install_AppImageWine_and_Logos.sh
That runs. Thanks.
For me the script (v2.20 fast AppImage) works very well on Ubuntu 20.10. I only changed the LOGOS version number in the script to 9.0.0.0181 before I ran it.
Thanks a lot for the good work.
Hello everyone,
I've updated the wasta-logos-setup process to use 32-bit wine 5.20-staging with the latest Logos 8 32-bit installer, 8.17.0.0014. With the wine updates and Logos updates it seems to run really well, with it only taking approximately 10-12 minutes to do a clean install from scratch (to install .NET 4.8, run the Logos installer, etc). Also, the Logos Indexer seems to be responsive and perform decently well (certainly much better than with older versions of Logos 8).
In summary, for those taking the conservative route waiting for 64-bit wine to be more stable, it seems like a good option to update to this "last of the 32-bit installers". I have re-organized the wasta packages, placing things in a "Wasta-Wine" Ubuntu PPA rather than the previous "Wasta Logos" PPA. The documentation on getting it setup and installed is on the Logos 8 Wine Installation Google Doc
If you are on the older wasta-logos-setup and everything is running well you may not want to update. If you do update, please save your Data, Documents, and Users directories from your current install so you can restore them later. Likely the updated Logos version may require some additional resource updates, but you may save some bandwidth by saving and restoring these folders. This is explained in the above guide.
Rik
Rik Shaw:for those taking the conservative route waiting for 64-bit wine to be more stable, it seems like a good option to update to this "last of the 32-bit installers
I appreciate this, Rik. I am currently on Logos 9 64-bit AppImage, with no indexing or search features working. I'd love to revert, but I wonder how we can keep Logos 8 from updating to Logos 9 from within the app itself. Is there a "Do Not Update" setting somewhere?
Also, do you know if those of us with version 9 licenses and features activated can go back to v.8?
While following the new wasta instructions provided by Rik, nothing happens when I run "wasta [Logos] Setup" from the Main Menu.
When I run "sudo wasta-logos-setup" in Terminal on Ubuntu 20.10 I see:
wasta-logos-setup started as root user.No processing done. Exiting....
That's funny. I just ran it without "sudo" and it started the installer. It proceeds until I say yes to corefonts, then hangs:
------------------------------------------------------Running /opt/wasta-wine/bin/wineserver -w. This will hang until all wine processes in prefix=/home/purist/.wine-logos terminate------------------------------------------------------
@purist: 32-bit will not upgrade to version 9 because there is no Logos 9 32-bit (we are going to be stuck on Logos 8 for 32-bit).
Yes, you can NOT use sudo to run wasta-logos-setup because it is a user level process. I should make the error message more clear to restart without sudo.
The wineserver message is "normal" but after some time it should continue....
Now, to the main problem you may see: what Ubuntu version are you on? I am having problems with 18.04 with wine 5.20-staging. It is crashing after activating Logos with this message:
RtlConvertToAutoInheritSecurityObject () at Z:\root\wine-git\dlls\ntdll\sec.c:17210x7bc565c9 RtlConvertToAutoInheritSecurityObject+0x199 [Z:\root\wine-git\dlls\ntdll\sec.c:1721] in ntdll: ret Unable to access file 'Z:\root\wine-git\dlls\ntdll\sec.c'
I put a note on the Google Doc saying if you are running 18.04 to WAIT until we sort out if this is possible to get around, but the error is coming from an update to wine 5.17+. I don't know why 20.04 isn't hit with the same crash, mysteries abound.
It may be that we need to roll back to the "safe" wine 4.18 for Ubuntu 18.04 users. Or it may mean if I re-compile wine with a reversion of that "fix" that causes the crash it will work. Using 4.18 means it will take longer to install, but it may be "stable". I'll report back after further testing.