Newest Puppies full installation support?

[witekjeden]

Hi.
Does the newest Puppies Fossapup9.5 and Slacko7.0 not supported full installation internal hd/ssd? Or i missed something?

[peebee]

Hi.
Does the newest Puppies Fossapup9.5 and Slacko7.0 not supported full installation internal hd/ssd? Or i missed something?

They do - but its well hidden as full install has no advantages over so-called frugal install and actually has some disadvantages. We encourage you to try "frugal" install - you will be pleasantly surprised and delighted. Remember "frugal" does NOT mean lesser performance it just refers to much more efficient and flexible use of your storage space.

If you really insist on doing a full install we can provide the rune (by private message) to enable it.

[TerryH]

That's because the devs are trying to steer new users to use frugal installs, as it was designed to best use puppy. It is still possible, but not recommended. I've never done a full install, so can't offer any details on how that is currently achieved.

[witekjeden]

@TerryH
I am a Puppy user from 4.2.1 how many years? 11? And always use full install (frugal only for compilation). Actually i wrote a post newest Slacko7 and my 14-years old laptop some lags Youtube. So i want full installation.

@TerryH
Thanks for support but not good idea real time because my english not exist. But maybe for the well hidden possibility can made a hidden instruction for users like me?
Will be happy.

[bigpup]

Frugal installs:

Can be put on any partition any format, any type storage device.

They load more of Puppy into RAM.

Uses a save file or folder to store all changes, settings, added stuff, etc.....
Has control of how the save is used, when it is written to or not written to, where it is located.

Easier to backup, because all changes, settings are in the save. The core Puppy files never change. Only what is in the save changes. All you have to do is copy the save to have a backup.
If Puppy really gets messed up. Just delete the save and replace it with the backup save.

You can easily load or unload SFS program packages.
This lets you use a program without actually installing it to Puppy. You will have to use this option to fully understand it.

All of Puppy is placed in a directory (folder).
You can have many Puppies on one partition.
All completely separate from the other.
All in different directories (Linux term for folder).

Full installs:
Must be installed to a Linux formatted partition.
Uses the entire partition.
Main advantage is it uses less memory to boot to desktop.
Does not use layered file system.
Works best for compiling.
Does not run into size limit that a save file has on a fat32 format.

[peebee]

I sent @witekjeden a PM with rune but it hasn't been read.....

[witekjeden]

Ok, now i see it. Tomorrow try to install.

[mikeslr]

witekjeden,
SaveFolders were developed long after the ability to run Puppys as a Full Install became available. Like a Full Install, a SaveFolder requires the use of a Linux Ext formatted partition and never requires resizing. It will expand to the available space on its partition if you need it to. But unlike a Full install, a SaveFolder only needs its own folder (not the entire partition), and can load and unload SFSes. An unloaded SFS require no RAM. You can't install two conflicting applications. But two conflicting applications can co-exist as SFSes: just don't load them at the same time.
A SaveFolder can also be backed-up. A screwed-up/corrupted Full Install is almost impossible recover from. A Screwed-up/corrupted SaveFolder can be replaced by its backup in a couple of minutes. You can also develop variations such a one for general use, one for video-editing and one for compiling and on boot-up be offered the choice of which variation to use.

In other words, using a SaveFolder has many advantages over doing a Full Install.

If the reason for using a Full Install is that your computer is RAM-Challenged, the argument 'pfix=nocopy' can be added to the kernel/linux line of the boot-menu/config. It instructs Puppy not to copy files into RAM beyond those needed to have a functional system and access to applications.

If you have the time, may I suggest that you explore the use of a SaveFolder and see if it meets your needs.

[Starlyte]

I've been using Puppy since the Puppy-100 and something, but due to time and other obligations, I guess I got out of touch, even as far as using "the other" OS on a laptop
Anyhow, now I'm here with Fossa, and all this talk of hidden rune to do a full installation bugs me. I use an old laptop with a reasonable HDD but not a lot of RAM. So... I pressed on "full install" and got the frugal... shucks!
Do I really need to ask you for the rune to full-install Fossapup? It's getting a bit non-open source IMO, but any how...
So what's the secret please?

[bigpup]

Newer Puppy Linux version are fully supporting frugal or live installs.
Being developed for that way to operate.
No one has worked on fully supporting full installs for years.
There are a few differences on how internal processes have to work for full installs.

If you are limited to less than 1GB of RAM.
There are boot settings to limit what gets loaded into RAM.

Try a frugal or live install.
You may be surprised on how well it works.

[amethyst]

What we need to do, is to give this a test. Someone with an old machine and limited resources, say 1GB running a new Puppy. So frugal install (pfix=nocopy, savefolder, swapfile/partition versus full install with swap. Let's get the results with regards to performance, etc. If the performance is basically the same (can't see how it can be otherwise), frugal will be a good selling point with all its other benefits. This should convince the full install die-hards but if not, well then I don't have sympathy for them and they can struggle themselves to get their beloved full install going. BTW - I think this was a good idea to make it "more difficult" to do a full install. Unfortunately I don't have that old a machine to do the test myself.

[Clarity]

Puppy Linux's focus for over a decade is on running in such a way as to give the very best performance and user experience. It is "REALLY" accomplished when, as @BigPUP explains "...RAM" meaning operating in RAM with little to no drive operations. A full install changes operation as the complete Puppy filesystem is expanded out and operates from the "slow" drive(s) vs running in RAM as Puppy is designed.

The developers have created a distro that natively intends to be a LIVE system with a persistence ability. We, as users, have 3 methods to boot and manage system behavior:

1. Direct from a PUP's ISO file, downloaded and booted as is (I call "ISO Direct")

2. Write the ISO contents, after downloading, to an additional folder (called Frugal install)

3. Extract and expose all info contained in the individual content files extracted from the Frugal files to boot with all system info appearing on the system boot drive as seen in most other Linux distros (called FULL install)

1. and 2. above give identical and best performance (they are essentially "exactly" the same)
3. above is different and certainly not as fast because its operations involves constant keeping the physical drive in sync

The boot-to-shutdown behavior of all 3 methods will maintain proper system information for all user activities.

[JASpup]

If the performance is basically the same (can't see how it can be otherwise), frugal will be a good selling point with all its other benefits.

I'm trying to understand how you're not using a pupsave, and my only guess would be a very careful remaster.

Part of the reason I'm glued to Xenial is Windows conditioning -- new versions hogging resources w/significantly boosted requirements.

I've learned in Puppyworld at least that isn't the case, but conditioning won't die.

[amethyst]

I'm trying to understand how you're not using a pupsave, and my only guess would be a very careful remaster.

I only save small system configuration changes to an adrv. I don't install applications but use sfs addons. I move things like browser caches out of the puppy running environment. That's about it. If you want to operate this way, you can save the contents of your current savefile to a ydrv and then proceed further as mentioned without a savefile. Alternatively you can do a remaster and then operate with the adrv as mentioned but that's not necessary.

[JASpup]

I only save small system configuration changes to an adrv. I don't install applications but use sfs addons. I move things like browser caches out of the puppy running environment. That's about it. If you want to operate this way, you can save the contents of your current savefile to a ydrv and then proceed further as mentioned without a savefile. Alternatively you can do a remaster and then operate with the adrv as mentioned but that's not necessary.

Great Puppy option. Are small changes tedious? I generally don't update my pupsave without at least 3 changes for it, doing so before cache gets loaded into the save, etc.

I'd probably have to get better at making SFS the same, though it probably doesn't hurt to temporarily install an app that doesn't always need to be available.

The other concern is the system treating the change like a live boot, i.e., half ram dedicated to ramdisk.

[amethyst]

I only save small system configuration changes to an adrv. I don't install applications but use sfs addons. I move things like browser caches out of the puppy running environment. That's about it. If you want to operate this way, you can save the contents of your current savefile to a ydrv and then proceed further as mentioned without a savefile. Alternatively you can do a remaster and then operate with the adrv as mentioned but that's not necessary.

Great Puppy option. Are small changes tedious? I generally don't update my pupsave without at least 3 changes for it, doing so before cache gets loaded into the save, etc.

I'd probably have to get better at making SFS the same, though it probably doesn't hurt to temporarily install an app that doesn't always need to be available.

The other concern is the system treating the change like a live boot, i.e., half ram dedicated to ramdisk.

The idea is to keep your system savings very small, that's why I basically only save system configuration settings. My adrv with system configuration changes is about 5MB. I have a script which I run to save changes to the adrv or ydrv whenever I like. Look at my nicOS-Save2SFS tool which is part of my utility suite if you are interested. You can use that tool to save changes to an adrv or ydrv (read the help for more information) whenever you like.

[williams2]

The other concern is the system treating the change like a live boot, i.e., half ram dedicated to ramdisk.

From https://wiki.archlinux.org/title/Tmpfs

The actual memory/swap consumption depends on how much is used, as tmpfs partitions do not consume any memory until it is actually needed.

When the tmpfs is created with a maximum size of 1/2 the total ram, that does not mean that half the ram is now unavailable to the system. All of the ram in the tmpfs file system that is unused by the tmpfs is usable by the operating system.

I usually run in live mode (pfix=ram) with an adrv instead of a save file. Usually, the ram used in the tmpfs in my BionicPup64 is about 5MiB
( mostly in /initrd/mnt/tmpfs/pup_rw/lib/modules )
If I copy Firefox executables and configuration files to ram, it increases the ram usage to about 250MiB.

https://wiki.archlinux.org/title/Firefox_on_RAM

I have a script which shows how much space is being used in the tmpfs file system,, in KiB:
du /initrd/mnt/tmpfs/* | sort -nk1

Human readable:
du --block-size=1 /initrd/mnt/tmpfs/* | sort -nk1 | numfmt --to=iec-i --suffix=B --field=1

EDIT: Same:
du -h /initrd/mnt/tmpfs/* | sort -hk1

I think that if Puppy is almost completely unusable because of lack of ram on a slow computer, then a full install might improve things slightly. But it would not be much of an improvement. It would still be almost unusable. I think of a full install as a desperate attempt to make it less unusable, that is not likely to be effective.

[JASpup]

The idea is to keep your system savings very small, that's why I basically only save system configuration settings. My adrv with system configuration changes is about 5MB. I have a script which I run to save changes to the adrv or ydrv whenever I like. Look at my nicOS-Save2SFS tool which is part of my utility suite if you are interested. You can use that tool to save changes to an adrv or ydrv (read the help for more information) whenever you like.

Sounds handy, though I need to learn alphabet drive theory better first. I know those posts are in here or the old forum somewhere. I would guess a ydrv is basically the output of the builtin remaster utility, essentially containing /root and any changes made to the system directories, including home of the windows managers/DEs.

An adrv is perhaps a more limited layer?

'Course anything loaded to ram should be limited.

I'm having poor luck with system configuration manipulation.

E.g., yesterday in 32-bit Iron 75 I removed the config directory to symlink it before the browser stopped running looking for a dependency (normally it runs). That was Mainline Xenial.

I also lose the XFCE equivalent of the pinboard deleting config files. This ALSO happens heavy browsing:

It's not 2am and the backdrop isn't grey.

The first gist is XFCE will be less flexible for my custom configurations, 32-bit at least. The overall gist is I need to know what I'm doing before config experimentation.

[JASpup]

All of this makes sense. Made lay for application, it appears make the point:

Do not worry about ramdisk consumption in PUPMODE 5.

What is the difference between an advanced user using this method and making it standard?

I would also be concerned if it is possible anyhow to make Task Manager and Conky accurately display system resource usage. It is almost an artist comprehension with a lot of qualifications.

Code: Select all

root# du /initrd/mnt/tmpfs/* | sort -nk1
195788	/initrd/mnt/tmpfs/puppy_xtahr_2.0.sfs

~200k total in PUPMODE 13, or is that in k? Seems small.

The other concern is the system treating the change like a live boot, i.e., half ram dedicated to ramdisk.

From https://wiki.archlinux.org/title/Tmpfs

The actual memory/swap consumption depends on how much is used, as tmpfs partitions do not consume any memory until it is actually needed.

When the tmpfs is created with a maximum size of 1/2 the total ram, that does not mean that half the ram is now unavailable to the system. All of the ram in the tmpfs file system that is unused by the tmpfs is usable by the operating system.

I usually run in live mode (pfix=ram) with an adrv instead of a save file. Usually, the ram used in the tmpfs in my BionicPup64 is about 5MiB
( mostly in /initrd/mnt/tmpfs/pup_rw/lib/modules )
If I copy Firefox executables and configuration files to ram, it increases the ram usage to about 250MiB.

https://wiki.archlinux.org/title/Firefox_on_RAM

I have a script which shows how much space is being used in the tmpfs file system,, in KiB:
du /initrd/mnt/tmpfs/* | sort -nk1

Human readable:
du --block-size=1 /initrd/mnt/tmpfs/* | sort -nk1 | numfmt --to=iec-i --suffix=B --field=1

EDIT: Same:
du -h /initrd/mnt/tmpfs/* | sort -hk1

I think that if Puppy is almost completely unusable because of lack of ram on a slow computer, then a full install might improve things slightly. But it would not be much of an improvement. It would still be almost unusable. I think of a full install as a desperate attempt to make it less unusable, that is not likely to be effective.

[williams2]

195788 from du is KiB, so 195788KiB is about 196MiB

I run Puppy "live" (pfix=ram, the run mode is 5) with an adrv.sfs to remaster the original file system.
So I have no save file or save folder.
All changes to the file system are made to the rw layer, which is ram.

the save layer pup_rw/ and /tmp/ and the sfs files are all in the tmpfs file system, which is ram.

Other Puppys running in different modes will have things mounted differently.

Mostly, I was saying that the ram used instead of a save file typically uses about 5MiB.
If I copy all of Firefox to ram, it increases ram usage to about 250MiB

[amethyst]

The idea is to keep your system savings very small, that's why I basically only save system configuration settings. My adrv with system configuration changes is about 5MB. I have a script which I run to save changes to the adrv or ydrv whenever I like. Look at my nicOS-Save2SFS tool which is part of my utility suite if you are interested. You can use that tool to save changes to an adrv or ydrv (read the help for more information) whenever you like.

Sounds handy, though I need to learn alphabet drive theory better first. I know those posts are in here or the old forum somewhere. I would guess a ydrv is basically the output of the builtin remaster utility, essentially containing /root and any changes made to the system directories, including home of the windows managers/DEs.

An adrv is perhaps a more limited layer?

'Course anything loaded to ram should be limited.

I'm having poor luck with system configuration manipulation.

E.g., yesterday in 32-bit Iron 75 I removed the config directory to symlink it before the browser stopped running looking for a dependency (normally it runs). That was Mainline Xenial.

I also lose the XFCE equivalent of the pinboard deleting config files. This ALSO happens heavy browsing:

It's not 2am and the backdrop isn't grey.

The first gist is XFCE will be less flexible for my custom configurations, 32-bit at least. The overall gist is I need to know what I'm doing before config experimentation.

The adrv and ydrv are normal sfs files which load on top (have preference to) the base sfs. So, you can rename any existing extra sfs file to an adrv or ydrv for example OR create a sfs file and rename it to an adrv/yddrv and it will load on top of the base sfs. The adrv has preference to the ydrv. The order of layer preference is as follows: pupsave (/initrd/pup_rw) > adrv > ydrv > base sfs > fdrv > zdrv

[JASpup]

The adrv and ydrv are normal sfs files which load on top (have preference to) the base sfs. So, you can rename any existing extra sfs file to an adrv or ydrv for example OR create a sfs file and rename it to an adrv/yddrv and it will load on top of the base sfs. The adrv has preference to the ydrv. The order of layer preference is as follows: pupsave (/initrd/pup_rw) > adrv > ydrv > base sfs > fdrv > zdrv

I don't consider this your responsibility to drive the message home, but in pup_rw I see a collection of system directories. In the pup_ro? slots, particularly 2, I see more and not sure how they relate to alphabet drives. What am I saving to 'a' or 'y'? Where is any of it loaded from? Do I just save a directory to SFS then make sure it's loaded to preserve a setup? And how do I know which one?

I know among ro? layers priority matters (recent Pale Moon puzzle: viewtopic.php?f=4&t=2785&p=24228&hilit=pale+moon#p24228).

ro2 doesn't let me SFS a newer Pale Moon.

If it's just a matter a knowing layer priority, I'm sure I could cobble something together, but I like to have a general gist of what I'm doing.

[amethyst]

The adrv and ydrv are normal sfs files which load on top (have preference to) the base sfs. So, you can rename any existing extra sfs file to an adrv or ydrv for example OR create a sfs file and rename it to an adrv/yddrv and it will load on top of the base sfs. The adrv has preference to the ydrv. The order of layer preference is as follows: pupsave (/initrd/pup_rw) > adrv > ydrv > base sfs > fdrv > zdrv

I don't consider this your responsibility to drive the message home, but in pup_rw I see a collection of system directories. In the pup_ro? slots, particularly 2, I see more and not sure how they relate to alphabet drives. What am I saving to 'a' or 'y'? Where is any of it loaded from? Do I just save a directory to SFS then make sure it's loaded to preserve a setup? And how do I know which one?

I know among ro? layers priority matters (recent Pale Moon puzzle: viewtopic.php?f=4&t=2785&p=24228&hilit=pale+moon#p24228).

ro2 doesn't let me SFS a newer Pale Moon.

If it's just a matter a knowing layer priority, I'm sure I could cobble something together, but I like to have a general gist of what I'm doing.

The /initrd/pup_..'s are the Puppy mounting layers in order of preference. For frugal installs:
/initrd/pup_rw = Top savings layer (contents change during a session).
/initrd/pup_ro1 = Existing savefile if you are using a usb drive (pupmode 13). This layer is not used when you have an internal HD install (in the latter case your existing savefile will be mounted as /initrd/pup_rw)
/initrd/pup_a = adrive (adrv)
/initrd/pup_y = ydrive (ydrv)
/initrd/pup_ro2 = Puppy base sfs
/initrd/pup_f = fdrive (fdrv, firmware)
/initrd/pup_z = zdrive (zdrv, kernel modules/drivers)

Puppy's init script looks for the above and mounts them automatically at bootup.

/initrd/pup_ro3, /initrd/pup_ro4, /initrd/pup_ro5 and so on... = extra sfs files loaded during a session with a utility like sfs_load.

BTW - Make a new thread if you want to know more about Puppy's workings, we are hijacking this one.

[JASpup]

I have a script which shows how much space is being used in the tmpfs file system,, in KiB:
du /initrd/mnt/tmpfs/* | sort -nk1

I notice zdrv is in /initrd/mnt/tmpfs4. Accurately accounting for ramdisk usage we would include all tmpfs directories in /initrd/mnt PLUS /tmp, or does /initrd include all ram storage? (pup_rw etc.)

[williams2]

does /initrd include all ram storage? (pup_rw etc.)

In BionicPup64, running with no save file, pfix=ram, so that the top writable aufs file system layers is in ram (tmpfs):

Code: Select all

# ll /initrd/mnt/tmpfs/
total 450M
-rwxrwxrwx  1 114M Mar  9 01:29 adrv_bionicpup64_8.0.sfs
-rwxrwxrwx  1 279M Apr 26  2019 puppy_bionicpup64_8.0.sfs
drwxr-xr-x 13  300 May 18 13:01 pup_rw
drwxrwxrwt 16  640 May 18 13:06 tmp
-rwxrwxrwx  1  57M Apr 26  2019 zdrv_bionicpup64_8.0.sfs
#

This is where the Puppy system sfs files are when copied to ram.
tmp/ is /tmp/
pup_rw/ is the top writable aufs layer, which for pfix=ram, is ram.
For PupMode 12, pup_rw/ would be the save file or save folder.
For PupMode 13, pup_rw/ would be in ram.

The actual script I am using to see how much space is being used in the tmpfs file system is:

Code: Select all

#!/bin/ash
cd /initrd/mnt/tmpfs/
du -h pup_rw/ tmp/ | sort -hk1

which does not show space used by the Puppy system sfs files, because it's always the same (unless Puppy boots pfox=nocopy)

I sometimes use this python script to show how much memory each process is using:
http://www.pixelbeat.org/scripts/ps_mem.py

[JASpup]

The actual script I am using to see how much space is being used in the tmpfs file system is:

Code: Select all

#!/bin/ash
cd /initrd/mnt/tmpfs/
du -h pup_rw/ tmp/ | sort -hk1

which does not show space used by the Puppy system sfs files, because it's always the same (unless Puppy boots pfox=nocopy)

I sometimes use this python script to show how much memory each process is using:
http://www.pixelbeat.org/scripts/ps_mem.py

If du line covers entire system tmpfs it's a solution.

My output in X-Tahr PUPMODE 5 for the three system .sfs:

Code: Select all

root# ls -alh /initrd/mnt/tmpf*
/initrd/mnt/tmpfs:
total 192M
drwxrwxrwt  2 root root   60 May 19 02:25 .
drwxr-xr-x 14 root root  176 May 18 11:02 ..
-rwxrwxrwx  1 root root 192M Aug 19  2016 puppy_xtahr_2.0.sfs

/initrd/mnt/tmpfs2:
total 3.7M
drwxrwxrwt  2 root root   60 May 19 02:25 .
drwxr-xr-x 14 root root  176 May 18 11:02 ..
-rwxrwxrwx  1 root root 3.7M May 19 00:28 adrv_xtahr_2.0.sfs

/initrd/mnt/tmpfs3:
total 0
drwxr-xr-x  2 root root   3 May 18 11:02 .
drwxr-xr-x 14 root root 176 May 18 11:02 ..

/initrd/mnt/tmpfs4:
total 27M
drwxrwxrwt  2 root root  60 May 19 02:25 .
drwxr-xr-x 14 root root 176 May 18 11:02 ..
-rwxrwxrwx  1 root root 27M Aug 19  2016 zdrv_xtahr_2.0.sfs
root# 

This is still vaguely 100M less than Xenial JWM.

I suppose the question is interchangability., i.e., can we use the same command in every system if the file structure is set up a little differently.

All the tmpfs being data storage in ram (ramdisk), that plus whatever the system/apps are using should be total ram usage.

I don't consider cache so much if it's managed to be released for essential needs.

The easy way is to learn all the possible locations for tmpfs with a utility like Conky or Task Manager or your Python for the estimate. It appears to vary.

X-Tahr output of your du command 52M, 29M that the mere config of this Chromium I'm using. Ridiculous.

Code: Select all

29M	pup_rw/root/.config
29M	pup_rw/root/.config/chromium
31M	pup_rw/root
52M	pup_rw/
52M	total
root# 

[williams2]

This will show the largest files in tmpfs:

Code: Select all

find /initrd/mnt/tmpfs/ -ls |  sort -nk7 | awk '{printf "%12d %s \n", $7,substr($0, index($0,$11))}'

Or this should do the same thing:

Code: Select all

find /initrd/mnt/tmpfs/ -printf "%12s %p\n" | sort -nk1

The kernel works well managing the cache memory space, it shouldn't be a concern.

I'm running Firefox at the moment, it's using 220MiB for the program files, and 64MiB for the config files.
When I'm not using Firefox, it uses 0 bytes of space in the tmpfs.

[JASpup]

That's no fun with 2gb, 1.4-1.7MHz dual core. I run Firefox standalone on a HD, but for 32-bit I'm feeling like putting both Firefox and its config on usbflash. Flash is fast enough for app and it couldn't be any worse than a swap disk for config. My 32-bit world has dramatically lower download speeds, and that's the greatest bottleneck.

Correct me if I'm wrong, but this tmpfs data memory consumption we're seeing is not even the increased memory we see in resource monitoring while browsing? Or maybe it's the same data not accurately reported, because it's not system memory but where you tell it to config? Each tab/window we open just devours ram on mainstream web sites. Browsing feels like getting drunk, like you're gonna need the gusto elsewhere. I think it's both, resource monitor memory and config tempfs memory being used. Major pigout.

Why could old computers browse, and not much more slowly?

This will show the largest files in tmpfs:

Code: Select all

find /initrd/mnt/tmpfs/ -ls |  sort -nk7 | awk '{printf "%12d %s \n", $7,substr($0, index($0,$11))}'

Or this should do the same thing:

Code: Select all

find /initrd/mnt/tmpfs/ -printf "%12s %p\n" | sort -nk1

The kernel works well managing the cache memory space, it shouldn't be a concern.

I'm running Firefox at the moment, it's using 220MiB for the program files, and 64MiB for the config files.
When I'm not using Firefox, it uses 0 bytes of space in the tmpfs.