Porteus

Hello,

I have looked into some scripts that are being used to create modules: "lzm2xzm", "dir2xzm", "txz2xzm" etc.
They all use "liblinuxlive" and a call to "create_module" to actually create the module.
This does not always work for me and certainly often breaks with some squashfs-error message.

I solved this by replacing "create_module" from all the scripts, and calling "mksquashfs" instead.

For example, "txz2xzm" contains:

create_module $TMPDIR "$2"

I replace it by:

mksquashfs $TMPDIR "$2"

Same for "dir2xzm", etc.

Works wonders for me, maybe should be implemented this way in the final Porteus 1.0 .

Regards
ATT

For developper , that's a good idea.

But , for a normal user , We must stay with create_module function. The functions are optimized for older machine. If an user with a older machine use the argument -b 1M , Porteus will be very slow at boot for older machine.

Good Idea.

@att
when you look at liblinuxlive you will see that create_module function does exactly same thing:
"mksquashfs "$1" "$2" -b 256K -Xbcj x86 $3 $4 $5 $6 $7 $8 $9"

i have no idea why it makes troubles for you - never does for me.
it's easier to change settings in one file (liblinuxlive) then in all separately.

I was a little confused about the create_module at first. Now I understand its use. I think it is quite funny that on the main page we have.

It's small (under 300Mb) and insanely fast which allows you to start up and get online while most other operating systems are left spitting dust. Porteus comes in both 32 & 64 bit and aims to keep on the bleeding edge. It also supports several different languages and the user forum has language sections. Join the community now!

aims to keep on the bleeding edge

Hamza wrote:We must stay with create_module function. The functions are optimized for older machine.

I do understand why we keep support for the older machine crowd. It would make it just a little easier to comprehend the scripts, if we take att's suggestion on this. For normal users with little experience, they are not going to be running a muck modifying the blocksize in the dir2xzm, etc... scripts.
I side with Hamza on this is. The way it is implemented does well for keeping compression uniform. Uniformity keeps it simple, for troubleshooting.

82issa, what we've found is that using a larger block size in the compression makes the filesize of the modules smaller, but it slows down the compression and decompression speed. I may be wrong here, but I think that is the case whether you're on older hardware or newer hardware. Smaller block size = faster system with a slightly larger ISO. Larger block size = slower system with a slightly smaller ISO.

I've also not had issues with the *xzm* utilities, except when I was trying to use it with the wrong version of mksquashfs (my fault, not a problem in default porteus, except for 32bit V1.0 BETA, if you remove the xorg module from /porteus/base).

Not a terrible suggestion tho @att.

@Ahau I was just stating that I don't think anyone is intentionally going to change the blocksize. I do understand the pro/cons of adjusting the blocksize.

@82issa sorry, I misread your post! Bad Ahau!