KLV-Airedale-rc6.1 with Void Linux Kernel is Available!

[Sofiya]

save2flash on gtkdialog-splash

Code: Select all

#!/bin/bash

if grep -q "w_changes=RAM2" /proc/cmdline || grep -q "w_changes1=RAM2" /proc/cmdline; then
 if [ "$(mount | grep /mnt/layers/uc_ro | grep rw)" ]; then  

  if [ "$DISPLAY" != "" ]; then
gtkdialog-splash -text "Saving Session . . ." -placement center -close never -align right -bg_gradient_sens strong -font 'DejaVu Serif' -fontsize 16 -fontstyle normal -fontweight bold -fg '#000000' -bg '#B5B37F' -icon "/usr/share/pixmaps/spinner.gif" -icon_width 0 -margin_width 10 -margin_height 10 -bg_gradient true -border true -wrap true -ontop true &
pd=$!
/usr/bin/snapmergepuppy
sleep 4
kill $pd
  fi 

 else
yad --center --title="Save session" --text=" \n    Cannot run save session on demand\n    Directory <b>/mnt/layers/uc_ro</b> not connected  " --width=480 --button="Close!gtk-close:0"
exit
 fi
 
else
yad --center --title="Save session" --text=" \n    Cannot run save session on demand\n    Boot with option <b>w_changes=RAM2</b> or <b>w_changes1=RAM2</b> \n    to make use of this feature  " --width=480 --button="Close!gtk-close:0"
fi
 
 

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

Code: Select all

#!/bin/bash

if grep -q "w_changes=RAM2" /proc/cmdline || grep -q "w_changes1=RAM2" /proc/cmdline; then
 if [ "$(mount | grep /mnt/layers/uc_ro | grep rw)" ]; then  

  if [ "$DISPLAY" != "" ]; then
gtkdialog-splash -text "Saving Session . . ." -placement center -close never -align right -bg_gradient_sens medium -font 'DejaVu Serif' -fontsize 16 -fontstyle normal -fontweight bold -fg '#000000' -bg '#A3E7FF' -icon "/usr/share/pixmaps/spinner.gif" -icon_width 0 -margin_width 10 -margin_height 10 -bg_gradient true -border true -wrap true -ontop true &
pd=$!
/usr/bin/snapmergepuppy
sleep 4
kill $pd
  fi 

 else
yad --center --title="Save session" --text=" \n    Cannot run save session on demand\n    Directory <b>/mnt/layers/uc_ro</b> not connected  " --width=480 --button="Close!gtk-close:0"
exit
 fi
 
else
yad --center --title="Save session" --text=" \n    Cannot run save session on demand\n    Boot with option <b>w_changes=RAM2</b> or <b>w_changes1=RAM2</b> \n    to make use of this feature  " --width=480 --button="Close!gtk-close:0"
fi
 
 

[wiak]

@Clarity which distro's ISO does Ventoy boot? I need to see the differences in the overall boot mechanism.

I don't know anyone who uses Ventoy. I still don't see any advantages at all for using it over QEMU. My setup of Ventoy uses an exFAT partition for the ISO storage. I still have not manged to get many things running on Ventoy usb drives, nothing that would make me stop and say this is the bee's knees.

Straight Ventoy boot of KLV rc6.1 definitely works on my laptop (using Ventoy configured usb stick and putting KLV 6.1 iso in either root folder of that or in /BOOTISOS). Works very well in fact, and can optionally use a different partition (even on a different drive) as long as that partition is named 'Persistence' and the directory on it is named 'Sessions'. I use that for w_changes=RAM2 save on demand mode. I wouldn't worry about it just now. It is odd that SG2D works for Clarity with KLV, but not Ventoy - I can't fundamentally see the difference in terms of kernel/modules or whatever. One (SG2D) uses the iso's internal boot/grub/loopback.cfg to perform its magic, the other (Ventoy) uses the internal boot/grub/grub.cfg, which also works fine for me (and should by design) - any issue isn't a KLV Ventoy incompatibility - has to be something else re Clarity's machine or set up. The stanzas used in loopback and grub.cfg are certainly supposed to be different because SG2D adopts a different approach where it passes the full pathname of iso onwards - Ventoy doesn't do that so that information is supplied directly in the grub.cfg.

Other distros appear to adopt very complex search routines to find everything, but KLV was designed to expect the user to enter uuid or label values in the grub configurations rather than relying on whole system auto-find routines; that's why the iso internal boot/grub/grub.cfg actually contains LABEL information and the initrd/init only has one relatively simple search for known iso path to ascertain the partition it is in (still needs to know the full path to the iso - SG2D as I say passes that onwards to the initrd/init, Ventoy doesn't so the grub.cfg simply gives the path (being either / or /BOOTISOS). Works.

So the issue for Clarity machine is something else - perhaps kernel related, but I wouldn't know off the top of my head and am surprised anyway if, as I say, SD2D works for Clarity with KLV, but Ventoy doesn't. However, proof is in the pudding as they say - but I can't say what might be the issue for Clarity machine. Perhaps time will provide technical clues such that maybe a different kernel (huge kernel/modules easiest to swap in of course) fixes things for him. On the whole, the distro is fine with normal frugal installs so that is the main thing anyway - that is what it was designed primarily for; the rest is a bonus that I don't myself feel deserves too much dev time in comparison. Sorry if that is hard, but we have to prioritise efforts and human resources generally on what is most useful or desired overall.

I'm lucky maybe; all of qemu, Ventoy, SG2D, straight grub2 iso boot, and normal frugal installs (and pseudo full installs) work fine on my computers with KLV rc6.1 (even booting from sdcard from SD interface slot works fine on my older computer with this release and its modules fix - note that an sdcard plugged into a card reader is a simpler matter - that's just like a usb stick then, the SD card slot needed special modules support which rc6.1 includes). Some computers do not like everything about some kernels, however, that's just a noticeable fact for all distros.

[Phil_54]

@wiak
I downloaded a fresh rc6.1 iso and shasum-ed ok. Mounted and copied files one at a time.
I followed exactly as you described in viewtopic.php?p=78043#p78043, using sync;sync for each progressive file.
I put them both in root folder/ and also in sub folder /klv61.
My boot stanzas were copied from yours that you posted and modified for UUID and folder name appropriately. Sorry I don´t know how to post like you did, within a frame. Edit: followed guidance from @rockedge.

Code: Select all

title klv6.1 sdcard/klv61
  find --set-root --ignore-floppies /klv61/grub_config.txt
  kernel /klv61/vmlinuz w_bootfrom=UUID=81c65d04-c9ca-5e4a-7cc7-a8d1bce29dcb=/klv61 w_changes=RAM2
  initrd /klv61/initrd.gz

title klv6.1 sdcard
  find --set-root --ignore-floppies /grub_config.txt
  kernel /vmlinuz w_bootfrom=UUID=81c65d04-c9ca-5e4a-7cc7-a8d1bce29dcb=/ w_changes=RAM2
  initrd /initrd.gz

Neither booted, but hung after initrd line. Initially I did not copy the grub_config.txt file as I thought it irrelevant, but because it is in the stanza it gave an error about missing file. No error thrown up after putting grub_config.txt in.
I don´t have another sdcard to try pristine.

Ventoy and Ventoy/SG2D fails to boot rc 6.1 and beta25. (SG2D doesn´t list them anywhere I could see). My ventoy/SG2D works very well on standard distro iso's.
It also fails on a debiandog iso that I have.

Thanks for all your efforts, and I'm glad it boots on your sdcard, proving it works. My chromebook/sdcard/firmware must be inadequate for the void kernel. The debian kernel is great in beta25. All previous beta's were also fine.
I'll continue with beta25 for now.

Sorry to have taken up so much of your time.

[wiak]

Neither booted, but hung after initrd line. Initially I did not copy the grub_config.txt file as I thought it irrelevant, but because it is in the stanza it gave an error about missing file. No error thrown up after putting grub_config.txt in.
I don´t have another sdcard to try pristine.

Ventoy and Ventoy/SG2D fails to boot rc 6.1 and beta25. (SG2D doesn´t list them anywhere I could see). My ventoy/SG2D works very well on standard distro iso's.
It also fails on a debiandog iso that I have.

Thanks for trying Phil. The grub_config.txt file, by the way, is simply used as a 'marker' file in that boot stanza; isn't actually used in the boot itself (it is just a txt file for humans to read). By marker file, I just mean a way to tell grub4dos it is at the relevant folder (I noticed the need for that when reading grub4dos config file needs when using LABEL method - prior to discovering that I didn't even know grub4dos could handle that case).

Pity I don't have a machine like yours to test, but I agree from your tests with your opinion that something about the kernel (or more likely the modules from that kernel used inside the intird.gz) isn't satisfactory for your machine. You haven't wasted any of my time; rather you led me to notice that modules for sdcard booting were missing. Prior to the fix I then made, rc6.1 would not have been able to boot on my old HP 2560p laptop either, but it can now.

In summary, no waste of time involved at all, and maybe still just a module short of working on your machine, or maybe just not suitable for your computer afterall. The fact it works (Ventoy and all) with many other distros suggests to me it could be made to work with Void kernel too. If you don't mind, there is one more test we could do, which is to use a much bigger initrd.gz that includes all the modules that Void Linux provides by default. That is not hard for me to build so I'll do so anyway since can always later be tried on anyone's computer that is having similar difficulties. Worth a try I'd say and more so since if it works then it becomes easier to track down what the difference is. Of course, it could be a firmware issue, which would be the last thing I'd try (Void Linux official firmware is pretty huge). Actually, I doubt it is firmware, per se, since the beta25 release came with same firmware as 6.1 as far as I recall.

I was hoping to re-download the linux kernel 6.1 from Void along with its modules, but unfortunately I note that 3 hours ago Void Linux upgraded it to a slightly later version so the modules for that newer release won't do for KLV rc6.1 release. But I'm hoping (and think it is likely) that 00modules.sfs contains all the modules that were available for KLV rc6.1 and I'll simply shove a copy of all of them into the initrd.gz. If that doesn't work on your machine, I guess we have to give up on this release!

Actually, it is clear from your previous tests you know what you are doing so, though I will build a copy, I'll tell you the steps how to do it here:

1. In the directory where you have a frugal install of latest KLV rc6.1, open a terminal (for these instructions I refer to this as 'terminal 1') and fetch a copy of the shell script modify_initrd_gz.sh into your KLV rc6.1 frugal install directory, which can be done by using command:

Code: Select all

wget -c https://owncloud.rockedge.org/index.php/s/HRZhsnouSm3Gpf3/download -O modify_initrd_gz.sh && chmod +x modify_initrd_gz.sh

2. Now run that script using command:

Code: Select all

./modify_initrd_gz.sh initrd.gz

To produce a decompressed version of initrd.gz in its own folder named "initrd_decompressed". The procedure does not delete the original initrd.gz.
Do not close that terminal (terminal 1) or type any new commands into it thereafter till we have modifed the contents of the that initrd_decompressed directory that has been automatically been created in your frugal install directory.

3. What we are going to do now is simply go into that initrd_decompressed directory, using your filemanager to location initrd_decompressed/usr/lib/modules and delete the contents of that modules directory (6_0_12_1 or whatever version it is) because we are going to replace it with a full set of same kernel version modules prior to trying a reboot with some hope of success(?).

4. Hopefully (and I think) the full set of kernel modules are in 00modulesXXX.sfs, so assuming you are on a different KLV host or a Puppy system or a DebianDog when doing this modification/development work, just clicking in your filemanager on 00modulesXXX.sfs should open it up in a separate filemanager window; in that opened up result you go to usr/lib/modules and there you should see the 6.0_12_1 (or whatever version it is for current supplied kernel) subdirectory.. Continuing to use your file manager to do this, simply copy that 6.0_12_1 subdirectory (or whatever version number it has) into your initrd_decompressed/usr/lib/modules directory.

5. Finally, in the first terminal (the one we called terminal 1), simply enter the word: exit
and wait for a bit whilst the initrd_decompressed directory gets automatically compressed for you again.

6. Actually, there is one last simple step prior to trying to boot the system. The newly made full-module-set initrd.gz has been created with a datestamp in its name. You need to disable (meaning rename) the original initrd.gz and then rename the new datestamp version simply initrd.gz so that grub will find it. Now reboot, and good luck...

I would really like to get this one to work if possible, since same full module set initrd.gz might well then work for others, such as Clarity after which we may well be able to track down which extra modules made the difference.
Not wanting to be too optimistic, above might well not work... but worth a try maybe...

[wiak]

@Phil_54

EDIT: Below initrd didn't seem to originally work in my test so thought I maybe made it wrong. So I made new pristine KLV rc6 frugal install and tried it again and per EDIT2 the replacement full modules set intrd provided here worked on my system at least.
EDIT2: Okay, it did work for me though please check your original KLV rc6 was using kernel version 6.0.12_1 since that's what the following full module set initrd gz uses (just worried in case I am not using correct KLV rc6.1 iso, but think I am and don't want to download new one if I can avoid it...

Did it quickly, so not sure if correct, but here is my KLV rc6 full modules set initrd.gz (needs renamed to boot with):

https://mega.nz/file/7noQRYCZ#yvIHIbjAI ... 2t2UZufjxM

md5sum for this is 78b809ef1a2e9ad7f0515697f904d4f7

Note that this is a very big initrd since has all that full set of modules inside it (156MiB), but that doesn't matter in usage terms really (well... might take a noticeable bit longer to start up since loaded into RAM).

May or may allow more tricky computers to boot via usb stick or sdcard or Ventoy or whatever (well, not via Ventoy unless made into new iso of course - so just useful for normal frugal install test just now). Just a try anyway. My immediately above post describes how to make similar for yourself, which is a handy skill should you wish to try alternative kernel/module combinations on your KLV system.

@rockedge, for my peace of mind could you kindly confirm that KLV rc6 uses kernel version 6.0.12_1 (as in usr/lib/modules)?

[wiak]

Despite KLV rc6 not booting on some users machines/configurations I am confident I have KLV booting well now on Ventoy (on machines where there are not other issues such as kernel version).

The point to understand about using KLV (and any FirstRib initrd-based distro) with Ventoy, and similar, is that it is essential for the internal-to-iso config files to be created with entries that work... In current KLV releases, for Ventoy, that fact refers to the iso boot/grub/grub.cfg entries. Currently no user editing should be necessary to achieve save on demand w_changes1=RAM2 mode savefolder persistence with Ventoy, which is very handy (I personally find) indeed.

For SG2D it is the iso including loopback.cfg file, which I have not yet optimised for best SG2D usage (some manual editing at boot time probably required to achieve save on demand RAM2 mode savefolder persistence at this stage. I'll fix that better for later releases.

What is probably a more important use-case from my own usage perspective is Qemu, which I have thus far only used to boot KLV either as a normal frugal installation on a qemu image disk or as a no persistence w_changes=RAM0 mode boot.

KLV currently uses its internal to iso grub4dos menu.lst to boot from an actual iso and thus also from a qemu cdrom="KLVxxxxx.iso" (though could be done using syslinux directly or grub2 for that matter). I'm currently checking qemu booting out now in case I can improve the menu.lst in any way or offer advice on good way to use qemu with KLV (though I think rockedge has already established a good approach). I'll report back my overall findings eventually. Going slow now, as I said somewhere since summer here and my brain was near burn out level for a while (though after some recent sleep is actually back working not too badly right now - even managed to win a few online chess games again... sigh... what a struggle...).

Actually I'm also curious about a hybrid approach Clarity employs sometimes - using a Ventoy iso in qemu to then boot distros - I'd like to see if I can get that working with KLV (or if it already does on my machine). I'm not sure if I have a great use for that method, but who knows till I try it and think about the uses more? Fact is I'm often stuck in Zorin because we use it for business, so a 'virtual world' based around qemu is particularly relevant to me. By the way, I'm using Zorin lite xfce OS right now, but only as a host - I'm posting from KLV-Airedale rc6 running in qemu instance.

[wiak]

@rockedge
Just wondering what method you use to share files (back and forwards) between host system and your qemu virtual machine? To me, that is the tricky problem that needs a usable solution when using virtual machines. I do have an idea to share a folder (I didn't invent the idea but haven't used it before, but found it works), but want to know what people on this forum already use.

One day, eventually, I want to get back to using Kubernetes as a manager of containers built using the small components containerd and runc, which I briefly touched on here, where I used a container (only time I've done so) to run Fedora OS inside my Zorin lite OS host, but there is not enough time in the day and whilst I imagine virtual machines being heavier on system resources than container technologies, I'm not sure by how much, and I'm much more familiar with that technology. In fact twenty years ago most of my professional work was done using a mix of vmware and shared cow file based User Mode Linux networked virtual machines; qemu wasn't so well developed back then, but great now, so I may end up not bothering with containers at all despite the technological usefulness of it all... Just depends how much energy/enthusiasm I have to further experiment I suppose.

[Phil_54]

Neither booted, but hung after initrd line. Initially I did not copy the grub_config.txt file as I thought it irrelevant, but because it is in the stanza it gave an error about missing file. No error thrown up after putting grub_config.txt in.
I don´t have another sdcard to try pristine.

Ventoy and Ventoy/SG2D fails to boot rc 6.1 and beta25. (SG2D doesn´t list them anywhere I could see). My ventoy/SG2D works very well on standard distro iso's.
It also fails on a debiandog iso that I have.

Thanks for trying Phil. The grub_config.txt file, by the way, is simply used as a 'marker' file in that boot stanza; isn't actually used in the boot itself (it is just a txt file for humans to read). By marker file, I just mean a way to tell grub4dos it is at the relevant folder (I noticed the need for that when reading grub4dos config file needs when using LABEL method - prior to discovering that I didn't even know grub4dos could handle that case).
......

1. In the directory where you have a frugal install of latest KLV rc6.1, open a terminal (for these instructions I refer to this as 'terminal 1') and fetch a copy of the shell script modify_initrd_gz.sh into your KLV rc6.1 frugal install directory, which can be done by using command:

Code: Select all

wget -c https://owncloud.rockedge.org/index.php/s/HRZhsnouSm3Gpf3/download -O modify_initrd_gz.sh && chmod +x modify_initrd_gz.sh

2. Now run that script using command:

Code: Select all

./modify_initrd_gz.sh initrd.gz

To produce a decompressed version of initrd.gz in its own folder named "initrd_decompressed". The procedure does not delete the original initrd.gz.
Do not close that terminal (terminal 1) or type any new commands into it thereafter till we have modifed the contents of the that initrd_decompressed directory that has been automatically been created in your frugal install directory.

3. What we are going to do now is simply go into that initrd_decompressed directory, using your filemanager to location initrd_decompressed/usr/lib/modules and delete the contents of that modules directory (6_0_12_1 or whatever version it is) because we are going to replace it with a full set of same kernel version modules prior to trying a reboot with some hope of success(?).

4. Hopefully (and I think) the full set of kernel modules are in 00modulesXXX.sfs, so assuming you are on a different KLV host or a Puppy system or a DebianDog when doing this modification/development work, just clicking in your filemanager on 00modulesXXX.sfs should open it up in a separate filemanager window; in that opened up result you go to usr/lib/modules and there you should see the 6.0_12_1 (or whatever version it is for current supplied kernel) subdirectory.. Continuing to use your file manager to do this, simply copy that 6.0_12_1 subdirectory (or whatever version number it has) into your initrd_decompressed/usr/lib/modules directory.

5. Finally, in the first terminal (the one we called terminal 1), simply enter the word: exit
and wait for a bit whilst the initrd_decompressed directory gets automatically compressed for you again.

6. Actually, there is one last simple step prior to trying to boot the system. The newly made full-module-set initrd.gz has been created with a datestamp in its name. You need to disable (meaning rename) the original initrd.gz and then rename the new datestamp version simply initrd.gz so that grub will find it. Now reboot, and good luck...

I would really like to get this one to work if possible, since same full module set initrd.gz might well then work for others, such as Clarity after which we may well be able to track down which extra modules made the difference.
Not wanting to be too optimistic, above might well not work... but worth a try maybe...

@wiak
A miracle, at least to me.
I followed steps 1 to 6 exactly (you're a good teacher). Rebooted and here I am not that much later replying to you from RC6.1 on my sdcard/chrombook combo. Smooth, easy and pretty fast to boot considering initrd.gz size and my processor/memory constraints.
Thank you.
I guess you'll want to explore further what the differences are. If you need my support that's fine, but maybe in a separate thread, so all the other good folk reading this thread can get on with their questions and suggestions.

PS your follow on post pointed to an initrd file you'd created, but it was the one you made for me the other week for bespoke beta25 initrd with rc6.1 improvements.

[rockedge]

Sorry I don´t know how to post like you did, within a frame.

Highlight the text that is going into the code block ( code, script or configuration mostly ) and on the editor toolbar, click the </> button.
Or just before the text to code block manually type and place a [code] and at the very end a [/code] to close it

[wiak]

@rockedge
Just wondering what method you use to share files (back and forwards) between host system and your qemu virtual machine? To me, that is the tricky problem that needs a usable solution when using virtual machines. I do have an idea to share a folder (I didn't invent the idea but haven't used it before, but found it works), but want to know what people on this forum already use.

Continuing to wonder about the above @rockedge. I'm currently testing KLV on qemu and that kind of information is useful. Do you use samba or ftp or some other sharing between host and guest mechanism when you are using qemu?

In my current sharing experiments I am sharing very directly as the attached screenshot illustrates. I just created file OH_WOW (using touch command) in terminal on KLV virtual machine and the directory you see it immediately appearing in is in fact on the host system... I was really quite exciting it worked (I have a simple mind really); will explain this mechanism later.

I'm making this post from the KLV iso booted via qemu by the way. If I download a file inside the KLV virtual machine using its browser I can save directly to the underlying host (to the directory the iso was in).

[rockedge]

@wiak I usually turn on a pure-ftpd server on the host machine and then use Thunar ftp:// on the QEMU machine to connect to the host.
Here it is also very easy to use gftp to connect to pure-ftpd. I connect as 'root'

I gave up on folder sharing because support for this seems to be something that must be enabled in the kernel and so it is a pain to configure and iffy that it will work. I have not really looked closely enough to find a mechanism that you using to write directly to the host's partition's on physical drives.
It's very exciting actually!

During the betaXX series using some of the kernels I made and those from Debian, SAMBA worked through Thunar very well.
Example: Using F96 as host, turned on Samba via the Samba Simple Management. Then in the QEMU KLV-Airedale with Thunar, connect with smb://
Often selecting Network in Thunar shortcuts would detect samba shares and just clicking on them would start the connection process.

Then recently since using the Void Linux kernel the ability to connect with Samba via Thunar has stopped working so I use the FTP method because it is easy and reliable and I can access the entire file structure and all of the mounted partitions that the host machine has connected.

[wiak]

I gave up on folder sharing because support for this seems to be something that must be enabled in the kernel and so it is a pain to configure and iffy that it will work. I have not really looked closely enough to find a mechanism that you using to write directly to the host's partition's on physical drives.
It's very exciting actually!

It was exciting enough that I felt a bit shocked when I managed to get it working. It seems to be a reliable and secure method using Plan 9 Filesystem Protocol in Qemu. I've searched the forum but no-one seems to have posted as having used it before.

In 'theory' it seems it might be possible to use Qemu to boot from a normal frugal install directory and at the same time use this Plan 9 Filesystem Protocol to share the whole frugal install directory in either direction between the host and the guest VM. I haven't managed to get that working though. In my current 'experiments' (trying to do this) I have made initrd to include the extra modules required, and I modprobe them at boot time using w_addmodules= kernel line argument (since don't want them loaded unless for this special purpose). The modules are successfully loading, the KLV frugal distro boots as far as the switch_root, but fails to get past there at the moment - I end up at KLV initrd filesystem command line. From there running lsmod command evidences that the Plan 9 fs related modules are indeed loaded, but just doesn't switch_root (because, despite my intentions and loaded modules it is failing to see the underlying partition which I hoped would be visible via that Plan 9 fs.

When booting using qemu from iso (which is also very useful) the Plan 9 sharing works fine in both direction between the host and the guest, so that is a big win user-usage situation. Nevertheless the more complicated booting from an existing frugal install directory with Plan 9 fs sharing would be the icing on the cake...

[Clarity]

Between family visits, I will try to present a "HowTo" section in the upcoming QEMU-KVM User's Guide (KLV) for sharing a folder that a user can set to 'share' it to allowing moving information between the host and the VM(s).

I am awaiting some feedback from developers that will go into the Guide.

[dancytron]

I just tested the debian scripts that I usually use for zram and they seem to work fine. It might help low ram machines avoid/delay the browser lockup syndrome.

The slightly commented debian scripts is zram.sh. I made little start and stop scripts to go with it. see comments in zram.sh.

1. remove .gz,
2. put in /usr/local/bin
3. mark executable
4. start and stop with scripts
5. "zramctl --raw" to check status

edit: Link to original post

http://murga-linux.com/puppy/viewtopic. ... 747#980747

[Jasper]

@dancytron

Thanks for this

I also found this link on GitHub which contains a sample zramconf

Download the zipped file or copy, paste and save the code below as

zramswap.conf

place in

/etc/default (......tested in FP64-95 kernel 6.1.14)

https://github.com/highvoltage/zram-tools

Code: Select all

# Compression algorithm selection
# speed: lz4 > zstd > lzo
# compression: zstd > lzo > lz4
# This is not inclusive of all that is available in latest kernels
# See /sys/block/zram0/comp_algorithm (when zram module is loaded) to see
# what is currently set and available for your kernel[1]
# [1]  https://github.com/torvalds/linux/blob/master/Documentation/blockdev/zram.txt#L86
#ALGO=lz4

# Specifies the amount of RAM that should be used for zram
# based on a percentage the total amount of available memory
# This takes precedence and overrides SIZE below
PERCENT=50

# Specifies a static amount of RAM that should be used for
# the ZRAM devices, this is in MiB
# If PERCENT is set above it will override this
#SIZE=256

# Specifies the priority for the swap devices, see swapon(2)
# for more details. Higher number = higher priority
# This should probably be higher than hdd/ssd swaps.
#PRIORITY=100

[gychang]

I just tested the debian scripts that I usually use for zram and they seem to work fine. It might help low ram machines avoid/delay the browser lockup syndrome.

The slightly commented debian scripts is zram.sh. I made little start and stop scripts to go with it. see comments in zram.sh.

1. remove .gz,
2. put in /usr/local/bin
3. mark executable
4. start and stop with scripts
5. "zramctl --raw" to check status

edit: Link to original post

http://murga-linux.com/puppy/viewtopic. ... 747#980747

@dancytron testing on F96-CE4.iso installed on an 12yrs old fanless miniPC with 4G of RAM. I rebooted and got this. It seems to be working???

[dancytron]

Yes, it's working.

You can adjust the size inside the script. IIRC there are instructions in the comments.

[gychang]

Yes, it's working.

You can adjust the size inside the script. IIRC there are instructions in the comments.

my interpretation is 2.6G is saved as zram, seems reasonable with 4G of total RAM in my case...