OK, I get:
You open thunar and X11 crashes (sometimes) and sends you into 'lightdm' (the login screen).
So the machine is still alive at that moment .... It's X11 that conks out: Meaning that there are logs/traces to be had. So note the time the crash happened and:
Take a look at '/var/log/syslog' at around that time.... also look at '/var/log/Xorg.log for X11errors around that moment in time.
As you gathered, the '/var/log/' directory carries most of your logs.
For the Xorg log try this: less /var/log/Xorg.0.log |grep EE
That will filter out the errors.
These logs are kept ongoing, so don't wait too long to read/check them or you'll have a lot of scrolling to do.
Also try starting 'thunar' from the terminal and see what error messages that shows (if at all) whether it crashes X or not.
Maybe @Thanatermesis has more pointers on where to find more relevant info.
run "dmesg" after the crash to see if you have any messages
try to make it crash from a terminal instead from the hotkey, to see if we have any error message on the terminal, BUT since the crash is the entire desktop you need a non-dying terminal this means, open a terminal, run "tmux", and then run "thunar", if crashes, you can relogin on your desktop and re-attach to your previous tmux to see what happened using "tmux attach"
I wonder if this is simply hardware issues like a RAM in a bad state or hard disk badblocks (or, software in a bad state/corrupted), @Franc mentioned he had a similar issue but maybe his issue was just Nvidia, which should work without issues now after my many recent tests, fixes and improvements made to them
Looking at 'conky' on the video wasn't easy and turned away during the first crash but I did see the CPU go to, what looked like 100% when opening thunar later on.
yeah maybe is also good if @maxinou runs inside the tmux in an extra window (shift+down, ctrl+left/right) a "sudo htop" to see the ram usage & cpu usage and which process could be, but this maybe is only possible to do in realtime from a ssh since the desktop crashes or... to use asciinema command to record what is happening on that terminal (htop) during the crash
at least this is a good thing to know, as said maybe is just a hardware issue or something very specific to the machine
I think we can stop seeding the torrent @triantares , no more time for tests, these are the final isos, I will put them publicly (so not the previous link) from the website when the page is ready + announcement
I'm also waiting for @TheTechRobo to answer about an issue with his mirror, seems like cannot sync to it
I'm having trouble with zsync_curl on both .iso.zsync files so maybe that's related to sync issue.
##################-- 91.4%-1 returned
##################-- 91.4% 0.0 kBps aborted
failed to retrieve from elive_3.8.32_retro_hybrid_amd64.iso -1
Aborting, download available in elive_3.8.32_retro_hybrid_amd64.iso.part
but wait, is not yet published lol, we cannot announce it to the world is not showing it up, if people like distrowatch see that will be confusing for them
can be related to the fact i needed to rename the files manually, maybe the zsync doesn't match
the md5 matches so the isos are correct, but I have recreated the zsync files as you suggested, they have a different md5 than the previous one so I assume it should work now
In any case, that's not an issue with the mirrors, they don't use this, the mirrors always update manually
Tell me more about this mirror, is a real machine or is a server? what is the bandwidth speed and limits?
Not bad! already pretty fast from here in colombia (3 mb/s, 24 min total download)
Questions:
is your bandwith unlimited? (I don't want you to be overbilled for the big bandwith usage if i add it as a mirror)
is the machine always up? (with big uptimes, i mean not rebooting often), this is important because if somebody is downloading on that moment, will have a broken / corrupted download and probably not noticing the iso was wrongly downloading, leading to "elive don't works"
to add it as an official mirror will be needed to set up an user with ssh access (key-based only) in order to automatically sync the isos when there's a new one, no privileges are needed outside the user itself, except for the location of the isos that should be inside the user's directory and writable for it. This means, you (probably) should be able to link that user directory into your webserver "elive" directory
I can't made as many tests as I want (low energy), but trying the '386 .iso from the torrent (RC2) on the HP Compaq nc6320 gives a kernel panic just after selecting the first boot option...
I wasn't planning to use it as a continual mirror for Elive, only for Retrowave so that might be a little overkill.
I cannot guarantee a swift reboot if it does go down (like with failing electricity), seeing I'm not home that often. That's a big downside.
Bandwidth is unlimited with FUP .... so I'll get a warning if it gets out of hand.
and try both kernels (scrolling down you go to the kernel 5.x instead of 6.x)
the problem is that the download buttons manages themselves all automatically so it needs to work the same way as the other mirrors
electricity failing is unavoidable and doesn't happens much often if the machine is meant to be "running and up all the time" is perfectly fine. About the "machine shutted down" is not a big problem also because the button of the downloads always check if the mirror is available and online before to give the selected link (by selected I mean: it picks the best mirror based on the users downloading location)
im reading about FUP, what means "certain limit" ? lol, or more like: what is your actual limit?
Unlimited, until they think that I'm using commercial bandwidth i.e more than a private connection should (like a new youtube site or such). Then they'll offer me a commercial plan or tell me to cease.
In a few months I'll have fiber glass instead of cable, that'll speed hings up too.
So you think its a risk to add it as a download mirror? the last version had 5000 downloads between 3 (actual) mirrors, 5000 is a really low number for more than 6 months anyways... this is like 240 downloads per mirror per month which is 4gb which is let's say 1 tb per month per mirror
There's always a risk and a sudden uptick in continual upload bandwidth might cause a 'warning' to pop-up.
They'll probably think the machine has been hijacked for malevolent purposes.
On top the 40Mb is fairly quickly swamped if others are using a lot (there's 5 and a media center machines on there). I actually lowered my plan, since our gaming son went to his own place.
this means, open a terminal, run "tmux", and then run "thunar", if crashes, you can relogin on your desktop and re-attach to your previous tmux to see what happened using "tmux attach"
