Wow, I needed more coffee before I read this thread. Lotsa stuff...

FWIW IMHO best protocol:

1. Gparted: setup partitions
2. Devuan: Install normally and let system set normal permissions.

"But I want system to see other partitions including USB devices and let me open/read/use them with just a click from the user"

3. Then open /usr/share/polkit-1/actions/org.freedesktop.Udisks2.policy and edit accordingly. Settings will persist.

If I recall correctly, all I did this go-round, was:
Netinstall devuan 5 with core Mate desktop
Uninstall Pulseaudio, it demanded I install Pipewire in it's stead, I did so.
Then I uninstalled Pipewire, it didn't complain.
Added some extra packages for ALSA, alsamixer-gui to get mixer, and libasound equalizer package to get EQ, etc.

Mate works fine without anything but Alsa, and so does Openbox.

It's kind of freaky. Something's not right with something. The size of the data on the partition i'm concerned with is not in question, it's straight-up 2 gigs, no reason why it would squash much larger, the excalibur install is unquestionably smaller.

In fact it's blowing my mind, I just pulled out a ton more of stuff that was left in after the upgrade, old versions of libraries and binaries for things. Important stuff too. And now system size down to 1.9 gigs, same system in daedalus is 2.4.

The 6.12.6-amd64 kernel is listed at 109 mb in excalibur. The previous kernel I used in daedalus is listed at 408. WTH?

Kinda at a loss here...

Seems like something is getting rolled in to squashfs that should be excluded.

Off-topic: Getting a hella delay during boot right after "waiting for /dev to be populated".

Vuu-do 5.02 openbox mini and max versions compressed with zstd instead of xz for faster decompression during live sessions. 1st versions for testing. Results on older hardware tested so far are faster boot, faster program loading/opening and less lag time on first open, and faster install from liveUSB session. YMMV.

https://sourceforge.net/projects/vuu-do … do-5-zstd/

Running right now on a Corsair 32 gb stick several years old, but looks pretty much the same as the ones they sell now at wally world where I got it. Ran an iso of the Vuu-do max using zstd, came out as expected about 10% larger at 1.1 gb.

This usb is smoking the hard-drive, it boots so much faster, and here's the thing that's blowing my mind and making me super happy: Even when I load it all to ram it's still faster than the HD boot.

I looked up specs on this very stick and tests showed an average 22 mbs read and a 10 mbs write. But when I load it to ram I can watch it loading the largest file (squashfs) and it's loading at 30 mbs. The HD on this old machine usually runs around 35-45 in practice, so loading from usb is only about 10-30% slower, but it's loading 3 times the data.

It's compressed data, but zstd decompresses it 13 times faster than xz does.  I didn't have time for a smoke or to make a cup of coffee before it booted.

Procedure I followed:

Add entry to /etc/refractasnapshot.conf, enable, and comment out others. mksq_opt="-comp zstd -Xcompression-level 22"  Run iso.

Run Gparted on usb stick: new partition table, two new primary partitions both fat32, first slightly larger than iso with boot flag, second rest of stick labeled "DATA".

Refracta2usb: option iso2 findiso, install syslinux, edit boot menu to add toram and failsafe entries and remove others, syslinux boot splash ugly, replaced with boot splash from onboard isolinux that I made. Syslinux highlight color, also ugly, changed that.

@fsmithred you gotta try this, you're gonna love it.

Okay, posting now from an iso I just made using zstd, the Vuu-do openbox mini, running off a stick (usb 2) that I loaded Chromium into during this live-session. Totally worked to make a useable iso. Command I posted above and tried first error'ed out, I should have been paying more attention to the mksquashfs man page than the zstd man page. Thankfully the Refracta-snapshot log showed me not only the error of my ways but also how to fix it:

mksq_opt="-comp zstd -Xcompression-level 22"

All done on my Compaq CQ-58 circa 2012, amd dual-core APU @ 1.0 ghz.

In practice on the mini iso, 2.4 gigs unpacked, the highest level of compression for zstd made an iso about 10% larger than xz -Xbcj x86 did.

651 mb vs 712 mb.

The next part is subjective, I don't have a stopwatch to check small intervals. But after loading the iso to a USB, and using the regular boot option, NOT load-to-ram, the boot time was faster, the lag times when opening the menu and programs practically disappeared and it was easily as fast as I normally get loading the whole thing to ram. Fast as hell.

And after bootup before running anything, I was at 479 mb of total ram use as opposed to the 1.14 gigs when I loaded the system entirely to ram. The task manager showed actual usage by the services running at about 300 mb.

Obviously I need to do a whole lot more testing, and get some actual timing for things, I could have some confirmation-bias.

But, impressions:

1. zstd most definitely does not compress as small as xz when doing an iso. About a 10% difference.
2. The bottleneck of using an optical disc (CD in this case) is too much for this to make a difference.
3. A liveUSB2 though has about 5 times faster transfer speed than my disc-drive, and in practice it's still a small bottleneck, but most programs like the file manager, text-editor, terminal etc. are pretty small, and get transferred fast enough, and de-compressed noticeably faster than xz does.
4. I should be able to run an iso that's a gig in size on a liveUSB stick, and actually use it with only a gig of ram since it doesn't all need to get loaded and the speed doesn't suffer as a result of not loading it all to ram.

Fun stuff, gotta go do some more testing!

@kapqa, well i'm using gnlug instead of the main deb.devuan.org, but in it there is no "testing-security" or "testing-updates" files and so no release files either. None in the excalibur section, nor in the "testing" section which is in a different section than excalibur but I assume is mostly the same files.

So that may be why you're getting an error.

Also I don't think using the "testing" repo is the same exact thing as using the excalibur repo. I've loaded the testing before just to look at what's available, but haven't peeked at excalibur. I could be wrong.

In addition to the AMD firmware package, I also have the microcode package, don't know if that makes a difference in this case though.

One last question about snapshot. I noticed zstd is in the list quoted above, is it possible to use that for compression in snapshot?

My thinking may be way off base here, but was reading up on different compression methods and noticed that while it won't compress quite as small as xz, that it's decompression speeds are several orders of magnitude faster.

Use case scenario for that, that i'm interested in, is on a liveUSB, after it boots there is a lag time when you first open the menu or any programs, after that it's cached and plenty fast, but was just wondering if zstd would cut down that lag time.

Again, on a modern fast machine probably never notice, but on the 10-12 year old low-spec machines I typically have to deal with it seems like it might help?

ETA: I know the real bottleneck is going to be transfer speed from usb 2, but just looking for small speed tweaks here.

@ steve_v

For some of us yes.
For 99.999999 of the normie population that I make things for who have no idea what emacs, tty, or kate or even nano mean:

Ehrr, I don't like titlebar color, file manager>>filesystem root>>usr/share/themes/(default-theme)/(appropriate folder)/(appropriate file)

Right-click>>edit as root>>opens in text-editor as root>>edit file>>save>>close>>root privileges gone. Logout>>login>>changes applied.

Profit. It's all about the GUI for new users or users that don't care to learn how to use the CLI.

Well it should be simple, just edit the main thread title and first post with content I provide, which will be MUCH more concise than what I have now, and then simply delete the other threads, would clean things up nicely which ought to appeal to ralph.ronnquist.

Blogs, don't like 'em. I guess maybe one is needed somewhere, but typing out all this stuff is a lot of work for my two fingers. And since I only make these things about once every 5-7 years there wouldn't be any additional content for long periods of time.

But point well-taken, maybe i'll make one.

You may be right Golinux.

It's just that I like to share what's going on as I work, provide a little explanation as to why things get replaced and why I do things a certain way, to help people understand what they're in for if they choose to try it. And also to add some info to the database for future aspiring iso-rollers as reference to help them get started, and maybe avoid some of my mistakes. I know that kind of info in multiple places across the internet has certainly helped me a lot...

So at this point I would be happy to write out a single original post to replace the original post in the main vuu-do thread, that explains the different options, six of them now very briefly with links, and edit the original title to simply reflect Vuu-do info. And then you could scrap the other threads. Except maybe the Devuan-mini thread as that's not a Vuu-do version and maybe should have it's own, gotten quite a few downloads.

What do you think?

Yep.
I've been doing it for years, I actually made a right-click extension "Edit file as Root" years ago that opens files in Pluma for me to edit, super handy. Much better than just working in the root account for long periods of time I reckon.