Rationalisation of init

News, happenings
Message
Author
amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#76 Post by amigo »

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.

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#77 Post by gyro »

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

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#78 Post by gyro »

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

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#79 Post by gyro »

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

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#80 Post by gyro »

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

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#81 Post by amigo »

"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.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#82 Post by greengeek »

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.

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#83 Post by gyro »

@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

sheldonisaac
Posts: 902
Joined: Mon 22 Jun 2009, 01:36
Location: Philadelphia, PA

the new init

#84 Post by sheldonisaac »

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: Select all

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: Select all

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: BusterPup, BionicPup64, Xenial, etc
Intel DQ35JOE, Dell Vostro 430
Dell Inspiron, Acer Aspire One, EeePC 1018P

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

Re: the new init

#85 Post by gyro »

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

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#86 Post by sunburnt »

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/viewto ... 258#980258

s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#87 Post by s243a »

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/viewto ... 258#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.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#88 Post by sunburnt »

Or a new boot code to force the pupmode.

pupmode=

Post Reply