CrossOver Support - Community Forums

Hello,
I upgrade from 8.0.0. to 9.1.0 but the bottles don't get the ready status.

Regards

Bernd

Hi,

Before upgrading crossover, it is always advised that you backup
(cxarchive) your bottles prior to installing the upgrade, just in
case something like this goes wrong. I you have already done that
(with 8.0) then the solution is probably straightforward -- if you
have not done that, this will become rather bothersome....(and I'm
loath to advise you any further right now until I ascertain the exact
situation you're facing...ie; is there any crucial data in the existing
bottles that you wish to keep?)...

I would also be advisable to tell us which linux distro you are using.

Please post back with some more details regarding your distro and exact
situation regarding the contents of the existing bottles...

Cheers!

Hi,
thanks for your reply.
Yes, I have backups.
My distro is sidux which is Debian based. I use CrossOver Professional.

I'm not sure how to describe the contents of the bottles 😕

There are these bottles:
Bridge Baron
CADDRAW
CXHTML
Steuer2009
Unsupported-2
VR-Networld
smartrecover

I enclose a snapshot of the cxsetup.
[image=file:///home/bernd/Bildschirmfoto6.jpeg]
This doesn't work !?

Regards

Hi,

To embed images, they must be available beyond the domain of your local
machine...ie; upload them to public image repo (pastebin etc)..

OK...now that I I know you have backups, I think the problem you're
having is in the actual crossover directory, not so much the bottle
directory. If you installed crossover in your home directory, delete
the cxoffice directory and reinstall crossover. If you installed
crossover in /opt, become root user and the delete the /opt/cxoffice
directory and install the latest crossover again.

Let me know how you get on...

Cheers!

I tried both installation (/home and /opt) before.

I reinstalled now in /home (as 8.0.0. was) but same situation.
The initialisation process does not come to an end.

CrossOver is dertemining what applications are installed in this bottle

The bar is still moving. I tried all bottles.

Also after I closed the cxsetup it doesn't start correct again the panel is there but empty.
To get it work again a reboot is required.

Regards

Ouch...I was kinda afraid that might happen, hence my caution with all this.

The next logical thing to try, is to move/rename/delete your existing bottle
directory, remove/reinstall 9.1 and see if the new 9.1 installation can create
a new bottle directory and also create a new bottle (just to test functionality)
-- if that works, then try to restore your cxarchive bottle into the new installation
environment....

Keep me posted...

Cheers!

I tried to install Media Player 6.4. installation starts but the installer is freezing.
The bottle directory is just in parts installed e.g. the subdirectories but no apps. I also tried IE 7 and ebrary Reader.

Regards

Hmmm....I wouldn't have thought -that- much has changed from 8.0 -> 9.1
but perhaps I'm in error and overlooking something...could you paste back
the output of the follow command please?...

[if installed in your home directory] ~/cxoffice/bin/cxdiag --debug

[if installed in /opt system directory] /opt/cxoffice/bin/cxdiag --debug

....you might also try the following;

Test case: this should work with a fresh CXO-9.1 installation -- install the
following app via the C4P file provided on it's C4 page;

http://www.codeweavers.com/compatibility/browse/name/?app_id=857

The installation of that small app should complete cleanly -- if it does not,
at the end of the c4p install you will see a link to the install debuglog
created by the cxinstaller -- upload that log to rapidshare or the like and
post the download URL back here.

Cheers!

First part:
[b]bernd@volkmsidux2:~$ /home/bernd/cxoffice/bin/cxdiag --debug
libcapi20.so.3: cannot open shared object file: No such file or directory
[MissingLibCapi20]
"Level"="Suggest"
"Title"="Missing 32bit libcapi20.so.3 library"
"Description"="Provides support for some ISDN cards. Very few applications need this."

libxml2.so: cannot open shared object file: No such file or directory
[MissingLibXml2]
"Level"="Recommend"
"Title"="Missing 32bit libxml2.so library"
"Description"="This library makes it possible for Windows applications read and write XML files."

libxslt.so: cannot open shared object file: No such file or directory
[MissingLibXslt]
"Level"="Recommend"
"Title"="Missing 32bit libxslt.so library"
"Description"="This library lets Windows applications perform queries and transformations on XML files."

found libcrypto.so.0.9.8
found libssl.so.0.9.8
egrep 'hosts:.*mdns4' /etc/nsswitch.conf >/dev/null 2>&1 returned 256
default screen=0, planes=24
OpenGL vendor = 'NVIDIA Corporation'
OpenGL version = '2.1.2 NVIDIA 195.36.24'
NVIDIA version 195.36
[/b]

Second part:
C4P installtion does not come to an end, so there is no debug log.

Regards

Hi,

First part: it would be advisable to fix the missing libxml2/libxslt libraries
by adding the 32bit packages to your distro, however, that only has bearing on win32
programs being run in crossover, it doesn't pertain to crossover's operations as such.

Second part: ahh...that should've worked ; the fact it didn't, makes me suspect that
your system setup is missing something (or has older versions of some libraries) that
are needed by the new crossover GUI. If the installation of that above app hangs, you
can still get a debuglog -- retry the installation of sonique via c4p -- when the
installation hangs, click on cancel/cancel install -- that should take you to the final
cxinstaller window with the debug log link...(this debug log will more than likely
disclose what's going wrong system wise)

Keep me posted...

Cheers!

Hi,

Second part:

nop, no way to get to that final cxinstaller window 😥

This morning I tried the CO -.deb version but the same behavior.

Regards

You can try something like this to get a log of bottle creation:

~/cxoffice/bin/cxbottle --bottle test --create --template winxp --verbose

Hi again,

Thanks for being so patient trying to get to the bottom of this.

I'm going to suspect this has something to do with either your
perl/python libs and/or gtk/glib...hmmm....we'll need become a
tad more methodical here...

1. Can a fresh 9.1 installation create a new bottle? (click on the +Add button in the cxsetup GUI)

   if not, let me know

   if it can create a new bottle, click on the -Remove button to delete the bottle just created
   and move onto step 2 below.

2. If it can create a new bottle, click on the +Add button, create a new bottle (it's name will
   be 'New Bottle') and select 'New bottle type' to be win2000, then click 'Create'

3. Highlight the 'New Bottle' entry -> Advanced tab -> at the bottom, check the 'Use this bottle as the
   default for the command line' widget.

4. Download the Sonique installer from here --> http://members.tripod.com/~ultimtewarrior2/d/sonique196.exe
   and put the sonique196.exe file in your home directory.

5. Open a console/shell and issue the following command (assuming you've installed crossover in your home directory);

cd && ~/cxoffice/bin/wine sonique196.exe &>cxwine.log

6. When/if things hang/stop, issue a ^C in the terminal/shell (^C = ctrl-c) -- this should clear/quit the
   running installation process

7. Gzip the resultant file named 'cxwine.log' and upload it to a public repo like rapidshare or such, and post
   the download URL back here so I can grab it and have a look at what's going on.

Hear from you again soon....

Cheers!

edit: Ken's idea is a good test as well

Hi,

Ken Thomases wrote:

You can try something like this to get a log of bottle creation:

~/cxoffice/bin/cxbottle --bottle test --create --template winxp --verbose

That's all

[b]bernd@volkmsidux2:~$ /home/bernd/cxoffice/bin/cxbottle --bottle test --create --template winxp --verbose
CXConfig->read(/home/bernd/cxoffice/etc/cxoffice.conf)
7132: Grabbing the '/tmp/.wine-1000/bottle-80c-10e0e1.lock' lock
7132: Got the '/tmp/.wine-1000/bottle-80c-10e0e1.lock' lock
Running '/home/bernd/cxoffice/share/crossover/bottle_templates/winxp/setup' '--create'
Cannot connect to server socket err = Datei oder Verzeichnis nicht gefunden
Cannot connect to server socket
jack server is not running or cannot be started

[/b]

Regards

Artist Formally Known as Dot wrote:

Hi again,

Thanks for being so patient trying to get to the bottom of this.

I'm going to suspect this has something to do with either your
perl/python libs and/or gtk/glib...hmmm....we'll need become a
tad more methodical here...

1. Can a fresh 9.1 installation create a new bottle? (click on the
   +Add button in the cxsetup GUI)

   if not, let me know

Failure 😭

Regards

I think this has to do with the "jack" audio server. For some reason, something is trying to connect to it, is failing, and that's terminating everything.

Since this is before the bottle is created, I don't even think this has to do with Wine's audio configuration.

I don't know what is wrong. I think it has to do with the set of packages that are (or are not) installed on your system. You might try uninstalling any jack-related packages. (If you need or want jack installed, then you could reinstall it to see if that fixes things.)

Ken Thomases wrote:

I think this has to do with the "jack" audio server. For some
reason, something is trying to connect to it, is failing, and that's
terminating everything.

Since this is before the bottle is created, I don't even think this
has to do with Wine's audio configuration.

I don't know what is wrong. I think it has to do with the set of
packages that are (or are not) installed on your system. You might
try uninstalling any jack-related packages. (If you need or want
jack installed, then you could reinstall it to see if that fixes
things.)

Hmmm, so why is CO 8.0.0 running flawless?

I'm not sure. A big change with 9.x was the switch to using Python and pygtk for the GUI, but I don't think that should affect cxbottle.

cxbottle and the other tools it invokes are written in Perl. Of course, they have changed since 8.0, and one of those changes may involve pulling in different Perl modules, which might now interact with jack.

Or jack could be a red herring and something else could be wrong, but there's something wrong on your system.

I doubt libjack has anything to do with it - my 64bit Debian 5 doesn't even have libjack
installed and I'm not seeing this error -- CXO or CXG 9.1 can happily create bottles. I
just did a comparative test on my 32bit Debian5 instance --- that is, install CXO-8.0
and then upgrade to CXO-9.1 || again, libjack is not installed there either, and it can
still create bottles. Actually installing libjack has no negative effect....

Further, I recreated the situation on the 64bit Debian5 instance, both with and without
libjack, and upgrading from CXO-8.0 to CXO-9.1 works 'as exxpected'.

Ergo, as posited before, I have to suspect perl/python libs or glib/gtk (which pygtk hooks
into) as being the culprit -- it's the only thing I can think of that would thwart cxbottle
altogether -- python & friends would be my best guess.

@Bernd -- can you tell me the -exact- version of sidux you are using? In any event, I'm now
suspecting you'd have to upgrade to the 2010 sidux release, but it'd be helpful to know the
exact release you are using so I can try find/see where this issue is occurring - I can't
recreate the problem with 32/64bit installs of Debian 5, so it must be in sidux somewhere.

Cheers!

Hi,
this is the installed Kernel:
2.6.34-0.slh.11-sidux-686

The last upgrade was a complete dist-upgrade.

Regards

Hi,

Thank you....I'll install the latest sidux offering and see if I
can recreate/understand the issue....(might take several hours for
me to get back to this - nearly bedtime now in .AU 8)

Cheers!

Artist Formally Known as Dot wrote:

Hi,

Thank you....I'll install the latest sidux offering and see if I
can recreate/understand the issue....(might take several hours for
me to get back to this - nearly bedtime now in .AU 8)

Cheers!

Take your time!

Thank's and good night 😉

Hi again,

I used the sidux-2010-01-hypnos-xfce-i386-201006131622.iso

That gave me kernel 2.6.34-0.slh.9-sidux-686

CXO-9.1 didn't want to work -at-all- to begin with, however it would install....

...didn't create menu entries...(that'd be typical of xfce4 - I get the same here)

Not to worry...had a quick sniff around....I am root...

1> add non-free and contrib to your debian sources.list | apt-get update

2> apt-get install wine python-gtk2 python-glade2

...I am now the normal user again, ~/cxoffice/bin/cxsetup works, creating bottle
works, installing sonique works (although doing that made me realize I'll have to
think about wait_child_process_ignore or whatever in the c4p...or make it obvious
about the sonique quicklauncher hanging around 8)...but whatever, that got it working.

...I'm not absolutely sure if you used the i386(686) image or the amd64 build, but
in any event I'll hunch the problem is either those missing packages, or there's
some different/incompatible with the amd64 ones...

Hope this helps, let us know how you get on...

Cheers!

Hello,
thank's for the info.
Sorry don't have the time today, will try tomorrow.

Regards

Reading your post I was very optimistic but 😥
both packages are installed, I upgraded both.

CO still does not work. My System is 32bit.

Regards

Hello,
I purged the mentioned packages an reinstalled but still no change.

On my system is also a separate WINE installed could that cause the problem?

Regards

Hi,

No....I also installed wine with the sidux distro just to check that
angle, it made no difference....now I'm getting really stumped...ie;
I was hoping to be able to recreate it here using the same distro, but as
explained I did get it to work as described.....(grasping at mental
straws here)...might you be able to clearly eliminate your current user
account?....ie; create a new user, login as that user account, install
Crossover into that user's directory (use the .sh installer) and see
what happens in that instance? If it works, then obviously the problem
would be in your current user homedir -- if it doesn't, then it's definitely
systemwide/system environment causing this....it would help narrow down
the area of suspicion...

OH!...btw, if you edit an existing post, I won't see it turn up in my
email and that will delay my response -- don't worry about posting a new
thread to answer stuff (you should see some threads I've been involved with
that are 150+ postings big ;)...it helps get my attention...

Cheers!

Hi,
thank's for your reply again.
A new user didn't help, so it is not in my /home but in the system-environmet itself. Puuh.. that will be hard to find.

Regards

Hi,

Okay...definitely system....right, I know I've already seen a difference
between the kernel version I installed and what you have there -- I cited
the actual iso image I used in this thread above...this has me intrigued
so I'm happy to chase it -- you previously mentioned an update or such?

I'm fishing for history obviously...can you provide the exact iso filename
you used and, if you can recall, what system updates were involved? Or was
it more the case you had a previous installation and did a dist-upgrade?
Any clues or hints at all would be helpful....it's kinda of perplexing when
I can't recreate it with the same distro, so I'm trying to make sure I do
in fact have the -exact-same-distro-setup- all told...I'm more than happy
to try find the cause of this...so let me know...

Cheers!

Hello,
today I took a surples HD and installed the latest sidux release 'sidux 2010-1 Hyponos' added CO ..works. Next I made a dist-upgrade to kernel 2.6.34-0.slh.11-sidux-686 i686 CO Installation failed because Import Error: no module named gtk. So I installed wine python-gtk2 python-glade2. Ok, could install a new bottle.

My running system is sidux 'sidux 2009-4 Moros' but dist-upgrade to kernel 2.6.34-0.slh.11-sidux-686 i686. As far as I know due to the dist-upgrade there shouldn't be a difference between the two system environments. The only difference I can think of is that my system has the nvidia non-free driver installed.

Regards

Hi again,

Gee, thanks for the legwork there....and for recreating/confirming my own observations.

So we have it in our sights now... something in the dist-upgrade to kernel 2.6.34-0.slh.11-sidux-686 i686
is scuttling the boat ... you share my thoughts though here - "that's a bit odd" - and no, I doubt the
nvidia drivers are playing monkey here. Your description does fit the following construct however -- 'stale'
symlinks somewhere in your system's $LIBDIR that were originally propagated by the Moros instance, and not
correctly removed/relinked during the dist-upgrade process (/me has seen debian apt do that before). You
would not of course encounter this if starting from a fresh Hyponos install + update, because the offending
link would not be present....yeah, that'd have to be it I think....

Check in your system $LIBDIR for stale/incorrect symlinking wrt python/gtk and friends,
chances are one or more of those are pointing to the wrong library or libdatadir and they
will need to be removed/relinked and then update your ld.so.cache ..ie; run ldconfig after you
correct any links...keep in touch!

Cheers!

Hello,

Hmmm, I realy don't know how to follow your advices.

How can I identify those incorrect symlinks?

There are lots of python DIR's in /usr/lib/ and /var/lib/.

Regards

Hi,

I just checked the what that they've done in Hyponos. After installing the python-gtk2 python-glade2 packages,
you should see the following layout (I'm guessing pygtk is our trouble);

root@siduxbox:# ls -l /usr/lib/libpy*
lrwxrwxrwx 1 root root      32 Jun 14 02:48 libpyglib-2.0-python2.5.so.0 -> libpyglib-2.0-python2.5.so.0.0.0
-rw-r--r-- 1 root root   12332 Jun  8 04:43 libpyglib-2.0-python2.5.so.0.0.0
lrwxrwxrwx 1 root root      32 Jun 14 02:48 libpyglib-2.0-python2.6.so.0 -> libpyglib-2.0-python2.6.so.0.0.0
-rw-r--r-- 1 root root   12096 Jun  8 04:43 libpyglib-2.0-python2.6.so.0.0.0
lrwxrwxrwx 1 root root      19 Jun 14 02:30 libpython2.5.so.1 -> libpython2.5.so.1.0
-rw-r--r-- 1 root root 1232788 Apr 21 20:26 libpython2.5.so.1.0

root@siduxbox:# ls -l /usr/lib/pymodules/python2.5
total 28
drwxr-xr-x  2 root root 4096 Aug 19 13:26 cairo
lrwxrwxrwx  1 root root   37 Jun 14 03:06 cups-1.0.egg-info -> /usr/share/pyshared/cups-1.0.egg-info
lrwxrwxrwx  1 root root   35 Jun 14 03:06 cups.so -> /usr/lib/pyshared/python2.5/cups.so
drwxr-xr-x  2 root root 4096 Jun 14 03:07 cupsutils
drwxr-xr-x  3 root root 4096 Jun 14 02:57 dbus
lrwxrwxrwx  1 root root   36 Jun 14 02:57 dbus_bindings.py -> /usr/share/pyshared/dbus_bindings.py
-rw-r--r--  1 root root  181 Jun 14 02:57 dbus_bindings.pyc
lrwxrwxrwx  1 root root   45 Jun 14 02:57 _dbus_bindings.so -> /usr/lib/pyshared/python2.5/_dbus_bindings.so
lrwxrwxrwx  1 root root   50 Jun 14 02:57 _dbus_glib_bindings.so -> /usr/lib/pyshared/python2.5/_dbus_glib_bindings.so
drwxr-xr-x  6 root root 4096 Aug 19 13:26 gtk-2.0
drwxr-xr-x 16 root root 4096 Aug 19 13:26 numpy
lrwxrwxrwx  1 root root   40 Aug 19 13:26 numpy-1.4.1.egg-info -> /usr/share/pyshared/numpy-1.4.1.egg-info
lrwxrwxrwx  1 root root   29 Jun 14 03:06 pygtk.pth -> /usr/share/pyshared/pygtk.pth
lrwxrwxrwx  1 root root   28 Jun 14 03:06 pygtk.py -> /usr/share/pyshared/pygtk.py
-rw-r--r--  1 root root 2064 Jun 14 03:07 pygtk.pyc

You should see the same output, no red links -- if unsure, paste the output
of the same 2 commands back here ;)

Cheers!

Hi,
totaly different output 😒

Lots of blue and mint coloured.

root@volkmsidux2:/home/bernd# ls -l /usr/lib/libpy*
lrwxrwxrwx 1 root root      32  5. Jul 18:50 /usr/lib/libpyglib-2.0-python2.5.so.0 -> libpyglib-2.0-python2.5.so.0.0.0
-rw-r--r-- 1 root root   12332  7. Jun 20:43 /usr/lib/libpyglib-2.0-python2.5.so.0.0.0
lrwxrwxrwx 1 root root      32  5. Jul 18:50 /usr/lib/libpyglib-2.0-python2.6.so.0 -> libpyglib-2.0-python2.6.so.0.0.0
-rw-r--r-- 1 root root   12096  7. Jun 20:43 /usr/lib/libpyglib-2.0-python2.6.so.0.0.0
lrwxrwxrwx 1 root root      19 24. Apr 15:22 /usr/lib/libpython2.5.so.1 -> libpython2.5.so.1.0
-rw-r--r-- 1 root root 1232788 21. Apr 12:26 /usr/lib/libpython2.5.so.1.0
lrwxrwxrwx 1 root root      19  5. Jul 18:48 /usr/lib/libpython2.6.so.1 -> libpython2.6.so.1.0
-rw-r--r-- 1 root root 2394804  3. Jul 22:50 /usr/lib/libpython2.6.so.1.0
root@volkmsidux2:/home/bernd# ls -l /usr/lib/pymodules/python2.5
insgesamt 148
lrwxrwxrwx  1 root root    50  5. Jul 18:56 apt_xapian_index-0.38.egg-info -> /usr/share/pyshared/apt_xapian_index-0.38.egg-info
drwxr-xr-x  2 root root  4096  5. Jul 18:56 axi
drwxr-xr-x  2 root root  4096  7. Mär 14:01 cairo
lrwxrwxrwx  1 root root    37  7. Mär 14:01 cups-1.0.egg-info -> /usr/share/pyshared/cups-1.0.egg-info
lrwxrwxrwx  1 root root    35  7. Mär 14:01 cups.so -> /usr/lib/pyshared/python2.5/cups.so
drwxr-xr-x  2 root root  4096 31. Dez 2009  cupsutils
drwxr-xr-x  2 root root  4096  7. Mär 14:01 curl
drwxr-xr-x  3 root root  4096 14. Mai 09:30 dbus
lrwxrwxrwx  1 root root    36  7. Mär 13:59 dbus_bindings.py -> /usr/share/pyshared/dbus_bindings.py
-rw-r--r--  1 root root   181  7. Mär 14:03 dbus_bindings.pyc
lrwxrwxrwx  1 root root    45  7. Mär 13:59 _dbus_bindings.so -> /usr/lib/pyshared/python2.5/_dbus_bindings.so
lrwxrwxrwx  1 root root    50  7. Mär 13:59 _dbus_glib_bindings.so -> /usr/lib/pyshared/python2.5/_dbus_glib_bindings.so
lrwxrwxrwx  1 root root    29  5. Jul 18:55 deb822.py -> /usr/share/pyshared/deb822.py
-rw-r--r--  1 root root   313  5. Jul 18:56 deb822.pyc
drwxr-xr-x  2 root root  4096  5. Jul 18:56 debian
drwxr-xr-x  2 root root  4096  5. Jul 18:56 debian_bundle
drwxr-xr-x  6 root root  4096 23. Aug 08:38 gtk-2.0
drwxr-xr-x  2 root root  4096  5. Mai 08:31 iniparse
lrwxrwxrwx  1 root root    43  5. Mai 08:31 iniparse-0.3.2.egg-info -> /usr/share/pyshared/iniparse-0.3.2.egg-info                                               
drwxr-xr-x 16 root root  4096 19. Aug 20:36 numpy                                                                                                                
lrwxrwxrwx  1 root root    40 19. Aug 20:36 numpy-1.4.1.egg-info -> /usr/share/pyshared/numpy-1.4.1.egg-info                                                     
lrwxrwxrwx  1 root root    42  7. Mär 14:01 pycurl-7.19.0.egg-info -> /usr/share/pyshared/pycurl-7.19.0.egg-info                                                 
lrwxrwxrwx  1 root root    37  7. Mär 14:01 pycurl.so -> /usr/lib/pyshared/python2.5/pycurl.so                                                                   
lrwxrwxrwx  1 root root    29  5. Jul 18:56 pygtk.pth -> /usr/share/pyshared/pygtk.pth
lrwxrwxrwx  1 root root    28  5. Jul 18:56 pygtk.py -> /usr/share/pyshared/pygtk.py
-rw-r--r--  1 root root  2064  5. Jul 18:54 pygtk.pyc
drwxr-xr-x  3 root root  4096  5. Jul 18:55 PyQt4
drwxr-xr-x  2 root root  4096  5. Jul 18:55 python_debian-0.1.16.egg-info
drwxr-xr-x  2 root root  4096  7. Mär 14:01 rdiff_backup
lrwxrwxrwx  1 root root    47  7. Mär 14:01 rdiff_backup-1.2.8.egg-info -> /usr/share/pyshared/rdiff_backup-1.2.8.egg-info
lrwxrwxrwx  1 root root    43 24. Apr 15:32 sipconfig_nd.py -> /usr/lib/pyshared/python2.5/sipconfig_nd.py
-rw-r--r--  1 root root 68758 24. Apr 15:32 sipconfig_nd.pyc
lrwxrwxrwx  1 root root    32 24. Apr 15:32 sipconfig.py -> /usr/share/pyshared/sipconfig.py
-rw-r--r--  1 root root   515 24. Apr 15:32 sipconfig.pyc
lrwxrwxrwx  1 root root    34 24. Apr 15:32 sip.so -> /usr/lib/pyshared/python2.5/sip.so
drwxr-xr-x  8 root root  4096  5. Jul 18:54 smart
lrwxrwxrwx  1 root root    38  5. Jul 18:54 smart-1.3.egg-info -> /usr/share/pyshared/smart-1.3.egg-info
drwxr-xr-x 10 root root  4096  5. Jul 18:56 sqlalchemy
drwxr-xr-x  2 root root  4096  5. Jul 18:56 SQLAlchemy-0.6.1.egg-info

Regards

Hi Don,
glad to see you back 😊

Any idea how to continue?

Regards

Hi Bernd,

Would you believe, since last I typed here I've had my server trying
to download the only source of the Moros release that I could find...ie;
via the semi-official torrent. That is extremely slow...indeed, so far I've
it's only downloaded about 56mb....this could take the rest of the year at
this rate 8(

Of course, I'm doing that so I can actually recreate the issue as you
describe -- if (IF!! 8) I could get Moros and actually do what you have
explained, I could have a sure-fire answer for you in no time flat...it
would even be easy tbh. This problem is at the point where if I give you
the wrong advice, it may well break your installation, and so I am NOT
going to do that....

So we're sort of stuck between a rock and a hard place - I'm fairly certain
it's a crosslinked library or python version load order problem, but I need
to see the Moros makeup to determine exactly what the cause is.

If you have any URL that I can download the Moros ISO from directly, that
sure would help -- if you're prepared to upload the Moros ISO somewhere so
I can grab it (supposing you still have a copy?), that too would be a way
to quickly resolve this as well -- let me know the answers here if you would.

Cheers!

Hi,
no official mirror has moros anymore I was told. I do have an ISO but my line is 160 kBit/s upload. 😥

Regards

Btw, on a spare drive I made an fresh installation of moros and an dist-upgrade to actual kernel. CO 9.1. run's very well. 😕

Ciao

Now you're beginning to appreciate why I'm being so cautious here, and
also why I feel it's absolutely necessary to get Moros, do a dist upgrade,
and ascertain forsure* what is happening. Believe me, I've been building
my own linux installations for the past 10 years and thus have a very good
understanding on the complexity and interactions involved between the various
software components that go to make a linux distro....

FWIW, I never dist-upgrade -- I preserve my home directory, blow everything
away and start fresh, and then restore/reintegrate my home directory into
the fresh installation (I even do this with Debian boxes), but I readily admit
that's beyond user friendly and nor is it trivial - one has to know what they're
doing. I really need to see the Moros layout to understand how the dist-upgrade
process is getting things wrong....like I say though...and this is what I have
against 'rolling release' distros...when you encounter a problem like this, it
always seems near impossible to get a copy of the previous rolling release to
make it possible to properly untangle something like this.

I really can't do anything further until I see Moros....but in all honesty, if
you burnt Moros to a CD and posted it to me by snail, I think it would beat the
torrent download by at least 2 months....{sigh}...frustrating, I know, but there's
little else I can do...

Cheers!

Well, why not send you a DVD. We have gone so far now I realy like to know what happened (with your outstanding support).
If we will not succeed I can make an install from scratch anyway.

Regards

Hi,
where should I send the DVD?

Hello again,

I'll answer you via private email,

Cheers!