Debian Jessie Openbox LXDE frugal

[mcewanw]

Hi rufwoof,

I just remembered that I also created a how to create a frugal installation of Linux Mint (EDIT: Thanks for your comment mikeslr; in that howto from back then it was indeed Lubuntu, though I think much the same might work with Linux Mint, and my menu.lst below is for frugal Linux mint) (the iso download of official Linux Mint is around 1.5GB) - even onto ntfs partition with a casper-rw for persistence. My partner has been using that on her machine for the past few years now. Maybe some of the info from that howto will prove useful for your Debian Jessie frugal thread.

http://www.murga-linux.com/puppy/viewto ... 265#745265

The above was actually more about frugal booting straight from iso since less was understood about that. In practice, I put a more traditional frugal install of Linux Mint onto my partners machine back then, which has the menu.lst entry:

Code: Select all

title linuxmint in /linuxmint/casper (on third partition of drive /dev/sda = hd0,2) save in casper-rw
root=(hd0,2)
kernel /linuxmint/casper/vmlinuz boot=casper config swapon ignore_uuid cdrom-detect/try-usb=true showmounts union=aufs live-media-path=linuxmint/casper/ persistent
initrd /linuxmint/casper/initrd.lz

Actually, I've never touched that frugal Linux Mint installation for over two years and can't even remember where I found that menu.lst line I use to boot it - might have been from Toni - or maybe on some Linux Mint forum - I'm not sure.

I never took that further in terms of trying to "DebianDog" it with porteus boot and so on so maybe some of the info in present thread will be helpful in that regard for me too. In particular, maybe that snapmergepuppy stuff Fred discovered on Toni's github, and added to it, might be useful for my Linux Mint frugal setup too?

http://murga-linux.com/puppy/viewtopic. ... 156#914156

As I've said in the past I would really like some easy addon to the official Linux Mint or Ubuntu or Debian distributions that effectively 'DebianDog' them (not to bothered about size reduction, but like the flexible DebianDog boot mechanisms and remastering and installer utilities (and autoroot login to desktop of course...)

There remains also, of course, Toni's post:

http://murga-linux.com/puppy/viewtopic. ... 954#852954

EDIT: http://www.murga-linux.com/puppy/viewto ... 226#854226

William

[dancytron]

Fred and William,

Thanks for the reply, I'll give it a try soon.

Dan

[catsezmoo]

lead a horse to water but ya can't make him drink?
What's the cure for NIH (not invented here) Syndrome?

In the debianDog thread (and others, IIRC) I've repeatedly mentioned here in the puppy forums
that antiX Linux already has "all this stuff" -- liveboot, flexible persistence modes,
on-demand snapshotting and remastering from live session, frugal install -- it's well developed and well supported.

antiX ships with several window managers preinstalled, including JWM, iceWM, and fluxbox.
You can switch between WMs on-the-fly without disturbing your session. antiX even ships with gtkdialog preinstalled.
See for yourself -- test drive the "Full" (or "Base") antiX liveUSB, login as root (pw:root) choose JWM desktop...

It's like, well, it's been funnysad watching you folks, year after year, reinventing the persistence / remastering wheel.

https://sourceforge.net/projects/antix- ... /antiX-16/
https://github.com/AntiX-Linux
https://github.com/antiX-Linux/Persist- ... master/bin
http://antix.mepis.org/index.php?title=Main_Page
http://mepiscommunity.org/
http://forum.mepiscommunity.org/viewforum.php?f=104 (MX Linux, collaboration b/t Mepis community and antiX devs, ships with xfce desktop)
http://antix.freeforums.org/

Many of your ideas are quite clever. I'm not posting this to belittle your accomplishments.
I believe antiX fits well with your ideas and that you would achieve a greater result if you weren't bogged down by your re-inventing efforts.

[mcewanw]

lead a horse to water but ya can't make him drink?
What's the cure for NIH (not invented here) Syndrome?

And what makes you think you are the more expert doctor?
Perhaps you have made some wonderful programming/script contributions I have not had the pleasure of trying. Or do you believe it means anything to learn how to use the facilities of a distribution, antiX in your case, and then go to the threads for other distributions and tell them they are wasting their time with their own creation. Do you not realise that all distributions have very common roots and much in common - which does not mean that we do not like to 'reinvent' the wheel into somewhat different shapes that better suit our wishes and needs?

And do you really imagine I had never tried antiX when I've been using Linux since prior to the Internet becoming available for public consumption? In fact, I tried it around the time I became interested in the earliest DebianDog work by Toni, because I am continually trying out distributions in search of what feels like the 'ideal' distribution 'for my needs and pleasures'. AntiX was fine in many ways, but I simply didn't like the feel of it quite enough. Rather, I enjoyed the new, though rough at the time, gradually being made 'puppy-like' DebianDog live spin, and it is still me preferred distribution (and I've downloaded newer antiX isos through these DebianDog years, just to see what was on offer). Distributions (spins) learn from each other all the time... Still, Toni and Fred's efforts fitted better my own wishes and ways of organising Linux.

We don't just use distributions here - nor just read tons of technical documents and research all the methods - we implement them, just as the antiX developers do. Much of all of it could be said to be re-inventing the wheel - I would call it learning our craft better - but with the bonus that we sometimes and often discover some new tricks on the way, which is what any kind of research is all about. And I used to be in a research group helping to develop the original tcpip protocols to work more efficiency over big delay, noise prone, satellite links. Back before you probably knew what the Internet you now use was. But maybe you are more skilled than your narrow antiX comments suggest - which would be good - I hope you use these skills to benefit the community.

Just remember - each to their own.

William

[Belham]

lead a horse to water but ya can't make him drink?
What's the cure for NIH (not invented here) Syndrome?

In the debianDog thread (and others, IIRC) I've repeatedly mentioned here in the puppy forums
that antiX Linux already has "all this stuff" -- liveboot, flexible persistence modes,
on-demand snapshotting and remastering from live session, frugal install -- it's well developed and well supported.

antiX ships with several window managers preinstalled, including JWM, iceWM, and fluxbox.
You can switch between WMs on-the-fly without disturbing your session. antiX even ships with gtkdialog preinstalled.
See for yourself -- test drive the "Full" (or "Base") antiX liveUSB, login as root (pw:root) choose JWM desktop...

It's like, well, it's been funnysad watching you folks, year after year, reinventing the persistence / remastering wheel.

https://sourceforge.net/projects/antix- ... /antiX-16/
https://github.com/AntiX-Linux
https://github.com/antiX-Linux/Persist- ... master/bin
http://antix.mepis.org/index.php?title=Main_Page
http://mepiscommunity.org/
http://forum.mepiscommunity.org/viewforum.php?f=104 (MX Linux, collaboration b/t Mepis community and antiX devs, ships with xfce desktop)
http://antix.freeforums.org/

Many of your ideas are quite clever. I'm not posting this to belittle your accomplishments.
I believe antiX fits well with your ideas and that you would achieve a greater result if you weren't bogged down by your re-inventing efforts.

catsezmoo,

I am a antiX user (currently on 16), and, yes, antiX is an incredibly lightweight, fast environment that is already doing nearly everything puppy does (and sometimes better). But, here's the key: it's that word "nearly". You see, believe it or not, there are some things Puppy has done that antiX just looks past and figures the user doesn't want to be involved with that. It would do me no good to point out the number of things various puppy linuxes do that a user almost cannot do with antiX----but of course since you've never used any puppy it would do me no good to point these out. Also, puppy by nature "Forces" the user to learn more about how things work, and this is not true of antiX...and don't be an idiot and say otherwise. The level of users going to antiX forums now (especially with MX's iterations) has dropped to pure dumba## noob. This is not a bad thing, but here in puppy land, you are required and expected to read about various things, whereas in antiX this is not true (nor is it anticapitalista's & crew's mission anymore---they are trying to grow antiX to the mainstream).

Anyhow, I know for a fact before Mepis (2003) and antiX (2007) was floating around, Barry already had his puppy system up and running to a select group of friends before he ever went live with it in early 2003. In fact, Warren (Mepis...study your history) talked about how he admired Barry.

So you need to chill, go take that obvious holier-than-thou attitude out elsewhere, and remember what this forum and the puppy universe is actually about. Guys like rufwoof are exploring and learning here in ways they never could with antiX/Mepis and the way it is now currently setup. And they are teaching and re-teaching all here, old and new alike, as they go along their quest.

[trio]

Hi,

downloaded and boot succesfully (frugal) but I can't get wireless as it doesn't recognize b43 wireless? works ok with slacko tahr and most other puppies. any help? thanks ...

[rufwoof]

I left /etc/udev/rules.d/70-persistent-net.rules in the final version which should be deleted then save2flash and reboot

[rufwoof]

If you install screenlets from Synaptic (desktop clock ...etc widgets) then it wont run as root. You need to edit /usr/share/screenlets-manager/screenlets-manager.py and search for geteuid and change that to getppid save, and then screenlets work ok under root.

Not used screenlets before myself. The easiest way to set them up seems to be to open accessories | screenlets and then pick a screenlet and use the Create Desktop Shortcut option that places a icon on the desktop, and then drag/drop (move) that icon into ~/.config/autostart folder (create that folder if it doesn't already exist beforehand).

[rufwoof]

Finally got around to digging out the 64 bit AMD 4 core PC today and retired the Celeron single core that I've been using a few months now. Did a frugal install of the 64 bit AMD Debian Jessie onto a USB HDD, placing grub4dos, the Debian Live folder and making the same partition the persistence partition. That hung for ages at the boot prompt (loading vmlinuz or whatever). Shifting the live folder over onto the NTFS partition resolved that delay.

Skype proved a little awkward to get setup this guide came to my rescue. I think ??? its installed a 32 bit environment for that to run in ... not sure ??? MasterPDFEditor installed no problem. (They're the only two external (non synaptic) progs I run).

2GB ram. First load of libre spreadsheet/word processor is a little slow (being read from USB HDD), but acceptable (few seconds). Thereafter once memory bound subsequent startups flash up in less than a second.

[mikeslr]

Hi trio,

I'm trying to follow rufwoof's process but using debian jessie 64-bit.. Booted OK, but still haven't worked out persistence (see below). Had set the project aside primarily because (a) I have a more pressing project having nothing to do with Linux and, especially (b) I also couldn't get wifi working even though I had downloaded and installed firmware-ralink_0.43_all.deb.

The problem I have with debian distros, including Ubuntus with a couple of exceptions such as zorin, is that OOTB they lack the firmware/drivers required by my desktop.

Yesterday, I remembered that debiandog64 had functional wifi. So I booted into it and copied its entire /lib/firmware directory to a temporary folder. Then, booting into Tahrpup, I copied filesystem.squashfs from /live to another directory, changed its ending to sfs, unpacked it with UExtract, copied the firmware directory into /lib, repacked it and changed the name back to filesystem.squashfs.

After substituting the modified filesystem.squashfs for the original, Jessie64 booted up with functional wifi.

So, trio, if you had wifi running debiandog-jessie, and nothing else works, you might try the above technique.

The ultimate objective of my project is a frugal zorin with persistence using a directory (rather than a file or partition). Zorin, because it's my 2nd favorite "distro" which --when run as its makers provided-- generally works OOTB on every computer I've tried. Thanks fred and mcewanw for the information you've provided. Hopefully, when I get back to my project that information will be useful.

@ mcewanw. Your previous post referred to a project involving Linux Mint. The post you provided a link to, however, concerned Lubuntu. For my purposes this is even better. Zorin, like Lubuntu, is an Ubuntu remaster. But maybe you should correct the scribner's error. And, I think renaming your thread to "HOWTO use Ubuntu live-cd on ntfs hd subdirectory with grub4dos" would make it easier for those of us interested in running other distros Frugally to find it.

At any rate, thanks guys for your continuing work in this area.

mikesLr

[mcewanw]

Thanks, made quick edit to the posts.

William

[fredx181]

Hi rufwoof, all,

Another interesting idea from Toni (see: 4. The perfect full install):
https://github.com/MintPup/DebianDog-Wh ... options.md
Or maybe call it 'the perfect frugal install' ?

Anyway I tested that setup and it works well, here's what I did:
Opened a terminal in the 'live' folder (where filesystem.squashfs is located and:

Code: Select all

# extract the compressed filesystem in folder: zchanges.dir (named zchanges.dir because it needs to be later in alphabetical order than any other <module>.squashfs 
unsquashfs -d zchanges.dir filesystem.squashfs
# backup original filesystem.squashfs
mv filesystem.squashfs filesystem.squashfs.orig
# make new empty directory and create (empty) filesystem.squashfs
mkdir new
mksquashfs new filesystem.squashfs

EDIT: just found that it works also without (empty) 'filesystem.squashfs' at all, so the last two steps can be skipped.

EDIT2: No, without .squashfs, sfs-load doesnt work (tested on DebianDog now) "cannot find any free loop devices" , indeed there aren't any in /dev

Changes are not preserved after reboot unless you run 'snapmergepuppy' before shutting down.
see here for info about custom snapmergepuppy and download:
http://www.murga-linux.com/puppy/viewto ... 156#914156

Tested this also on DebianDog and it works well also.
(still having the advantages of frugal install e.g. sfs-load and other module tools, except apt2sfs became useless this way, using apt2sfs for full install works fine though)

Boot code in case /DEB/live on 4th partition:

Code: Select all

 title DebianLive686 NOPERSISTENCE (run snapmergepuppy to save to live/zchanges.dir)
root (hd0,3)
kernel /DEB/live/vmlinuz2 boot=live live-media-path=/DEB/live/
initrd /DEB/live/initrd2.img

Or even better (makes kernel version update possible without problems):

Code: Select all

 title DebianLive686 NOPERSISTENCE (run snapmergepuppy to save to live/zchanges.dir)
root (hd0,3)
kernel /DEB/live/zchanges.dir/boot/vmlinuz-3.16.0-4-686-pae boot=live live-media-path=/DEB/live/
initrd /DEB/live/zchanges.dir/boot/initrd.img-3.16.0-4-686-pae

Fred

[rufwoof]

Hi Fred

I had played around with a similar concept. Extracted all of the filesystem.squashfs to the persistence partition so always top read from there once up and running, and replaced the filesytem.squashfs with a slimmed down version that had all of the main apps such as Libre Office, browser, gimp .... etc. removed i.e. primarily for initial booting purposes. But from what Toni's done it looks like that could have been emptied out totally. Nice.

I like your kernel version update boot code tweak. Neat.

[fredx181]

I had played around with a similar concept. Extracted all of the filesystem.squashfs to the persistence partition so always top read from there once up and running, and replaced the filesytem.squashfs with a slimmed down version that had all of the main apps such as Libre Office, browser, gimp .... etc. removed i.e. primarily for initial booting purposes.

Ah, yes, lots of things are possible.

I like your kernel version update boot code tweak. Neat.

Toni's idea, not mine.

See my EDIT in previous post, it can be totally without filesystem.squashfs
EDIT: Gotta take that back, gives complications using sfs-load on DD, see EDIT2 in previous post

Fred

[rufwoof]

Using Debian live CD filesystem (updated to latest versions and LXDE tweaked to run as root), extracted that to zchanges.dir as suggested, extracted the snappy puppy merge tgz and renamed the snappuppymerge file to saveondemand (just my own personal choice of naming), which I dropped into /usr/bin within the zchanges.dir sub-directory tree

Booting using (I'm now using a search (find) to locate the root rather than specifying a particular hd0,0 or whatever)

Code: Select all

title DebianLive686 NOPERSISTENCE (run saveondemand to save to live/zchanges.dir)
find --set-root /DEB/live/vmlinuz
kernel /DEB/live/vmlinuz boot=live live-media-path=/DEB/live/
initrd /DEB/live/initrd.img

and all worked fine. Started up, made changes, rebooted without saving and no changes preserved. Ditto, but running saveondemand and it merged the changes in fine (preserved across reboots).

I was testing that as you posted your last post i.e. I ran with a empty filesystem.squashfs file content ... so off now to test when run with no filesystem.squashfs at all.

I think this is all absolutely great !!! I had just assumed that filesystem.squash had to be there in order to boot ... never thought to confirm or otherwise that.

[rufwoof]

For that second choice of menu.lst entry I had to change mine to :

Code: Select all

title DebianLive AMD64 NOPERSISTENCE (run saveondemand to save to live/zchanges.dir)
find --set-root /DEB/live/vmlinuz
kernel /DEB/live/zchanges.dir/boot/vmlinuz-3.16.0-4-amd64 boot=live live-media-path=/DEB/live/
initrd /DEB/live/zchanges.dir/boot/initrd.img-3.16.0-4-amd64

to account for that I used the filesystem.squashfs from the Debian AMD64 bit live CD/ISO (as I'm now using a 4 core 2GB AMD64 PC).

[rufwoof]

I'm happy to run without SFS loading (no filesystem.squashfs). Debian's stable repository is very good and adequate. Where things are missing usually there are .deb's. SFS's risk corrupting the package database (so I believe). Frugal with save on demand, and access to great repository and quick security updates ... fulfills my personal needs.

With no filesystem.squashfs I've just

mkdir -p tmp
mount -o loop ./some.squashfs tmp/

and the filesystem was mounted ok i.e. cd tmp and content readable. Afterwards

umount -f tmp
rmdir tmp

to 'unload' the sfs.

Of course that doesn't layer the sfs, but layering can cause problems sooner or later, I'm content to avoid that.

[rufwoof]

https://github.com/MintPup/DebianDog-Wh ... options.md

4. The perfect full install.

I've described this method using save file or save partition in How to reduce the size of Debian Live image and here. But now the option to save changes on exit in directory with live-boot makes possible to have perfect full install.

In short using live-boot (2 or 3 or 4) without persistent boot code (only save file or save partition needs persistent boot code) and having in "live" empty 01-filesystem.squashfs and the system (the content of 01-filesystem.squashfs) extracted in changes.dir folder you will boot in frugal mode with read-only system in changes.dir. Any changes you make will be lost after reboot if you dont save on exit. But when you save changes in changes.dir there will be no duplicated files in the empty 01-filesystem.squashfs and changes.dir and there is no need to remaster the system anymore. The remastering or backup process could be simple archive of changes.dir folder (after some cleaning) portable to install (extract) on different drive, usbflash or sdcard. And the system boots uncomressed changes.dir content much faster compared to squashfs module. You get all advantages of full install in frugal mode keeping the option to save or not your changes and to load extra squashfs modules. There is no problem to combine this boot method with real save file or partition adding persistent (persistence) boot code in case you have low RAM machine. The difference is all changes will be preserved in save file but you can remove this file or boot without persistent code any time after saving the changes you need in changes.dir.

Not sure (my bold highlighted in above) And the system boots uncomressed changes.dir content much faster compared to squashfs module ... is accurate!

Running pure Debian with persistence partition, with two boot choices of booting read/write or read only

title Debian Jessie LXDE READ/WRITE
find --set-root /DEB-LXDE/live/vmlinuz
kernel /DEB-LXDE/live/vmlinuz boot=live config persistence quickreboot noprompt showmounts live-media-path=/DEB-LXDE/live/ config
initrd /DEB-LXDE/live/initrd.img

title Debian Jessie LXDE READ ONLY
find --set-root /DEB-LXDE/live/vmlinuz
kernel /DEB-LXDE/live/vmlinuz boot=live config persistence persistence-read-only quickreboot noprompt showmounts live-media-path=/DEB-LXDE/live/ config
initrd /DEB-LXDE/live/initrd.img

... then I can either have most/all of the content in filesystem.squashfs, or extract all of that content to the peristence partition and have no filesystem.squashfs

Of the two, at least for a physical HDD, if the filesystem.squashfs is compressed using a fast decompressor such as lzo level 1 (or for a later kernel that supports it .... even faster lz4), then typically the filesize is halved (compression), and on my system at least its actually quicker to disk IO half as much and decompress that using lzo (i.e. using a lzo compressed filesystem.squashfs) than it is to disk IO twice as much but have no decompression involved (i.e. all of filesystem extracted to the persistence partition). More so under multi-cores where all four or whatever cores might be decompressing in parallel. With lz4 the decompression speed throughput can conceptually exceed ram speeds (i.e. in practice is slowed down by ram speed limits).

Another advantage of the two RW or RO boot choices is that any large updates applied to a RW session are instantly saved to disk, so there's no risk of breaching memory limits compared to alternative methods that save on demand (such as running save2flash or snapmerge).

The persistence partition choice also means there's no script involved ... and that has to be maintained/changed. It all runs using pure Debian only. Of course some changes are desirable, such as changing to run as root rather than as a "user" - which has knock on changes being required such as changing VLC and other config files to enable running as root.

I also like the clearer distinction. Boot RW purely to make changes or apply updates before rebooting back into RO mode again, helps keep the main system more pristine/factory fresh.

Another point of note is that the persistence partition can be the same partition as where menu.lst (grub4dos) and where the live (Debian) filesystem.squashfs is. You can also set it to look for a different partition name (LABEL) also. So you might for instance have menu.lst, DEB/live and the persistence saves all within the same single partition, maybe also with your own data/docs also stored within that single partition (but outside of Debian save space). Does make it less tidy/separated, but equally keeps it all within a single partition/space (see attached image)

[mandibule2005]

firmwares debian wireless drivers

https://drive.google.com/file/d/0Bz1ZmB ... sp=sharing

[rufwoof]

I've shifted the live folder up one level ... to the root of the partition.

So fundamentally ... create and format a primary ext3 partition to install grub4dos (bootloader) to and install grub4dos. Give that partition a LABEL of 'persistence' and set its flag as a boot partition. Copy the live folder from the LiveCD ISO to that partition. Extract the content of the filesystem.squashfs in that live folder to the root partition - the way I did that was first extract it to a sub-directory and then move everything up to the root level before deleting that empty directory

Code: Select all

cd /
unsquashfs -d extracted /live/filesystem.squashfs
mv /extracted/* .
rmdir extracted

Afterwards create a empty /live/filesystem.squashfs content

Code: Select all

cd /live
rm filesystem.squashfs
mkdir etc
mksquashfs etc filesystem.squashfs
rmdir etc

Now that single partition acts as the grub4dos, Debian filesystem and persistence.

My /menu.lst looks like

Code: Select all

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

title Debian Jessie Frugal RW
find --set-root /live/vmlinuz
kernel /boot/vmlinuz-3.16.0-4-amd64 boot=live config persistence quickreboot noprompt showmounts live-media-path=/live/ config
initrd /boot/initrd.img-3.16.0-4-amd64

title Debian Jessie Frugal RO
find --set-root /live/vmlinuz
kernel /boot/vmlinuz-3.16.0-4-amd64 boot=live config persistence persistence-read-only quickreboot noprompt showmounts live-media-path=/live/ config
initrd /boot/initrd.img-3.16.0-4-amd64

So I can boot either read only (no changes preserved) or read/write where changes are written immediately to disk. Note that the initrd /boot/initrd.img-3.16.0-4-amd64 and kernel /boot/vmlinuz-3.16.0-4-amd64 point to the internal versions, so its more accommodating of any kernel updates

I allocated 16GB to that partition and it has 9.5GB left free after applying all updates and installing a load of programs (Openshot, blender, inkscape, audacity, recordmydesktop, devede, brasero, vlc ....etc.)

The only thing I've found that doesn't work so far is Plymouth animated splash. Rather it works, but you can't change its theme.

EDIT : attached is a modified snapmergepuppy .... so now you can either boot "persistence" and have all changes immediately stored alongside menu.lst in the root of the partition, or boot "persistence persistence-read-only" and no changes are preserved .... except if you run snapmergepuppy in a terminal (save on demand style).

Generally you might run persistence persistence-read-only most of the time, so changes can be made or not (on demand) by running snapmergepuppy. But sometimes such as a large Debian update that might exhaust memory/ram, booting persistence (changes stored as and when they're made) circumvents memory exhaustion problems.

Caveats : Have to be running Liveboot3 style and with a persistence root partition alongside where menu.lst is installed (first partition), not be a file type persistence and the label for persistence partition has to be 'persistence' (can't be changed to something else and use persistence-label=xxx boot parameter for instance - as snapmergepuppy looks for the hard coded 'persistence' keyword).

EDIT - uploaded another version as BASE grep line was potentially picking up more than one line (so added -m 1 parameter so only the first line is picked up).