Avoid "Searching for Puppy files" during bootup - revisited
Avoid "Searching for Puppy files" during bootup - revisited
This has been inspired by Wognath's topic by a very very similar name, http://www.murga-linux.com/puppy/viewtopic.php?t=99212.
In particular his comment "The idea is that once Puppy has been run, all the info found in the Searching... section is recorded in PUPSTATE."
However I've implemented the concept in a rather different way, hence the different topic.
The most significant difference is that the "init" script is patched from the start.
Version 3:
Withdrawn, continued as version4.
Version 4:
It continues to work just like the standard "init" until you specify a "nosearch" boot parameter. e.g "nosearch=sda3:/tahr/tahrsave.2fs".
Then it uses the specified file/directory as the savefile/savefolder, bypasses the "Searching for Puppy files" code, and includes the "/etc/rc.d/PUPSTATE" file from the savefile/savefolder, thus setting all the relevant variables that are usually set via the "Searching for Puppy files" code.
At least 1 boot must be done with the savefile/savefolder in place to ensure that "PUPSTATE" is appropriately setup, before the "nosearch" boot parameter is specified.
The "init" script will revert to normal processing, if the "nosearch" boot parameter is removed, or "pfix=ram" is specified.
So if you want to add a ydrv, move the ydrv file into the frugal install directory, reboot without the "nosearch" parameter, reboot with the "nosearch" parameter.
Version 5:
Withdrawn, could not work with usb devices.
Version 6:
Same as version 5 but fixed to work with usb devices.
Searching for puppy files is avoided if a "nosearch" boot parameter specifies the partition containing a copy of the file "PUPSTATE" in the frugal install directory, e.g. "nosearch=sda3".
See later post for version 5 for more info.
You don't need to patch the "init" script yourself, you only need a patched "initrd.gz" for your particular puppy.
This has been tested in pupmode=12.
It should work in pupmode=13, and might work in pupmode=6 and pupmode=7.
Patched "initrd.gz" files for tahrpup 6.0.2 are available here:
noPAE: initrd_nosearch_nopae.gz
PAE: initrd_nosearch_pae.gz
Edit: these have been withdrawn, they crash if the specified file does not exist.
Please use version 4.
Edit: Uploaded version 4 of patch. A major rewrite to avoid extra mount and umount.
Patched "initrd.gz" files for tahrpup 6.0.2 are available here:
noPAE: http://www.fishprogs.software/puppy/tah ... nopae-4.gz
PAE: http://www.fishprogs.software/puppy/tah ... h_pae-4.gz
Edit: version 5
A major rewrite to simplify the code.
Edit: version 6
Fixed to work with usb devices.
Patched "initrd.gz" files for tahrpup 6.0.2 are available here:
noPAE: http://www.fishprogs.software/puppy/tah ... nopae-6.gz
PAE: http://www.fishprogs.software/puppy/tah ... h_pae-6.gz
Download, rename to "initrd.gz", move to frugal install directory, reboot.
I have also attached a gziped patch file for the "init" script in "initrd.gz".
Download, gunzip to produce "init.nosearch-6.diff", extract "init" from "initrd.gz", patch "init" with "init.nosearch-6.diff", re-compress "initrd.gz" containing patched "init", reboot.
gyro
In particular his comment "The idea is that once Puppy has been run, all the info found in the Searching... section is recorded in PUPSTATE."
However I've implemented the concept in a rather different way, hence the different topic.
The most significant difference is that the "init" script is patched from the start.
Version 3:
Withdrawn, continued as version4.
Version 4:
It continues to work just like the standard "init" until you specify a "nosearch" boot parameter. e.g "nosearch=sda3:/tahr/tahrsave.2fs".
Then it uses the specified file/directory as the savefile/savefolder, bypasses the "Searching for Puppy files" code, and includes the "/etc/rc.d/PUPSTATE" file from the savefile/savefolder, thus setting all the relevant variables that are usually set via the "Searching for Puppy files" code.
At least 1 boot must be done with the savefile/savefolder in place to ensure that "PUPSTATE" is appropriately setup, before the "nosearch" boot parameter is specified.
The "init" script will revert to normal processing, if the "nosearch" boot parameter is removed, or "pfix=ram" is specified.
So if you want to add a ydrv, move the ydrv file into the frugal install directory, reboot without the "nosearch" parameter, reboot with the "nosearch" parameter.
Version 5:
Withdrawn, could not work with usb devices.
Version 6:
Same as version 5 but fixed to work with usb devices.
Searching for puppy files is avoided if a "nosearch" boot parameter specifies the partition containing a copy of the file "PUPSTATE" in the frugal install directory, e.g. "nosearch=sda3".
See later post for version 5 for more info.
You don't need to patch the "init" script yourself, you only need a patched "initrd.gz" for your particular puppy.
This has been tested in pupmode=12.
It should work in pupmode=13, and might work in pupmode=6 and pupmode=7.
Patched "initrd.gz" files for tahrpup 6.0.2 are available here:
noPAE: initrd_nosearch_nopae.gz
PAE: initrd_nosearch_pae.gz
Edit: these have been withdrawn, they crash if the specified file does not exist.
Please use version 4.
Edit: Uploaded version 4 of patch. A major rewrite to avoid extra mount and umount.
Patched "initrd.gz" files for tahrpup 6.0.2 are available here:
noPAE: http://www.fishprogs.software/puppy/tah ... nopae-4.gz
PAE: http://www.fishprogs.software/puppy/tah ... h_pae-4.gz
Edit: version 5
A major rewrite to simplify the code.
Edit: version 6
Fixed to work with usb devices.
Patched "initrd.gz" files for tahrpup 6.0.2 are available here:
noPAE: http://www.fishprogs.software/puppy/tah ... nopae-6.gz
PAE: http://www.fishprogs.software/puppy/tah ... h_pae-6.gz
Download, rename to "initrd.gz", move to frugal install directory, reboot.
I have also attached a gziped patch file for the "init" script in "initrd.gz".
Download, gunzip to produce "init.nosearch-6.diff", extract "init" from "initrd.gz", patch "init" with "init.nosearch-6.diff", re-compress "initrd.gz" containing patched "init", reboot.
gyro
- Attachments
-
- init.nosearch-4.diff.gz
- gunzip to produce file "init.nosearch-4.diff"
- (1.62 KiB) Downloaded 325 times
-
- init.nosearch-6.diff.gz
- gunzip to produce file "init.nosearch-6.diff"
- (714 Bytes) Downloaded 369 times
Last edited by gyro on Wed 19 Aug 2015, 14:11, edited 11 times in total.
In my system with 2 disks and 6 partitions $pupsave is 2900-3200msec (depending on mode and partition) faster that the normal init.
One issue that you may want to fix is that it crashes the system if savefile/folder is not found (renamed, misspelled etc). You may want to add a condition that the file/folder/partition exists.
One issue that you may want to fix is that it crashes the system if savefile/folder is not found (renamed, misspelled etc). You may want to add a condition that the file/folder/partition exists.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
Once again gyro doing what should have been done in the first place
fair play to yer ...
Puppy has a pile of boot options ending up pretty much with the slax approach of configuring the system from the vmlinuz line rather than guessing what it is... so it might as well accept that this is how it is and.... erm stop guessing... give it a profession feel eh and yes sooo much faster... in my case if it IS guessing it limits how much of that is done which at least saves time... guessing is really for first boots and quick tests rather than installed systems after all.
mike
fair play to yer ...
Puppy has a pile of boot options ending up pretty much with the slax approach of configuring the system from the vmlinuz line rather than guessing what it is... so it might as well accept that this is how it is and.... erm stop guessing... give it a profession feel eh and yes sooo much faster... in my case if it IS guessing it limits how much of that is done which at least saves time... guessing is really for first boots and quick tests rather than installed systems after all.
mike
I make no claims about the speed benefit. I just wanted to prove it could be done another way.mavrothal wrote:In my system with 2 disks and 6 partitions $pupsave is 2900-3200msec (depending on mode and partition) faster that the normal init.
Thanks, good catch. Yes, in all my testing I always got it right.mavrothal wrote:One issue that you may want to fix is that it crashes the system if savefile/folder is not found (renamed, misspelled etc). You may want to add a condition that the file/folder/partition exists.
Not as simple as it would seem, since no partition mounted at the time the decision is made, but It should be possible, I'll hopefully get back with an updated patch.
My site is currently down, so I probably won't have replacement "initrd.gz" files.
gyro
Last edited by gyro on Fri 26 Jun 2015, 13:04, edited 1 time in total.
And they are also missing any checks, so typos result in broken systemsgyro wrote:the "pupsfs", "zdrv", "adrv" and "ydrv" boot parameters that are already in "init".
I guess a test_presence() should be setup to to verify the parameters are valid though this may defy the speed up purpose.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
updated patch to init.nosearch-2.diff
I've updated the patch to "init.nosearch-2.diff".
This now checks if the specified savefile/savefolder exists on the specified partition, before skipping "Searching" code.
If the file is not found it writes an error message to the console, and continues on to "Searching" code.
Mounting and umounting a partition just to test the existence of a single file, seems a bit excessive, but that's the obvious way. The decision has to be made before the "Searching" code, (where partitions get mounted).
@mavrothal
The technosaurus parameters setup some variables and then continue into the "Seraching" code, so maybe the testing for the existence of the file could be delayed till after the partition is mounted, but before any "find" commands.
I have not done any testing of these other parameters.
gyro
This now checks if the specified savefile/savefolder exists on the specified partition, before skipping "Searching" code.
If the file is not found it writes an error message to the console, and continues on to "Searching" code.
Mounting and umounting a partition just to test the existence of a single file, seems a bit excessive, but that's the obvious way. The decision has to be made before the "Searching" code, (where partitions get mounted).
@mavrothal
The technosaurus parameters setup some variables and then continue into the "Seraching" code, so maybe the testing for the existence of the file could be delayed till after the partition is mounted, but before any "find" commands.
I have not done any testing of these other parameters.
gyro
Re: updated patch to init.nosearch-2.diff
Yes they all break the installation.gyro wrote: @mavrothal
The technosaurus parameters setup some variables and then continue into the "Seraching" code, so maybe the testing for the existence of the file could be delayed till after the partition is mounted, but before any "find" commands.
I have not done any testing of these other parameters.
The following patch works for me, though we could delay the $file.sfs definitions for after ALLPARTS is recorded so the propepart_init call can be avoided. Though as is is not a major delay.
Code: Select all
--- a/init 2015-06-26 18:23:04.840026666 +0300
+++ b/init 2015-06-26 18:20:52.070017775 +0300
@@ -599,12 +599,22 @@
[ $PSUBDIR ] && [ "`echo -n "$PSUBDIR" | cut -c 1`" != "/" ] && PSUBDIR="/${PSUBDIR}" #add leading /.
+test_presence() {
+ FILEEXISTS=''
+ PARTITION="$(echo "$1" | cut -f1 -d ':')"
+ FILETOCHECK="$(echo "$1" | cut -f2 -d ':')"
+ FSTYPE=$(probepart_init -k| grep "$PARTITION" | cut -f2 -d '|')
+ mount -t $FSTYPE /dev/$PARTITION /mnt/data
+ [ -e /mnt/data/$FILETOCHECK ] && FILEEXISTS="true"
+ umount /mnt/data
+}
+
#100915 requested by technosaurus (formats get changed further down)...
-[ $pupsfs ] && PUPSFS=$pupsfs #format partition:<path><filename> ex: sda2:/wary071/wary_071.sfs
-[ $zdrv ] && ZDRV=$zdrv #ex: sda2:/wary071/zdrv_071.sfs
-[ $adrv ] && ADRV=$adrv
-[ $ydrv ] && YDRV=$ydrv
-[ $pupsave ] && PUPSAVE=$pupsave #format partition:<path><filename> ex: sda2:/wary071/warysave.2fs
+[ $pupsfs ] && test_presence $pupsfs && [ "$FILEEXISTS" = "true" ] && PUPSFS=$pupsfs #format partition:<path><filename> ex: sda2:/wary071/wary_071.sfs
+[ $zdrv ] && test_presence $zdrv && [ "$FILEEXISTS" = "true" ] && ZDRV=$zdrv #ex: sda2:/wary071/zdrv_071.sfs
+[ $adrv ] && test_presence $adrv && [ "$FILEEXISTS" = "true" ] && ADRV=$adrv
+[ $ydrv ] && test_presence $ydrv && [ "$FILEEXISTS" = "true" ] && YDRV=$ydrv
+[ $pupsave ] && test_presence $pupsave && [ "$FILEEXISTS" = "true" ] && PUPSAVE=$pupsave #format partition:<path><filename> ex: sda2:/wary071/warysave.2fs
[ $underdog ] && UNDERDOG=$underdog #120130 specify partition for Underdog Linux (refer also underdog.lnx).
Oh well I think all $file.sfs need fixing and my patch is for all of them
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
Re: updated patch to init.nosearch-2.diff
If you look at the code for these right at the beginning of the "Searching" section you will see that some of the decoding is already done.mavrothal wrote:though we could delay the $file.sfs definitions for after ALLPARTS is recorded so the propepart_init call can be avoided. Though as is is not a major delay.
But I want to play with moving the checks even further down into the code that already mounts the partitions.
I thing that it would be nice to have checks for the the sfs file parameters anyway, even if we never bother seriously implementing the "pupsave" parameter.
gyro
OK.gyro wrote: I'll try my idea tomorrow.
Another concern is the psavemark. In this case we have to make sure that main sfs etc are still found properly when pupsave is defined (though I just looked at the code to see if/how your change may affect this. Did not tested it)
Yes I had seen this though I believe is recorded to /tmp logs at a latter pontgyro wrote:If you look at the code for these right at the beginning of the "Searching" section you will see that some of the decoding is already done
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
Well i never found the mount unmount routine to be significant in time usage.... the use of find and multilevel searches followed by rationalizing the resultant pile of info on the other hand was a big hit ..way slower than the original use of ls <pattern match> .
After all the init goes through a myriad of hoops just to generate the pupsave variable...so why not supply it and save the trip.
mike
ps...I did wonder how grub searches and find files....but probably not something we could use for this ... find... set kernel parameter idea....
After all the init goes through a myriad of hoops just to generate the pupsave variable...so why not supply it and save the trip.
mike
ps...I did wonder how grub searches and find files....but probably not something we could use for this ... find... set kernel parameter idea....
Another little issue is that $pupsave works fine when savefile/folder is in another disk. In this case /mnt/home is a broken link. Adding psavemark is useless in this case.
BTW savefile/folder is in another partition of the boot disk works fine for /mnt/home, with of without psavemark.
Some code should be added so either pupsave should not be allowed in another disk or /mnt/home also consider safefile/fodler drive in addition to partition.
I think the latter is better.
BTW savefile/folder is in another partition of the boot disk works fine for /mnt/home, with of without psavemark.
Some code should be added so either pupsave should not be allowed in another disk or /mnt/home also consider safefile/fodler drive in addition to partition.
I think the latter is better.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
It makes coding way way easier if one works on the basis that an install is located in one place rather than scattered over several devices...that one grew out of the live CD usage and a lack of comfortable booting options and has stuck even though methods have moved on/improved.
I don't have floppies and only have an external DVD writer now for starters...and my gear is old. A superfloppy zip drive... never even seen one.
Mike
I don't have floppies and only have an external DVD writer now for starters...and my gear is old. A superfloppy zip drive... never even seen one.
Mike
The basic assumption is that the user all (s)he wants is to use their machine with no hassle what so ever and no idea of its inner workings and requirements are.mikeb wrote:It makes coding way way easier if one works on the basis that an install is located in one place rather than scattered over several devices...that one grew out of the live CD usage and a lack of comfortable booting options and has stuck even though methods have moved on/improved.
There are mini-distros that require you to define a number of cryptic, complex and precise options to boot, and this is perfectly fine. Puppy, to keep true to its goals, should rather give the ability of "cryptic, complex and precise boot options" if you want to use them, but still be forgiving and relaxed about them.
BTW the /mnt/home issue is not as bad as originally reported. Is only the first time that has an issue. Then it behaves better. Still needs to be looked at though.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
hmm i found the puppy 2 approach fulfilled that requirement quite nicely and 4+ meant an increasing number of confusing boot parameters and a complex init script with quirky hbehaviour.. As a noob I found puppy 2 straightforward. Hence the interest in gyros re-evaluation of the boot methods in use....bit of a pet subject ..no pun intended.The basic assumption is that the user all (s)he wants is to use their machine with no hassle what so ever and no idea of its inner workings and requirements are.
Anything to streamline and keep user friendly is welcome.
mike