What is the basic procedure for substituting an adrv for a pupsave?

[JASpup]

It seems to be a popular technique for expert users. I'm wondering the pros/cons (vs. pupsave) or how to do it so I can discover them myself.

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.

[ozsouth]

@JASpup - you could simply rename the pupsave file to adrv.sfs. Will be very specific tho.

[amethyst]

It seems to be a popular technique for expert users. I'm wondering the pros/cons (vs. pupsave) or how to do it so I can discover them myself.

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.

Do you mean savefile converted to adrv? I've already addressed and explained this to you in another thread of yours. Did you try it? Advantages of the adrv instead of savefile > it's an sfs file so read only. Can not easily be corrupted. This is also a disadvantage because you must edit or replace the adrv with another one if you want to make changes, it's not as flexible as a savefile which is read/write. There is nothing wrong with using a savefile, I just think one should keep it very small (some would disagree with me) if you are going to use one. It's your choice how you want to run Puppy.

[Feek]

Hello JASpup,

I use succesfully adrv…sfs instead of savefolder in Bionicpup64 (I didn´t try it in other puppies). The way how to achieve it is relatively easy.

Let´s assume there is a savefolder with your personal settings (savefolder is required for this method).
Reboot with boot param. pfix=ram, so your savefolder is not loaded.
(for sure update the system in Quickpet to be stable).
Go to the location with your savefolder, right click on it and choose „dir2sfs“.
It will create a .sfs from your savefolder and after that rename it to the right name (adrv_.....sfs).
Now when you reboot with the param. pfix=ram, it will load the adrv (your personal settings) with other drv´s. The savefolder itself will not be loaded.

If I boot this way, the pupmode=5, everything happens in ram. After the booting is finished I can unmount the usb stick (can not be compromised if not mounted), which is not possible when I use savefolder. I can install new packages without a fear that it will create a mess in my savefolder or if something crashes, because after reboot there will be allways the same „read only“ system. When you use savefolder, you can also be without a fear if you use pupsave backup feature.

[williams2]

When you first try Puppy, it's good to make a boot cd/dvd or usb flash drive.

You can automatically save changes to a save file, or, if you have a linux partition, to a save dir/folder.

You can easily backup the save space, and start again with a new save space if you like.

After some experimentation, maybe after some weeks or months, if you are still interested in Puppy, you might want to install Puppy to your hard drive. It won't run better, but you wouldn't need to boot from a cd/dvd or usb flash drive.

I have not bothered to install Puppy on my hard drive. To boot Puppy, I plug in my flash drive, press F9 to get the boot manager, and select booting the flash drive. I chose which Puppy I want to boot, and when the initrd is loaded (about 1 second) I unplug the flash drive. The flash drive acts like a key.

At this point, you might like to configure Puppy to run in ram, with a save file or save dir, so that no changes will be saved unless you explicitly save the changes to the save space.

If you've run Puppy for a while, and still like it, you could remaster Puppy, which basically saves your changes in the save file/folder to the Puppy .sfs file. Then you can have a clean empty save file/folder.

In addition to remastering the Puppy sfs file, or instead of remastering the Puppy sfs file, you could save changes to an adrv.sfs file. When you save changes in the save file/folder to an adrv.sfs file, you are remastering the adrv.sfs file the same way as remastering the Puppy sfs file. The adrv.sfs file could be much smaller than the (remastered, or not) Puppy sfs file.

If you remaster the Puppy sfs file, and /or if you remaster an adrv.sfs file, either way, you can boot as a live cd/dvd/usb, without a save file/folder, and it will be setup the way you like, and it will boot the exact same way each time, no changes will have been made. Unless you chose to make changes.

[JASpup]

There is nothing wrong with using a savefile, I just think one should keep it very small (some would disagree with me) if you are going to use one.

What is the design function of the adrv? (i.e., Why was it created?)

Why does, say, an alt-windows manager land in a ydrv instead?

The message for the mass Puppy audience is install any apps you want and save them to a pupsave (with soft hints about conserving).

My biggest concerns are what gets loaded into ram, and the possibility of data corruption. If save apps are read from media squash, not loaded into ram, then a pupsave seems fairly safe so long as you have full control over saves.

I have modest utilities, but the big hog in several of my pupsaves is Chromium. It's probably the least friendly browser to install. I would just as soon take it out and have the utilities I use like encfs and xfce terminal+app finder as static parts of the system.

[ozsouth]

@JASpup - adrv & ydrv can usually contain whatever you wish. The idea is flexibility. adrv is loaded last, so it makes sense to have personalisation there, if at all. Some devs have constructed these specifically (Fossapup; ScPup64) however, so care is needed. I also edited initrd.gz & DISTRO_SPECS to allow more drives (xdrv initially, then others) for more flexibility.

[JASpup]

When you first try Puppy, it's good to make a boot cd/dvd or usb flash drive.

You can automatically save changes to a save file, or, if you have a linux partition, to a save dir/folder.

You can easily backup the save space, and start again with a new save space if you like.

After some experimentation, maybe after some weeks or months, if you are still interested in Puppy, you might want to install Puppy to your hard drive. It won't run better, but you wouldn't need to boot from a cd/dvd or usb flash drive.

I only run Puppy from USB. The reason is I don't want to alter the boot partitions of Windows machines. I spend so much time customizing, I'll boot another distro instead of jumping through hoops trying to get one distribution to do everything I want.

For compatibility, I stick with save files on FAT partitions. I have not found files limiting.

I have not bothered to install Puppy on my hard drive. To boot Puppy, I plug in my flash drive, press F9 to get the boot manager, and select booting the flash drive. I chose which Puppy I want to boot, and when the initrd is loaded (about 1 second) I unplug the flash drive. The flash drive acts like a key.

Intermediate. USB is my first priority. Inserted it boots, not internal hd boots. USB could change your boot manager even if the os are on your HD. Even with USB 3.0, I don't see how Puppy could be loaded from USB in one second. I'm going to watch the boot sequence more carefully to see if I can see initrd.

At this point, you might like to configure Puppy to run in ram, with a save file or save dir, so that no changes will be saved unless you explicitly save the changes to the save space.

Puppy booting evolves. Tahr expects terminal commands. Xenial has a nice simple menu for choosing ram or save, etc. Even if you choose save, you can choose the specific save or ram still if you have more than one savefile.

If you've run Puppy for a while, and still like it, you could remaster Puppy, which basically saves your changes in the save file/folder to the Puppy .sfs file. Then you can have a clean empty save file/folder.

I used to stumble around with remasters before I knew what I was doing. If I do it again, it will be after extensively simplifying the JWM menu system.

In addition to remastering the Puppy sfs file, or instead of remastering the Puppy sfs file, you could save changes to an adrv.sfs file. When you save changes in the save file/folder to an adrv.sfs file, you are remastering the adrv.sfs file the same way as remastering the Puppy sfs file. The adrv.sfs file could be much smaller than the (remastered, or not) Puppy sfs file.

Remaster saves changes in Puppy[version].sfs. The adrv is similar but a different layer. Got it. What then is the ydrv?

If you remaster the Puppy sfs file, and /or if you remaster an adrv.sfs file, either way, you can boot as a live cd/dvd/usb, without a save file/folder, and it will be setup the way you like, and it will boot the exact same way each time, no changes will have been made. Unless you chose to make changes.

Most of this I understood, failing the simple step of how to make an adrv and how its contents differ from other sfs layers.

[JASpup]

@JASpup - adrv & ydrv can usually contain whatever you wish. The idea is flexibility. adrv is loaded last, so it makes sense to have personalisation there, if at all. Some devs have constructed these specifically (Fossapup; ScPup64) however, so care is needed. I also edited initrd.gz & DISTRO_SPECS to allow more drives (xdrv initially, then others) for more flexibility.

But XFCE or LXQt should be in a ydrv?

There's the option to load specific SFS at boot, so the initial choices should be sufficient for intermediate users.

[williwaw]

some flavors can load a sfs on the fly and others load a sfs at boot time. you could put chromium in a sfs and choose accordingly if you did not want to load it automatically each time

[JASpup]

some flavors can load a sfs on the fly and others load a sfs at boot time. you could put chromium in a sfs and choose accordingly if you did not want to load it automatically each time

You bolster my point. Where are all the Chromium SFS? How easy is it to make one?

I would love to make a 32 Chromium 65 SFS (or newer if possible) for Tahr, but for the effort I just boot Xenial and run 87.

Chromium on Tahr would be dead for me if it weren't for 666philb.

[williwaw]

Where are all the Chromium SFS?

on the old forum you could find links to some repos with older versions, maybe even a portabalized one

How easy is it to make one?

nick gave greengeek some pointers @
viewtopic.php?p=12983#p12983

[williams2]

I don't see how Puppy could be loaded from USB in one second

When I boot Puppy from a usb flash drive, in legacy boot mode, it copies the first 512 bytes of the flash drive to ram and executes the instructions.
Which is, to copy the syslinux boot loader program from the hard drive to ram, and execute it.
Syslinux finds the syslinux.cfg file and displays a menu. I usually press enter to select the default option (boot BionicPup64 pfix=ram)
This copies vmlinuz (the kernel) and initrd.gz (the initial ram drive, a tiny Puppy Linux which finds the sfs files and mounts the layered file system.)

It is the copying of vmlinuz and initrd.gz to ram that takes about 1 second. After the 1 second or 2 to copy vmlinuz and initrd.gz to ram, I can unplug the flash drive, it's done it's job of starting Puppy, it is not needed anymore.

The boot loader starts vmlinuz executing, and vmlinuz starts initrd.gz executing. Which finds the sfs files (on my hard drive) and copies them to ram and mounts them and mounts an aufs layered file system. Then runs init to start the real Puppy.

failing the simple step of how to make an adrv and how its contents differ from other sfs layers.

You would probably run a script written by amethyst, maybe nicOS-Utility-Suite viewtopic.php?p=12983#p12983
I haven't run any remaster scripts other than my own.

My script is simple, basically:

copy pup_a/ files to tmp
copy pup_rw/ files to tmp
mksquashfs

The lines in my script that do this are:

Code: Select all

rsync -av /initrd/pup_a/ /tmp/a1
rsync -av --exclude=.wh.* /initrd/pup_rw/ /tmp/a1

cd /tmp/a1
rm -rf .dbus .cache .thumbnails .XLOADED
rm -rf lib/modules
rm -f etc/DISTRO_SPECS
rm -f etc/rc.d/PUPSTATE

cd /tmp/
mksquashfs a1 out.sfs

The rm lines delete things that are unecessary, and makes the sfs file smaller.
There are 32 lines in my script, but these 3 lines do most of the work.
Some of the other lines are more rm instructions, and some cd instructions etc etc.

EDIT: I added cd instructions to the script, in case someone tries to execute it. Those few lines are just the main part. The script is not intended to be run. I have a slightly different script for Xenial and for Fossapup.

[JASpup]

When I boot Puppy from a usb flash drive, in legacy boot mode, it copies the first 512 bytes of the flash drive to ram and executes the instructions.
Which is, to copy the syslinux boot loader program from the hard drive to ram, and execute it.
Syslinux finds the syslinux.cfg file and displays a menu. I usually press enter to select the default option (boot BionicPup64 pfix=ram)
This copies vmlinuz (the kernel) and initrd.gz (the initial ram drive, a tiny Puppy Linux which finds the sfs files and mounts the layered file system.)

I think I'm reading not even your bootloader is on your USB, USB simply tells UEFI to look for it, begging the question: What purpose is your USB serving?

Still not sure if bootloader and os files are on your internal hd, why do you need USB inserted for it? Complete execution of the instruction?

The nic utility looks like a combination of SFS functions which could be useful. The latter function in question is making a browser SFS from pet and dependencies. Not sure which selection that would be:

[amethyst]

When I boot Puppy from a usb flash drive, in legacy boot mode, it copies the first 512 bytes of the flash drive to ram and executes the instructions.
Which is, to copy the syslinux boot loader program from the hard drive to ram, and execute it.
Syslinux finds the syslinux.cfg file and displays a menu. I usually press enter to select the default option (boot BionicPup64 pfix=ram)
This copies vmlinuz (the kernel) and initrd.gz (the initial ram drive, a tiny Puppy Linux which finds the sfs files and mounts the layered file system.)

I think I'm reading not even your bootloader is on your USB, USB simply tells UEFI to look for it, begging the question: What purpose is your USB serving?

Still not sure if bootloader and os files are on your internal hd, why do you need USB inserted for it? Complete execution of the instruction?

The nic utility looks like a combination of SFS functions which could be useful. The latter function in question is making a browser SFS from pet and dependencies. Not sure which selection that would be:

The suite does not include a .pet to sfs converter. You can extract the contents of a .pet to a folder with UExtract and then build an sfs from the contents of the folder with PackIt.

[amethyst]

There is nothing wrong with using a savefile, I just think one should keep it very small (some would disagree with me) if you are going to use one.

What is the design function of the adrv? (i.e., Why was it created?)

Why does, say, an alt-windows manager land in a ydrv instead?

The message for the mass Puppy audience is install any apps you want and save them to a pupsave (with soft hints about conserving).

My biggest concerns are what gets loaded into ram, and the possibility of data corruption. If save apps are read from media squash, not loaded into ram, then a pupsave seems fairly safe so long as you have full control over saves.

I have modest utilities, but the big hog in several of my pupsaves is Chromium. It's probably the least friendly browser to install. I would just as soon take it out and have the utilities I use like encfs and xfce terminal+app finder as static parts of the system.

See this post: viewtopic.php?p=16630#p16630

[amethyst]

Some of my posts disappeared from this thread????

[wiak]

Some of my posts disappeared from this thread????

Not sure if accurate, but I checked the moderator logs and they claim you deleted the posts. Are you sure you didn't accidentally click the X at these posts (which would result in their deletion - albeit with a warning so seems unlikely). See screenshot attached.

wiak

[amethyst]

Some of my posts disappeared from this thread????

Not sure if accurate, but I checked the moderator logs and they claim you deleted the posts. Are you sure you didn't accidentally click the X at these posts (which would result in their deletion - albeit with a warning so seems unlikely). See screenshot attached.

wiak

The screenshot shows three deleted posts. I deleted two posts then did another post with an attachment which were published but later disappeared. I also unsuccessfully tried to post with Opera Mini earlier. There was some problem.

[Feek]

Remaster saves changes in Puppy[version].sfs. The adrv is similar but a different layer. Got it. What then is the ydrv?

Here is information from the old forum about the notionally content of puppy modules from gyro:
https://oldforum.puppylinux.com/viewtopic.php?p=906486

--------------------------------------------------------
#48 Post by gyro » Sat 04 Jun 2016, 01:43

The sfs's end up in the stack in this order from the top down:
1) adrv - notionaly an "application" layer
2) ydrv - notionaly a "fix" layer
3) pupsfs - the main puppy sfs from the iso
4) fdrv - notionaly a "firmware" layer
5) zdrv - notionaly a "driver" layer

6) Any "extra" sfs's loaded with sfs_load.

So both adrv and ydrv cover the main pupsfs and so can be used to update it.
The fdrv is under the main pupsfs but covers zdrv and so can be used to update it.
Any "extra" sfs's cannot update any system sfs's.

Note1: In woof-ce puppies the fdrv and zdrv contain files that do not exist in the main pupsfs, (so it doesn't matter that they are below it).
Note2: The save layer is always above any sfs's, so a ".pet" can update any sfs.

gyro
--------------------------------------------------------

As ozsouth wrote adrv and ydrv can contain anything you wish. Plus to know a little what are the relationships between the layers.

[rockedge]

@amethyst I looked over the logs and all 3 where deleted at 2:01, 2:04, 2:05 by the author. I am a bit concerned about the post with the attachment disapearing. I wonder if the attachment became "orphaned" and was purged? Don't know yet...dealing with a major license certificate problem with our main server...which now seems to be resolved and fixed.

[JASpup]

The suite does not include a .pet to sfs converter. You can extract the contents of a .pet to a folder with UExtract and then build an sfs from the contents of the folder with PackIt.

I've gotten that far, less manually with other utils. What I haven't been able to do is grab all the required dependencies for a working Chromium SFS.

chromium-browser_65.0.3325.181 [32]

I think I'm understanding: the HUGE difference between an adrv and a pupsave is the latter isn't loaded default into ram, hence an adrv is no better place for browsers.

I've been symlinking browser configs on media, but I think what I want, at the expense of ram, is to copy a static config each session, yet only if I intend to use the browser, similar to how we'll only load SFS if we intend to use them.

The real coup would be getting 32 Chromium 65 standalone, as a UK stalwart has a recent unGoogled 64 Chromium standalone. The last 32 Chrome needs options, but it runs well standalone. For me this is more an aptitude than use challenge, as I can adjust to later distros for newer browsers.

Legacy computing begs this type of ram conservation.

[amethyst]

@amethyst I looked over the logs and all 3 where deleted at 2:01, 2:04, 2:05 by the author. I am a bit concerned about the post with the attachment disapearing. I wonder if the attachment became "orphaned" and was purged? Don't know yet...dealing with a major license certificate problem with our main server...which now seems to be resolved and fixed.

What do you mean by the attachment becoming "orphaned"?

[amethyst]

The suite does not include a .pet to sfs converter. You can extract the contents of a .pet to a folder with UExtract and then build an sfs from the contents of the folder with PackIt.

I've gotten that far, less manually with other utils. What I haven't been able to do is grab all the required dependencies for a working Chromium SFS.

chromium-browser_65.0.3325.181 [32]

I think I'm understanding: the HUGE difference between an adrv and a pupsave is the latter isn't loaded default into ram, hence an adrv is no better place for browsers.

I've been symlinking browser configs on media, but I think what I want, at the expense of ram, is to copy a static config each session, yet only if I intend to use the browser, similar to how we'll only load SFS if we intend to use them.

The real coup would be getting 32 Chromium 65 standalone, as a UK stalwart has a recent unGoogled 64 Chromium standalone. The last 32 Chrome needs options, but it runs well standalone. For me this is more an aptitude than use challenge, as I can adjust to later distros for newer browsers.

Legacy computing begs this type of ram conservation.

The adrv will copy to RAM by default if you have enough RAM. However if you choose the pfix=nocopy parameter it won't copy to RAM. Why do you want to make the Chromium sfs an adrv? Load it as an extra sfs file. You can include your "static" browser configuration in the browser sfs.

[JASpup]

Why do you want to make the Chromium sfs an adrv? Load it as an extra sfs file. You can include your "static" browser configuration in the browser sfs.

I don't. I want Chromium out of the pupsave, which would mean SFS (which I'd have to learn to make) or better standalone. That's a good idea, start repacking SFS with my configurations. It appears they're always magically generated if they do not already exist.

[amethyst]

Why do you want to make the Chromium sfs an adrv? Load it as an extra sfs file. You can include your "static" browser configuration in the browser sfs.

I don't. I want it out of the pupsave, which would mean SFS or better standalone. That's a good idea, start repacking SFS with my configurations. It appears they're always magically generated if they do not exist.

So you still using a savefile. Why don't you just move the browser configuration out of the puppy file system (out of the savefile) to your puppy folder partition and symlink it back to its location of origin? That way it will not occupy savefile space.

[rockedge]

@amethyst I mean that there is a control panel for orphaned attachments. Now if you want me to stop what I am doing to fix the freaking certificate problems that will crash everything in about an hour, I will go an investigate and research the reasons and causes of orphaned attachments in phpBB.

Once a day I see if there are any...if so I delete them. I will learn more about the cause and effect for you AFTER the license and certificate problems are completely sorted out. If not this will all stop dead in it's tracks, and you don't need to worry about it anymore.

[JASpup]

Why don't you just move the browser configuration out of the puppy file system (out of the savefile) to your puppy folder partition and symlink it back to its location of origin? That way it will not occupy savefile space.

Because even though the system benefits from having it out of ram, it will be saved modified wherever it's stored. It has to renew every time, in ram or on media.

I guess I'd have to pull the config each boot before creating the symlink and put it in ram via script.

[amethyst]

@amethyst I mean that there is a control panel for orphaned attachments. Now if you want me to stop what I am doing to fix the freaking certificate problems that will crash everything in about an hour, I will go an investigate and research the reasons and causes of orphaned attachments in phpBB.

Once a day I see if there are any...if so I delete them. I will learn more about the cause and effect for you AFTER the license and certificate problems are completely sorted out. If not this will all stop dead in it's tracks, and you don't need to worry about it anymore.

No, I was just curious what you are talking about. I was wondering if I didn't delete that post with the attachment by mistake although I'm quite sure I didn't. BTW - I ran to some other posting problems earlier on when using Opera Mini. I replied to posts quoting the other user. What happened is that my post was published with the other user's quotation but without my replied text field. Strange.

[amethyst]

Why don't you just move the browser configuration out of the puppy file system (out of the savefile) to your puppy folder partition and symlink it back to its location of origin? That way it will not occupy savefile space.

Because even though the system benefits from having it out of ram, it will be saved modified wherever it's stored. It has to renew every time, in ram or on media.

I guess I'd have to pull the config each boot before creating the symlink and put it in ram via script.

The browser will write new stuff to its folder when in use during a session. The only way to discard this, is not to save it. So either, run without a savefile or with a savefile but not saving your session (providing the browser configiration/cache is in the running filesystem). Personally, I don't mind the continual browser changes, I just clear the browser cache every now and then (it's also set to a size limit). My browser stuff is moved out of the running filesystem as mentioned. You can add your initial browser configuration to your browser extra sfs as suggested (no need to load it to RAM first).