Porteus

All ZSTD compression

Porteus-OPENBOX-v5.0rc2-k5.9rc7-x86_64.iso (468 M)
http://www.mediafire.com/file/qcrdwjt8a ... x86_64.iso
md5sum: fd572f9723f02485c92ca002ab5dbcaf Porteus-OPENBOX-v5.0rc2-k5.9rc7-x86_64.iso


It is an ISO composed of all ZSTD compression with overlayFS kernel 5.9-rc7.

1.Kernel: 5.9-rc7 (without AUFS)
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_KERNEL_ZSTD=y

2.initrd:
CONFIG_RD_ZSTD=y
Porteus-OPENBOX-v5.0rc2-k5.9rc7-x86_64/boot/syslinux/initrd.zstd:
Zstandard compressed data (v0.8+), Dictionary ID: None

3.XZM:
Porteus-OPENBOX-v5.0rc2-k5.9rc7-x86_64/porteus/base/*.xzm
zstd


P.S.
I am trying to try something new by interrupting the posting on the Porteus forum site.
One of the challenges is to implement APorteus with OVERLAYFS.
I applied the result to Porteus.
This post is an interim report of the results.
I will return to work to try new things.


Thanks.

--------------------------
[updated on 2020.08.31] kernel & initrd of Porteus-OPENBOX-v5.0rc2-k5.9rc1-x86_64.iso were updated to 5.9-rc3.
[updated on 2020.09.21] kernel & initrd of Porteus-OPENBOX-v5.0rc2-k5.9rc6-x86_64.iso were updated to 5.9-rc6.
[updated on 2020.09.28] kernel & initrd of Porteus-OPENBOX-v5.0rc2-k5.9rc7-x86_64.iso were updated to 5.9-rc7.

Hi neko.

Just came back to thank you for all your efforts and work.

All the best.

Cheers!

Hello neko,

As far as i remember overlayfs did not allow to insert new branches (modules) to the live filesystem.
Meaning that you could not activate new modules during the Porteus session.

Did anything change in this matter or its still the same?


Thanks

@M. Eerie
Thank you for your words of encouragement.
But I still continue to try many new things without participation Porteus forum.
And when I will get some result, I will report it same as "All ZSTD".

Thanks.


@fanthom
After booting Porteus-OPENBOX-v5.0rc2-k5.9rc3-x86_64.iso,
a new XZM module can be activated/deactivated.
Please try Porteus-OPENBOX-v5.0rc2-k5.9rc3-x86_64.iso.

It has a ristriction that activated XZMs during booting can not be deactivated.

Thanks.

neko wrote: ↑

20 Aug 2020, 11:09

After booting Porteus-OPENBOX-v5.0rc2-k5.9rc1-x86_64.iso,
a new XZM module can be activated/deactivated.

It has a ristriction that activated XZMs during booting can not be deactivated.

Hi neko,
If so, does Porteus still need Aufs?

neko,

it boots really fast! (at least to text mode)

Too bad that uvesafb driver is not compiled: I cant test your ISO in VirtualBox as Xorg crashes.

Hmmm .....

I have booted with 'vga=791' kernel parameter and framebuffer is initialized now.
Still cant start the Xorg though ... not sure whats wrong.


Standard Porteus ISO works ok in VirtualBox:
http://ublaze.ru/Porteus-v5.0rc2/Porteu ... x86_64.iso

Only your build is causing troubles - please check it when you get a chance.


Thanks

@fanthom
Please try Porteus-OPENBOX-v5.0rc2-k5.9rc3-x86_64.iso.
http://www.mediafire.com/file/qqj1xzwhw ... x86_64.iso

Thanks.

----------------------
[updated on 2020.08.31] kernel of Porteus-OPENBOX-v5.0rc2-k5.9rc3-x86_64.iso was built with CONFIG_FB_UVESA.

neko...Excellent, booted at first attempt. As usual, zstd is really fast. 8 seconds to desktop. I added some modules and made some changes to suit my way of doing things. Built a changes modules from porteus setting centre. Things work perfectly after reboot.

Just to compare, I did the same with official Porteus 5.0rc2. Booted in 11 seconds. On reboot after inserting "changes" module, found Network Manager was disabled. Disabled changes module, still no network. No heart to pursue further to probe. It has been a struggle with new releases.

Contents remain same for both, except compression and aufsVS overlay.

If you have compiled a "Conky" modulefor this release, which prints on the desktop wallpaper please upload.

Good luck in your mission. Great work.Cheers.

Just now found "changes" were not saved in he module prepared by Porteus setting centre. May be the script is incomplete.

@neko, nice job, very interesting , thank you.

raja wrote: ↑

20 Aug 2020, 18:09

Just now found "changes" were not saved in he module prepared by Porteus setting centre. May be the script is incomplete.

looks like the changes work differently with this overlayfs: /mnt/live/memory/changes/upperdir looks like where the live changes are situated.
so, it's that the script is not adapted for this system.. a minor change, i should think. (although this is also one the scripts on the list for pygobject conversion)

@babam
"If so, does Porteus still need Aufs?"
---->
If Aufs will be maintained under good timing, it will be needed.
Because it is just fit to Porteus usage more than OverlayFS.

Thanks.


@raja, @ncmprhnsbl
Overlayed Temporary Areas of AUFS and OVFS are difference.
Therefor the construct of "changes" areas are difference each other.

Thanks.

Note:
Introducing OverlayFS into Porteus is under constructing.
So it might have some bugs.