Trying to understand how/where modifications to Puppy are stored

[smithsa]

I'm building a project and am looking for an OS platform and Puppy Linux looks perfect.

What I'd like to do is take the base system, modify it for my project's needs, create an ISO from that and make that available to others. I want my users to burn the ISO onto a USB, put it into their computers and run it without any installation. The users are rather unsophisticated, so the simpler the system is, the better. Puppy Linux looks perfect for the job.

Here's what I've tried:

1. I took a copy of the base system and burned it to USB1. I did it with Rufus and created a persistent area.

2. I booted USB1 on Computer1. It came up quickly and beautifully.

3. I installed Chrome and deleted a few icons from the desktop.

3. I used /usr/sbin/remasterpup2 to create a custom ISO.

4. I wrote this custom ISO onto USB2. I did it with Rufus and created a persistent area.

5. I booted USB2 on Computer1. It came up Chrome installed and the modified desktop. Much excitement ensued.

6. I shut down Computer1 and booted USB2 on Computer2. It came up, but my customizations were not there. No Chrome and no desktop modifications, just a clean base system.

Okay, so now I'm confused. Where are these changes being written? Are they written to the USB? To the persistent area? Is the persistent area even meaningful? Why did Computer2 come up without the changes?

What do I need to do so that my changes are seen regardless of which computer I plug the USB into?

[mikewalsh]

@ smithsa:-

Hallo, and welcome to the new forum.....which we're all still getting the hang of.

I assume you've been creating along the lines of the "persistence" which Ubuntu and many of its re-spins support. Puppy won't even look at that. She creates her own 'persistent' storage at first shutdown, either a save-file (fixed size, older way of doing things), or a save-folder (newer option, expands/contracts with contents.....up as far as the size of the partition it's created in).

Let Puppy create this when you shut down for the first time, and you should have no problems with saving apps/settings, etc.

Others will expound further upon this, no doubt. Be patient; somebody else will be around before too long.


Mike.

[taersh]

Looks like your persistent area is on internal hard drive at computer 1.
Also, you had probably booted with pfix=ram on computer 2.
If so, then no save file / save folder is loaded at boot.

Assuming you are using Grub4DOS as the boot-loader, the kernel line should look like this for booting with persistent area loaded.

kernel /DiscoDingo/vmlinuz psubdir=DiscoDingo pmedia=usbflash pfix=fsck

[bigpup]

Puppy Linux, as a live install or a frugal install, uses a save file or folder to store any changes, additions, settings, etc...

It does seem you actually have the pupsave on the computer 1 and not on the actual USB drive.

I took a copy of the base system and burned it to USB1. I did it with Rufus and created a persistent area.

Assuming you have everything needed in this so called base system.
The pupsave needs to be on the USB drive when you make it.
If it is.
It should be getting used anytime you boot the usb.

However, there is a boot option pfix=ram, that keeps the pupsave from being used.
I assume you see a boot menu when you boot.
Do not use any menu entry, but the normal boot one. (Should be first entry)
Do not use one that says ram only. That boots not using the save.

To stop guessing.
What exact Puppy base did you use?
Exactly what did you take out and how did you do it?
The USB drive is partitioned how and what format are the partitions?
What boot loader config files are on the USB?
Grub.cfg?
isolinux.cfg?
syslinux.cfg?
I will guess it is using grub.cfg to boot.
Open it in a text editor. Paste what is in it for us to see what your boot options are?

[smithsa]

Okay, first off, I'm very impressed with the amount of help and speed that this community offered with my problem.

I was able to determine that the save file must have been on the hard drive of the host computer. Not sure how it got there but I probably did something wrong. In reality, I'm not even even sure how (or why) the hard drive was even mounted. Maybe I did something really wrong.

So, I started off very cleanly - new version of Bionic Pup running on a host computer where I reinstalled the OS so there would be no old save files. I changed a few things and was very careful when shutting down and the save file was being created. The information in the popups does tend to be fairly wordy and complex and often provides options that I don't understand why anyone would want them.

In any case, I created an ISO from this system, wrote it to a USB and booted on a different computer. I was a bit surprised when Quick Setup started, but I can understand why. The system came up fine with all of my changes and does exactly what I need.

Thanks to everyone for your help.

One additional (uncomfortable) issue: I've been noticing that quite a bit of knowledge seems to be unavailable on murga-linux. I can see that losing John meant losing a real cornerstone of the community. Is there anything we can do to help save that work?

[mikewalsh]

@ smithsa:-

Mm-hm! Puppy does take a little bit of getting used to. Many things in Puppy are done in a unique way.....similar to "mainstream" Linux, but just different enough that it can throw out even Linux veterans....

With regard to the old Murga-Linux forum, there is hope that things can be "retrieved":-

viewtopic.php?p=179#p179

However, we need to be patient. The family must be allowed to complete the grieving process, and to come to terms with what has happened.....and to achieve "closure". Only then, can efforts be set in motion to try and recover access to a decade and a half of valuable information.....


Mike.

[bigpup]

The information in the popups does tend to be fairly wordy and complex and often provides options that I don't understand why anyone would want them.

Puppy Linux has always been about providing information, when you are actually trying to do something.
Puppy Linux has always been about you deciding what to do. Giving choices and you decide.
Very few things will happen, unless you are offered choices and info on what the choices will do.

Sorry but,
WE Are Puppy!
Resistance is futile!
Learn you must!

[cobaka]

The information in the popups tend to be wordy/complex. They often provides options that I don't understand. Why anyone would want them?

I find the pop-up pup-'elps/instructions "about right".
That was especially true when I installed 'da Pup' for the first time.

[marinewonder]

Hello,

I wanted to post a follow-up question since I'm in a similar, probably worse boat and not quite sure where the problem is. This is with Bionic Puppy Live CD.

1. On a computer with no storage other than the Puppy LIVE USB, I booted Puppy first-time, added an application folder to the root, then shutdown to create a save state during first shutdown.

2. I rebooted Puppy Live and found things set as I wanted and shutdown.

3. I attached a second storage device, and booted up Puppy LIVE USB, confirmed my setttings were all in place, performed operations on the second storage device from within Puppy, all good.

4. I used Setup - Remaster Live Puppy CD, use second storage as work area, it pulls data from the original ISO also on the second storage.

5. During creation it asks if I "want to make zdrv.bionicpup......sfs. the separate driver file", cryptic, but at least "NO" is pre-selected, so I choose NO.

6. Continue with defaults for compression, then it starts to creating file systeme that shows one sort of warning saying it "cannot stat exclude dir/file /lib/modules/4.19.23/initrd because no such file exists, ignoring".

7. Continue with creation of ISO, prompted to make but do not make further changes to any filesystem.

8. I wrote this custom ISO onto USB2. I did it with Rufus.

9. I booted USB2 on Computer1, but it fails to boot with first error: "finding puppy main SFS file: failed". I repeat this with or without a second storage device attached.

I've tried several times just in case the ISO is not copying properly, with the same results.

Thinking step 5 is worth trying with YES, but not sure.

Edit update:

I tried with step 5: YES, it proceeds. Step 6 this time shows error: "cannot stat exclude dir/file /archive because no such file exists, ignoring, but results are the same.

Looking over the contents of the newly created USB, i can see the puppy_bionicpup64_8.0.sfs file clear as day, if that's what it's looking for I don't see how it can't find it.

Some noticed differences:

Only the PuppyLive USB I created this from has the bionicpup64save.3fs fil..... interesting.

Shouldn't at least the save file be part of my remastered ISO? Isn't the process trying to re-create an ISO of the custoimzed Puppy OS?

-MW

[mikewalsh]

@marinewonder :- Hallo....and to the "kennels".

Well, I can't help with the re-mastering stuff, I'm sorry to say. Despite using Puppy for the best part of a decade, I've never once bothered with the re-master process.

I can, however, tell you that with any modern Puppy, the zdrv.sfs is absolutely essential.....because this is where Puppy keeps all the kernel modules. It's the changing of this, together with the vmlinuz, that permits easy swapping of kernels. That much I can tell you.

As for the re-master stuff.....be patient. We have several members who are pretty good with this stuff, and should be able to answer your questions. Someone will be along pretty soon, so hang in there.

Mike.

[marinewonder]

Thanks, yeah.

I'm optimistic, this community seems pretty helpful.

I did try with the ZDRV as the separate driver file: YES, but I got the same result.

I'm obviously missing something really obvious if the OP could get his ISO to boot to the desktop, but he used /usr/sbin/remasterpup2 to create a custom ISO, so I'm going to look at this more later.

-MW

[wizard]

@marinewonder

What version of Rufus? They broke it in v3.18 & newer (for Puppy).

Use Rufus v3.17 portable from here https://www.fosshub.com/Rufus-old.html

wizard

[marinewonder]

Rufus 3.11.1678.

I suppose its possible its too old, so I used 3.17 and had the same result.

Here's a screenshot.

[mikewalsh]

@wizard :-

Isn't this something to do with specifying "usbflash" for the media.....and then it increases the delay time during which it searches for the main Puppy .sfs?

I know how you do that with Grub4DOS. Since I've never, ever used Rufus, I don't know what bootloader mechanism it employs, OR how you'd edit it.

Just a thought that occurred to me, that's all, 'cos I've had the exact same issue myself at various times over the years, and that's the advice that I was given.

Mike.

[wizard]

@mikewalsh
Rufus sets up grub/grub2 entry correctly, but sets pmedia=cd. This does not interfere with booting from the USB. All my remastering is done from internal hdd, OP is using external drives so that may be affecting. Will have to experiment to find out. Why are you not asleep?

@marinewonder

Only the PuppyLive USB I created this from has the bionicpup64save.3fs fil..... interesting.

Shouldn't at least the save file be part of my remastered ISO? Isn't the process trying to re-create an ISO of the customized Puppy OS?

It is, when you remaster, most of the save file is merged into bionicpup64save.3fs

Some things like wallpaper, desktop icons, and others are not retained by the standard remaster script. You have to use a modified procedure to get those.

What is your intention/use for the remaster?

wizard

[marinewonder]

Intention is to create a re-usable ISO that others can use on their computer.

The ISO will include a new tools folder in root that has an application tool I need to run.

I re-did this with a different USB stick, and I no longer get the error, it reached desktop.

But now I'm exactly where the OP was.

None of my customizations kept, no folder in root, except for the ICON removal on the desktop.

It asked for initial language and dispaly setup, and network setup, and had not setup a SAVE state file as it asked to set it up during first exit.

Yet, something got saved in the re-master as it did save my icons?

So, at least I'm past the first issue, but nowhere near where I need to be.

[marinewonder]

I may have a way to work around this, but sure wish this was handled through official methods instead.

I have my customized bootable Puppy Live that has the bionicpup64save file.

I injected this save file into the ISO, and re-burnt the ISO to the USB, viola.

Things came up as expected.

Hope this helps someone.

[wizard]

@mikewalsh

My initial post above about Rufus's grub entry stated it was setup correctly, I have edited it to clarify it is correct in that it does boot from the USB without issue, but pmedia is set to cd (in the Rufus version I use).

@marinewonder

I injected this save file into the ISO, and re-burnt the ISO to the USB, viola.

Good show. That is one way that will work just fine and actually may have some advantages vs. remaster.

wizard

[mikeslr]

There's a better and easier way. Better because its faster. Easier because it avoids a lot of guesses.
Most settings and customizations are stored as hidden files (Left-Click rox's EYE to see them) in /root and subfolders under /root such as /root/.config. During the process of Remaster using the builtin version you have an opportunity to copy files from your /root into the 'work folder'. But even after working with Puppys for a dozen years, doing many remasters and publishing a couple, I still have to guess how to create an Exact duplicate.

The following will work with all Puppys except that with Fossapup* some preparation is needed.

Don't remaster at all.

Download nicOS-Utility-Suite-2022.pet.gz, https://www.forum.puppylinux.com/viewto ... 983#p12983 remove the FALSE gz and click the pet to install it. Run it. You'll see the GUI shown on the above post. Select "5: Save2SFS". You'll be given the choice of whether to create an adrv.sfs or a ydrv.sfs and where to build it. For the latter choose RAM if you have sufficient: its much faster. For reasons I'll explain when I get back choose to create a ydrv.sfs.

The ydrv.sfs created will include all your settings and customizations. Which means before running the application you should consider 'undoing' some. As examples, your wifi password. Another, Geany keeps a record of the files you've opened. Start Geany and open Edit>Preferences>Files. Set it to Zero, and check. Also open LibreOffice and clear recent files.

That's it. Under Bionicpup64 a ydrv_bionicpup64_8.0.sfs will be created. Place it with your other system files and include it in the ISO.

See https://www.forum.puppylinux.com/viewtopic.php?t=5818 for why this works.

With the exception of Fossapup64*, the only reason to remaster is to remove unwanted builtins, and doing that achieves little. See, https://www.forum.puppylinux.com/viewto ... 453#p47453. Much easier to just use radky's Menu Manager to toggle-off the display of unwanted applications.

-----
* I'll explain about Fossapup64 when I get back. Gotta run.

[amethyst]

There's a better and easier way. Better because its faster. Easier because it avoids a lot of guesses.
Most settings and customizations are stored as hidden files (Left-Click rox's EYE to see them) in /root and subfolders under /root such as /root/.config. During the process of Remaster using the builtin version you have an opportunity to copy files from your /root into the 'work folder'. But even after working with Puppys for a dozen years, doing many remasters and publishing a couple, I still have to guess how to create an Exact duplicate.

The following will work with all Puppys except that with Fossapup* some preparation is needed.

Don't remaster at all.

Download nicOS-Utility-Suite-2022.pet.gz, https://www.forum.puppylinux.com/viewto ... 983#p12983 remove the FALSE gz and click the pet to install it. Run it. You'll see the GUI shown on the above post. Select "5: Save2SFS". You'll be given the choice of whether to create an adrv.sfs or a ydrv.sfs and where to build it. For the latter choose RAM if you have sufficient: its much faster. For reasons I'll explain when I get back choose to create a ydrv.sfs.

The ydrv.sfs created will include all your settings and customizations. Which means before running the application you should consider 'undoing' some. As examples, your wifi password. Another, Geany keeps a record of the files you've opened. Start Geany and open Edit>Preferences>Files. Set it to Zero, and check. Also open LibreOffice and clear recent files.

That's it. Under Bionicpup64 a ydrv_bionicpup64_8.0.sfs will be created. Place it with your other system files and include it in the ISO.

See https://www.forum.puppylinux.com/viewtopic.php?t=5818 for why this works.

With the exception of Fossapup64*, the only reason to remaster is to remove unwanted builtins, and doing that achieves little. See, https://www.forum.puppylinux.com/viewto ... 453#p47453. Much easier to just use radky's Menu Manager to toggle-off the display of unwanted applications.

-----
* I'll explain about Fossapup64 when I get back. Gotta run.

Nothing wrong with using the Save2SFS utility but I suggest using the Alternative Remaster script of the utility suite for a genuine remaster. The method (of copying files over) is basically the same as the Save2SFS method BUT whiteout files will be handled correctly, in other words, builtin files which were "deleted" will be excluded in the remaster. You will of course have a new base sfs file in this scenario whereas with the Save2SFS utility your base sfs stays the same. The Save2SFS method is much faster though because it only saves the changes to the system (to a new additional sfs drive) whilst a full remaster reconstructs the base sfs (basically ads the changes to the original base sfs). Also - with a remaster you have an opportunity to choose whether you want to save your current hardware settings or not. The latter is important if you are going to use the system on different machines or distribute it to other people because the Save2SFS method does not have this option.

[mikeslr]

Thanks, amethyst, for spelling out how your Remaster-Alternative differs from your Remaster-Classic and its practical difference with just creating an adrv or ydrv.

I have a question which specifically relates to Fossapup64.

There was often a request for a 'Bare-bones' version of a Puppy: that is, one which would boot to desktop, provide a minimum of applications leaving it to the user to 'flesh the OS out' only with applications of his/her choice. Other devs of Puppys have sometimes included a light-weight browser in an adrv.sfs: enough to get one started. After installing the web-browser of his or her choice, the User could 'ditch' the light-weight browser by deleting the adrv.sfs. But in creating Fossapup64 666philb apparently had the desire for a 'bare-bones' Puppy in mind. Many 'user' applications were located in its adrv.sfs.

Working before wizard published Friendly-Fossa64, https://www.forum.puppylinux.com/viewto ... 902#p43902, I only had three choices (a) delete the adrv.sfs; then 'flesh-out' the bare-bones fossa64; (b) remaster so that the contents of the 'adrv' would be included in puppy_fossapup64_9.5.sfs; or (c) rename the adrv to ydrv and create a new adrv. adrvs have priority over ydrvs. In Puppys 'merge in RAM file system' the adrv is 'loaded' after the 'ydrv'. It's contents will be use if they conflict with those of the ydrv. I tried all three options.

(a) Proved both laborious and resulted in a remaster which I wasn't really pleased with. Ultimately, I settled on (c). But I spent some time doing a remaster. IIRC, I had to do it manually. I knew that the 'builtin' remaster completely ignores adrvs and ydrvs. So does shinobar's Remaster-x. What I did was create a work folder, mount puppy_fossapup64_9.5.sfs, copy its contents into the work folder; then mount adrv_fossapup64_9.5.sfs and copy its contents into the work folder; then dir2sfs [maybe I used packit] the work folder renaming it puppy_fossapup64_9.5.sfs.

Are any of your Remaster versions capable of including the contents of either an adrv or ydrv in the remastered 'base' sfs?

[amethyst]

Are any of your Remaster versions capable of including the contents of either an adrv or ydrv in the remastered 'base' sfs?

Yes, the classic script will include the contents of all loaded sfs's (except the fdrv and zdrv). To exclude any additional drives, you have to boot without it. This is another reason why you should consider which of the two remaster scripts you want to use (one method may work better than the other depending on the contents of your adrv or ydrv).