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

Under development: PCMCIA, wireless, etc.
Message
Author
User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#21 Post by 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.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#22 Post by 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
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#23 Post by 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
Attachments
SauvPerso-0.1.pet
First pet for this script. Supersedes the bz2 archive below.
(3.08 KiB) Downloaded 255 times
SauvPerso.tar.bz2
Goes in /root/my-applications/bin. The wrapper should have a link in /root/Startup.
(2.22 KiB) Downloaded 222 times
Last edited by musher0 on Mon 17 Feb 2014, 22:10, edited 2 times in total.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
Puppus Dogfellow
Posts: 1667
Joined: Tue 08 Jan 2013, 01:39
Location: nyc

#24 Post by Puppus Dogfellow »

greengeek wrote: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).

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#25 Post by 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
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#26 Post by musher0 »

Hello.

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

Thanks.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
dejan555
Posts: 2798
Joined: Sun 30 Nov 2008, 11:57
Location: Montenegro
Contact:

#27 Post by 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.
puppy.b0x.me stuff mirrored [url=https://drive.google.com/open?id=0B_Mb589v0iCXNnhSZWRwd3R2UWs]HERE[/url] or [url=http://archive.org/details/Puppy_Linux_puppy.b0x.me_mirror]HERE[/url]

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#28 Post by 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
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
dejan555
Posts: 2798
Joined: Sun 30 Nov 2008, 11:57
Location: Montenegro
Contact:

#29 Post by 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.
puppy.b0x.me stuff mirrored [url=https://drive.google.com/open?id=0B_Mb589v0iCXNnhSZWRwd3R2UWs]HERE[/url] or [url=http://archive.org/details/Puppy_Linux_puppy.b0x.me_mirror]HERE[/url]

gcmartin

This thread indirectly educates use, along with the benefit

#30 Post by 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
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#31 Post by 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...) :roll:

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
Ted Dog
Posts: 3965
Joined: Wed 14 Sep 2005, 02:35
Location: Heart of Texas

#32 Post by 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..

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#33 Post by 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
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#34 Post by musher0 »

Ted Dog wrote: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?
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
Ted Dog
Posts: 3965
Joined: Wed 14 Sep 2005, 02:35
Location: Heart of Texas

#35 Post by Ted Dog »

he = gcmartin
:shock:

User avatar
Ted Dog
Posts: 3965
Joined: Wed 14 Sep 2005, 02:35
Location: Heart of Texas

#36 Post by Ted Dog »

most of the intermediary work will be done in fatdog64. proof of concept demonstrated of technology etc.

but I plan to bootstrap the methodology and hopefully just build a general remaster of existing puppylinux spin to make it happen.

If it continues to evolve as its planned hopefully no new separate puppylinux spins would be required. I do not like to support another DINO (distinct in name only ) we have way too many already and its a problem for those new and old to puppy.

But it will be a significant change In storing speedup and saving puppylinux data. But if successful the puppylinux spin will never know any difference. IE Quirky6s will still be unmodified with a brief loader change and a way of saving backups that use the matching change in the preloader.

bill
Posts: 490
Joined: Wed 28 May 2008, 15:32

Is there a way to deploy a pupsave at first boot in frugal?

#37 Post by bill »

Very interesting concept you are researching Ted Dog,another Texas home boy :) I can well understand why you wish to " deploy a pupsave at first boot in frugal" as it could eliminate any confusion to a new user who burns a .ISO and it would be good to go on first boot.I am basically trying to do the same thing only adding a readme.txt file to be carried to a remastered "Custom Puppy" . I do know you can convert a "pupsave.2fs" to a "pupsave.sfs" using mksquashfs then remastering this .sfs to the Custom.iso but now how you get this pupsave.sfs to autoload I don't have a clue.If I come up with something I will post you.I'm looking :roll:

It's a shame BK has left the building :cry:

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#38 Post by mikeb »

Some have used zdrv code to load an sfs of a save but I just modified the initrd ...in the former case its still remains a read only config.

I just have it loaded to the pup_rw

mike

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#39 Post by musher0 »

Hi, bill.

Hmm... Your understanding is different. I mean "deploy an empty pupsave file at first
boot." I believe you are talking about the regular Puppy process of loading an already
created pupsave file during the boot process.

As to loading any sfs file, in recent Puppies, there's a utility in the menu called "sfs-load-
on-the-fly" or similar title.

Not to mention the clever tricks resident magician mikeb always has up his sleeve! :)

I guess I'll have to change the title. Sincere thanks for indirectly pointing it out and
making this thread more focused.

BFN.

musher0
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#40 Post by mikeb »

ooops yes a little derailment but the topic does bring in quite a bit of related material.
I would stick with your original concept which is making things preconfigured in a user friendly way for save file users as its a good one.

mike

Post Reply