DebianDog64 - 64 bit DebianDog-Jessie

[fredx181]

Hi Fred and William,

I'm trying DebianDog64 for the first time (very nice!) and it recognizes my trackpad! But I have a Broadcom BCM43142 Wifi and DD doesn't see it. From everything I've read (and a helpful post in Additional Software/Drivers), I need broadcom-sta-dkms_6.30.223.248-3_all.deb (which I got). Assume I'm a complete idiot who's never built a kernel driver (because I AM a complete idiot who's never built a kernel driver) and please walk me through it. I've got the devx, but every other package I need has to be downloaded in Fatdog, so no apt-get for me. Sad

Unless of course you have a magic driver already packed up and raring to go.

Thanks
Marc

Hi Marc,

I will see what I can do, probably compile the driver and make a .deb from it.
Will get back later about it.

Fred

[fredx181]

Hi Marc,

I've got the devx, but every other package I need has to be downloaded in Fatdog, so no apt-get for me. Sad

Probably impossible to do without apt-get, so here's a deb package containing the compiled kernel module:
https://googledrive.com/host/0ByBgCDlZZ ... _amd64.deb

I followed the instructions from here:
https://wiki.debian.org/wl

Note that I couldn't test it because I don't have such wireless card, but lsmod gave me:

Code: Select all

root@jessie64:~# lsmod | grep wl
wl                   6299053  0 
iwl3945                58397  0 
iwlegacy               55017  1 iwl3945
mac80211              474277  2 iwl3945,iwlegacy
cfg80211              405538  4 wl,iwl3945,iwlegacy,mac80211

That is: after reboot, probably best after installing the .deb to do:
(from https://wiki.debian.org/wl)

Unload conflicting modules:

# modprobe -r b44 b43 b43legacy ssb brcmsmac bcma

Load the wl module:

# modprobe wl

Hope it works for you!

Fred

[mjaksen]

Hi Fred,

Success!

I am writing this from DebianDog. Wifi connection looks good.

Than you very much.

Marc

[rufwoof]

RE: Skype.

Going through this thread I've see a few postings about skype, so thought I'd post a general reply to those postings. I'm not running DD64 Jessie, but actual Debian Jessie (amd64 liveCD version) installed frugally. Given the similarities however this might work in DD64, it certainly works for me on my system https://mike632t.wordpress.com/2015/09/ ... -0-jessie/. I think I'm now running pulseaudio - but in truth I don't know for sure.

I also installed pavucontrol which really helps me with setting up the right channels as if you play (or record) something you see the volume rise and fall visually and just need to select the channels until you actually hit on the right choice and actually hear the sound. All very hit and miss for me as I know little about those sorts of things. I just do what works for me.

Fundamentally that link suggests running

apt-get update;apt-get upgrade
wget -c http://download.skype.com/linux/skype-d ... 1_i386.deb
dpkg --add-architecture i386
dpkg -i skype-debian_4.3.0.37-1_i386.deb
apt-get -f install

where that last 'fix' install (get dependencies) is a real big one (bloat), which I note includes systemd and systemd-sysv, so this might all just be valid for systemD (liveboot3) as systemd-sysv installation more or less enforces that (similar to putting init-bin=systemd or whatever the boot command is)

[fredx181]

See for a howto of installing DebianDog64 on a 'persistence' partition by using rufwoof's method for Debian Live (as fundamentally here described: http://www.murga-linux.com/puppy/viewto ... 639#915639) here:

http://murga-linux.com/puppy/viewtopic. ... 339#916339

Fred

[rufwoof]

Dropped in Skype SFS and all working well.

The same apt-get -y install --reinstall libreoffice-kde libreoffice-gnome libreoffice-gtk works in DD64 as well. After running that (mine froze for a bit on a download and pressing enter resumed updates) running libreoffice --quickstart puts the libre quickstarter icon in the tray (at least running ROX based desktop (I've cleared all desktop icons out of puppy pin))

I've set that libreoffice --quickstart to run at startup (in a script in the startup folder) but it can also be set in Libre calc (or whatever), tools, options, libre office, memory, and tick the enable systray quickstart option.

Starting to like tint2, especially the menu, advanced settings, tint2 config taking you to the config file, my laucher section now looks like

# Launchers
launcher_tooltip = 1
launcher_icon_theme = Faenza-minimal
launcher_apps_dir = .local/share/tint2launch
#launcher_item_app = /usr/share/applications/menu.desktop
#launcher_item_app = /usr/share/applications/desktop.desktop
#launcher_item_app = /usr/share/applications/debian-xterm.desktop
launcher_item_app = /usr/share/applications/leafpad.desktop
launcher_item_app = /usr/share/applications/masterpdfeditor3.desktop
launcher_item_app = /usr/lib/libreoffice/share/xdg/writer.desktop
launcher_item_app = /usr/lib/libreoffice/share/xdg/calc.desktop
launcher_item_app = /usr/share/applications/galculator.desktop
launcher_item_app = /usr/share/applications/skype.desktop
launcher_item_app = /usr/share/applications/firefox-esr.desktop
launcher_item_app = /usr/share/applications/pcmanfm.desktop

i.e. puts the apps I like to use often in the tray

[rufwoof]

8GB USB image. 998MB (1,046,640,867 bytes, md5sum 89677c7a579b42bd35a54952b0fd03b2)

Boot to USB provides two options, default is no changes saved, unless you run flush2disk in a terminal. Second boot choice (first in boot menu) has all changes written immediately to disk (USB).

On one PC I have access to it starts booting immediately. On the other it 'sticks' at the bzimage initial booting screen (terminal) for around 30 seconds before starting the boot process. Might be because its a older PC (BIOS).

i.e. download and write to a 8GB or larger USB (all data on the USB will be lost) using something like :

gzip --decompress --stdout debdog64-8GB-usb.img.gz | dd of=/dev/sdf bs=4M conv=fsync

changing /dev/sdf in the above to YOUR OWN USB 'disk' not the partition of the USB (as indicated by running terminal command lsblk or whatever)

Perhaps write it to a microSD and plug it into one of these for a possible dual boot system with everything on a single 'USB'

The above image comes pre-loaded with Audacity, Blender, Openshot and (full) inkscape .... so video and audio editing ready to go. recordmydesktop (for creating a video of your desktop), the full LibreOffice (so word processing, presentation, spreadsheets etc.), masterpdfeditor3 (for PDF editing) and Skype. Along with the original CD/DVD etc utilities that comes with DebianDog64.

Mostly contained within a lz4 compressed filesystem squashfs file, but a few additional changes recorded in the save partition (that I forgot to do until after having created the filesystem sfs. LZ4 is lightning fast at decompressing and will use all cores (mine has all 4 processors running when compressing/decompressing with lz4).

Uses save to partition method, where the same single partition where the bootloader and filesystem squashfs is stored is the partition that is saved to i.e. the USB has a partition label of changesdd64, so that's recognised as being the 'save' area.

Includes a close equivalent version to Fred's modified save process that uses rsync. So changes that are saved are (mostly) deleted from memory at that time, so a subsequent run of 'flush2disk' isn't flushing memory that had already once before been written to 'disk' (USB).

If you don't run flush2disk in a terminal, it doesn't save anything, unless you booted with the read/write boot option when all changes are immediately saved (handy for if a massive Debian update that otherwise would eat all of available free memory space).

Set up to start with ROX desktop - but I've cleared out all desktop icons and just added what I use more often to the tray. See Menu, Advanced Settings, Tint2 Config ... as a guide of how to change those (look for the launchers section, and add/remove lines in reflection of what .desktop files you want (see /usr/share/applications folder for a list of application .desktop files)).

df -h on mine shows
/dev/sdf1 7.3G 1.3G 5.7G 18% /lib/live/mount/persistence/sdf1
i.e. 1.3GB used, 5.7GB free out of 7.3GB total USB partition size.

Test at your own risk, make backups first etc.

[fredx181]

Thanks Rufwoof! For a DD64 deLuxe Edition

Looks promising, will download and probably test tomorrow and report back.
(have to find a usable 8GB USB, don't want to delete your KDE version)

Fred

[rufwoof]

Hi Fred

I use the same USB stick and just
dd if=/dev/sdf of=kde.img bs=4M conv=fsync
to offload it onto HDD

... and write it (or another) image back to USB again using
dd if=kde.img of=/dev/sdf bs=4M conv=fsync

Best done when you're away from the PC for 10 minutes or so i.e. time to let it run.

Given how good Synaptic and apt-get are, having the nearly empty 'puppy' is a good idea if you're running on a PC that has high speed internet (ethernet and good/fast ISP). MasterPDFEditor3 for instance provides a .deb but that requires other dependencies, however if you
dpkg -i masterpdfeditor3.deb
to install it ... whilst it complains about missing dependencies, if you then run
apt-get -f install
that fixes the missing libraries automatically for you ... and you're up and running. There are exceptions however, and masterpdfeditor3 is one such case i.e. when you first run it, it will ask for another apt-get install for a thing that apt-get -f install seems to miss.

Its quite easy to set up a script that runs apt-get to 'install' a suite of programs for a particular task. i.e. you could have a bare bone core and a bunch of scripts (again assuming high internet speeds). I think it was RSH who set up a puppy like that some time back, on demand installation of programs via the net ... somewhat automated via a menu click (to run the program). "I want to run Openshot" .. you click the menu entry for that, it detects its not locally installed already so downloads/installs/runs it type thing. The local menu can then be a reflection of the entire Synaptic repository ... well at least the application entries.

A nice feature about a light/bare version is that even on a older slower USB being so small it still boots up relatively quickly.

So this fully loaded version is more just for testing purposes. Impressively fast once booted and your rsync based saving is great. Libre spreadsheet on first run takes around 2 seconds to load on my system after initial booting. Thereafer ... a blink of a eye (i.e. remains memory bound). On the other PC I have access to you'd be hard pressed to see a difference between booting from HDD or from USB, both comparable speeds. The exception is when you run flush2disk as then a slowdown is distinct. For large amounts of changes it can even be a cup of tea type break timing. Again with your modified version of saving, after saved once any further saves resume to being acceptably quick again.

[rufwoof]

@Fred

Here's a for-instance of when the modified snapmergepuppy (that I call flush2disk for the persistence partition approach) weaker grep filter could backfire (see attached).

The background of how that arose is I wondered whether using journal ext format might be slower to boot (ext3/4) than non-journal'd (ext2); And/or whether grub4dos handling of ext format might be a slow-down issue. So I partitioned a USB for a small FAT16 partition for menu.lst/grldr and installed grub4dos boot loader to the MBR, and then created a second ext2 partition to hold the filesystem (/live) and a third ext3 partition with a label of changesdd64 as the 'save' partition.

Booting that and running "mount -l | grep persistence" then shows as attached ... i.e. two rows/values, which could prove to be a problem i.e. attempting to save the overlay (memory) content to sdf2 instead of sdf3 in the above setup case.

The key line of code I've personally used in my own flush2disk (where the choice of persistence partition label I used is changesdd64) looks like :

Code: Select all

BASE=`mount -l | grep "\[changesdd64\]" | grep -m 1 /lib/live/mount/persistence | awk 'BEGIN{FS=" "} {print $3}'`

that correctly returns the single line of /lib/live/mount/persistence/sdf3

[fredx181]

Hi Rufwoof,

Its quite easy to set up a script that runs apt-get to 'install' a suite of programs for a particular task. i.e. you could have a bare bone core and a bunch of scripts (again assuming high internet speeds). I think it was RSH who set up a puppy like that some time back, on demand installation of programs via the net ... somewhat automated via a menu click (to run the program). "I want to run Openshot" .. you click the menu entry for that, it detects its not locally installed already so downloads/installs/runs it type thing. The local menu can then be a reflection of the entire Synaptic repository ... well at least the application entries.

I think RSH uses a .sfs file for that, that's where lz4 (the fastest compression) would be the best use for (nearly) 'instant' executing a new installed program (sort of: apt2sfs > lz4 (squashfs) > sfs-load (execute requested program).
Definitely something to work on in the future for me.

So this fully loaded version is more just for testing purposes.

Yes, I see, so following testing report , some issues:
- The script 'remove-netrules' in ~/Startup works only after reboot with save (ethernet interface wasn't right first time boot, so no internet).
Sorry if I wasn't clear, the real fix to have it detect the right network interface first time boot is to just not include it in the base filesystem (so remove /etc/udev/rules.d/70-persistent-net.rules before you create filesystem.squashfs).
- Palemoon isn't very user friendly, thought having disabled 'noscript' still struggling at this moment to write this (clicking 'quote' or 'code' doesn't do anything, so having to manually type the quote or code codes
- wbar: difficult to get to disabled state (noticed your script in ~/Startup) , found that /etc/xdg/autostart/wbar.desktop is the problem (rm /etc/xdg/autostart/wbar.desktop solves it)
(from a pristine DD64 it's not a problem, but maybe because of having installed more (gnome?) programs / dependencies it became, not sure really)

Here's a for-instance of when the modified snapmergepuppy (that I call flush2disk for the persistence partition approach) weaker grep filter could backfire (see attached).

The background of how that arose is I wondered whether using journal ext format might be slower to boot (ext3/4) than non-journal'd (ext2); And/or whether grub4dos handling of ext format might be a slow-down issue. So I partitioned a USB for a small FAT16 partition for menu.lst/grldr and installed grub4dos boot loader to the MBR, and then created a second ext2 partition to hold the filesystem (/live) and a third ext3 partition with a label of changesdd64 as the 'save' partition.

Booting that and running "mount -l | grep persistence" then shows as attached ... i.e. two rows/values, which could prove to be a problem i.e. attempting to save the overlay (memory) content to sdf2 instead of sdf3 in the above setup case.

Wrong assumption from me that there can be only one mountpoint in /lib/live/mount/persistence

As l like solutions that covers all cases I'd propose like this for the BASE variable (parsing 'label name' first from kernel cmdline):

Code: Select all

# Remount the 'home' partition read-write, otherwise we can't copy the changes
   persist_label=$(grep -o "persistence-label=.*" /proc/cmdline |sed 's| .*||' |sed 's|persistence-label=||')
   if [[ -z "$persist_label" ]] ; then
      persist_label="persistence"
   fi
BASE=`mount -l | grep "\[$persist_label\]" | grep -m 1 /lib/live/mount/persistence | awk 'BEGIN{FS=" "} {print $3}'`
if [ -z "$BASE" ]; then
 echo persistency partition label not found - exiting
 sleep 4
 exit
fi
mount -o remount,rw $BASE 2> /dev/null

[rufwoof]

Hi Fred

As l like solutions that covers all cases I'd propose like this for the BASE variable (parsing 'label name' first from kernel cmdline)

Some others use casper-rw ... or other dissimilar persistent partition labels as the 'default' label. Perhaps instead ....

Code: Select all

# Remount the 'home' partition read-write, otherwise we can't copy the changes
BASE=$(grep -o "persistence-label=.*" /proc/cmdline |sed 's| .*||' |sed 's|persistence-label=||')
if [ -z "$BASE" ] ; then
 BASE=`mount -l | grep -m 1 /lib/live/mount/persistence | grep "\[" | grep ordered | awk 'BEGIN{FS=" "} {print $3}'` 
fi
if [ -z "$BASE" ]; then
 echo persistency partition label not found - exiting
 sleep 4
 exit
fi
mount -o remount,rw $BASE 2> /dev/null

... goes a little further in trapping that (???). That is however subjective to the data=ordered mount condition being in place, some systems might not have that set .... so maybe something like if more than one line then check to see which is the more likely candidate, perhaps checking for a specific file or folder that would tend to always be in the persistence space, if [ ! -d /lib/live/mount/persistence/etc/xdg ]; then (test other case(s)) .... type thing ???

[fredx181]

Some others use casper-rw ...

That's Ubuntu specific default label, aren't we just talking about Debian here? ('persistence' is default AFAIK)
(BTW, I searched and tried a similar way for Xenialdog, but 'persistence-read-only' or 'persistent-read-only' doesn't work apparently with Ubuntu based distro).

But, yes, of course the safer the better for catching the real persistence mountpoint.

Edit:

if [ ! -d /lib/live/mount/persistence/etc/xdg ]; then (test other case(s))

Nice concept idea, but I think it wouldn't work because you always have:
/lib/live/mount/persistence/sdxx
so still need to determine sdxx before knowing about /lib/live/mount/persistence/sdxx/etc/xdg
But maybe it can be scripted with a 'find' command line, something to experiment with at least.

Fred

[rufwoof]

Just had a education of exporting (or rather not) from within sub-shells. Tried export BASE = $N from within the while loop ... and all sorts. Ended up with this (having to write to /tmp) [my bad bash knowledge]

Code: Select all

# Remount the 'home' partition read-write, otherwise we can't copy the changes
BASE=$(grep -o "persistence-label=.*" /proc/cmdline |sed 's| .*||' |sed 's|persistence-label=||')
if [ -z "$BASE" ]
then
 rm /tmp/persistence-check
 mount -l | grep -m 1 /lib/live/mount/persistence | grep "\[" | grep "\]" | awk 'BEGIN{FS=" "} {print $3}' |
 while read N
 do
  if [ -d $N/etc/xdg ]
  then
   echo "$N" >/tmp/persistence-check
   break
  fi
 done
fi
if [ ! -f /tmp/persistence-check ]; then
 echo persistency partition label not found - exiting
 sleep 4
 exit
else
  BASE=`cat /tmp/persistence-check`
  rm /tmp/persistence-check
fi
mount -o remount,rw $BASE 2> /dev/null

[rufwoof]

Some others use casper-rw ...

That's Ubuntu specific default label, aren't we just talking about Debian here? ('persistence' is default AFAIK)
(BTW, I searched and tried a similar way for Xenialdog, but 'persistence-read-only' or 'persistent-read-only' doesn't work apparently with Ubuntu based distro).

I've been running with kubuntu live frugal today and it uses persistent kernel boot parameter instead of persistence ... and doesn't have any other of the persistence settings that I can find. Does use a initrd.lz however and there are code snippets around about how to extract and change that i.e. porteus style. Different arrangement as well as it stands by default. Wont share the same partition for menu.lst and saving, needs a "format" file in the root partition instead of "persistence.conf" (the content of which just indicates its a unionfs type overlay) .... but otherwise not too dissimilar.

kubuntu is nice for having all of the latest progs, and includes by default the non-free stuff, but not so nice that they can be unstable. Debian is great for stability, but not so nice that you have to link in all of the non-free stuff. Of the two, once you've overcome the initial lacking (non free...etc) I prefer Debian for its greater stability, and isn't a down-link type 'tweaked' thing that piggy backs off Debian.

[rufwoof]

I think RSH uses a .sfs file for that, that's where lz4 (the fastest compression) would be the best use for (nearly) 'instant' executing a new installed program (sort of: apt2sfs > lz4 (squashfs) > sfs-load (execute requested program).
Definitely something to work on in the future for me.

Debian stable repository is ... stable and extensive. It does require some tweaks to occasionally be made however. recordmydesktop is a example, the configuration file has DEFAULT configured as the sound device, whereas to work properly that needs to be changed to a lower-case default. For a fully working version of Openshot you also need blender, inkscape (full version) .. which again Debian apt-get performs a great job, but it does leave out one other (semi) dependency (forget the exact case, some weird name like frie0r or something like that).

I love having elements of puppy (save (or not) on demand, running via a filesystem sfs (that can halve or more the disk size used and transfer/decompress quicker than transferring the non compressed), and running in ram (mostly) ...etc.). I love the Debian stability and extensive repository. Combined with security patches coming through very quickly that's a well rounded setup, even if its not puppy like in size (up at GB rather than perhaps 200MB). With a somewhat barebone version such as your DD64 combined with apt2sfs along with some occasional 'tweaks' (such as needed by recordmydesktop) that boot frugally ... and that's well on the road to being a great/outstanding system.

Should say thank you more often to you Fred. Your knowledge, skills and efforts are greatly appreciated. Thanks.

[rufwoof]

Inspecting the ISO's 01-filesystem.squashfs using unsquashfs -s 01-filesystem.squashfs I see that it was compressed using xz and a dictionary size of 524288. I'd be interested in how was that 'optimal' choice identified?

With hindsight, using

Code: Select all

mksquashfs squashfs-root 01-fs.sfs -comp xz -Xbcj x86 -Xdict-size 524288 -always-use-fragments -nopad -b 524288

matches (is marginally smaller) than the ISO version - which with no foresight would have required a lot of iterations to deduce?

Doubling up that block size :

Code: Select all

mksquashfs squashfs-root 01-fs.sfs -comp xz -Xbcj x86 -Xdict-size 1048576 -always-use-fragments -nopad -b 1048576

does knock a little more off, around 4.5MB less. Only the small matter however for that extra saving .... it doesn't boot. Gets to a cannot stat /union/sbin/init ... or something like that before falling over. I guess perhaps because of byte (mis) alignment issues maybe.

All relative to the https://dl.dropboxusercontent.com/u/36381953/DebDog64-Jessie/DebianDog64-Jessie-openbox-2016-03-20.iso 20.03.2016 ISO

Stripping out palemoon, mpv and youtube downloader did boot OK and weigh in at around 20MB less filesystem.squashfs size (around 140MB using mksquashfs with xz (no additional parameters). After all it is quite easy to apt-get update, apt-get install firefox-esr (or whatever) from that lighter base (where the user can choose to install their preferred choice of browser). Gnome player still worked fine (removing mpv appeared to have no ill effect on gnome mplayer).

You've done a incredible job with this one Fred. Being able to get a GUI/X Debian Jessie down to 150MB or less is most impressive/exceptional.

[rufwoof]

openbox wallpaper can be set with

hsetroot -cover /root/Pictures/euphoria.jpg

(or whatever image file you have available)

[rufwoof]

Copy of the latest DD64Jessie ISO, but with palemoon, mpv (and youtube downloader) stripped out, with filesystem squashed using

Code: Select all

mksquashfs squashfs-root 01-filesystem.squashfs -comp xz -Xbcj x86 -Xdict-size 1048576 -b 1048576

ISO filesize 152MB
01-filesystem.squashfs filesize 124MB

ISO here

That has no browser installed, so as part of first time run you'll want to open a terminal and run something like :

apt-get update
apt-get install firefox-esr

or use Synaptic to choose/install whichever browser you prefer.

I don't know how to set things back to as per 'first-run' i.e. where it shows a list of keyboard shortcuts the first time you boot it, so that's not shown in this version.

For grub4dos HDD frugal type install (typical puppy style) ... extract the ISO live folder content to HDD directory such as /DD64 and create a grub4dos menu.lst something like

title PorteusDog (sda1)
root (hd0,0)
kernel (hd0,0)/DD64/live/vmlinuz1 noauto from=/DD64 changes=EXIT:/DD64/live/
initrd (hd0,0)/DD64/live/initrd1.xz

... that's assuming you frugal to your sda1 (first HDD, first partition i.e. (hd0,0) - change that as necessary (for instance second HDD, third partition would be (hd1,2))

If you'd rather just download the filesystem, initrd and vmlinuz files to frugal boot from then they're here : initrd.gz and here vmlinuz1 and here 01-filesystem.squashfs

That's like a pupmod 13 boot, keeps all changes in memory which are lost at shutdown unless you open a terminal and run save2flash which will then preserve all changes up to that point in the /DD64/live/changes folder/sub-directory.

Debian as a desktop is stable if you only use Debian programs i.e. install using synaptic from the main Debian Stable (Jessie) repository. This is like a barebone puppy type thing, where it gets you to a gui desktop and once up and running you should have access to all of that extensive stable programs environment (typically using apt-get (command line) or synaptic (gui)). If you install/load/mix-in other non-Debian stuff then you break that stability.

================================================

Repository 101

/etc/apt/sources.list lists the Debian repositories that are scanned (package database downloaded to a local copy) whenever you run "apt-get update". After having downloaded (or updated) that local package database you can run apt-get install ..... to download/install a program. So you can tune /etc/apt/sources to perhaps only look for security updates and perhaps comment out all of the other repositories in /etc/apt/sources.list, or leave it as-is and get updates for everything newly/recently updated. Or once set up to how you like not bother updating any more thereafter. Personally I prefer to update i.e. I periodically (typically once/week) run

apt-get update
apt-get upgrade
apt-get clean

In that case however you can end up with loads of updates being installed over time, using up more disk space and perhaps changing programs that you might preferred hadn't been updated/changed.

So if you like a fixed system you might just use apt-get (or synaptic which is the gui version) to install programs and then leave that as-is thereafter. Or perhaps just look for security updates thereafter. Or perhaps keep updating everything so that your installation remains aligned with the current stable Debian. The latter is the 'proper' way, but will mean that the changes folder size will tend to increase in size ... potentially to quite a large size (1GB or more).

[rufwoof]

If you anticipate doing a large update, or just using a lot of disk space, then as the changes=EXIT menu.lst boot parameter keeps all changes in memory during the session, there's a chance you might run out of memory space with too many changes being stored.

To preserve all changes as and when they occur, drop the EXIT: part from the boot parameter i.e.

changes=EXIT:/DD64test/live becomes changes=/DD64test/live

that will slow things down as changes are written to disk as changes occur, but will avoid exhausting memory space. For instance I've just freshly booted and run

apt-get update
apt-get upgrade

to update things. I then installed firefox

apt-get install firefox-esr

and then installed KDE

apt-get install kde-full

After a reboot it was back to the normal desktop. Opening file manager (pcmanfm) and opening up TOOLS, Run a Command ... to run the command "startkde" ... has KDE loaded .... but weirdly ... a mixture of both desktops - has wbar and tint panel showing along with the clock, but all of KDE seems to be working alongside/within that. Obviously more configuring needs to be done to disable the old desktop and boot KDE. Also to note is with just the updates, firefox and KDE installation, the changes folder has a size of 2.4GB !!