Synaptic search for wireless drivers produced the results as per the attached imagemandibule2005 wrote:firmwares debian wireless drivers
https://drive.google.com/file/d/0Bz1ZmB ... sp=sharing
Debian Jessie Openbox LXDE frugal
Re: firmwares debian wireless drivers
- Attachments
-
- s.png
- (63.59 KiB) Downloaded 557 times
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%:
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):
Fred
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
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:~$
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.fredx181 wrote:Hi rufwoof,
Just noticed your EDIT about using your modified snapmergepuppy with persistence persistence-read-only
I tested and it works great!
Nice. Thanks.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%:When using persistence-read-only, specially for those with small amount of RAM this gives a little more space to install packages etc..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
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.
Last edited by rufwoof on Sat 30 Jul 2016, 13:56, edited 2 times in total.
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).
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).
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!!
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!!
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).Belham wrote:I am trying to put the changes that both of you are discussing into (Fred's) DD-Jessie 64-bit.
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.
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.
....but ( as you just stated above Belham)...Rufwoof (and Fred),
Boy, this thread is interesting as heck!
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 !!
Being curious about how you done it, I had a look at it and all seems fine to me.rufwoof wrote: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.
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.
What else can there be in /lib/live/mount/persistence than the 'persistence' partition? (e.g. sda5)Added -m 1 grep parameter
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 sda5One 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).
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.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).
You mean something like in DebianDog, choice of 'Save' or 'NoSave' at shutdown ?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).
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
Hi Belham
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
Too bad for you it went wrong.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!!!!
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
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.fredx181 wrote:What else can there be in /lib/live/mount/persistence than the 'persistence' partition? (e.g. sda5)
I've created a script in /usr/local/bin to run thatfredx181 wrote: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
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
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
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?
I see, good to be sure it will pick the first one then.rufwoof wrote: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 have not been digging into live-boot that much to know about these (probably exceptional) cases)
Yes, puppy uses ~/Startup and DebianDog followed that.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?
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
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.
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.
- Attachments
-
- snapshot1.jpg
- (24.29 KiB) Downloaded 439 times
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 :
Fred
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
- Attachments
-
- snapexit_0.0.1_all.deb.tar
- - Choice to save or nosave from console at shutdown (remove fake .tar)
- Expand space in /lib.live/mount/overlay - (6.29 KiB) Downloaded 162 times
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
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
- Attachments
-
- debdog-20160801231957.jpg
- (44.05 KiB) Downloaded 332 times
Yes, I've seen exactly that also, thought I got rid of it, it's not because of your resolution.rufwoof wrote:... 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.
For me it happened only the first time (just after installing the .deb).
Pressing Enter or wait 20 seconds will save.
Fred
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).fredx181 wrote: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...
- Attachments
-
- l.jpg
- (104.75 KiB) Downloaded 266 times
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.
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.
- Attachments
-
- m.jpg
- (54.14 KiB) Downloaded 264 times