You have to change limit_cpu="no" to "yes" for cpulimit to work. It's not on by default.

Changing the work and snapshot directories should work correctly. Check the config file to make sure you edited it correctly. Make sure the storage device is mounted. If you want a more verbose error log, run it in debug mode (add -d option or change the setting in the config file).

I am puzzled that nobody mentioned refractasnapshot.  What an amazing tool! 
I wish I had tried it before I went through all this trouble as described above.
I suppose the next stage would be to make a gui out of manually editing the two .conf files while browsing files/folders to exclude and
clicking on boxes for the options.

I had spend some time studying and practicing building live images and there was always something little I'd forget to do right and then the next time I had to figure it all out from scratch, as my note taking abilities are very poor.

This is making backups of the system a breeze.  A good reason to be here alone.
One thing that didn't work was altering the directories for work and snapshot, they were still gone to the default locations.  No problem.
The other was the part in the conf about processor use, I left it at 50 as was the default, but it went way up there at their limits and temps
went up as well.  This went on while it was squashing the file system into the tiny image.  I did run a tasks monitor in bg with low priority even
though it is not advised to run anything.  I suspect that such process that run as standalones don't matter.

The refracta team deserves an aplaud!  I was also told by someone in the xorisso team that they weren't aware of anyone working on a xorisso related gui.  I guess this is not specifically a gui of xorisso but it seems that it is the next best thing.

Not happy, extatic of the possibilities this creates for some of us uncomfortable with code and sequences of commands.

rsyslog is a known problem.  Just throwing this here but please search the forum and DNG for other discussions.

https://botbot.me/freenode/devuan/2017- … 009&page=6

Bottom line:

fsmithred wrote:

rsyslog is not ready. Use syslog-ng or busybox-syslogd instead

syslog-ng seems to work fine, thank you for the heads-up

To each, his own. I couldn't get away from the default slim background fast enough. Is it the blue one or the red one?

That orangy looking mesh that came with ceres upgrade.  It saus Text.4 somewhere on it

rsyslog from jessie-backports installs and works in ascii, so that's another option. I haven't tried it in ceres.

To each, his own. I couldn't get away from the default slim background fast enough. Is it the blue one or the red one?

On my testbed installation I jumped to ceres and linux4.11 which comes with header files that are not dependencies and did not exist in 3.16 or (maybe?) 4.9. 

Slim was still installed before I switched to my trusty lightdm, but the login screen changed.  Great background.jpg (look in share --> slim ).  I kept it since lightdm is black bkgrnd.  Definetely slim has a very slim footprint.  The problem was there was no option to select anything other than entering user and password, so the xfce started.

Glancing through the menu the dreaded "services" was on, clicked and it was there.  I got a cold chill down my spine, I thought the systemd nightmare was back!  Quickly I checked through the tasks and I suppose those "services" are daemons started by the init system.
Phheeeewwww!!!!!!

# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.9.0-3-amd64
I: The initramfs will attempt to resume from /dev/sda9
I: (UUID=8e052cee-0f67-4af6-guud-707b91db2d1b)
I: Set the RESUME variable to override this.
live-boot: core filesystems devices utils udev wget blockdev dns.

dev/sda9 is the swap partition .... I remember seeing this during shutdown...?
Is it sweeping the swap?

If you use swap for resuming, you can't share it with other systems. That's all to it. But how to set it up, not fresh at it... Haven't used resume lately.

Purple/violet is fine. Devuan is a purple beast... Well, to me. Or it's more like purpy, but one would have to ask the chief Devuan web/logo/other-stuff designer, one golinux for details .

EDIT 2017-07-18 21:18 UT START: You read in the next post:

That's because two posts from here to the post with that quote, belatedly (but that's fine, everyone gets tired in sleepy hours), moved to:
Devuan is a purpy beast
http://dev1galaxy.org/viewtopic.php?id=1147
Only noticed now, didn't get any notice about it (but Dev1Galaxy is fine enough).
EDIT 2017-07-18 21:18 UT END.

# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.9.0-3-amd64
I: The initramfs will attempt to resume from /dev/sda9
I: (UUID=8e052cee-0f67-4af6-guud-707b91db2d1b)
I: Set the RESUME variable to override this.
live-boot: core filesystems devices utils udev wget blockdev dns.

dev/sda9 is the swap partition .... I remember seeing this during shutdown...?
Is it sweeping the swap?  4 different systems share the same swap space and the
same home partition.  Not a problem ever.  Since I have all 4 users being 1000
they all have access to each other's stuff.  I did try a single same name 1001 user
but I like the variety of 4 users.  Like this is my purple/violet personality ...!!

This where my installation troubles were listed as I found the topic relevant.

I am worried about somesuch, it always gets me.

rsyslog is a known problem.  Just throwing this here but please search the forum and DNG for other discussions.

https://botbot.me/freenode/devuan/2017- … 009&page=6

Bottom line:

fsmithred wrote:

rsyslog is not ready. Use syslog-ng or busybox-syslogd instead

I prefer waiting for rsyslog to get fixed. I have to say, it simply continues to work fine in my system(s).
See:

# lsb_release -a
No LSB modules are available.
Distributor ID: Devuan
Description:    Devuan GNU/Linux 2.0 (ascii)
Release:        2.0
Codename:       ascii
#

and:

# apt-cache policy rsyslog
rsyslog:
  Installed: 8.4.2-1+deb8u2
  Candidate: 8.14.0-2+devuan1.0
  Version table:
     8.23.0-2~bpo8+1 100
        100 http://auto.mirror.devuan.org/merged jessie-backports/main amd64 Package
     8.14.0-2+devuan1.0 500
        500 http://packages.devuan.org/merged ascii/main amd64 Packages
        500 http://auto.mirror.devuan.org/merged ascii/main amd64 Packages
        500 http://packages.devuan.org/devuan ascii/main amd64 Packages
 *** 8.4.2-1+deb8u2 100
        100 /var/lib/dpkg/status
#

but:

# apt-get install rsyslog
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Starting pkgProblemResolver with broken count: 1
Starting 2 pkgProblemResolver with broken count: 1
Investigating (0) rsyslog:amd64 < 8.4.2-1+deb8u2 -> 8.14.0-2+devuan1.0 @ii pumU Ib >
Broken rsyslog:amd64 Depends on liblognorm2:amd64 < none @un H > (>= 1.1.2)
Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 rsyslog : Depends: liblognorm2 (>= 1.1.2) but it is not installable
E: Unable to correct problems, you have held broken packages.
#

Let readers see in full the inability to update to newer version... But, I repeat, I have no issues. It logs just great... (well... except for logging too much under grsec kernel, or my manually compiled grsec kernel... such as in all: kern.log, messages and syslog ... But I couldn't live without a lot of logging... It's such great tool to learn your system! Especially the configurably very abundant grsec kernel logging...)

You gotta have logs, c'mon!

You just go into your profile, and open up your topics or your posts, and paste the link. But freely forget it, I was more like thoughtful for other readers and being principled (if I use the word correctly).

debelop? a typo? develop you must have meant...

IOW, it's a mess because of the same UUIDs, and once you change them and run:

# update-initramfs -u -a

or somesuch, and if all UUIDs are set correctly, i.e. update-initramfs runs without errors, it then can, upon reboot, boot fine.

initrdmfs? initramfs, yes...
Aaahh.. Great. Enjoy Devuan. I do!... Let's make this kind beast more and more capable and powerfull... Each giving the little or the much that any of us can...

@miroR you asked me for a link and I have no idea what link this may be.  What I am talking about in reference to cloning is to make an installation in partition sdz1  and making a copy in partition sdy3 and debelop from the same snaposhot of the system 2 different ways.
All you need to do is to "properly" edit fstab with new uuids and the grub.cfg

I suspect, without knowing, that the initrd.img in /boot contains the original uuid which is passed to grub and it creates this confusion.
Once linux kernel gets updated all this goes away.  In other words unattended updates of grub creates an entry with two different uuids for the same menu item, which results to a prompt at the initrdmfs prompt where there is not much you can do (or maybe there is if you know how to deal with it).

https://botbot.me/freenode/devuan/2017- … 009&page=6

Bottom line:

The only glitch which may be related to the lxde desktop not really being a devuan ported pkg, was rsyslog which in ascii it says it has unmet non-existent dependencies.  So I removed it.

And what do you have for system logging?

BTW, it's this bug:
rsyslog depends on liblognorm2 in ascii, but it's not available
https://bugs.devuan.org//cgi/bugreport.cgi?bug=96

I have rsyslog held back, because of that. But I don't have any issues with it. I think it can wait.

So what do you have for system logging, now that you removed rsyslog, the default system logger in Devuan(/Debian)?

As mentioned elsewhere in my installation experience when I cloned the original usb installation to a different partition (dev/sda11) with a new uuid grub

Just why not give the link, and at this very spot, so users who want, may visit the link?

I clone in cycles, from Air-Gapped which sees no internet, other than minuscule fragments that I only need to update it, and mail, and other stuff from online, but nothing wholesale.

And I run into the need to change UUIDs on my encrypted partitions all the time... But it works, not just slowly, here.

Hmmmh, not related to UUIDs, don't know what this could be...

I don't think... But I don't know.

Everything else is running fine.

Hopefully this information may help someone else cloning their devuan installation.  I do this often when I want to play either with unstable or compile software that may break the system as a testing installation and only apply procedures that work on my main installation.
In this case I reversed the process leaving the original installation as the playground.

Let's see what ceres does (I am really going to miss SID as I liked the name   -   I will rename my grub entry Devuan SID or Vicious Devuan)

So long, systemd suckers!