How to change alphabet drives without crashing Puppy?

[JASpup]

Using a Puppy with a, y, base, & z taken:

Can a, y, base be moved down to y, base, f without blowing up Puppy?

Essentially this is making the base .sfs an fdrv and changing the others correspondingly.

Is .sfs loading at boot all about load order or do the actual file contents matter for normal operation (i.e., no remasters and such)?

The goal is freeing up an alphabet drive that loads after the base .sfs.

[amethyst]

Using a Puppy with a, y, base, & z taken:

Can a, y, base be moved down to y, base, f without blowing up Puppy?

Essentially this is making the base .sfs an fdrv and changing the others correspondingly.

Is .sfs loading at boot all about load order or do the actual file contents matter for normal operation (i.e., no remasters and such)?

The goal is freeing up an alphabet drive that loads after the base .sfs.

You can't do it during a session (well actually I think you can but it's very risky , you will probably need to have the system copied to RAM) and will probably make the running system unstable. And yes the order is established at bootup. If your question relates to interchanging the names of the drives before bootup, yes you can but again it will depend upon what the drives contain and whether that change up will make the system unstable or make some things not to work properly. Just as information - the implementation of these extra drives were only introduced in newer Puppys. I do not use a savefile and save my changes to an adrv. Because older Puppys did not have an adrv (in fact many of them also did not have a zdrv because the kernel was builtin to the base sfs (but the implementation of the zdrv was available), I used to rename the base sfs to the zdrv and save my changes to an sfs drive which I renamed to the name of the base sfs.

[williams2]

You can see the layers of an aufs file system like this:

cat /sys/fs/aufs/*/br[0-99]

I also use the @amethyst method, using an adrv.sfs instead of a save file.

FossaPup uses an adrv.sfs as the main part of the operating systems' file system.
So I renamed the FossaPup adrv.sfs to ydrv.sfs.
adrv.sfs is now my save file, and takes precedence over the ydrv.sfs, which is what I want.
It's seems to work properly.

adrv.sfs takes precedence over ydrv.sfs
ydrv.sfs takes precedence over pup.sfs (the base of the Puppy OS)
pup.sfs takes precedence over fdrv.sfs
fdrv.sfs takes precendence over zdrv.sfs (if I remember correctly)

If you rename the ydrv.sfs to fdrv.sfs or to zdrv.sfs,
then the ydrv.sfs no longer has precedence over the pup.sfs
This can cause problems. Puppy might become unstable, no longer completely trust worthy.

if you do something like rename a ydrv.sfs file to fdrv.sfs,
and if you ask for help on the forum about anomalous behaviour from Puppy,
then please tell anyone trying to help you what you have done.
{the phrase "unspeakable evil" comes to mind ...)

[JASpup]

You can see the layers of an aufs file system like this:

cat /sys/fs/aufs/*/br[0-99]

[snip]

If you rename the ydrv.sfs to fdrv.sfs or to zdrv.sfs,
then the ydrv.sfs no longer has precedence over the pup.sfs
This can cause problems. Puppy might become unstable, no longer completely trust worthy.

Clear explanations like usual, but my gist is about renaming a ydrv the base .sfs and making the base .sfs an fdrv.

Does the base .sfs have to have its name for normal functioning?

It seems specialized community creations are under-tested and tend to work under specific, unpredictable conditions, so I have to do things that are straightforward no matter how unconventional they may be.

Does anyone, say, add a PUPSAVE .sfs after an adrv?

[williams2]

renaming a ydrv the base .sfs and making the base .sfs an fdrv.

AFAIK, if the aufs layered file system is created by initrd in the usual order,
then the virtual file system that Puppy has (and all Linux operating systems have), consisting of /bin, /sbin, /usr. /root, /etc etc etc ... should work properly.

The base, core files of the operating system will no longer be in /initrd/pup_ro2/
That might cause problems if something, maybe a script, in the operating system, or possibly installed software, accesses the mounted sfs files in /initrd/ directly.
For example, the nicOS utility suite might or might not always work as expected. Or remaster scripts in Puppy.

I think renaming the sfs files should work, but I could easily be wrong.
I don't think it would be possible to guarantee that it would work without problems.

I think it would be safer testing it using the pfix=ram option, so that no drives are mounted.

Does anyone, say, add a PUPSAVE .sfs after an adrv?

The save file/folder needs to be the top rw layer of the layered file system.
If an adrv is above the pupsave, then the files in the adrv can not be over written or deleted or modifed in any way.

You can always remaster the original pup.sfs file, merging in any adrv and ydrv files, and any other loaded sfs files, and even the save file, making 1 bigger pup.sfs file. Then you would be free to add adrv, ydrv, fdrv, zdrv files later, as desired, and load other sfs files, as desired.

[amethyst]

renaming a ydrv the base .sfs and making the base .sfs an fdrv.

AFAIK, if the aufs layered file system is created by initrd in the usual order,
then the virtual file system that Puppy has (and all Linux operating systems have), consisting of /bin, /sbin, /usr. /root, /etc etc etc ... should work properly.

The base, core files of the operating system will no longer be in /initrd/pup_ro2/
That might cause problems if something, maybe a script, in the operating system, or possibly installed software, accesses the mounted sfs files in /initrd/ directly.
For example, the nicOS utility suite might or might not always work as expected. Or remaster scripts in Puppy.

I think renaming the sfs files should work, but I could easily be wrong.
I don't think it would be possible to guarantee that it would work without problems.

I think it would be safer testing it using the pfix=ram option, so that no drives are mounted.

Does anyone, say, add a PUPSAVE .sfs after an adrv?

The save file/folder needs to be the top rw layer of the layered file system.
If an adrv is above the pupsave, then the files in the adrv can not be over written or deleted or modifed in any way.

You can always remaster the original pup.sfs file, merging in any adrv and ydrv files, and any other loaded sfs files, and even the save file, making 1 bigger pup.sfs file. Then you would be free to add adrv, ydrv, fdrv, zdrv files later, as desired, and load other sfs files, as desired.

Renaming the sfs files will not influence the classic remaster script as files are copied directly from the top level of the system and not from the mounting points at /intrd (/initrd and a few other folders are excluded). Renaming the sfs files may or may not work correctly as mentioned before and it all depends on the preference of mounting and which files are contained. There must always be an sfs file with the base name otherwise you will get an error that the base sfs can't be found at bootup. The savefile/folder has preference to sfs files including the adrv. The savefile is not an sfs file, it's a file containing a linux file system with read/write abilities. If you rename an sfs file to something like PUPSAVE.sfs it will be seen as an extra sfs files by the system and all alphabetic lettered drives (adrv, zdrv, fdrv, etc. and the base sfs) will have preference. So saving your changes to an sfs file called PUPSAVE.sfs will not work, you will have to rename it to an adrv to have preference above all other sfs files (but it will still not have preference to any existing savefile/folder).

[JASpup]

I don't think it would be possible to guarantee that it would work without problems.

Starting with a d.i.y. disclaimer: I tried both a remaster and Nic-OS for this project.

Simply conceived, it's the Battleshooter 64 Xenial XFCE puplet with my PUPSAVE.

Sparing details, my two attempts did not work at all.

Mainline Xenial JWM works both 64/32 with manual adrv creation save glitches like quickpet returning to the desktop and two copies of pmcputemp running (those that I can see, functioning seems normal). On my 32 machines I'm cleaning the adrv up with a script, but don't see how we can easily right-click to remove items on the pinboard, yet if we do it editing/replacing PUPPYPIN we have to restart X to reflect changes.

I take your renaming caveat to mean: you'll probably get a boot that looks normal but are likely to run into operating problems which makes sense.

I think it would be safer testing it using the pfix=ram option, so that no drives are mounted.

An adrv would test in PUPMODE 5, I suspect without worries of mounting a partition unless deliberately specified.

The save file/folder needs to be the top rw layer of the layered file system.
If an adrv is above the pupsave, then the files in the adrv can not be over written or deleted or modifed in any way.

I hadn't thought of this. If we load a PUPSAVE as a post-adrv .sfs, it's going to be above Puppy's read-write layer (the new PUPSAVE) and we'll be stuck with it.

I take the essence to mean: Booting PUPMODE 5 with a PUPSAVE necessitates having that as an adrv or ydrv in Puppy Linux. - a logical but frustrating constraint

You can always remaster the original pup.sfs file, merging in any adrv and ydrv files, and any other loaded sfs files, and even the save file, making 1 bigger pup.sfs file. Then you would be free to add adrv, ydrv, fdrv, zdrv files later, as desired, and load other sfs files, as desired.

I'm attached to my 32 machines for daily use, but I'm going to try again.

[amethyst]

I hadn't thought of this. If we load a PUPSAVE as a post-adrv .sfs, it's going to be above Puppy's read-write layer (the new PUPSAVE) and we'll be stuck with it.

That's wrong. An existing loaded savefile or a newly created savefile will ALWAYS be on top, having preference to any sfs file. If you load an adrv with the correct puppy name it will be automatically booted at bootup by the system and will have preference to any other sfs file BUT NOT HAVE PREFERENCE TO your savefile. If you have an adrv not called the correct name (or something like save.sfs) which you want to use as an "adrv", it will not be booted automatically by the system but will be treated as an extra sfs file which will have lower preference than an alphabetically named sfs file (with the correct puppy name) which are loaded automatically by the system. So in order of preference: savefile>adrv>ydrv>base sfs>fdrv>zdrv>any other extra sfs file with whatever name.

[JASpup]

There's a high potential for confusion. When you indicate the 'root' directory, do you mean "/" or "/root" (rhetorical).

I was referencing this:

The save file/folder needs to be the top rw layer of the layered file system.
If an adrv is above the pupsave, then the files in the adrv can not be over written or deleted or modified in any way.

The adrv for purposes of discussion is the PUPSAVE.

My understanding is the r/w layer is loaded after the adrv. If you load a .sfs PUPSAVE in the r/w layer, how can it ever be below it like an adrv, and does this not present potential conflicts?

Another way to put it: If I load a PUPSAVE .sfs in the r/w layer, would it ever be the same as making it an adrv?

The goal is achieving the same functionality differently.

[JASpup]

If you have an adrv not called the correct name (or something like save.sfs) which you want to use as an "adrv", it will not be booted automatically by the system but will be treated as an extra sfs file which will have lower preference than an alphabetically named sfs file (with the correct puppy name) which are loaded automatically by the system.

I see some users indicate browser "adrv".

Summarily these co-exist with system adrv except they are not loaded unless somehow manually specified? If so, why would they be called an adrv? (instead of just a browser .sfs) We can have a regular adrv and a browser adrv?

[amethyst]

I don't know what you mean by loading the save.sfs in/on the read/write layer, you can't. Sfs files are read only and the only way it possibly could have preference to a loaded savefile is if you physically copy the contents thereof (the files in the sfs) to the running file system during a session. It will then show in /initrd/pup_rw. The only reason I can think of naming an sfs file which contains a browser the adrv, is if the adrv.sfs contains some files which should have preference to the distribution's base sfs. All my browsers are loaded as extra sfs files.

[williams2]

In other words, to have a writable file system, the top layer must always be writable (rw)

sfs files are always read-only, not writable.

My "save file" is an adrv.sfs file, therefore read-only.
It is not the top layer, because it can't be, it is read only.
The top layer is a tmpfs file system in ram. I boot Puppy using the pfix=ram paramater.

[JASpup]

I consider this thread's problem [SOLVED] but untested {not the experimental idea of renaming alphabet drives}.

The answer is to remaster Puppy which combines alphabet drv into the main .sfs, leaving room for PUPSAVE alphabet drv.

In my remastering trial Puppy booted without PUPSAVE changes, like the PUPSAVE wasn't included when it must have been. It booted but looked unchanged. I didn't try to make alphabet drives after remaster which is what I'm doing next trial.

Test 1:
Frugal Boot -> Remaster

Impending Test:
Live Boot -> Remaster -> Live Boot w/PUPSAVE alphabet drv

Just clarity: loading a read-only .sfs in the read-write layer might work despite no one attesting to this possible use. Everyone seeking custom PUPMODE 5 is using alphabet drv, despite the fact we can load .sfs after all alphabets have been loaded.

Since loading a .sfs PUPSAVE after boot is not the same as an alphabet drv, I'm skeptical.

[amethyst]

The answer is to remaster Puppy which combines alphabet drv into the main .sfs, leaving room for PUPSAVE alphabet drv.

It's not necessary to do a remaster but it can be an alternative (although this will change your original base sfs, something I'm not really fond of). If you go the route of saving your system changes to an sfs file instead of using a savefile/folder all you need to do, is make sure that the sfs containing your system changes has preference over all other sfs files and this means it should be an adrv with the appropriate puppy name (not "save" whatever). I've been running puppy like this for years. I have a script which automatically updates and replaces my existing adrv with a new adrv with the new changes recorded.
PS: If you already have an adrv which contains other stuff like a browser or applications, the simple solution would be to rename this to a ydrv (which is already implemented in most Puppys) and then proceed with saving your system changes to an adrv. ALSO - there are "experimental" initrd scripts which enables more alphabetical drives like a bdrv, cdrv, ddrv, etc. which makes things even easier. Depending how the initrd script has been changed, these additional drives will also have preference to the base sfs but the order of sfs preference will probably be adrv > ydrv > bdrv > cdrv > ddrv, etc .......The base sfs, fdrv, zdrv, extra sfs files have lower priority. That's how my altered initrd script works anyways. Once you understand how the order of preference works, it is easy to achieve the correct results by combining different sfs files, etc. if you so wish...and there are tools available to do this for you correctly.

[JASpup]

If there were relatively unambiguous & fool-proof instructions or utilities, I would use them.

The whole idea of saving incremental adrv changes is valuable, but it has to work straightforward.

Preferences come after basic functionality.

Nothing is going to become an adrv in a puplet that is already full without some hackery. If we can use b, c, ddrv, they fall in line before the ydrv?

That would be simple if known.

[amethyst]

If there were relatively unambiguous & fool-proof instructions or utilities, I would use them.

The whole idea of saving incremental adrv changes is valuable, but it has to work straightforward.

Preferences come after basic functionality.

Nothing is going to become an adrv in a puplet that is already full without some hackery. If we can use b, c, ddrv, they fall in line before the ydrv?
That would be simple if known.

Well, it has been working straightforward for me for years and I think the instructions are actually clear enough and many users have benefited from it. However this is not the "normal" way Puppy is being used (most users use a savefile/folder) and it does require a relatively good understanding how Puppy works and what you want to achieve and maybe that is not so easy for someone new to Puppy to understand as readily. There is one "drawback" of saving your changes to an adrv instead of using a savefile and that is that so-called white-out files will not be "hidden" like with using a savefile. However, I have overcome that obstacle as well with an additional script. My adrv with system changes operates exactly like an existing savefile would.
Invoking additional alphabetic drives requires some tinkering with the initrd script. It is not too difficult to invoke additional drives besides the adrv and ydrv we already have (but you still need to know what you are doing because you can mess things up very easily). The easier way was to just add it to existing adrv, ydrv entries and that is why the order of preference will be adrv, ydrv and then the other drives. However, it may be possible to move the added bdrv, cdrv up in order to supersede the ydrv but I haven't tried that. Maybe someday when I have a look at it again. Don't want to get too technical but it is also possible to "select" which of the added drives should load into RAM or not. I've also done that before. You may further find it interesting that the names of the additional drives can be changed, for instance it's possible to change the name of the bdrv to say bdrv_Palemoon.sfs for instance which could be quite nice for identification in terms of what the drive is containing. So one can also change the name of the adrv to something like adrv_Save.sfs. And so on and so on...interesting things can be achieved by playing with the initrd script. Puppy is a lovely distro to tinker with.......