If you download a current Debian stable liveCD you can format a HDD partition (and set its boot flag as being on), copy the /live folder from the CD/ISO to that HDD, install grub4dos (which despite its name can install a bootloader and menu.lst onto a ext format partition) and point menu.lst to boot that /live folders initrd, vmlinuz and filesystem.squashfs.
Allocate that partition a label of 'persistence' and you can boot that same set up but with all changes being preserved into the same partition (alongside the /live folder and grub4dos menu.lst ....etc).
Boot with a peristence persitence-read-only kernel boot parameters and that will read the persistence (changes) during bootup, but wont add to them (changes lost at shutdown) [There is a method to flush those memory based changes to disk if you so desired, but that's more involved and whilst I have a working copy of that, I'm not going to detail that any further here].
Take all that a step further and if you extract the content of the /live/filesystem.squashfs to the / folder, then in effect all changes are being recorded outside of filesystem.squashfs ... which becomes redundant. Rather than just deleting it however its better to create a empty version of that file, as without it no other squashfs files can be loaded at bootup. I just removed filesystem.squashfs and created a new one using
mkdir somedir
mksquashfs somedir filesystem.squashfs
rmdir somedir
(you need squashfs-tools to be installed in order to run mksquashfs).
Taking that one step further still, if you start off with a full install running from / then you can work things the other way around and just install a /live folder with a empty filesystem.squashfs and provided you install grub2 to the root partition rather than the mbr, then you can install grub4dos to the mbr and have that either boot the read only 'live CD' style choice, or chain to the grub2 boot menu to boot a 'full install' boot style.
A nice thing about full install is that updates ...etc work as intended and you can run a 'pure' Debian in the usual manner. But with the liveCD boot style (but booting from HDD) booted read-only (all changes recorded in memory/lost at shutdown (with exception of a optional script to flush memory records to disk as I indicated earlier)) you can run tests on that installation, where any changes are lost when you reboot. Great for trying out new programs etc. installed via apt-get or synaptic or whatever, but where you might decide to 'undo' those changes. Or for trying out different configurations that might end up with a messed up system, but where a simple reboot has all those changes undone. The main appeal to me is that I can run in read-only mode for most of the time (just have to store docs ...etc elsewhere (on another partition)) and reboot the exact same 'factory fresh' version each and every time; But when updates are apparent then reboot the full version (read/write) to install those updates before rebooting back into read-only mode again.
This is what part of my /menu.lst looks like (note that I created a /debian-usb flag file for grub to find)
title Debian Jessie Frugal RO
find --set-root /debian-usb
kernel /vmlinuz boot=live config rw rw-basemount nofastboot persistence persistence-read-only persistence-label=persistence quickreboot noprompt showmounts live-media-path=/live/ config
initrd /initrd.img
# Full installed Linux
title Debian FULL Install : GNU/Linux, kernel 3.16.0-4-amd64(sdf1/boot/grub/menu.lst)
find --set-root /debian-usb
configfile /boot/grub/menu.lst
commandline
In my case installation of debian resulted in grub pc being installed into /boot/grub/ ... so the first boot loader chains to another grub legacy style menu - that might equally however have been a chain to teh more normal grub2 style boot config file/loader
PS : a trick I use ... as when you boot the exact same system in RO or RW modes you can sometimes forget which way you actually booted ... is to run the command cat /proc/cmdline which provides a indication of which way the current session was booted.
PPS : if you've booted a RO session then the number/size of changes are limited to available free memory space, beyond that and the system will slow right down (more changes than what can be stored in available free memory).