Rationalisation of init
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.
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
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
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
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
"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.
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.
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.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.
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.
@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
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
-
- Posts: 902
- Joined: Mon 22 Jun 2009, 01:36
- Location: Philadelphia, PA
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:
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
Intel DQ35JOE, Dell Vostro 430
Dell Inspiron, Acer Aspire One, EeePC 1018P
Re: the new init
The existence of files "/initrd/init" and "/initrd/tmp/HAVE_PARTS" would indicate that you have it.sheldonisaac wrote:How can I tell whether a Puppy has this new init?
Modern puppies built using woof-ce "testing" have it.
There are lots. If you really want to know then please read the preceeding posts in this thread.sheldonisaac wrote:What are the main ways it works differently from older ones?
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
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
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: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
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.