Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 25 Apr 2018, 16:19
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Announcements
Rationalisation of init
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 6 of 6 [88 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6
Author Message
amigo

Joined: 02 Apr 2007
Posts: 2641

PostPosted: Sat 30 Jul 2016, 04:29    Post subject:  

When passing boot parameters, anything not recognized by the kernel itself is passed unchanged. The same happens with the 'init' program --the real one I mean, not the puppy init script. It also ignores anything it doesn't recognize. The params are not set into the environment but are available from /proc/cmdline.
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1490
Location: Brisbane, Australia

PostPosted: Mon 01 Aug 2016, 13:03    Post subject:  

The puppy init script picks up boot parameters by name.
So if you don't get the parameter name correct, then init script will never know about it.
gyro
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1490
Location: Brisbane, Australia

PostPosted: Tue 02 Aug 2016, 13:33    Post subject:  

One more question:
I understand that the latest losetup does not support all the crypto stuff in the current init.
If that is so, do I take this oportunity to introduce new crypto stuff e.g. ecryptfs?
Or do I simply port the crypto stuff from the current init?

gyro
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1490
Location: Brisbane, Australia

PostPosted: Thu 25 Aug 2016, 17:15    Post subject:  

Some folk have noticed that sometimes /initrd/tmp/bootinit.log contains messages from losetup complaining about some sfs's being of incorrect length.
I can confirm that if the 32 byte IDSTRING is removed from the end of these sfs files, losetup no longer complains.

Note: The new init does no use these IDSTRING's anyway.

gyro
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1490
Location: Brisbane, Australia

PostPosted: Wed 31 Aug 2016, 10:45    Post subject:  

The new init is not a clone of the old init.

Concepts:

The init script should as simple as possible, basically build an aufs stack and get out of there.
So, search for files only if it can't be avoided, and stop as soon as we've found it.
Only wait for usb storage, if it's actually needed.

Move complexitiy out of init to places where the full system is available.
So, processing of extra sfs's is gone, left to sfs_load.

For the sfs files, we know the name of the file we are looking for and the directory we are lookinng in,
so their presence can be established with a simple [ -f ] test.

Build the stack one file at a time, so if there's a problem with one of them we just continue without it.
Current testing is just for being non-zero size, [ -s ] test.
Extra integerity testing could easily be included if the necessary utility was included in initrd.gz.
Of course if it's the main puppy...sfs, we abandon the boot.

A normal frugal install consists of a single directory containing all the necesary files.
So, find the directory that contains puppy...sfs by name, and use the files in it. Don't search for vmlinuz or use DISTRO_IDSTRING.

Any other setup is an exception, any exceptions should be specified with a boot parameter.
(Support for SAVEMARK, initmodules.txt, and underdog.inx files, should ideally be removed.)

Provide extremely flexible boot parameter specification facilities so that virtually any exception can be covered.

Since boot parameters might be considered a bit exotic for some users. Provide an alternate that can be supported from a utility in the running system.
So, include "/BOOT_SPECS" file contained in initrd.gz. The file contains variable definitions, these can be used to override the variables that would otherwise be set by boot parameters.
Could include SAVEPART, PIMOD, or UNDERDOG variables. Of course any init variable could be set. In testing I use it to set TZ to my time zone.
Still needs a utility for the running system to edit a copy of the file and then merge it into initrd.gz. We already have the software technology to do this.
Ideally this could be complex enough to present the user with a series of checkboxes for pfix parameters, or a file selector to generate a PSAVE variable.

Yes, this won't help anyone booting from a cd, but maybe that's on the decline and booting from a writeable device like a usbstick or usbhd is becomming the external boot device of choice.
Although it might be possible to do something with an "open" cd, along similar lines to the "copy folders", I'm not inclined to spend the effort there.


What it does support:

Message translation for non-english puppies using a locale file of messages.
Booting in pupmode 5,6,7,12,13,77
Support for specifying partitions as a name, label, or uuid.
Logs if a specified file is not found.
Save layer upgrading
Savefolder
Savefile and savefile resizing
Encrypted savefile, but this should possibly be removed because current losetup does not support it.

gyro
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2641

PostPosted: Wed 31 Aug 2016, 14:29    Post subject:  

"basically build an aufs stack and get out of there" That is the definition of what should happen in the *initrd*. The real init should be just that sysvinit with nice flexible shells scripts which setup things in the normal way, using fstab to mount the entries -using real mount.

Study the simple init process of any real slackware distro. Most distros have replaced all the sysvinit stuff with systemd which is much less flexible.

There should be no GUI stuff during bootup -if anything (for running 'Live') use the dialog utility. Keep it spare with any questions to the user during bootup -rather wait until the desktop is up and provide setup utils there for network, etc.
Back to top
View user's profile Send private message 
greengeek


Joined: 20 Jul 2010
Posts: 4945
Location: Republic of Novo Zelande

PostPosted: Wed 31 Aug 2016, 15:28    Post subject:  

gyro wrote:
Yes, this won't help anyone booting from a cd, but maybe that's on the decline and booting from a writeable device like a usbstick or usbhd is becomming the external boot device of choice.
Although usb and HDD booting is by far the most common approach I would highlight use of CD booting as the only real method by which a normal user can emulate a ROM boot - by which I mean that the code loaded into ram is pristine and unchanged each boot.

Both usb and HDD are writable media and can't be 100% relied on if the user wants identical boots each time, and also wants session changes dumped.

A closed CD is (as far as I am aware) unwritable and an extremely useful method to ensure reproducability of performance.

If we had some method of producing ROMs into which we could burn our favourite puppy we wouldnt need CDs but in the meantime i would love to see acceptance of optical media continued if possible.
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1490
Location: Brisbane, Australia

PostPosted: Wed 31 Aug 2016, 17:47    Post subject:  

@greengeek,

It seems to me that fewer and fewer new computers have optical drives.

But, I actually intended that paragraph to refer to the previous paragraph, i.e. the as yet unwritten utility that supports the /BOOT_SPECS file and so exposing boot parameters via a gui app. This utility wouild merge an updated version of the file into the initrd.gz of the running system. Much more complicated to do with a cd/dvd, than a writable device, and hence more likely to not get done.

gyro
Back to top
View user's profile Send private message 
sheldonisaac

Joined: 21 Jun 2009
Posts: 717
Location: Philadelphia, PA

PostPosted: Sat 02 Dec 2017, 15:13    Post subject: the new init  

gyro, please excuse; I'm just a user, not an expert.

Over the last several months, I've seen mentions of "the new init".

How can I tell whether a Puppy has this new init?

What are the main ways it works differently from older ones?

Thank you,
Sheldon Isaac

Oh, here's some info from the Puppy I'm in now, musher0's simplified Xenial:
Code:
uname -a
Linux puppypc2261 4.1.2-EmSee-32-pae #1 SMP Wed Jul 15 12:39:34 BST 2015 i686 i686 i686 GNU/Linux

Code:
ls -lat /sbin/init /initrd/pup_ro2/sbin/init  /initrd/init
-rw-r--r-- 1 root root 54996 Dec  2 02:47 /initrd/init
-rwxr-xr-x 1 root root 10013 Oct 18 20:09 /initrd/pup_ro2/sbin/init
-rwxr-xr-x 1 root root 10013 Oct 18 20:09 /sbin/init

_________________
Dell E6410: Xenial, etc
Dell Mini 9, Acer Aspire One, EeePC 1018P, PowerBook G4
Intel D865GBF, Intel DQ35JOE
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1490
Location: Brisbane, Australia

PostPosted: Mon 11 Dec 2017, 10:33    Post subject: Re: the new init  

sheldonisaac wrote:
How can I tell whether a Puppy has this new init?
The existence of files "/initrd/init" and "/initrd/tmp/HAVE_PARTS" would indicate that you have it.
Modern puppies built using woof-ce "testing" have it.

sheldonisaac wrote:
What are the main ways it works differently from older ones?
There are lots. If you really want to know then please read the preceeding posts in this thread.
But some are:
Internal algorithm is very different.
Has better support for internationalisation.
Extra-sfs's are now solely the responsibility of "sfs_load".
Better support for using boot parameters to specify the puppy sfs files to load.
Support for saving onto a partition other than the puppy frugal install partition.

gyro
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5087
Location: Arizona, U.S.A.

PostPosted: Sun 14 Jan 2018, 20:45    Post subject:  

Hello. I posted a thread asking for removal of flash drive boot code.
New flash drives ( USB & SD ) last about as long as H.D.s now.

http://www.murga-linux.com/puppy/viewtopic.php?p=980258#980258
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 848

PostPosted: Sun 14 Jan 2018, 22:31    Post subject:  

sunburnt wrote:
Hello. I posted a thread asking for removal of flash drive boot code.
New flash drives ( USB & SD ) last about as long as H.D.s now.

http://www.murga-linux.com/puppy/viewtopic.php?p=980258#980258


That's only if you have a USB 3.0 connection. Many people here run older hardware. For me even the old USB boot code doesn't wait long enough. See thread:

Tahrpup Can't find Save folder on Large USB Hard Drive

Also note that if one connects many USB devices to a HUB they won't get USB 3.0 speed.
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5087
Location: Arizona, U.S.A.

PostPosted: Mon 15 Jan 2018, 05:24    Post subject:  

Or a new boot code to force the pupmode.

pupmode=
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 6 of 6 [88 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Announcements
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0717s ][ Queries: 15 (0.0242s) ][ GZIP on ]