KLV-Airedale-beta+ Released, Ready for Download

[pemasu]

I created bootable beta2 using weedogit.sh script. Then I installed using android phone usb connection gcc and friends ( about 100 MB ) and then I downloaded the appropriate kernel source sfs from ozsouth. I do have working broadcom-sta driver source. I cant compile wl.ko module because I cant create working build and source symlinks to the kernel modules root folder pointing to the /usr/src/linux. Read only filesystem was the error message.
Something due to that kernel module sfs when loaded seems to prohibit to create any file to the /lib/modules/5.15.12-64oz folder ?
So question is, how do you compile kernel module drivers in this distro ?

[wiak]

(the way I've been doing it);

Can you write the rsync command line you used ? I like to test that simple method too, I tried something like that first , but resulted in complications, but perhaps I did wrong, so could be that my code in snapmergepuppy is a bit over-complicated.

Yes, I posted earlier about the simple one-liner I use when rockedge asked for it:
viewtopic.php?p=48795#p48795

As I said then, could do with some 'exclude' extras to prevent rsyncing back caches and suchlike.

I did use this one-liner for quite a long time and didn't notice any ill-effects, but truly I didn't test in any rigorous way the effect it had or might have on whiteout combinations.

But... my reasoning was that:

say you have, for example 4 layer files

and second one has some whiteouts (which effectively cause underlying filenames to appear deleted in the overall merge)

then the third one similarly

and finally, in external upper_changes you might have a few more

Well, on boot, per usual, the whole lot get merged (into /mnt/layers/merged) and the whiteouts do their job correctly regardless of which ones and which layers they are in, so /mnt/layers/merged doesn't show whiteouts itself.

But because of w_changes=RAM2, that boot session uses the in-RAM upper_changes at /mnt/layers/RAM/upper_changes, which may or may not end up with some whiteouts in it depending if you delete anything that currently shows up in merged during that boot session.

So if you do a delete, it's going to only create new whiteouts in that /mnt/layers/RAM/upper_changes and when you rsync back any such new whiteouts will (correctly) be rsync'd back to the on media upper_changes (i.e. the one that is read only mounted at /mnt/layers/uc_ro).

So, that all seems correct and reasonable to me. No problem there at all as far as I see it. Why would you need to scan through the underlying sfs files (and do what? You can't remove whiteouts - they are for making sure layers further below don't show up in merge.

But maybe I'm missing something - and I haven't studied your script as yet Fred, so I really don't know what it is you do regarding whiteouts. For me, I simply never came across any problems from the simple one-liner rsync, but maybe I missed something or was lucky in what I was doing. I always meant to think about it further, but was always to busy. So, for now, I can't see the problem, but am happy to be enlightened!

Of course, on the other hand, if you were doing a 'remaster', well you don't want to include all the whiteouts, but /mnt/layers/merged just contains the final result (so no need to scan and remove whiteouts and associated 'underneath files' then either.

[wiak]

I created bootable beta2 using weedogit.sh script. Then I installed using android phone usb connection gcc and friends ( about 100 MB ) and then I downloaded the appropriate kernel source sfs from ozsouth. I do have working broadcom-sta driver source. I cant compile wl.ko module because I cant create working build and source symlinks to the kernel modules root folder pointing to the /usr/src/linux. Read only filesystem was the error message.
Something due to that kernel module sfs when loaded seems to prohibit to create any file to the /lib/modules/5.15.12-64oz folder ?
So question is, how do you compile kernel module drivers in this distro ?

The 00modules.sfs method being employed is a wee 'trick' to allow the use of Puppy kernel/modules without having to embed any modules from Puppy zdrv into the intird (actually only one needed anyway is overlay since not by default built into most Puppy kernels).

It's implemented as a bind mount to /usr/lib/modules, so when an sfs is being used that means it is read/only so yes that is a limitation - you have to do something different if you really need to change something in the modules, such as compiling a new one.

One way to do that would be not to use that 00 trick, but instead to actually include the overlay modules inside the initrd at location /usr/lib/modules and to number the modules.sfs to appear at a higher layer (since then it is not a bind mount but instead just a normal overlayfs mount - then you can write to /usr/lib/modules since result then actually goes into upper_changes (which is a read/write layer). But there is another, easier way, than re-arranging the system that much. The initrd allows either sfs addons or uncompressed directories (including for that 00 special case modules provision). So this should work:

Assuming you are booted into a different distro to do this:

rename 00modules.sfs to D00modules.sfs (the D just means it will be ignored/disabled since filename no longer starts with 2-digits - doesn't need to be a D...)

Then simply unsquash it to become:

squashfs_root, and rename that uncompressed directory version of the original zdrv to 00squashfs_root

Now, reboot your KLV-Airedale and you should be able now to read/write to /usr/lib/modules (since the bind mount is no longer to a read-only sfs but instead is a bind mount to that uncompressed writable modules directory - that contains the /usr/lib/modules/blablabla hierarchy).

Compiling new modules should now work fine. If you want to thereafter you can always mksquashfs it again if you wish.

The KLV-Airedale arrangement is not the way most weedogit type distros are constructed - they instead embed any modules required by the initrd inside it and no bind mount to a read-only sfs is involved so compiling modules works fine out-of-the-box in that case. Great thing is you can unsquashfs any KLV-Airedale related sfs and it will still work fine (which is pretty handy at times when you want to change for example main root filesystem contents manually).

wiak

[fredx181]

But... my reasoning was that:

say you have, for example 4 layer files

and second one has some whiteouts (which effectively cause underlying filenames to appear deleted in the overall merge)

then the third one similarly

and finally, in external upper_changes you might have a few more

Well.., looks like we have small misunderstanding...
What my 'complex' script does is check for whiteouts in the changes (RAM) corresponding with files in the SFS layers, not whiteouts inside the layers.
So what it finally does is that there will appear only whiteouts in the changes (uc_ro) that are existing in the layers (BUT removed from the filesystem).
And no whiteouts will appear in the changes (uc_ro) from new created files and later removed (so just removed from the changes, instead of masked.
Yes, these things hurt my brain a bit too Anyway as you can read at my EDIT in previous post, your simple way seems to work okay from my quick test.
(but as I said, I still prefer that no unneeded whiteouts exist in the changes (uc_ro))

[stemsee]

I have just tried booting this on my Acer 714 chromebook, and it boots and shutsdown very quickly indeed.

Networking worked connecting to wifi.

No sound yet as I will need to add firmware and ucm2 configs. No touchscreen yet, probably just needs firmware.

webcam works.

I didn't have a save boot code, but after installing packages I used sfs-direct-remaster in ram with success.

How to start stop services .. I selected start gnome-services but no difference? After installing bluez I couldn't get bluetoothd to run. bluealsa ran but couldn't connect to the daemon. same for bluetoothctl.

Using tray to control brightness and colour temp works but if i set colour, then again adjust brightness then colour is reset and vice versa, setting colour after brightness resets full brightness without adjusting slider .... needs a little work in reading settings. Yad is working very well.

It would be nice to have zstd as an option in dir2sfs, otherwise the new gui is very intuitive and superbly simple.
Move to trash is not reliable. After creating sfs files in / they remained after selecting in rightclick menu 'Moveto Trash'..EDIT ... they did move to trash but Thunar didn't update the window contents.

stemse

[wiak]

Well.., looks like we have small misunderstanding...
What my 'complex' script does is check for whiteouts in the changes (RAM) corresponding with files in the SFS layers, not whiteouts inside the layers.
So what it finally does is that there will appear only whiteouts in the changes (uc_ro) that are existing in the layers (BUT removed from the filesystem).
And no whiteouts will appear in the changes (uc_ro) from new created files and later removed (so just removed from the changes, instead of masked.
Yes, these things hurt my brain a bit too

Funnily enough, as I was reading what you wrote above I was about to reply 'my head hurts', and only then I noticed you last line there: "Yes, these things hurt my brain a bit too". I was accused of reading mikeslr's brain recently - clearly you just read mine. Puppy forum must be generating new powers in us.

[pemasu]

Compiling new modules should now work fine

After unsquashfsing and rebooting the creation of missing symlinks was possible and compiling the wl.ko module was successful. After placing the compiled wl.ko to the kernel module tree, depmod -a, rmmod bcma and modprobe wl, the internet connection happily announced that there is wifi available. Connection was successful also. Now writing using wifi.

Little bit tricky though. Might be good to compose cook recipe ( with link to the kernel source sfs and how to load it and howto create rw kernel module tree folders with involved steps for other wannabe kernel module compilers.

[fredx181]

Well.., looks like we have small misunderstanding...
What my 'complex' script does is check for whiteouts in the changes (RAM) corresponding with files in the SFS layers, not whiteouts inside the layers.
So what it finally does is that there will appear only whiteouts in the changes (uc_ro) that are existing in the layers (BUT removed from the filesystem).
And no whiteouts will appear in the changes (uc_ro) from new created files and later removed (so just removed from the changes, instead of masked.
Yes, these things hurt my brain a bit too

Funnily enough, as I was reading what you wrote above I was about to reply 'my head hurts', and only then I noticed you last line there: "Yes, these things hurt my brain a bit too". I was accused of reading mikeslr's brain recently - clearly you just read mine. Puppy forum must be generating new powers in us.

Yes, telepathy, works even if you are at the other end of the globe.
No, I actually was just referring to what you wrote similar a few posts back.

Why would you need to scan through the underlying sfs files (and do what?

Let me try to explain with a very simple practical example (and I won't bother you any further (for a while )
- if using the simple rsync one-liner:
Say you create /root/myfile , then reboot saving changes, then after reboot /root/myfile appears in upper_changes, ok.
Then you delete /root/myfile, save changes, after reboot /root/myfile is created as a mask file in upper_changes.

- if using the complex script and do the same as above, there is finally NO mask file /root/myfile in upper_changes, it's deleted as if it never was there before.

So, in other words, the complex script will only copy masked files that are also present as files in one of the SFS layers.

[wiak]

Let me try to explain with a very simple practical example (and I won't bother you any further (for a while )
- if using the simple rsync one-liner:
Say you create /root/myfile , then reboot saving changes, then after reboot /root/myfile appears in upper_changes, ok.
Then you delete /root/myfile, save changes, after reboot /root/myfile is created as a mask file in upper_changes.

- if using the complex script and do the same as above, there is finally NO mask file /root/myfile in upper_changes, it's deleted as if it never was there before.

So, in other words, the complex script will only copy masked files that are also present as files in one of the SFS layers.

Now I am with you in understanding. Yes, the complex script is a bit better in that case. Now that you mention that effect, I remember now coming it across it too - i.e. left over whiteout after making and deleting file on reboot (without experimenting on purpose, but then experimenting with it at the time to see what was going on - actually I don't think it was the RAM2 situation I was experimenting with at the time - I have a feeling it was something to do with one of these scripts by rufwoof that rockedge posted again recently - there was somethpng I didn't like about the result, but I really forget the details - maybe it was afterall something to do with RAM2. As you see, despite having no issue with your wee example above, my head still hurts a bit from previous explanations.

[wiak]

Compiling new modules should now work fine

After unsquashfsing and rebooting the creation of missing symlinks was possible and compiling the wl.ko module was successful. After placing the compiled wl.ko to the kernel module tree, depmod -a, rmmod bcma and modprobe wl, the internet connection happily announced that there is wifi available. Connection was successful also. Now writing using wifi.

Little bit tricky though. Might be good to compose cook recipe ( with link to the kernel source sfs and how to load it and howto create rw kernel module tree folders with involved steps for other wannabe kernel module compilers.

There is indeed a case for arranging KLV-Airedale differently (not using that 00modules trick, which was devised more than two years ago just to quickly test using Puppy huge kernel and modules (with that read-only nuisance you have pointed out). I don't know how many wannabe kernel module compilers there are (and who would not be satisfied with simply using the unsquashed modules). But, certainly, the issue could be avoided altogether by different arrangement:

Store only the single module being /usr/lib/modules/XXXXXXX/kernel/fs/overlayfs/overlay.ko inside the initrd along with one-liner modprobe.dep (there are no dependencies for that module). I am no expert at all with depmod (since a year or two since I used it) - I forget how to use it, so probably involved in the best way to do that. However, quickly tried that hierarchy and put that single overlay.ko module into the initrd as described.

The second thing then needing done would be to put the whole modules directory into location /usr/lib/modules in the main KLV-Airedale rootfs sfs and then no separate 00modules.sfs is required at all so overall size when thus assembled pretty much the same. Or use say 02modules.sfs will be easier from root filesystem point of view.

That works - I just tried it. Manually creating structure initrd/usr/lib/modules/XXXXX/kernel/fs/overlayfs/overlay.ko along with the single line module.dep. I am pretty sure the overlay.ko doesn't need to be buried in so many layers of hierarchy (maybe depmod fixes that all up automatically if you put it just under modules/NNNNkernelXXX/? But whatever, that kind of rebuild would remove the read-only limitation without needing any unsquashing.

EDIT:But, on second thoughts, I wouldn't do that. The whole point is that it is easy to just swap kernel/module/firmware to different versions as it stands. Would be a real pain having to continually change the initrd and/or the main root filesystem just to change kernel/modules. Fine as it is, but yes unsquashfs 00modules if you need to compile new ones...

[mikewalsh]

Hmm.... Curious. Coupla questions, guys?

@fredx181 :-

Now; I'm in the latest Beta2 ATM. This 'modified' version of TRIM4SSD, yes? For me, It'll fire up.....but none of the buttons will call their functions any longer.

I also tried the earlier, unmodified version KLV version. This also won't call any of its functions now. A few days back, under Beta1, this version was working, so.....what's changed between Beta1 and Beta2?

------------------------------------------

Following the recent modifications made to the Chrome-portable's update script - it will now check for a new version, and if one is available, will offer to upgrade:-

viewtopic.php?p=50801#p50801 --> onwards

.....I thought it was high time I tried it out under KLV. Since the updater uses 'ar' for .deb extraction (NOT dpkg-deb, which is more for installing/uninstalling; 'ar' is the one everybody recommends as first choice for .deb extraction), and Void/KLV has 'ar' by default, I figured there was a good chance it should work.

It does, nicely. I have an older version of Chrome (v91) that I've been using for these update tests, and this, indeed, duly updated to the current v98. And the way baraka and I have written it, after the updater has done its thing the new version launches automatically. Which is neat.

-------------------------------

Now; at various points during the script, I've inserted gtk-dialog 'banners' just so the user knows something is actually happening. Some of my 'portable' apps use these as well, and during the 'Alpha' phase, these would show OK. Not with the designated colours, but they WOULD show. Since moving to the 'Beta' phase, however, none of these 'banners' will show any longer.

Have we moved to a different version of GTK-3? Just curious....

Perhaps I'll need to re-write these to use a small YAD 'info' GUI with an auto-timeout instead? Thoughts?

Mike.

[fredx181]

@fredx181 :-

Now; I'm in the latest Beta2 ATM. This 'modified' version of TRIM4SSD, yes? For me, It'll fire up.....but none of the buttons will call their functions any longer.

I also tried the earlier, unmodified version KLV version. This also won't call any of its functions now. A few days back, under Beta1, this version was working, so.....what's changed between Beta1 and Beta2?

What unorthodox KLV Beta2 setup you did , Mike ?
Well... can only say that TRIM4SSD mod works fine for me on a pristine install of Beta2.
(nothing that I edited in TRIM4SSD that could cause the issue you have AFAIK, btw)

[rockedge]

How to start stop services .. I selected start gnome-services but no difference? After installing bluez I couldn't get bluetoothd to run. bluealsa ran but couldn't connect to the daemon. same for bluetoothctl.

I am also starting to address the bluetooth mechanisms. Starting and stopping services are performed by runit, here is a link to the information to describe how to use it: https://docs.voidlinux.org/config/services/index.html

It is fairly easy and straightforward to manage the services with runit. For example I need some logs to debug why Rox is crashing in some cases on a certain machine. So I will install the package socklog-void to provide the service at system start. Which is done simply with symlinks.

Code: Select all

xbps-install -Sy socklog-void

To enable socklog logging

Code: Select all

ln -s /etc/sv/socklog-unix /etc/runit/runsvdir/default/socklog-unix
ln -s /etc/sv/nanoklogd /etc/runit/runsvdir/default/nanoklogd

[wiak]

Once a service is enabled per rockedge first post, things get much easier anyway - you just use sv utility to start and stop and check what services are running:

https://docs.voidlinux.org/config/services/index.html

To start, stop, restart or get the status of a service:

# sv up <services>
# sv down <services>
# sv restart <services>
# sv status <services>

where services is the name of the service or services

[rockedge]

In beta2 I am experiencing a Rox-filer (Rox) segmentation fault crashing Rox. The crash is occurring when I attempt to go into sdb1.

Beta1 is not doing this. Tested on bare metal and virtual machine that only in beta2 Rox is crashing.

[wiak]

In beta2 I am experiencing a Rox-filer segmentation fault crashing Rox. The crash is occurring when I attempt to go into sdb1.

Beta1 is not doing this. Tested on bare metal and virtual machine that only in beta2 Rox is crashing.

I noted that Rox-filer does not seem to be available from Void repo.

EDIT: Ah, sorry, I presume it is 'Rox', which is indeed in the repo so rest I write here is likely rubbish...

I've found that segmentation faults such as these occur sometimes when an app has been compiled for use with a library or libraries that has substantially changed (internal symbols and so on) in recent version of a distro. May be therefore (though I don't know) that you will need to recompile Rox-filer with current Airedale.

[williams2]

Rox has a recurring bug. It crashes if it tries to make a thumbnail of a zero size picture file.

If you right click the eye icon on the bar at the top of the rox window to turn off displaying thumbs
and it no longer crashes, then you would know it is that bug.

If it still crashes, you can clear the thumbnails first in rox options.

If it still crashes, it is not that particular bug.

[rockedge]

Thanks for the tips. Odd really, the seg fault only is happening to certain paths. The log is indicating "error 6" out of all the info provided. The rest of the log message I can't seem to make headway with.

Thunar works on the same drives and partitions, in beta1 this Rox crash is not occurring. So far only when I go to /mnt/sdb1 or /mnt/sda1/ISO Rox just closes after it looks like its scanning and loading.

[rockedge]

I am having doubts about beta2 since I found Rox is crashing opening up certain partitions and directories. Some work and some not. Thunar is not effected. In beta1 Rox is not crashing (segmentation fault) at all and can open all of the same partitions and drives without any problems.

I installed socklog-void and started the service but have not found much to help pinpoint what is happening.

There is little difference between beta1 and beta2.

Mostly the empty /mnt in the rootfs SFS and @fredx181 's code modification to swapper.sh are the changes.

I have tried to do a total system update, which was successful but did not improve the bug.

[wiak]

I am having doubts about beta2 since I found Rox is crashing opening up certain partitions and directories. Some work and some not. Thunar is not effected. In beta1 Rox is not crashing (segmentation fault) at all and can open all of the same partitions and drives without any problems.

I installed socklog-void and started the service but have not found much to help pinpoint what is happening.

There is little difference between beta1 and beta2.

Mostly the empty /mnt in the rootfs SFS and @fredx181 's code modification to swapper.sh are the changes.

I have tried to do a total system update, which was successful but did not improve the bug.

I can confirm the issue. Same with me on /mnt/sda2/isos and several other of directories I have myself in that sda2 directory. No idea why rox immediately crashes.
I am not in KLV right now, but also noticed several processes constantly running that I don't know what they are formal (but maybe normal and likely nothing to do with rox issue); for example: curl command; sed command - I tried killing these but they keep coming back so I guess part of background service of some sort, but for rox issue I have no idea. Thunar is indeed apparently fine.

[wiak]

I have a theory that seems to be correct thus far about the rox issue, but I don't know the cause or the solution.... FORGET IT - theory no good; see below

The theory, or how it seems to be, is a 4GB limit. Any directory under that size opens fine in rox, but rox crashes if above that.

So, if turns out to be the reason, that will be a big clue. But how to track down what is causing that limit - and only for rox, not for thunar...!!! and a new problem, you say in this release (I no longer have alpha1 to test). I rather suspect that Void rox compile, though maybe something new added conflicting with it - I don't know. Is it a different binary/libraries involved with that rox than the one in alpha1?

EDIT: trashed my 'theory' already. The KLV-Airedale directory also causes crash, and a couple of others under 4GB so that's not it... hmmm ... problematic
Maybe something you are doing with symlinks to directories that rox somehow not liking? I haven't been following the thread closely of late cos too busy with weedogit

Now downloading KLV beta1 (using weedogit.sh, as it happens - just entered beta1 for revision and happy to find that finds correct iso).

I can also confirm that the rox issue does not occur in beta1. I tookt he ROX-Filer app from there and put in beta2 /usr/share, but problem still exists. I again can't help wondering if that ROX-Filer is no good because of some lib changes in beta2, but maybe something simple else - did you do anything fundamentally different re: the filesystem hierarchy or symlinks going from beta1 to beta2?; could be a big problem, though I hope not. It is a weird one.

[rockedge]

@wiak That's the funny thing. I did not change much between beta1 and beta2.

These are the changes I made, removed all the entries in /mnt from the 07KLV-airedale_rootfs.sfs and added the modified code from @fredx181 in /root/my-applications/bin/swapper.sh and squashed the rootfs again.

I will take the 07KLV-airedale_rootfs.sfs from beta1 and unsquash it (is that an actual English word?) and I can start again from there to track down the problem.

socklog-void is doing a good job logging and I had this in the base builds of WDL-Void which I like to call WeeDog64-Void (or WeeDog32-Void since I've made both via PLUG file), so I'm pondering adding it to KLV-Airedale.

But now this Rox crash needs to be sorted out first before anything else. I thought for a minute maybe two, that beta2 would lead right into rc1.

I have examined htop running in beta1 and there is NO curl or sed going! This might be a clue. There should be NO curl or sed running continuously and I will begin immediately to examine this in beta2. Perhaps I added a package one of us made that is curl'ing and sed'ing for some reason. I must start to look at this. This might be a big clue pointing to something unwanted.

UPDATE I have no sign of either curl or sed processes running. Rox can open /mnt/sda1 which is also around 148 Gb but if I attempt to go into /mnt/sda1/ISO Rox crashes immediately. Any try in /mnt/sdb1 crashes Rox BUT if I use Thunar and use it to go into /mnt/sdb1/KLV-Airedale-beta2 then using Thunar open a terminal and in that terminal start Rox, it will open no problem. But going up one level with Rox into /mnt/sdb1 again immediate crash.

[rockedge]

This is the error reported in /var/log/socklog/messages/current after using Rox and seeing the crash ->

Code: Select all

ROX-Filer[880]: segfault at 7fffe35adff0 ip 0000000000466725 sp 00007fffe35adff0 error 6 in ROX-Filer[400000+8c000]
2022-02-27T15:33:36.46742 kern.info: Code: c8 fa ff 5b 48 89 ef 5d 41 5c e9 46 c8 fa ff 66 0f 1f 44 00 00 41 56 41 55 41 54 55 53 48 83 ec 10 4c 63 77 08 45 85 f6 7e 53 <48> 89 34 24 48 c7 44 24 08 00 00 00 00 45 31 e4 4c 8b 2f eb 0e 66

[bigpup]

Maybe something here can help
http://rox.sourceforge.net/desktop/node/16.html

[rockedge]

Started like this in a terminal: rox --debug using gdb

Screenshot(3).gif (260.66 KiB) Viewed 819 times

not much more than seg fault is indicated in the several methods I am using to track the error(s)

I've also after installing acl-progs noticed other small errors disappear that were not really noticed before examining detailed logs. That the use of setfacl was required by pulseaudio and was missing. It didn't seem to effect pulseaudio that much but the addition silenced the nagging in the log's.

[rockedge]

This is a run of Rox using valgrind to track what is happening.

rox --valgrind -n

Code: Select all

root# rox --valgrind -n
==8426== Memcheck, a memory error detector
==8426== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==8426== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==8426== Command: /usr/share/ROX-Filer/ROX-Filer -n
==8426== 
==8426== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==8426== 
==8426== Process terminating with default action of signal 11 (SIGSEGV)
==8426==  Access not within mapped region at address 0x1FFE801FF0
==8426== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==8426==    at 0x466725: ??? (in /usr/share/ROX-Filer/ROX-Filer)
==8426==  If you believe this happened as a result of a stack
==8426==  overflow in your program's main thread (unlikely but
==8426==  possible), you can try to increase the size of the
==8426==  main thread stack using the --main-stacksize= flag.
==8426==  The main thread stack size used in this run was 8388608.
==8426== 
==8426== HEAP SUMMARY:
==8426==     in use at exit: 2,813,227 bytes in 38,825 blocks
==8426==   total heap usage: 150,483 allocs, 111,658 frees, 13,303,161 bytes allocated
==8426== 
==8426== LEAK SUMMARY:
==8426==    definitely lost: 9,148 bytes in 251 blocks
==8426==    indirectly lost: 27,535 bytes in 1,113 blocks
==8426==      possibly lost: 37,243 bytes in 1,088 blocks
==8426==    still reachable: 2,607,717 bytes in 35,324 blocks
==8426==         suppressed: 0 bytes in 0 blocks
==8426== Rerun with --leak-check=full to see details of leaked memory
==8426== 
==8426== For lists of detected and suppressed errors, rerun with: -s
==8426== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Segmentation fault

@wiak this might be something like you mentioned about the memory size overflow theory.
ALSO I remember now installing a MIME definitions package from @fredx181 . I wonder if that has something to do with it.

Code: Select all

==8486== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==8486== 
==8486== Process terminating with default action of signal 11 (SIGSEGV)
==8486==  Access not within mapped region at address 0x1FFE801FF0
==8486== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==8486==    at 0x466725: ??? (in /usr/share/ROX-Filer/ROX-Filer)
==8486==  If you believe this happened as a result of a stack
==8486==  overflow in your program's main thread (unlikely but
==8486==  possible), you can try to increase the size of the
==8486==  main thread stack using the --main-stacksize= flag.
==8486==  The main thread stack size used in this run was 8388608.
==8486==

This is the very end of the backtrace

Code: Select all

#262054 0x00007ffff78e4b6f in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#262055 0x00007ffff78e4f18 in ?? () from /usr/lib/libglib-2.0.so.0
#262056 0x00007ffff78e520b in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#262057 0x00007ffff7ca21aa in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#262058 0x0000000000415971 in ?? ()
#262059 0x00007ffff70cce0a in __libc_start_main (main=0x414d70, argc=2, argv=0x7fffffffea68, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffea58) at ../csu/libc-start.c:314
#262060 0x0000000000415a4e in ?? ()

[wiak]

In another thought, I wonder if an xbps upgrade to beta1 brings in new libs that cause rox issues? I haven't tried - busy trimming trees...

The better the plugin build you have, the easier to simply rebuild and slowly add anything back in that isn't in the plugin. Worth seeing if a brand new plugin build works with rox okay anyway - could take forever with no resolution trying to find the needle in the haystack otherwise.

[dimkr]

This is a run of Rox using valgrind to track what is happening.

Looks like the ROX-Filer executable is stripped, or at least, you don't have the debugging symbols. It will be much easier to debug this if you rebuild ROX-Filer, this time with -g -O0.

[rockedge]

@dimkr Good point and I see the complaints starting up in debug that the debugging symbols are missing so it makes sense to try this. I will do it because I would like to find out what I did to cause this.

I have dropped to a version that works well and will again see if I can add in the last changes to check how it goes again. Beta2 had also an issue that alpha13 did not have which is Xorg server crashing when switching tty1 to tty2 and back again. Should go cleanly back into the running xfce4 desktop. But beta1 and beta2 the Xserver crashes. An exit command on the console does again the tty1 autologin but this not how it should work. Alpha13 does this cleanly and Rox works error free.

So I will start from this version and add the few changes that made it beta1 and beta2 and try again with beta3!

[wiak]

Well... rox is not the issue per se (though I don't know what is).

I just built a new version using build_firstrib_rootfs and the last plugin I have, which was for alpha5. Though lots have been added since, we have to remember that Void Linux is a rolling release so the build I just made is the latest underneath in terms of core files, libs, rox, and so on.

rox works fine in this one.

I therefore think rebuilding rox with debug info is actually likely to be a waste of time. Better to start a fresh build (as I have done) and re-incorporate the additions. A lot of work I know, but pretty much guaranteed to produce the most up-to-date error-free build. The more you have managed to script into more recent build plugin the better of course - in fact I really recommend keeping your build plugin up to date every time you add a new facility - takes a bit extra time to script such alterations but well worth it in practice at times like this.

Code: Select all

bash-5.1# rox --version | grep version
Compiled with GTK version 2.24.24
Running with GTK version 2.24.33
bash-5.1# rox --version | grep Filer
ROX-Filer 2.11
ROX-Filer comes with ABSOLUTELY NO WARRANTY,
You may redistribute copies of ROX-Filer
bash-5.1# ldd --version
ldd (GNU libc) 2.32
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
bash-5.1# firefox --version
Mozilla Firefox 97.0
bash-5.1#