Debian Frugal [THREAD CLOSED]

[rufwoof]

[THREAD CLOSED]

Assuming you boot using grub4dos and have a ext2/3/4 type partition, then you can create a save file to use with a Debian Live CD, where the filesystem is moved to that
ext2/3/4 HDD (so no CD actually needed, all boots and runs from HDD frugally). I used my sda4 ext3 partition to do that, and created a 4GB savefile (count=4096)

cd /mnt/sda4
dd if=/dev/zero of=/mnt/sda4/persistence bs=1M count=4096

format that

mkfs.ext3 /mnt/sda4/persistence

find a free loop

losetup -f

(mine returned /dev/loop1 as being free). Mount it and create the persistence.conf that Debian requires

losetup /dev/loop1 persistence

mkdir -p tmpfs
mount -t ext3 /dev/loop1 tmptfs/
cd tmpfs
echo / union >persistence.conf
echo >>persistence.conf
cd ..
umount /dev/loop1

that save file must be named "persistence" and reside in the root directory of the partition i.e. /mnt/sda4/persistence in my case.

Grab a ISO via the Debian Live web site (I clicked on the i386 CD/DVD/USB link around two thirds of the way down that page and opted to grab the KDE version debian-live-8.5.0-i386-kde-desktop.iso )

Open that ISO with ROX or Thunar (or whatever filemanager) and copy the "live" folder from the CD/ISO over onto your hard disk, perhaps into a new directory called DEB (I created mine on the first HDD 4th partition (sda4) which is numbered hd0,3 in grub4dos terms

Edit your grub4dos menu.lst to point to that frugal, mine looks like :

# menu.lst
color white/blue black/cyan white/black cyan/black
timeout 1
default 0

title DebianLive686 PERSISTENCE
root (hd0,3)
kernel /DEB/live/vmlinuz2 boot=live config persistence quickreboot noprompt showmounts live-media-path=/DEB/live/ config
initrd /DEB/live/initrd2.img

... and you're ready to boot frugally and where all changes will be preserved across reboots.

As the above frugal saves all changes during/after each session no matter what (no choice other than to have changes preserved, except of course if you boot with no persistence parameter being passed to the kernel in menu.lst) I'm playing around with having a optional persistence choice. Note that the "persistence" save file in the root directory can actually be a symbolic link. So my thoughts are along the lines of having two copies of the persistence savefile, initially exactly the same at bootup, but where one is sym linked as the current session savefile ... such that at shutdown you might either opt to preserve those changes (leave the 'persistence' sym link pointing to the updated save file version), or not (repoint the sym link to the prior 'persistence' save file). That would require copying potentially large (save) files however (4GB in my case), which for larger savefiles can be quite a slow process. i.e. if no save then you need to make the two savefiles (active and copy) the same as the copy, or if save then you need to make the copy the same as the active. Still thinking that through, for example maybe have even more copies, one that creates a copy of the copy during a session, running as a background task with a 'nice' command during a session, so if no save is requested at the end of a session the copy has already been made beforehand during the session; And/or some form of active savefile duplication/mirroring during the session ... in a similar manner. Whilst that becomes disk space heavy, in more modern hardware diskspace often isn't a problem/issue.

Debian KDE certainly is highly configurable with some nice features. Being able to boot frugally with optional persistence makes something that's already very good .... a little bit better.

[learnhow2code]

i would love to try this with devuan. i gave my extra drive to someone who needed it, but i could do something with a usb.

im really curious what it would take to make a "pup in a .deb" (pupkit? instantpup? chiapup?) that you installed in debian/devuan to make it as much like puppy as possible.

im thinking of "full chia" which includes puppy-style init, and to start, "mini chia" which focuses on easy stuff like rox config, desktop/config, the familiar apps...

similar to the idea of making a script to create dpup from a debian/devuan iso. some of the workings may already be in place.

[fredx181]

Hi rufwoof,

As the above frugal saves all changes during/after each session no matter what (no choice other than to have changes preserved, except of course if you boot with no persistence parameter being passed to the kernel in menu.lst) I'm playing around with having a optional persistence choice.

Just for info (I didn't test any of the below):

During the discussion we had on the DebianDog - Jessie thread about the libc6 upgrade and resulting in a crash when using porteus-boot EXIT:/... Toni wrote about "persistence-read-only" boot parameter (and copying changes during session which may have the same effect as EXIT:/..):
From here:
http://murga-linux.com/puppy/viewtopic. ... 431#890431

Reboot adding persistence-read-only

Code:
title DebianDog persistence-read-only
root=(hd0,0)
kernel /live/vmlinuz1 boot=live config quickreboot noeject showmounts persistence persistence-read-only
initrd /live/initrd.img

Check out mount command and you will see /dev/loop1 (your save file) mounted read-only and all changes will be saved in RAM and lost after reboot.
Upgrade to the latest libc6:
Code:
apt-get install libc6

Now use mnt-img to mount persistence save file and try the same "cp -a -f" command that fails with porteus-boot save on Exit:
Code:
cp -a -f /lib/live/mount/overlay/root/* /media/+lib+live+mount+persistence+sda1+persistence/

Maybe this can be scripted (without the libc6 install command of course) to have some sort of 'save2flash' on Debian frugal


Fred

[rufwoof]

Thanks Fred.

New to me, persistence read only. Just reading through https://craftedflash.com/info/live-dist ... parameters. Also see that you can specify other names and locations for the persistence (save) file.

I'll have a look through Debian save2flash as a combination of that with read only persistence would be a ideal solution. Pretty generic also if you can specify location and names via kernel boot parameters.

[Belham]

Debian KDE certainly is highly configurable with some nice features. Being .

rufwoof,

Be careful of the "cube" It will suck you in, and you'll get so enamored of it that you'll yearn to see it, just tapping your mouse to bring the computer awake. LOL. almost 2 years ago, I became a KDE desktop fanatic, had the most luck making it stable setting up & running Arch with KDE Plasma 4 (and now Plasma 5). Between that little bit of fun, there is one other thing that makes the KDE desktop (though it is a major RAM hog) outstanding:

-----------any window, of any program/folder/terminal/etc/etc, if you just right click on its top bar, a tab comes up with the normal Minimize, Maximize, Attach to, but then there is one choice there that is magical: the "More Actions". Scroll over it and/or click on it, and behold the world of KDE and its powerful attraction. Gives you powerful, precise, detailed control over every window placed on the desktop screens that KDE controls. The one setting in there "Special Window Setting", my God, how other distros don't hop all over & steal this is beyond me. You click that "Special Window Settings", and the first two choices (of the many that pop), let you dictate the "Position" and "Size" of each & every window, and how it will be saved for eternity (and you never have to touch it again---if you move the window, the settings move with you & thus save the new ones). Just remember to click "Remember" by both "Position" and "Size", and it will make your whole desktop experience transformed. Being able to open multiple aps, folder, etc, if you want, and they all have their special placement in whatever monitor or monitors world that you have, is just incredible. Even for laptops, this feature is deadly useful.

One of the biggest headaches/nightmares in the Linux world is so many distros inability to let the user dictate when, where, how, and what size a window for a program, file, terminal, update, etc, etc opens and is placed (for anything within the desktop environment). KDE is just sublime in this regard. Just look at the fine, granular control you have over placement (ala like Conky setting if you so desire, but you don't have ot get that detailed, just click those two settings and put that window wherever you want it and it will open there (and whichever screen) until you actually move/drag that window again.


KDE can be really wonky at times, so be prepared for a few headaches. But they are worth it, especially if you're someone who demands fine, granular control of your desktop.

Live long & prosper

[rufwoof]

Thanks for that tip Belham. Neat.

galculator annoyingly for me kept opening at the top left of screen. With your tip it now opens more to where I prefer. Thanks again.

Love how you can scale individual icons and even rotate them (and widgets) to any angle

[rufwoof]

Tried the persistence-read-only kernel boot parameter and it just didn't overlay the persistence content (booted to just the filesystem.squashfs desktop only).

Gave me the idea of trying to set persistence as read-only to prevent writes, and see what happened if I then adjusted it to being read/write later, whether changes would be written. No luck though, during the streams of fast passing bootup messages I'm pretty sure I saw something mentioned about read only, read/write required ... would be adjusted/corrected .... and indeed changes were preserved even though the persistence file remained with just read only permissions. So looks like the system is clever enough to circumvent such write blocking. Shame, that would have been a nice easy method (queue up all of the changes until you decided to set the rw permissions and have all of the changes preserved (or not bother and have all of the changes blocked from being written).

[rufwoof]

A simple solution is just to leave it as non-optional persistence, and just make backups so that its easy to revert to a prior version(s).

Installing squashfs-tools from the repository and using no compression mksquashfs and sudo mksquashfs persistence persistence-backup.squash -noD -noX -noF -noI (that's a big i) ran through a 4GB persistence filesize in around a minute on this slow/old PC and reduced the filesize down to 800MB. (And you can use unsquashfs to extract that backup).

Easy backups and not having to dedicate a partition is after all the main benefits of frugal.

[rufwoof]

I've moved persistence from the root directory of sda4 into the /DEB sub-directory and renamed it to be called "savefile" Keeps it all more together that way and somewhat more aligned to puppy-style. To accommodate those changes I changed my grub4dos menu.lst entry to :

# menu.lst
color white/blue black/cyan white/black cyan/black
timeout 1
default 0

# Debian KDE in grub terms in hd0,3 i.e. sda4 first HDD, 3rd partition counting from 0
title DebianLive686 PERSISTENCE
root (hd0,3)
kernel /DEB/live/vmlinuz2 boot=live config persistence persistence-storage=file persistence-label=savefile persistence-path=DEB quickreboot noprompt showmounts live-media-path=/DEB/live/ config
initrd /DEB/live/initrd2.img

So now a copy of the original Debian liveCD/ISO 'live' folder copied to /DEB/live and a persistence file in /DEB called 'savefile' (sda4 /DEB/savefile in my case).

Haven't tried it but I guess you could have other such instances/copies for different versions of Debian (XFCE, GNOME ...etc) in a similar manner but in other sub-directories and have grub4dos menu prompt you for whichever one you wanted to boot.

Creating a new savefile would involve something like

cd /mnt/sda4/DEB
dd if=/dev/zero of=/mnt/sda4/savefile bs=1M count=4096 # create block file
mkfs.ext3 /mnt/sda4/savefile # format it

losetup -f # find a free loop
# (mine returned /dev/loop1 as being free).
# so mount it using that free loop and create the persistence.conf that Debian requires

losetup /dev/loop1 savefile

mkdir -p tmpfs
mount -t ext3 /dev/loop1 tmpfs/
cd tmpfs
echo / union >persistence.conf
echo >>persistence.conf
cd ..
umount /dev/loop1

[rufwoof]

i would love to try this with devuan. i gave my extra drive to someone who needed it, but i could do something with a usb.

I grabbed this Devuan ISO, opened it up, created a DEVUAN directory in the root of my sda4 (hd0,3 in grub4dos speak) and copied the 'live' folder from the ISO to sda4 /DEVUAN/live

Using the ISO as a template I set grub4dos menu.lst to

# menu.lst
color white/blue black/cyan white/black cyan/black
timeout 1
default 0

title Devuan PERSISTENCE
root (hd0,3)
kernel /DEVUAN/live/vmlinuz boot=live union=aufs nomce apm=power-off locales=en_GB.UTF-8 persistence live-media-path=/DEVUAN/live/
initrd /DEVUAN/live/initrd.img

I created a new savefile as per Debian in other posts in this thread and booted up OK. It didn't however save the session. Perhaps they use a different persistence name (others use the likes of live-rw or other such names).

[learnhow2code]

I created a new savefile as per Debian in other posts in this thread and booted up OK. It didn't however save the session. Perhaps they use a different persistence name (others use the likes of live-rw or other such names).

first of all, this is VERY COOL and definitely shows that it could possibly work with devuan. the distro you selected is devuan-based (compare to a debian-based distro, there are so many) but devuan itself is a lot closer to debian (and may work better.) thats cool though, im glad it booted and this is a lot of fun, thank you.

[watchdog]

I have experimented with frugal Debian and Ubuntu some time ago. Forum user Saintless with others and the Debiandog thread can come useful doing it. I abandoned my experiments for two reasons:

1-Debian and Ubuntu are not statically built and updating is a must with these distros. I don't like authomatic updates with very large mantained repositories. The savefile has little life and can grow very fast in a frugal install. These distros work better with a full install.

2-I like the stripped libraries of puppy and I was afraid installing very large packages instead of the tiny packages of puppy.

[rufwoof]

1-Debian and Ubuntu are not statically built and updating is a must with these distros. I don't like automatic updates with very large maintained repositories. The savefile has little life and can grow very fast in a frugal install. These distros work better with a full install.

You could perhaps make a backup of the content of /etc/apt/sources.lst and then empty that file to disable updates to make a static version. Then periodically make a backup of the savefile, re-enable updates and apply all changes .... test as desired and either keep, or not those changes (rollback to the previous copy of the savefile).

Frugal makes backing up a bit easier, and doesn't require a dedicated partition.

[anikin]

Wait, what you guys are talking about?
To the best of my knowledge, neither Ubuntu, nor Debian do automatic updates by default. https://help.ubuntu.com/12.04/servergui ... dates.html

Automatic Updates

The unattended-upgrades package can be used to automatically install updated packages, and can be configured to update all packages or just install security updates. First, install the package by entering the following in a terminal:

sudo apt-get install unattended-upgrades

https://help.ubuntu.com/community/Autom ... ityUpdates Secondly, I personally am very skeptical about "save/persistence" options. If you feel the need to preserve the changes to your Debian/Ubuntu/Pup/Dog, please do yourself a favor - remaster! Let us promote and share the best possible practices. Why create additional layers of complexity (/unions/loops/whatever) and confuse us little puppians with totally unneeded and redundant procedures - don't we deserve better?

[learnhow2code]

Why create additional layers of complexity (/unions/loops/whatever) and confuse us little puppians with totally unneeded and redundant procedures - don't we deserve better?

all those procedures should be maintained by developers, not users-- people who have taken time to learn how puppy works.

puppy has always provided options for saving parts of the users changes to the system, and remastering was never as easy or trivial as using a savefile.

whats unneeded to you is the reason someone else uses puppy in the first place, thats why there are options.

[Belham]

Wait, what you guys are talking about?
To the best of my knowledge, neither Ubuntu, nor Debian do automatic updates by default. https://help.ubuntu.com/12.04/servergui ... dates.html

Automatic Updates

The unattended-upgrades package can be used to automatically install updated packages, and can be configured to update all packages or just install security updates. First, install the package by entering the following in a terminal:

sudo apt-get install unattended-upgrades

https://help.ubuntu.com/community/Autom ... ityUpdates Secondly, I personally am very skeptical about "save/persistence" options. If you feel the need to preserve the changes to your Debian/Ubuntu/Pup/Dog, please do yourself a favor - remaster! Let us promote and share the best possible practices. Why create additional layers of complexity (/unions/loops/whatever) and confuse us little puppians with totally unneeded and redundant procedures - don't we deserve better?

Let me get this straight? You want us users to "remaster" whatever puppy we are using every time we make a change to it, whether a much needed security update to, say, a browser, or openssl, or etc, etc, etc? How in the heck/he!! do us "users" have all these things saved for the next boot, if we don't use the "save/persistence" option on some of the Pups and their derivatives? If I am not mistaken, not every pup and/or derivative has an "overlay" function where everything you do is saved for the next reboot. To me, it sounds like a pure headache to have to remaster every time I am coming out of puppy. No, make that is sounds "jacka@@"-ish to do it. Sorry, anikin, but I cannot understand where you are coming from with your comment (apologies if I am misunderstanding something here).

I'd say 95% of pup users aren't fooling around like learnhow2code and rufwoof and others do. But what they do helps us continue to learn how puppy works. That is what Barry always wanted when he first did his puppy many, many moons ago.

[fredx181]

I grabbed this Devuan ISO, opened it up, created a DEVUAN directory in the root of my sda4 (hd0,3 in grub4dos speak) and copied the 'live' folder from the ISO to sda4 /DEVUAN/live

I like this one specially because of KDE3 (now called Trinity) and because of what the exegnu developers did with it, many programs in less than 700MB iso.

The options for save should be "persistent" rather than "persistence" on the kernel command line and the savefile or partition should be named/labeled "live-rw" (using the older live-boot v2)

EDIT: said the above too easily, only read about it to do it that way, but couldn't make it actually work (can't understand yet, maybe "persistence" boot parameter should be it, but not sure)

Belham,

Let me get this straight? You want us users to "remaster" whatever puppy we are using every time we make a change to it

Probably anikin didn't mean to say to remaster everytime after any small change, but only after making many changes you'd like to keep, e.g. install/uninstall lots of programs or e.g. changing complete desktop GUI .

Fred

[gcmartin]

I am late to this party. But, I have used persistence/persistent in the past.

Does use of the partition approach for persistence operate as a save-session same as the savefile that is referenced here. Further, for some of us, a save-session folder arrangement provides a better approach in understanding versus a loop-based savefile which consistently runs out of space.

Can persistence using a folder approach versus a "loop-file" approach be available or optional?

Because of the focus on savefile, is there something inherently wrong with a save-folder for persistence?

And lastly, could a persistence savefile be made into a persistence save-folder and that folder found and used at boot-time?

Curious. Seeking merely an understanding.

[rufwoof]

Hi gcmartin

The 'usual' is to have a save partition, more often called something (having a label) like live-rw, casper-rw, persistence ... depending upon the system being run. Debian at least has a option to use a file that's been created as a filesystem type alternative ... i.e. a savefile. Which is more convenient if you want to run multiple systems frugally as that can be in the same sub-directory as the main filesystem (squashfs). One partition for each system in contrast .... is no different to just doing a full install of each system into its own partition in many respects.

Not sure about a savefolder option. I've just tried creating a savefile with a savefolder sub-directory beneath where that savefile is located, with that savefolder having empty directories of etc, home, usr, lib .... etc, and then the savefile having relative symbolic links to those ... but when that savefile was used by Debian as a savefile, it didn't work (didn't preserve changes nor store anything in those sub directories). i.e. tried a savefile choice where the file is mounted as a filesystem, and where that filesystem sym links to local ext3 directories ... but didn't work. That would have been a relatively easy way to have a savefolder type choice, but apparently not a option ... unless I did something wrong or there is a alternative choice (I did notice that the savefile had a additional UNION folder created in it when active, so there may be other approaches that might perhaps work). I did also try booting using a persistence partition where the etc var usr .... etc folders were all sym links to folders within a sub-directory on another partition .... but that also didn't work.

As you say a savefolder is a nice choice, no issues with space running out, and more flexible than partition based saves. A savefolder would be the ideal IMO.

[fredx181]

Comment about what I wrote in previous post about Exegnu:

EDIT: said the above too easily, only read about it to do it that way, but couldn't make it actually work (can't understand yet, maybe "persistence" boot parameter should be it, but not sure)

Indeed as I thought later: for Exegnu it's just the same as Debian Jessie :
"persistence" parameter on kernel boot line and savefile/partition named/labeled "persistence"
Strange thing is that a wallpaper change isn't applied after reboot but other things I did were changed/added properly; e.g. installing new programs,adding icons to desktop.

Fred