How do we deploy an empty pupsave at 1st boot in frugal?

[mikeb]

Maybe I need new glasses, but I couldn't find anything close to the subject in the
Nimblex docs

pretty sure it was a boot option in extended boot menu... but don't quote me.

mike

have fun with the init...

[musher0]

Hello, people!

On the other hand, there is a way to put a pupsave-create script in /root/Startup that is
executed only if you do not have a pupsave file. It could end with a "reboot", and there
you go, you have a 100 % chance of getting your pupsave file created on 1st boot.

On 2nd boot, this script is ignored and you've got a flaming new frugal Puppy all ready
for you.

So maybe fiddling with the init is not necessary. The above is less elegant, but it does
the job.

BFN.

musher0

[mikeb]

I would think rc.sysinit would be a better idea.... indeed thats where creating a swap file used to occur ....suppose you want a shiny gui for it though

Auto or manual its like the slax way of create a file and use on reboot which works just fine...

mike

[technosaurus]

Its been a while since I tried it, but the process went something like:

1. use dd to create a file full of zeroes using /dev/zero as the input file
2. format the file to your filesystem (ext2,3,4 for puppy, but it could be others)
3. use bzip2 to compress the file (it works the best for zero-files)
4. repeat steps 1-3 for different save file sizes
5. modify init to bunzip one of the image files to the save file location if one isn't found (feel free to add boot parameters for this)

^6... if you have time, remove all of the insane crap dealing with the old, stupid way

NOTE: Using bzip an empty multiple gigabyte filesystem compresses down to a couple kb and decompression to disk is extremely faster than generating the filesystem on the fly. ... of course this will take more time up front for whoever does it, but it will make the Puppt experience much better thereafter.

[amigo]

"remove all of the insane crap dealing with the old, stupid way" HeHe, that means starting with a completely blank filesystem in the case of puppy.

[greengeek]

I feel that every puppy should boot into ram as a default (rather than requiring pfix=ram) and that it should ask during the boot process if the user intends to continue as live only, or intends to create a savefile and keep the puppy.

Maybe as follows:
1) If no savefile currently exists boot as Live only
2) Ask the user if they definitely want to create a savefile, or if they want to pick up a savefile from elsewhere (bring up a file manager to find it...), or if they want to delay their choice till later. (some value in offering a small basic savefile maybe? 32 or 64MB for starters maybe?)
3) Carry on with the boot.

It has always struck me as odd that the newby user has to understand the value of pfix=ram long before there is any way for them to know what the heck it even means.

[mikeb]

Well the slax way of setting in the boot parameter the save mode used and whether to go to x or not does make for a very simple non quirky boot process.
The default therefore is eqivalant to a pfix=ram session with vesa video.

I just compromised and simplified the choose at shutdown and guess at boot method for pups which is more akin to the version 2 approach which was significantly simpler, less quirky and faster. The archive save method is also much faster than creating a save file since only new data is stored which might be as low as a few hundred k for a first run.

I also changed the first run shutdown to default to do nothing with a 8 second time out...ie no save config ...especially handy if the framebuffer presents you with a blank terminal.

mike

[musher0]

Many thanks for your interest, guys.

Hopefully we can offer a friendly solution to all newbies on this important item.

Here's something alpha. It's not an "init" solution. Rather, you'd link the wrapper in
/root/Startup. You'll see that there a "0" un-tested section for when the Puppy would be
started from CD, hence this script is still in alpha.

Feel free to chew over it and suggest your own improvements or alternatives.

Many brains are better than one!

BFN.

~~~~~~~~~~~
EDIT, Feb. 17, 2014 -- I've attached an update, v. 01, as a pet attachment.
This one checks the PUPSTATE, and proceeds from there. In other words,
it offers the choice NOT to create a pupsave if the user wants to use Puppy
in multisession mode from CD/DVD.

I'll call it a "beta1" version, since it does the job well, but there is still room to
grow, for ex. by incorporating some of the interesting suggestions elsewhere
on this page.

Also, the problem remains: if the user gets stuck creating his/her pupsave
with BK's script, how do we tell her/him that there is an alternative?

BTW, tested on Precise 5.7.1-retro. YMMV, and if so, I'd appreciate knowing
about it.

Anyway, it's a step in the right direction, and as long as we put one foot after
the other, there's progress!

BFN.

musher0

[Puppus Dogfellow]

I feel that every puppy should boot into ram as a default (rather than requiring pfix=ram) and that it should ask during the boot process if the user intends to continue as live only, or intends to create a savefile and keep the puppy.

Maybe as follows:
1) If no savefile currently exists boot as Live only
2) Ask the user if they definitely want to create a savefile, or if they want to pick up a savefile from elsewhere (bring up a file manager to find it...), or if they want to delay their choice till later. (some value in offering a small basic savefile maybe? 32 or 64MB for starters maybe?)
3) Carry on with the boot.

It has always struck me as odd that the newby user has to understand the value of pfix=ram long before there is any way for them to know what the heck it even means.

that sounds great. would make it easier to move around save files (i find they'e not always found) when needed.

which brings up something i've been wondering about. if you move a save file onto a f2fs partition, is it on the media as f2fs and in ram as the ext(s) commonly offered? does the format of the virtual file system matter much?

anyway, it would be great to be able to reinstall new/old puppies to use with various save files whenever and wherever. and that does sound a bit cleaner for first boot--just add the options for full save and frugal save to partition (still not exactly sure that those two are in fact not the same thing).

[mikeb]

which brings up something i've been wondering about. if you move a save file onto a f2fs partition, is it on the media as f2fs and in ram as the ext(s) commonly offered? does the format of the virtual file system matter much?

the format within the save file is totally independant of the format of the partition it resides on which is why such as NTFS can be used. (some may chime in with journalling stipulations but that depends on whether you believe theory or practise)
Bear in mind of course that the kernel in question has to have support for whatever partition you wish to subject it to.

The format within tends to matter in terms of reliability ..at least in terms of the features offered buy ext2, ext3 and unjournalled ext4.
Not standard for puppy, but such as reiserfs and XFS could be used as well as long as its posix compliant.

mike

[musher0]

Hello.

I've updated the script. Please see above,
http://murga-linux.com/puppy/viewtopic. ... ost#758938

Thanks.

[dejan555]

I had a script back on puppy 3.x and 4.x series to make blank pupsave, should still work but naming of pupsave maybe needs change and formating of pupsave

http://www.murga-linux.com/puppy/viewtopic.php?t=43553

Maybe something will be usefull, don't remember fully how it's coded anymore.

[musher0]

Thanks, dejan555.

I did preliminary research before I started this project, and I was aware of the
suggestions on your thread. Result : I started the project anyway!

If I remember correctly, your initial proposal was sound, but the following "simple
pupsave" procedure proposed by ASRI and RSH, etc., was not precise enough, IMO,
and I felt it was not "battle-ready"... The options were not focused enough, the user
needed something more closely adapted to the actual Puppy he or she is on.

My script above is not as pretty, it has only a terminal interface, but it goes right to
the point in sequential fashion. For the creation of such a fundamental function as
the pupsave, the new user does not need to be offered multiple bewildering options at
once in a panel.

Most of them are really newbies and they will not know how to handle those options or
what is supposed to come before or after. My script does not draw question marks
above the user's head: it simply asks the user to put one foot in front of the other until
the job is done.

Sorry to be so frank, and if the tone seems a bit harsh. I will obviously welcome any
constructive criticism or improvement suggestions for my script coming from an
experienced Puppy-ist such as yourself. PM me if you wish.

BFN.

musher0

[dejan555]

Sounds good to me, I just linked to code in case you needed to pull out some commands out of it, I know it's old and yes I remember that user needed to know exact location where to put files which might indeed be confusing for newbies.

[gcmartin]

I am clear on the approach offered in this thread. It is sound and makes good sense in what it offers. Thus, any user, on first boot, can have all system/subsystem changes saved in real-time versus at the end of user's session at shutdown.

This, in essense, provides protection for system in event of a sudden system lockup or power outage or...

In addition to this on-going work, there is another ripple in the water, also occurring. @Ted Dog has been making good progress where he is extending the SAVE-SESSION Process to create same-similar to what occurs, today, for multi-session users. His offering has importance as it saves user's work in chunks (called multi-sessions) just as is done on CD/DVD disc. Value of his effort is that should you have a session that got it wrong, you could eliminate that session using simple techniques or reboot.

Together, this makes for advances in boot process as well as advances in their ability to assist in user's work and system stability.

If there is a way to combine both of these into a solid foundation for Puppy developers use as they build distro that the community of users use, it benefits all.

Here to help

[musher0]

Thanks gcmartin "from Earth" for your comments. I grew up in the same
neighbourhood!

As to Ted_Dog's save-session research, do you mean the one he's pursuing on the
new Quirky 6, here:
http://murga-linux.com/puppy/viewtopic. ... t=lastpost ?

Thanks in advance.

It would interesting indeed to see if the two approaches can be paired.

For now, though, I am looking for a sure-fire way to incorporate this new pupsave-
creation script in the simplest and most efficient manner possible for the user.

Early on, I swore that I'd never put a Puppy derivative together because there are
already too many, but now I'm at the point where maybe I'll have to, to test correct
incorporation of this script in Puppies generally. Chucks! (My medieval buddy
Ockham won't like it...)

BFN.

[Ted Dog]

I think he was. But most of the idea to make compressed saved data and reload is taken from FATDOG64 since you do NOT need to use optical drives but anything usb hardrive etc.
I like the input you are getting on this thread and hope some of the brain trust hope over to my thread since while title describes the purpose of my thread the how and why methods does mirror this thread so I can see why gcmartin dropped the linkage..
We are both addressing the same type of problem and methods discussed would fix both.
I should have the new Fatdog64 630 rebuilt to support the speed issues used in its version of multisession. He has already added the flags and code to run full install directly in RAM. He did not go all the way as I suggested.
I will drop some code there and here so you can better follow how the ideas are nearly the same..

[mikeb]

Yes i have had sfs saves that load into ram since puppy 2.12 so can verify this system works nicely (3 years is a good test) and to me suits the nature of the way puppy is structured. It does away with mode 13 which has problems of its own and save files in general and also for usb installs means the drive can be removed during running but still have the benefit of persistent storage.
The only alternative I find is using a save folder (mean all fits on one partition and can be shared with other frugals) which is good for heavier usage and/or when ram is limited though i do include swap space for tmpfs which does give more leg room.

Along with that and ability to load to ram and used large numbers of sfs files these are features which have been proved and would be nice to be available for a wider user base rather than having to use derivatives.

mike

[musher0]

I think he was. But most of the idea to make compressed saved data and reload is taken from FATDOG64 since you do NOT need to use optical drives but anything usb hardrive etc.
I like the input you are getting on this thread and hope some of the brain trust hope over to my thread since while title describes the purpose of my thread the how and why methods does mirror this thread so I can see why gcmartin dropped the linkage..
We are both addressing the same type of problem and methods discussed would fix both.
I should have the new Fatdog64 630 rebuilt to support the speed issues used in its version of multisession. He has already added the flags and code to run full install directly in RAM. He did not go all the way as I suggested.
I will drop some code there and here so you can better follow how the ideas are nearly the same..

Euh... who's this mysterious he, please?

[Ted Dog]

he = gcmartin