I've read a thread here about this conversion which was about re-mastering. Needless to say, I didn't understand a lot of it. My main intention is to run puppy with pfix=ram. Unfortunately this means having to supply the usual xorg parameters each time, and, if you want to access the internet, using something basic or do an install. I don't want to do a multi-session DVD or create a permanent pupsave. It occurs to me that with the load SFS-on-the-fly facility I could keep to pfix=ram and add in different collections of installed pets, depending on what I intended to do for the session. I looked for a convert pupsave to sfs but could not find one.
Any help or suggestions would be appreciated.
Converting pupsave to sfs
Converting pupsave to sfs
LxXenial16.08, LxPupSc17.07.01,Lucid 5.2.8 and others - all frugal
Luki023 (Saluki) has adrv.sfs and zdrv.sfs and may be a good candidate for what you require.
Slacko 5.9.3 has zdrv.sfs and is being developed.
However, the HOW 2 make it work evades me.
There must be a guide somewhere.
Slacko 5.9.3 has zdrv.sfs and is being developed.
However, the HOW 2 make it work evades me.
There must be a guide somewhere.
[b]Asus[/b] 701SD. 2gig ram. 8gb SSD. [b]IBM A21m[/b] laptop. 192mb ram. PIII Coppermine proc. [b]X60[/b] T2400 1.8Ghz proc. 2gig ram. 80gb hdd. [b]T41[/b] Pentium M 1400Mhz. 512mb ram.
Hi wimpy,
Re-mastering with the in-built "re-master Puppy live CD" program isn't hard once you know where to click "yes" and where to click "no". I've just saved a PC from a dumpster and Lupu 5.11 runs well on it. I intend to do the re-master thing in the next couple of days and will make step-by-step notes of the process, which I will post on this Thread.
Re-mastering with the in-built "re-master Puppy live CD" program isn't hard once you know where to click "yes" and where to click "no". I've just saved a PC from a dumpster and Lupu 5.11 runs well on it. I intend to do the re-master thing in the next couple of days and will make step-by-step notes of the process, which I will post on this Thread.
If it's not Backed-Up, then it isn't really yours.
You just think it is.
You just think it is.
The problem with remastering is that you end up with a new pup.sfs that is named the same as the original pup.sfs. It's confusing and shouldn't be necessary. I like wimpy's idea of making an sfs from the 2fs or 3fs savefile. I tried it once myself but unfortunately without success.
Surely someone must have succeeded with this?
(I think the problem is that puppy layers an sfs UNDERNEATH the main puppy sfs, whereas it layers a savefile ABOVE the main sfs. You cant just turn a 2fs into an sfs because it won't sit at the correct level within the layered filesystem)
Surely someone must have succeeded with this?
(I think the problem is that puppy layers an sfs UNDERNEATH the main puppy sfs, whereas it layers a savefile ABOVE the main sfs. You cant just turn a 2fs into an sfs because it won't sit at the correct level within the layered filesystem)
The layering bunny ...
one method was to swap the names of a zdrv and the main sfs...IF zdrv is use. There is a (erm)drv.sfs option for some pups that supposed to be on top....thats all I know.
to make the sfs from save you use mksquashfs...BUT if the pup is running in X then .xloaded is a problem....you also usually filter out certain folders like /proc . If its a one off do it from a pfix=ram session .
My save sfs does not end up as a layer but is copied back into the pup_rw tmpfs layer.... but could just as easily be an extra layer....but you need something which fits in with standard puppies and that where the head scratching comes in due to the way things are done.. There are several threads on this buried on the forum.
Which is why remastering is a common suggestion...at least thats IS an option thats available even though it seems like overkill.
mike
one method was to swap the names of a zdrv and the main sfs...IF zdrv is use. There is a (erm)drv.sfs option for some pups that supposed to be on top....thats all I know.
to make the sfs from save you use mksquashfs...BUT if the pup is running in X then .xloaded is a problem....you also usually filter out certain folders like /proc . If its a one off do it from a pfix=ram session .
My save sfs does not end up as a layer but is copied back into the pup_rw tmpfs layer.... but could just as easily be an extra layer....but you need something which fits in with standard puppies and that where the head scratching comes in due to the way things are done.. There are several threads on this buried on the forum.
Which is why remastering is a common suggestion...at least thats IS an option thats available even though it seems like overkill.
mike
Ok there is some info on it somewhere... but think of layers of glass with various symbols on them... stack them on top of each other and look down...you only see the topmost symbol if there is more than one and that's how you get the final picture... in pup is the same but with files/filesystems
mike
mike
Re-mastering Puppy
The following describes how I re-mastered a Puppy 5.2.8.6 installation, using the in-built “Re-master Puppy live CD
If it's not Backed-Up, then it isn't really yours.
You just think it is.
You just think it is.
Re: Re-mastering Puppy
[quote="Latitude"]The following describes how I re-mastered a Puppy 5.2.8.6 installation, using the in-built “Re-master Puppy live CD
hi nic007,
the reason I merged /etc into /tmp/etc was I noticed that, while my running /etc folder was 2.4 MB, the /tmp/etc folder created by the program was 3.5 MB. I was afraid that if I deleted /tmp/etc and copied in my running /etc folder to replace it, I would be losing 1.1 MB of data.
As dodgy as my method may be, it seems to have worked and I haven't lost any settings at all in the re-master. But your script sounds like it would be more user-friendly, so I'll give it a go next time.
the reason I merged /etc into /tmp/etc was I noticed that, while my running /etc folder was 2.4 MB, the /tmp/etc folder created by the program was 3.5 MB. I was afraid that if I deleted /tmp/etc and copied in my running /etc folder to replace it, I would be losing 1.1 MB of data.
As dodgy as my method may be, it seems to have worked and I haven't lost any settings at all in the re-master. But your script sounds like it would be more user-friendly, so I'll give it a go next time.
If it's not Backed-Up, then it isn't really yours.
You just think it is.
You just think it is.
Just for your interest:
Replacing /tmp/etc with content of /etc from the running system probably will make the system unable to boot properly on different computers with different hardware as well as on the machine used to remaster when replacing some hardware of this machine, like e.g. Graphics Card etc.pp.
Replacing /tmp/root with /root will include all of your private data into the new system, if there is any private data in /root - so be careful on this.
I recommend not to replace /tmp/etc and/or /tmp/root.
Instead extracting the packages that are installed into the new system and copying the /etc and /root directories from these extracted/installed packages manually to /tmp/etc and /tmp/root when remastering. On the next remaster these directories and files are copied pristine into the new system, so there isn't any future manually copying needed for these directories and files - except one needs to keep some modifications of these directories and files at a next remaster.
Replacing /tmp/etc with content of /etc from the running system probably will make the system unable to boot properly on different computers with different hardware as well as on the machine used to remaster when replacing some hardware of this machine, like e.g. Graphics Card etc.pp.
Replacing /tmp/root with /root will include all of your private data into the new system, if there is any private data in /root - so be careful on this.
I recommend not to replace /tmp/etc and/or /tmp/root.
Instead extracting the packages that are installed into the new system and copying the /etc and /root directories from these extracted/installed packages manually to /tmp/etc and /tmp/root when remastering. On the next remaster these directories and files are copied pristine into the new system, so there isn't any future manually copying needed for these directories and files - except one needs to keep some modifications of these directories and files at a next remaster.
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
My suggestion is indeed for a quick and robust, personalized, customized remaster on your own machine. If that is not your aim, you can actually use the built-in script with no changes to tmp/root and tmp/etc although in that case the built-in program may not include bigger installations like WINE for example (which is normally installed to /root with a frugal install). So be wary of that too.
Hi wimpy, I'm no expert on layering - in fact it is something that I only started to understand recently when I saw Barry Kaulers description about how puppy is designed.wimpy wrote:I'll just have to keep looking and reading. I wasn't aware of the concept of layers, until now.
I recommend having a look at his descriptions here.
In particular there are some good diagrams about a quarter of the way down the page which illustrate the relative priorities of different layers. An understanding of this is quite important if the user is to take a savefile (top layer) and convert it into an sfs (bottom layer)
I think there are moves underway at the moment to make the official "CE Puppy" more capable of reflecting a personal sfs as the top layer (liike a savefile) but don't quote me on that as I am only watching from the fringes. I've been working on my own methods to achieve the same thing you described, but I'm still trying to grasp the concepts more fully.
I feel it should be easier than it currently is...
