Puppy as Primary Operating System

[hollipl]

As you have 1 Gb of RAM and can run Tahrpup easily, there is no advantage if you chose a Full Install. One of the disadvantages of a Full install is that applications you install --and crap you acquired while surfing the web-- will automatically be written to your hard-drive.

Hollipl only has 512MB Mike. For a full install you ideally need at least a GB I'd say. 512MB would work provided you had a swap file/partition ... but would tend to be slowed down by swapping to/from disk.

With a Frugal Install, you can set Tahrpup up to only write to your hard-drive on command

Except in some cases, such as when you load a PET and it uses the 'save' space as a work area.

The way I run Debian LXDE is I installed grub4dos, created a empty partition and use that partition for everything, grub4dos (menu.lst, grldr), the main filesystem (filesystem.squashfs) and as the save folder (partition). Nothing preventing that also being the location of a swap file either ... such as creating/activating a 1GB swapfile :

dd if=/dev/zero of=swapfile bs=1M count=1024
mkswap swapfile
swapon swapfile

You have to set that partition as being bootable such as in gparted, and also give it a partition LABEL of 'persistence' (without the quotes).

For the Debian LXDE I use I downloaded a CD from here http://cdimage.debian.org/cdimage/unoff ... rent-live/ that includes non-free firmware, in my case selecting the amd64 folder choice as my PC is 64 bit (use the i386 folder is 32 bit) http://cdimage.debian.org/cdimage/unoff ... rent-live/ select the iso-hybrid sub-directory and ... pick one. I went for the ....lxde-desktop+nonfree.iso type file to download.

Once downloaded then you need to extract the live folder from that iso to the HDD partition alongside grldr and menu.lst (grub4dos installed files).

Then its just a matter of editing menu.lst to use that, something like

title Debian Jessie Frugal RO
find --set-root /live/filesystem.squashfs
kernel /live/vmlinuz boot=live config nofastboot persistence persistence-read-only persistence-label=persistence quickreboot noprompt showmounts live-media-path=/live/ config rw
initrd /live/initrd.img

A second boot choice of booting read/write so all changes are recorded requires only the persistence-read-only boot parameter to be removed

title Debian Jessie Frugal RW
find --set-root /live/filesystem.squashfs
kernel /live/vmlinuz boot=live config nofastboot persistence persistence-label=persistence quickreboot noprompt showmounts live-media-path=/live/ config rw
initrd /live/initrd.img

Taking that a step further, you can extract all of the filesystem.squashfs to the save 'folder' i.e extract all of filesystem.squashfs to the / folder. You can't do that directly so first you extract to a new/empty folder and then move everything in that folder up to the root folder

cd live
unsquashfs -d tempfolder filesystem.squashfs

... and then open tempfolder in a filemanager window, ensure all files including hiddenfiles are highlighted/selected and drag/drop those to another window showing the / folder and 'MOVE'. tempfolder is then left empty and can be deleted.

With everything in the 'save folder' there's no further need for filesystem.squashfs so that can be deleted, but best to create a empty one in its place otherwise that could prevent sfs's from being loaded.

cd live
rm filesystem.squashfs
mkdir tmp
mksquashfs tmp filesystem.squashfs
rmdir tmp

With that further step you in effect have a full install that can be booted like a frugal where changes aren't preserved on disk, just recorded in memory .... which runs a lot faster. Or you can boot it read/write where all changes are preserved as and when made.

The final step is to adjust from using /live/initrd and /live/vmlinuz boot files to using sym links to those in /boot ... as that way any Debian kernel updates will be correctly installed/used. i.e. create initrd.img and vmlinuz as sym-links to the initrd and vmlinuz files (with longer file names that indicate the version numbers) in /boot and adjust menu.lst to use those sym-links

title Debian Jessie Frugal RO
find --set-root /live/filesystem.squashfs
kernel /vmlinuz boot=live config nofastboot persistence persistence-read-only persistence-label=persistence quickreboot noprompt showmounts live-media-path=/live/ config rw
initrd /initrd.img

title Debian Jessie Frugal RW
find --set-root /live/filesystem.squashfs
kernel /vmlinuz boot=live config nofastboot persistence persistence-label=persistence quickreboot noprompt showmounts live-media-path=/live/ config rw
initrd /initrd.img

Instead of the RW boot choice above, I've set mine to chain to the Debian boot loader, which I installed from within Debian

title Debian FULL Install RW filesys must be extracted (/boot/grub/menu.lst)
find --set-root /boot/grub/menu.lst
configfile /boot/grub/menu.lst
commandline

So no different to a full install ... except that its booted via grub4dos that chains to it. I use that choice to run updates, that otherwise might exceed available memory space i.e. written to disk as soon as changes made. Slow, but used relatively infrequently. For the rest of time I use the RO boot choice (faster), but where no changes are recorded. However you can link from that read only layer to the main save folder, for example I created a /Documents-Persistent folder and once booted I created a sym link to that from within /home/user folder, so that I have a Documents, Picture ....etc where changes are lost after reboot, but also a Documents-Persistent folder where any changes within that are preserved across reboots.

I also have a script that I can run that's very similar (a adjusted version of) snapmergepuppy, so I can flush all changes in a RO session to disk to preserve them simply by running that script.

If you only use programs from Debian repository and perform updates periodically i.e. in a terminal running as root

apt-get update
apt-get upgrade

then you'll have a very stable installation that keeps up to date, that in the above case can be booted read only so you can try out things and not save them ...etc.

Don't forget to set a root password i.e.

sudo passwd root

and enter a password of your own choice (you have to enter it twice).

Debian runs by default as 'user' not as 'root' which is safer, especially if you run a browser. LXDE is nice in that respect as its file manager pcmanfm includes a right click menu option to open a folder in a root based window. Which at first seems a bit weird to do after using puppy, but soon becomes more natural instinct.

I suspect that with a swap file created/used of perhaps 1GB size, Hollipl could have that running ok on that laptop. Can't say for sure as mine has 2GB (more than enough such that I don't even need to allocate a swap file/partition).

You can still load sfs's with that (when booted RO only) simply by dropping them into the /live folder. Any files with .squashfs suffix will get loaded at bootup in alphanumeric order. Or if you create a filesystem.module file in that /live folder then only the .squashfs files listed in that file will get loaded at bootup, in the order specified in that file. Personally I don't bother as its just as easy for me to load/unload stuff using Synaptic (from the Debian repository).

For completeness my /usr/local/bin/flush2disk script is attached below, which of course needs to be made executable in order to run. Other than that script the rest of my installation is pure Debian. Around 4GB in total space used (no swap file included) which I have installed on a 15GB partition.

Best of all worlds IMO. Stable repository with security updates quick to come through. And can boot frugal style where changes aren't recorded, except if you want them to be. And runs quicker as changes are recorded in memory instead of to disk. But can be booted to the equivalent of a fully installed Debian (which reminds me another change you should make is make the repositories inspected be a wider range i.e. /etc/apt/sources.list should look like

###### Debian Main Repos
deb http://ftp.uk.debian.org/debian/ jessie main contrib non-free

###### Security
deb http://security.debian.org/ jessie/updates main contrib non-free

If you intend to compile stuff then you should add the sources (src) to that e.g. maybe a sources.list content of :

deb http://http.debian.net/debian/ jessie main contrib non-free
deb-src http://http.debian.net/debian/ jessie main
deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main

rufwoof,

That actually sounds amazing! it doesn't sound too terribly complicated, but i would probably still want someone to walk me thru it a little bit more indepth, tho it definately is not out of my skill range at the moment. The system you were describing would be almost perfect to get maximum use out of this old machines specs. I can be reached by adding @outlook.com to my username and sending an email :] perhaps you could walk me through a little bit on an instant messenger or skype? at the moment I'm running tahrpup with xcfe FULL install, and whenever I use an application i'm forcing any saved files to goto the 48 gig partition by browsing to such location.. etc.

This is my first real dive into puppy, and I knew that it had plenty of power to setup such a system as you were describing I just didn't know where to start to get my hands dirty. I migrated recently from Bunsen labs because someone had abandoned the repos and I kept getting KEY ERRORS all over the place installing things from command line, so then I was tracking down package files in the web browser to satisfy dependances and It was just a mess

[foxpup]

Try "pupx" from a shell.

@hollipl: try this for your blank screen

[hollipl]

Try "pupx" from a shell.

@hollipl: try this for your blank screen

foxpup,
I ran pupx from shell, disabled the check by screensaver enabled, and put 0 in the timeout seconds box, and will now wait to see if it still turns off.

Code: Select all

root# xset q
Keyboard Control:
  auto repeat:  on    key click percent:  0    LED mask:  00000000
  XKB indicators:
    00: Caps Lock:   off    01: Num Lock:    off    02: Scroll Lock: off
    03: Shift Lock:  off    04: Group 2:     off    05: Mouse Keys:  off
  auto repeat delay:  500    repeat rate:  20
  auto repeating keys:  00ffffffdffffbbf
                        fadfffdfffdfe5ef
                        ffffffffffffffff
                        ffffffffffffffff
  bell percent:  50    bell pitch:  400    bell duration:  100
Pointer Control:
  acceleration:  20/10    threshold:  4
Screen Saver:
  prefer blanking:  yes    allow exposures:  yes
  timeout:  0    cycle:  600
Colors:
  default colormap:  0x20    BlackPixel:  0x0    WhitePixel:  0xffffff
Font Path:
  /usr/share/X11/fonts/misc/,/usr/share/X11/fonts/TTF/,built-ins
DPMS (Energy Star):
  Standby: 600    Suspend: 600    Off: 600
  DPMS is Disabled

[Mike Walsh]

Hallo, hollipl.

With regard to your screen 'timeout' issue, there's an easy way to adjust this. Go to Menu>Desktop>pupx set properties of x. This will enable you to adjust timeout, screen-saver, mouse acceleration, keyboard adjustments, etc, etc.

As Mikeslr says, you will not find a /home partition/folder in Puppy. This is a peculiarity mainly of the Debian/Ubuntu-based distros, which are primarily multi-user systems. Every 'user' has their own /home folder, and nobody is allowed to run as root, except very temporarily. Puppy is primarily a single-user system, and always runs as root. Many Linux users (some of long-standing) are absolutely horrified by this..!

You may find this interesting:-

http://barryk.org/puppylinux/technical/root.htm

...an explanation by the Puppy Master himself, Barry Kauler.

Hope that helps a wee bit. I originally ran Tahrpup myself, on a 14 yr-old Dell Inspiron laptop, which now has a 2.6 GHz P4, 1 GB of RAM, and a 64GB SSD. It ran flawlessly.


Mike.

[foxpup]

foxpup,
I ran pupx from shell, disabled the check by screensaver enabled, and put 0 in the timeout seconds box, and will now wait to see if it still turns off.

Okay.
I thought you missed Semmes post.

[poorguy]

"Puppy's Philosophy: FEAR NOT ROOT!"

[Mike Walsh]

"Puppy's Philosophy: FEAR NOT ROOT!"

^^^ +1, old son. Touchè..!


Mike.

[Semme]

Classified under "Developers" distro. And we're all one of those, right?

[Mike Walsh]

Hey, Semme.

I'm just thinking, now: that avatar of yours ain't a self-portrait, is it? Seems quite appropriate for someone who spends a lot of his time 'yanking my lead' (*groan*)

Sorry; couldn't resist that. And don't take it the wrong way, please..!


Mike.

[rufwoof]

...I just didn't know where to start to get my hands dirty....

Grab a livecd and boot from that, start here https://www.debian.org/CD/live/ reading through the detailed guides https://www.debian.org/releases/stable/installmanual ... and use that livecd to install a full install to a HDD partition which is relatively simple/painless. Boot and setup that full install ... and then use that full install as a 'save' folder (partition) content and overlay a frugal (livecd style) boot. Which in effect distils own to creating a /live folder in addition to the fully installed files/folders, allocating the partition a 'persistence' label using the likes of gparted or fdisk and adding grub4dos with an appropriate menu.lst that boots either that full install or the frugal choice.

The /live folder can be empty - as everything is in effect stored in the savefolder (partition). Personally I copy the /live folder from the liveCD to /live on HDD and just empty the filesystem.squashfs content as that's redundant (everything is stored in the 'save file' (partition)).

The big difference between full and frugal is that instead of writing all changes to disk as they occur as with full, with frugal all changes are recorded in (faster) memory. The system will also do a reasonable job of disk-caching so the first time you load a program may be slower (as its read from disk) than the second time you run it assuming it has remained in cache. The downside is that it doesn't preserve changes ... unless you manually flush those to disk (as per my earlier script). Another downside is that if changes exceed available memory space it will lock up. So large updates or program installations are better performed using the (slower to run) Full installed boot choice.

As a example, Installed that way to a USB stick and there is a massive difference between the operational speed of the full version and the frugal version. Frugal runs as fast as a HDD version as slower USB writes aren't being used, just writes to memory. Only if you flush those memory recorded changes to 'disk' (USB) does the slow write operation become apparent.

With the likes of Tahr puppy the aim is to create a small total filesystem that can all be loaded into ram at bootup, which caters for the boot medium then being ejected (no longer needed because its all in ram). With the above there's a large amount of files/data, but that's on HDD and parts of that are read in as-when required and can be swapped in/out as the system determines best. So whilst 'large' much of that wont be read anyway, mostly just there just in case its needed (foreign locale's, doc's ....etc). Reading everything into ram at bootup is slower to bootup, but quicker thereafter compared to reading stuff in as/when required. The latter is also makes more efficient use of memory space, by only reading in what is required/when it is required, not the entire filesystem ... which will contain programs/libs that aren't even used during a session.

[Semme]

Nah Mike, I don't smoke but I'm more cat than dog.

My ears aren't quite as tattered either. Still, I think it's hilarious!

Years ago there was a wise-ass on this board I know who sported this av..

[Burn_IT]

Ive learned a lot about Linux by rooting around in Puppy!!

[foxpup]

With the above there's a large amount of files/data, but that's on HDD and parts of that are read in as-when required and can be swapped in/out as the system determines best. So whilst 'large' much of that wont be read anyway, mostly just there just in case its needed (foreign locale's, doc's ....etc).

Hi rufwoof

I've been reading your posts here with much interest.
I still wonder about some things.

The above, that debian reads in as-when required, is this typically debian/major distro? Do you have to tell it to do so?

My second question is why you move the /live/filesystem.squashfs to /filesystem? What does it change?

Thirdly a remark. The easy update/upgrade mechanism in debian can cause problems on older computers, if the update/upgrade puts bigger demands on the machine. For example, I have SSE, not SSE2. If an upgrade involves a program moving towards SSE2, I will have a fall-out for that program after upgrade. Use with caution!

[rufwoof]

With the above there's a large amount of files/data, but that's on HDD and parts of that are read in as-when required and can be swapped in/out as the system determines best. So whilst 'large' much of that wont be read anyway, mostly just there just in case its needed (foreign locale's, doc's ....etc).

Hi rufwoof

I've been reading your posts here with much interest.
I still wonder about some things.

The above, that debian reads in as-when required, is this typically debian/major distro? Do you have to tell it to do so?

My second question is why you move the /live/filesystem.squashfs to /filesystem? What does it change?

Thirdly a remark. The easy update/upgrade mechanism in debian can cause problems on older computers, if the update/upgrade puts bigger demands on the machine. For example, I have SSE, not SSE2. If an upgrade involves a program moving towards SSE2, I will have a fall-out for that program after upgrade. Use with caution!

Hi foxpup. Taking your #2 first ...

Extract (not copy) the filesystem.squashfs to /
Which when the / partition is also the save 'folder' (partition) is the same as putting all of the main squashfs into the save 'folder' (partition).

Imagine (in Puppy CE terms) a empty tahr.sfs (and zdrv.sfs) with all of that content in the savefolder. The main sfs in effect is redundant as a higher layer (savefolder) content overlays everything that otherwise would have been in the tahr.sfs (so tahr.sfs can be emptied).

Which leads to your #1 ... if all files are in the save folder (partition) then the system will only read in what it needs, when it needs it. Once read in on systems with a reasonable amount of memory often those files remain cached (in memory). That all occurs 'naturally' (as controlled by the kernel/system). Being a HDD there's no issues with the drive being ejectable (with tahr CE you might want everything ... Out house sink and all, read in so that the medium (CD/DVD) can be ejected and freed up to perhaps burn a new CD/DVD).

Good #3 point. Security and program updates are good in some respects, but can cause problems if the upgrades are to higher versions than what your hardware supports. With Debian stable the 'latest' stable versions do tend to be older well-proven/tested versions that more often support older hardware anyway. I guess its a judgment call ... either install and stick with that as-is, applying no updates (or maybe just selective (security) updates), or check-for/install updates to remain aligned to the latest Debian Stable version. A good thing about frugal style boot is you can run the update and test it out first, and then either opt to save that or not (excepting large sized updates (transition from one major version to the next likely will exceed the amount of memory space available to record all of those changes and as such wouldn't be doable via a frugal type boot ... have to be done by first backing up and then booting full boot (read/write) style, before downloading/applying the updates).

Debian caters for app pinning. Where you can pin versions of programs/kernel ...etc. so that they're excluded from being updated. I don't use that myself and know relatively little about any dependency conflicts that could cause. Debian documentation indicates that you're on your own if you pin things https://wiki.debian.org/AptPreferences When pinning, you must ensure compatibility of packages by yourself since Debian does not guarantee it. Note that pinning is completely optional, and Debian does not encourage pinning without thorough consideration.

[foxpup]

@rufwoof

I did mean "extracted". That's implied with "/filesystem", not "/filesystem.squasfs".

Do I understand this correctly?
#1 The setup you propose can be done with debian or puppy likewise.
#2 "reads in as-when required" is typical for the savefolder, also in puppy
#3 The kernel/initrd(?) reads the complete filesystem.squashfs and only what is needed from savefolder/partition/fs(?). But stilI savefolder is the top-level, meaning it overlays all other layers. That doesn' seem right to me, or at least complicated.

I do have 1G RAM, but still, with bigger programs (firefox, libreoffice) speed can be an issue. So having more RAM free could help. I speed up startup a little by not using compression for filesystem.squashfs. But extracting it in the savefolder could speed up startup AND speed up running bigger apps.

How about placing filesystem in initrd.gz? Is that an option?

Pinning could be usefull for me. OTOH, I only need latest versions of firefox and LibreOffice. That is mainly because I am not the (only) user of these apps So I update that manually.

[rufwoof]

Puppy can use the save file/folder space when adding a PET such that the savefolder content changes even if no save was requested during a session. It also needs zdrv sfs to fully operate so that can't be in the 'savefolder' as otherwise that isn't available until after the savefolder has been found/read. As such I don't believe the setup can be used by puppy as things currently stand.

If you load puppy pfix=ram then the entire main sfs is read into memory ... including programs that you might not use during a session. Slower to boot, quicker to run thereafter than not using pfix=ram (and the described choice doesn't use the equivalent of pfix=ram i.e. stuff is read in as and when required, so quicker to boot, slower to load each program the first time, similar speed to load programs 2nd/subsequent times assuming it has remained memory bound (cached)).

In the standard puppy setup the main sfs is overlaid by any additional sfs's which is overlaid by the savefolder. In the described approach the main sfs is empty (and at the bottom layer, which is overlaid by any other sfs's loaded at bootup, which is overlaid by the save (partition) layer. Its more like UnderDog as Barry outlined here (around a quarter of the way down that document) or as outlined here

Compression and smaller filesize (IO) can be faster than reading full non compressed IO. I have used fast lzo or lz4 compressors/decompressors solely for that reason. If for example you mksquashfs the main / partition (excepting the /live folder) and drop that in as /live/filesystem.squashfs and then delete all of the / content (other than /live and menu.lst and grldr and persistence.conf...etc) i.e. shift things from the save partition to the main filesystem squashfs, then that will tend to boot/run quicker, especially on a multi-core system. Typically compression halves the amount of IO (filesize) at the expense of having to decompress that data, but where with four cores (say) decompressing that data is faster than IO speed. lz4 decompresses at around 400MB/core so 1.6GB/sec on a 4 core, which depending upon actual hardware can be faster than disk IO speed, maybe even approaching/exceeding ram speed.

I have run things that way, but it entails adding a 'remaster' script in order to update the main filesystem/empty the save space periodically. The way I had it set up was to use two copies of the main filesystem that it toggled between, so you can remaster a live running system. Its quite a nice way to run things, as remastering can be relatively quick, aufs mount the changes folder and main filesystem and create a new main filesystem and point the next reboot to use that newly remastered filesystem squashfs. That doesn't save on disk space as you're keeping two files (filesystem squashfs copies) available, but does noticeably speed up boot/first-time-run program load times.

I have inserted filesystems into initrd's in the past - handy for the likes of PXE based booting. That requires however that the initrd fully fits into memory, which for a larger system such as Debian often wont be the case. Its similar to trying to boot with pfix=ram in puppy but where the sfs is too large to fit into available free ram.

If you only want updates to firefox and libre office then one way would be to not apply any general updates and only ever update firefox/libre by periodically running

apt-get update (which updates the local copy of the repository)
apt-get install --reinstall firefox-esr
apt-get install --reinstall libreoffice

again however sooner or later that might break as other Debian stable stuff moves on. Only if you update the full stable system does it become a permanently stable system that evolves over time (at least until the current Debian stable at the time is beyond your hardware, but more often the hardware fails before then anyway).

[backi]

Regarding (automatic) saving of pets debs or Packetmanager installs to save/file/folder in Puppy during session .
rufwoof wrote :

Puppy can use the save file/folder space when adding a PET such that the savefolder content changes even if no save was requested during a session. As such I don't believe the setup can be used by puppy as things currently stand.

Yes quite annoying situation .......but ....
I myself found something which helped me to avoid unwanted savings to save file/folder during a session while (experimenting ) with pets or debs or using installs from Packet manager .
When installing :
Petget-20120418
http://shino.pos.to/linux/puppy/
Also have look here:
http://www.murga-linux.com/puppy/viewtopic.php?t=73829
Installing petget-20120418 will prevent any savings from any installs to save file/folder during session (Pup Event-Ḿanger Save-Intervals=0 )
If you like to save during session ...use save2flash ....
There is one disadvantage in in it .......Puppy-Package Manager will switch to an older Version .
There is something in this code which keeps session completely in ram ...unless saved with save2flash

[hollipl]

okay so after reading some of your suggestions, and after rooting around a bit in the full installation of puppy to my hdd, I've come up with this.

It seems to be a waste to install puppy to its own partition on the hdd, especially since it excells so much at being a frugal USB live distro, and i do want to dual boot with a slower running but more regular desktop distro like Lubnuntu or Bunsenlabs.

So I can do a fake dual boot using PLOP, a cdr based boot manager that allows my old computer to boot to the CD, then select USB and boot drives that my old bios previously could not boot from usb, but the same cd also puts my hdd partitions on the menu to boot. So I could just do a frugal install of puppy to a decent USB and still have it on the PLOP boot menu next to my HDD partitions. Can't you edit Grub to include a distro thats on USB, but left permanently plugged in?

[Burn_IT]

PloP can be installed on any really bootable device, including your main hard disk.

[backi]

Hi hollipi !

It seems to be a waste to install puppy to its own partition on the hdd, especially since it excells so much at being a frugal USB live distro,

Yes .......better go frugal ( maybe on Usb Flash Stick ) .......much more advantages over HDD install .