Debian Jessie Openbox LXDE frugal

[rufwoof]

firmwares debian wireless drivers

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

Synaptic search for wireless drivers produced the results as per the attached image

[fredx181]

Hi rufwoof,

Just noticed your EDIT about using your modified snapmergepuppy with persistence persistence-read-only
I tested and it works great!
It seems that you have found the ultimate frugal/full?? install

Here's a way to increase the size of /lib/live/mount/overlay, by default it's half of the total RAM.
To make it for example 90%:

Code: Select all

sudo umount /lib/live/mount/overlay  # in case mounted twice this is required
sudo mount -t tmpfs -o "remount,size=90%" tmpfs /lib/live/mount/overlay

When using persistence-read-only, specially for those with small amount of RAM this gives a little more space to install packages etc..

I have 2G total RAM,
Before and after df -h output (note that the size of / is also increased):

Code: Select all

user@debian:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
aufs           1008M  3.0M 1005M   1% /
tmpfs           404M  6.1M  398M   2% /run
/dev/sda5        20G  9.5G  9.8G  50% /lib/live/mount/persistence/sda5
/dev/loop0      128K  128K     0 100% /lib/live/mount/rootfs/filesystem.squashfs
tmpfs          1008M     0 1008M   0% /lib/live/mount/overlay
.....
.....
user@debian:~$ sudo umount /lib/live/mount/overlay
user@debian:~$ sudo mount -t tmpfs -o "remount,size=90%" tmpfs /lib/live/mount/overlay
user@debian:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
aufs            1.8G  4.6M  1.8G   1% /
tmpfs           404M  6.1M  398M   2% /run
/dev/sda5        20G  9.5G  9.8G  50% /lib/live/mount/persistence/sda5
/dev/loop0      128K  128K     0 100% /lib/live/mount/rootfs/filesystem.squashfs
tmpfs           1.8G  4.6M  1.8G   1% /lib/live/mount/overlay
.....
.....
user@debian:~$

Fred

[rufwoof]

Hi rufwoof,

Just noticed your EDIT about using your modified snapmergepuppy with persistence persistence-read-only
I tested and it works great!

My scripting ability is limited and mostly comprised of copying examples, i.e. not good so I'd suggest checking the code through for yourself Fred. I tend to add Rufwoof comment lines near/before changes I do make.

Here's a way to increase the size of /lib/live/mount/overlay, by default it's half of the total RAM.
To make it for example 90%:

Code: Select all

sudo umount /lib/live/mount/overlay  # in case mounted twice this is required
sudo mount -t tmpfs -o "remount,size=90%" tmpfs /lib/live/mount/overlay

When using persistence-read-only, specially for those with small amount of RAM this gives a little more space to install packages etc..

Nice. Thanks.

Alternatively if running a large update on a low ram system just reboot without the perisistence-read-only boot parameter - so all changes are written instantly and /lib/live/mount/overlay remains empty (low amounts of memory used as changes are instantly written rather than being 'recorded' in memory).

On initial startup my overlay is indeed mounted twice, with the second removing the write permissions to group i.e. mode 755 and using noatime instead of relatime which looking around seems to be to do with how often disk access times are updated

tmpfs on /lib/live/mount/overlay type tmpfs (rw,relatime)
tmpfs on /lib/live/mount/overlay type tmpfs (rw,noatime,mode=755)

Of the two, bug or feature, and looking around it looks more like a bug than a intentional feature (couldn't find anything to suggest either way for sure however). After running umount /lib/live/mount/overlay it leaves just the
tmpfs /lib/live/mount/overlay tmpfs rw,noatime,mode=755 0 0
entry in /proc/mounts. It could be a design feature, maybe to get livecd to work correctly .. just one of those things.

One downside of having the persistence partition the same as where grub4dos and /live is installed i.e. allocating the 'main' partition a LABEL of persistence is that does prevent using a encrypted persistence partition option. A benefit however is that if in menu.lst you point to /live that contains a empty filesystem.squashfs and also have menu.lst point the kernel and initrd to the /boot versions (so that kernel updates are ok), then /live is pretty much empty and could be the same for a number of different frugal installs providing each instance had the persistence-label set differently (and separate partitions were available to store changes to). The edits I made to snapmergepuppy wouldn't however currently support such and would need to be changed/improved.

[rufwoof]

I know of but don't really understand the systemd versus sysvinit conflict. Looking around it appears you can write 'units' to drop into systemd relatively easily ... this for example https://learn.adafruit.com/running-prog ... -a-service (I had to open NoScript to view the content properly).

Conceptually rather than having a script such as snapmergepuppy, that could be a systemd unit. As perhaps could be the setting up of a layered filesytem along sysvinit style. Too technical for me personally as you have to define where that unit fits in with the other units (when its run).

[Belham]

Rufwoof (and Fred),

Boy, this thread is interesting as heck! I am trying to put the changes that both of you are discussing into (Fred's) DD-Jessie 64-bit. Had it running really well, thought I did everything correctly, but I sure as heck messed something up in creating the live folder correctly on the same partition as the menu.lst, next thing I knew, I blew my DD64 USB completely up as persistence didn't go correctly when I thought it did Oh well. Live and learn. Later tonight and/or tomorrow, going to try all this again.......this all sounds to me like my dream puppy install......a frugal-acting full install with both ro and rw boot options Just doing updates alone, and kernel updates, holy heck, this is awesome!!!!

Anyhow, I just wanted to say thanks to you both......good thing grub4dos is at least understandable, as I cannot imagine doing this in grub2 (an infuriating boot scheme I regularly struggle with when putting different bigger/heavier linux distros on drives for family members who aren't ready for puppy-land yet).

Thank again!!

[rufwoof]

I am trying to put the changes that both of you are discussing into (Fred's) DD-Jessie 64-bit.

I'm actually using Debian Jessie 64 liveCD/ISO Installed to my HDD. I also installed to a USB HDD, but it became confusing as it started picking up some things from the HDD and other things from the USB HDD due to having multiple instances. Debian searches drives during boot so if something is on sda1 when you're trying to run sdh1 or whatever (USB) then it picks up the first find i.e. sda1 rather than the intended sdh1. I had one case that it was unintentionally picking up and loading a .squashfs on a different drive (I went around renaming them all to have a .X suffix after that).

Using different partition labels for each would help and then in menu.lst add a persistence-label=xxx to the kernel boot line (where xxx is the name you allocated to the partition). However I don't think the snapmergepuppy is generic enough as it currently is to pick up on that.

I opted for the LXDE Debian Jessie amd64 and have that set to autologin as root i.e. /etc/lightdm/lightdm.conf changed from having a line of autologin-user=user to autologin-user=root Running as root has so far had little impact of programs not working and those that didn't like running as root were easily fixed (VLC for instance). Saves having to bother with sudo which tends to be annoying after having come from puppy.

[rufwoof]

I've made a correction to the snapmergepuppy in http://murga-linux.com/puppy/viewtopic. ... 639#915639 as the BASE could pick up two locations. Added -m 1 grep parameter to limit that to just the first line as that is more likely to be the boot partition also. Not well coded (my skill limitation), so all very 'testing' type mode at present. Make sure you make backups before trying.

[backi]

Rufwoof (and Fred),

Boy, this thread is interesting as heck!

....but ( as you just stated above Belham)...
I am no Linux Expert and i don`t understand most of it ....doesn`t matter....
just works .

My intuition tells me ......these guys are quite sophisticated ......these Deb Dog and friends corner is (in my opinion ) the most active and avant-garde project you can find here on the forum....

Thumbs up ........Respect !!

[fredx181]

My scripting ability is limited and mostly comprised of copying examples, i.e. not good so I'd suggest checking the code through for yourself Fred. I tend to add Rufwoof comment lines near/before changes I do make.

Being curious about how you done it, I had a look at it and all seems fine to me.
The best test for me is to remove a package that's already included and see after reboot if it's really removed.
So removed 'lxmusic' and indeed it was gone after reboot.

Added -m 1 grep parameter

What else can there be in /lib/live/mount/persistence than the 'persistence' partition? (e.g. sda5)

One downside of having the persistence partition the same as where grub4dos and /live is installed i.e. allocating the 'main' partition a LABEL of persistence is that does prevent using a encrypted persistence partition option. A benefit however is that if in menu.lst you point to /live that contains a empty filesystem.squashfs and also have menu.lst point the kernel and initrd to the /boot versions (so that kernel updates are ok), then /live is pretty much empty and could be the same for a number of different frugal installs providing each instance had the persistence-label set differently (and separate partitions were available to store changes to).

Benefit? Not sure I understand what you mean, I have grub4dos (and menu.lst) in sda1 and works well with your setup having 'persistence' partition sda5

I'm actually using Debian Jessie 64 liveCD/ISO Installed to my HDD. I also installed to a USB HDD, but it became confusing as it started picking up some things from the HDD and other things from the USB HDD due to having multiple instances. Debian searches drives during boot so if something is on sda1 when you're trying to run sdh1 or whatever (USB) then it picks up the first find i.e. sda1 rather than the intended sdh1. I had one case that it was unintentionally picking up and loading a .squashfs on a different drive (I went around renaming them all to have a .X suffix after that).

That's why I think it's better idea to have a unique folder name on the root of the partition where 'live' is inside e.g. if on HD: /DEB64-HD/live or if on USB: /DEB64-USB/live and use boot parameter live-media-path=/.... corresponding.

Conceptually rather than having a script such as snapmergepuppy, that could be a systemd unit. As perhaps could be the setting up of a layered filesytem along sysvinit style. Too technical for me personally as you have to define where that unit fits in with the other units (when its run).

You mean something like in DebianDog, choice of 'Save' or 'NoSave' at shutdown ?
If so I can try to make it (systemd unit run at console after shutting down), (but then it will still call the snapmergepuppy script as last step).

Fred

[fredx181]

Hi Belham

Boy, this thread is interesting as heck! I am trying to put the changes that both of you are discussing into (Fred's) DD-Jessie 64-bit. Had it running really well, thought I did everything correctly, but I sure as heck messed something up in creating the live folder correctly on the same partition as the menu.lst, next thing I knew, I blew my DD64 USB completely up as persistence didn't go correctly when I thought it did Rolling Eyes Oh well. Live and learn. Later tonight and/or tomorrow, going to try all this again.......this all sounds to me like my dream puppy install......a frugal-acting full install with both ro and rw boot options Very Happy Just doing updates alone, and kernel updates, holy heck, this is awesome!!!!

Too bad for you it went wrong.
It should be possible also with DebianDog64 to have the same persistence setup as rufwoof described (of course anything is possible with linux!!), but DD64 (or any DebianDog) is just a little different, so it needs some extra explanation/tweaking.
I will soon test with DebianDog64 and report back.
If you want to try in the meantime, I'd suggest to use a Debian Live image from:
https://www.debian.org/CD/live/
And follow the instructions from this thread.

Fred

[rufwoof]

What else can there be in /lib/live/mount/persistence than the 'persistence' partition? (e.g. sda5)

Hi Fred. If I boot from sda1, but then mount sda2 on which I have another installation, then mount | grep persistence picks up two instances. -m 1 grep parameter makes sure it just picks up the first one, which would be ok provided the actual persistence occurrence matched that. I could foresee however that in some cases that could be incorrect. Might just be my system, it is rather unclean at present with different versions installed.

[rufwoof]

Here's a way to increase the size of /lib/live/mount/overlay, by default it's half of the total RAM.
To make it for example 90%:

Code: Select all

sudo umount /lib/live/mount/overlay  # in case mounted twice this is required
sudo mount -t tmpfs -o "remount,size=90%" tmpfs /lib/live/mount/overlay

I've created a script in /usr/local/bin to run that

Code: Select all

#!/bin/bash
# expand overlay space to 90% so have more ram available for workspace
umount /lib/live/mount/overlay # double mounted if already done no harm it will just say already in use
if [ -d /lib/live/mount/overlay/root ]
then
  mount -t tmpfs -o "remount,size=90%" tmpfs /lib/live/mount/overlay
fi

called it expandoverlay and made that script executable, then I created a /usr/share/applications expandoverlay.desktop file for that

Code: Select all

[Desktop Entry]
Version=1.0
Encoding=UTF-8
Name=expandoverlay
Comment=Expand Overlay
Exec=/usr/local/bin/expandoverlay
Terminal=false
Type=Application
Icon=background

.. and then highlighted that file in pcmanfm and used edit | create link to create a symbolic link for a ~/.config/autostart folder entry ... so it gets loaded on startup.

I'm still a bit old-hat where it was more usual to just drop a script into startup folder, but the 'new way' seems to prefer to use .desktop files ??? Is that right?

[fredx181]

Hi Fred. If I boot from sda1, but then mount sda2 on which I have another installation, then mount | grep persistence picks up two instances. -m 1 grep parameter makes sure it just picks up the first one, which would be ok provided the actual persistence occurrence matched that. I could foresee however that in some cases that could be incorrect. Might just be my system, it is rather unclean at present with different versions installed.

I see, good to be sure it will pick the first one then.
(I have not been digging into live-boot that much to know about these (probably exceptional) cases)

I'm still a bit old-hat where it was more usual to just drop a script into startup folder, but the 'new way' seems to prefer to use .desktop files ??? Is that right?

Yes, puppy uses ~/Startup and DebianDog followed that.
What you call the 'new way' is the 'LXDE way' AFAIK , not sure how other DE's handle this (maybe most of them do it that way?)

Fred

[rufwoof]

To confirm that snapmergepuppy also works fine in Debian Jessie KDE amd64. KDE 64 runs really well on this quad core 2GB amd (with a nvidia card). Openshot, Blender, Audacity, Inkscape, recordmydesktop, Libre Office, Skype, MasterPDFEditor3, firewall, mtpaint, gimp .... all installed from the respository OK, with snapmergepuppy saving fine (for the initial large update I ran with persistence i.e. immediate saves). Your tip/trick to expand the overlay space up to 90% of available ram seems to work well Fred. Amazing speed to 3D render Openshot animated titles, 10 frames/second type rendering (rather than 1 frame every second or two on my prior Celeron single core).

There is a noticeable difference between running with all files extracted and filesystem.squashfs empty, compared to shifting all files into filesystem.squashfs and having a empty persistence space, especially on a quad core. Disk transfer is around 100MB/sec, whereas when using lzo level 1 decompression with all four cores processing that ... its near ram speed (GByte type speeds). So a file approximately halved in size by compression (stored in squashfs) and disk transferred/decompressed is quicker than straight disk transfer of the non compressed. That said that speed improvement is mostly on initial boot and first loading of a program, as more often after that it has remained memory bound anyway (just as quick to load either way).

I set up three desktops with the second having a load of system monitoring widgets running. Does induce extra CPU load, but acceptably low enough to be near negligible. I love KDE's 3D cube (or three sided in my 3 desktop case) and the other general refinements such as when you expand/reduce a mp4 window it scales the movie as it expands up/reduces down. And how when you click something that does take a few seconds to load you get the indication that its loading by a bouncing ball type mini icon of the application being loaded next to the mouse cursor.

[fredx181]

Hi Belham, rufwoof and everyone,

See for a howto of installing DebianDog64 on a 'persistence' partition by using rufwoof's method (as described earlier in this thread) here:
http://murga-linux.com/puppy/viewtopic. ... 339#916339

It may seem complicated, but it's worth trying it, I can tell you.
Hope it's clear enough and I didn't miss something.

Rufwoof, here's attached snapexit_0.0.1_all.deb (remove fake .tar extension)
It contains systemd service units for:
- expandoverlay.service (will run /usr/local/bin/expandoverlay) for expand /lib.live/mount/overlay to 90%
- rc.local.shutdown.service (will run /etc/rc.local.shutdown > /usr/local/bin/snap-ex > /usr/local/bin/snapmergepuppy) for choice of saving or not from console at shutdown or reboot.
(gives a very simple option with countdown, install 'dialog' and you'll get a more sophisticated 'button' view)

Also included sysvinit scripts for in case systemd removed or not installed/running (debiandog compatible)

Install from terminal opened where snapexit_0.0.1_all.deb is located :

Code: Select all

sudo dpkg -i snapexit_0.0.1_all.deb

Fred

[rufwoof]

Wow! You're a genius Fred.

Off to give it a try ... making a system backup first. I'm using DD64 Jessie as a 'admin' secondary boot now Tint is new to me, struggling a bit to tweak things due to infamiliarity ... but getting there.

Thanks.

... Edit : Worked great. I also tried with "apt-get install dialog" installed ... however one problem with that was the console repeatedly overwrote exactly in alignment with the the save|no save dialog box text ... saying something like job running ... and a 1 minute 30 second ... second by second countdown, so it was unclear whether the current choice was save or no save (that you tab between) due to that overlaid system shutdown text.

Might be just my screen resolution/setup.

Edit 2 : noticed in DD64 I still have frisbee locked into one mode (always on in the attached image). On the celeron DD32 jessie I was using before that 'bug' prompted me to switch to wicd as the network monitor/tool ... at that time I thought it was that machine, but obviously not as its also happening on this amd64. Not a issue for me personally as I now prefer wicd instead of frisbee anyway

[fredx181]

... Edit : Worked great. I also tried with "apt-get install dialog" installed ... however one problem with that was the console repeatedly overwrote exactly in alignment with the the save|no save dialog box text ... saying something like job running ... and a 1 minute 30 second ... second by second countdown, so it was unclear whether the current choice was save or no save (that you tab between) due to that overlaid system shutdown text.

Might be just my screen resolution/setup.

Yes, I've seen exactly that also, thought I got rid of it, it's not because of your resolution.
For me it happened only the first time (just after installing the .deb).
Pressing Enter or wait 20 seconds will save.

Fred

[rufwoof]

Hi Belham, rufwoof and everyone,

See for a howto of installing DebianDog64 on a 'persistence' partition by using rufwoof's method (as described earlier in this thread) here:
http://murga-linux.com/puppy/viewtopic. ... 339#916339...

Weird ... on one PC a USB 8GB flashstick boot fires up straight away, seconds to desktop, but in KDE hardware widget (booting Debian KDE Jessie AMD64) it keeps adding the CPU details. On another PC boot takes ages, cup of tea type break, as though the whole USB is being read into memory (despite having less memory than the first PC). Once up and running, really flies (as does the first PC).

[rufwoof]

On shutdown the first (quick to boot) streamed out loads of error messages. Caught a glimpse of rt2860 so rebooted (after hard powerdown) and installed the firmware from Synaptic for that ralink ... and running even better now (starts up/shuts down quickly and working well).

Lost as to why the other PC takes so long to boot/load from USB

Found a neat system tool in KDE - kinfocenter - (see attached) The 'Free Memory' value changes continually to show right down to the last byte available at any one instant in time.