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 Thu 20 Sep 2018, 08:52
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
Avoid "Searching for Puppy files" during bootup - revisited
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 2 of 5 [62 Posts]   Goto page: Previous 1, 2, 3, 4, 5 Next
Author Message
mikeb


Joined: 23 Nov 2006
Posts: 11156

PostPosted: Fri 26 Jun 2015, 13:03    Post subject:  

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....
Back to top
View user's profile Send private message 
mavrothal


Joined: 24 Aug 2009
Posts: 2976

PostPosted: Sat 27 Jun 2015, 04:31    Post subject:  

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.

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 11156

PostPosted: Sat 27 Jun 2015, 04:40    Post subject:  

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
Back to top
View user's profile Send private message 
mavrothal


Joined: 24 Aug 2009
Posts: 2976

PostPosted: Sat 27 Jun 2015, 05:07    Post subject:  

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.

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

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 11156

PostPosted: Sat 27 Jun 2015, 09:51    Post subject:  

Quote:
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.

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.
Anything to streamline and keep user friendly is welcome.

mike
Back to top
View user's profile Send private message 
mavrothal


Joined: 24 Aug 2009
Posts: 2976

PostPosted: Sat 27 Jun 2015, 10:24    Post subject:  

mikeb wrote:
Hence the interest in gyros re-evaluation of the boot methods in use....bit of a pet subject ..no pun intended.
Anything to streamline and keep user friendly is welcome.
Gyro's additions are of course welcome, but they do not change anything in the boot process. They do add another option for a kernel command line argument which is very welcome. We just want to make it as much as possible user friendly and false-tolerant.
_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
gyro

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

PostPosted: Sun 28 Jun 2015, 03:07    Post subject: updated patch to init.nosearch-3.diff  

Updated patch to "init.nosearch-3.diff" see first post for download.

This is a significant rewrite to avoid extra mount and umount.

The code at the beginning of the "Searching" section does not set the "PUPSAVE" variable, rather it just checks that the partition exists and stores data for later.

The decision is now made in the "search_func" after the first partition is mounted.
The variable "LESSPARTS" is modified so that the specified partition is first in the list.
If the specified savefile/savefolder is not found, then normal searching is performed.

@mavrothal,
"psavemark" is irrelevent since that should have been sorted out before "nosearch" is activated, so it is now recorded in "PUPSTATE" and hence gets respected. The idea behind "nosearch" is that you get it all sorted out running normally, until "PUPSTATE" contains all the appropriate information. Then "nosearch" is activated by specifying a "pupsave" parameter.

I don't quite understand the problem with "/mnt/home".
The "pupsave" parameter could be used to choose between multiple savefiles/savefolders but I don't see any use for specifying the savefile/savefolder of another puppy.

Note: I will probably announce "initrd.gz" files for Tahrpup 6.0.2 in the near future. (My site is up again.)
Edit: now done.

gyro

Last edited by gyro on Mon 29 Jun 2015, 22:58; edited 1 time in total
Back to top
View user's profile Send private message 
gyro

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

PostPosted: Sun 28 Jun 2015, 03:45    Post subject:  

Just a thought:
One of the difficulties in implementing "nosearch" by reading "PUPSTATE" from the savefile/savefolder is that the issues of it being a savefile or savefolder, and is the savefile encrypted, have to be sorted before "PUPSTATE" can be read.
It would probably be easier to implement "nosearch" if it were triggered by "pdev1" boot parameter being supplied, and the presence of "${PDEV1}${PSUBDIR}/PUPSTATE".

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

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

PostPosted: Sun 28 Jun 2015, 05:56    Post subject: validating existence of boot parameter sfs files  

@mavrothal,
Here is a patch to check the existence of an "adrv" boot parameter file:
Code:
--- init.orig   2015-06-24 09:52:21.966056508 +1000
+++ init   2015-06-28 19:47:14.014732397 +1000
@@ -473,6 +473,13 @@
     done
    fi
   
+   if [ "$PADRVDEV" = "$ONEDEV" ];then
+    if [ -s "/mnt/data${PADRVSPEC}" ];then
+     ADRVSFS="`basename $PADRVSPEC`"
+     ADRV="${ONEDEV},${ONEFS},${PADRVSPEC}"
+     echo -n " adrive" > /dev/console
+    fi
+   fi
    if [ "$ADRV" = "" ];then
     FND_FILES="`find /mnt/data${PSUBDIR} -maxdepth ${SEARCHDEPTH} -xdev -type f -iname ${ADRVSFS} | grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`"
     for ONEPUPFILE in $FND_FILES
@@ -799,11 +806,13 @@
 fi
 
 if [ "$ADRV" ];then
- DEV="`echo "$ADRV" | cut -f 1 -d ':'`"
- FS="`echo "$PCPARTS0" | grep "${DEV}|" | cut -f 2 -d '|'`"
- SPEC="`echo -n "$ADRV" | cut -f 2 -d ':'`"
- ADRVSFS="`basename $SPEC`"
- ADRV="${DEV},${FS},${SPEC}"
+ PADRVDEV="`echo "$ADRV" | cut -f 1 -d ':'`"
+ if [ "`echo "$PCPARTS0" | grep "${PADRVDEV}|"`" != "" ];then
+  PADRVSPEC="`echo -n "$ADRV" | cut -f 2 -d ':'`"
+ else
+  PADRVDEV=""
+ fi
+ ADRV=""
 fi
 
 if [ "$YDRV" ];then
The idea is to delay checking the file until the "search_func", when a partition is already mounted. A bit like my latest "nosearch" patch.
Obviously the same approach could be applied to the other sfs parameters.

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


Joined: 24 Aug 2009
Posts: 2976

PostPosted: Sun 28 Jun 2015, 11:08    Post subject: Re: validating existence of boot parameter sfs files  

gyro wrote:
@mavrothal,
Here is a patch to check the existence of an "adrv" boot parameter file:[code]-

Looks good.
You may want to send a pull request with the changes.
If you get ti it pls try to include verifications for $zdrv and $pupsfs as well as.
Thx

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
gyro

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

PostPosted: Sun 28 Jun 2015, 19:08    Post subject: Re: validating existence of boot parameter sfs files  

mavrothal wrote:
You may want to send a pull request with the changes.
If you get ti it pls try to include verifications for $zdrv and $pupsfs as well as.
My plan is to implement a full patch that includes all the sfs parameters, and then announce it in a separate topic to give others a better chance of commenting. After all this topic is about "nosearch". Pull request later.

I've simplified the code a bit so it is in only 2 places, where the boot parameters are first processed, and in search_func.

In testing, I liked being able to specify an adrv with the wrong name, and in a different directory.

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


Joined: 24 Aug 2009
Posts: 2976

PostPosted: Mon 29 Jun 2015, 01:54    Post subject: Re: validating existence of boot parameter sfs files  

gyro wrote:
I liked being able to specify an adrv with the wrong name, and in a different directory.

Why adrv only?
Theoretically SFSs can be anywhere as long as they are loaded in RAM. You do not care after that.
You can actually have a small 10MB partition for vmlinuz/initrd/grub(2) and then point to anywhere you want.

One thing that should be checked with the "anywhere" approach is how the system will behave if SFSs are not loaded in RAM either because there is not enough or because they are called with pfix=nocopy and are in different drives.

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
gyro

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

PostPosted: Mon 29 Jun 2015, 03:28    Post subject: Re: validating existence of boot parameter sfs files  

mavrothal wrote:
Why adrv only?
Because that is all I had implemented at the time, as a proof of concept.
mavrothal wrote:
Theoretically SFSs can be anywhere as long as they are loaded in RAM.
The first limitation is which partitions get mounted during the "Loading puppy files" section of "init". See http://www.murga-linux.com/puppy/viewtopic.php?t=100011. Copying to RAM overcomes only the second challenge; which partitions remain mounted.

Please continue any discussion of sfs boot parameters in the other topic.
This topic is about "nosearch".

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

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

PostPosted: Mon 29 Jun 2015, 22:55    Post subject: Updated "initrd.gz" files for version 3 available  

I have uploaded "initrd.gz" files for Tahrpup 6.0.2 for version 3 of the patch.
See the first post for download details.
gyro
Back to top
View user's profile Send private message 
Marv


Joined: 04 May 2005
Posts: 1074
Location: SW Wisconsin

PostPosted: Mon 06 Jul 2015, 11:57    Post subject:  

Tested with and without pupsave kernel parameter in X-tahr-1b2 non-PAE on a core 2 duo laptop and on one of my Bay Trail desktops with the very slow USB flag returns. In these two tests the modified init does just what it is supposed to. Speedup on both systems is the same as my ignore=usb modification to init. If this were to be incorporated in the 'stock' inits, it would save me folding in my patch when using a new initrd.

Thanks,

Edit: Init script also used in X-slacko-3.0n. Booting correctly with and without pupsave parameter there also. All of these tests are on Grub4Dos frugal installs with standard unencrypted savefiles.

_________________
Pups currently in kennel Very Happy LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64, and LxPupBB for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS. Now tazpup for puzzles Smile
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 2 of 5 [62 Posts]   Goto page: Previous 1, 2, 3, 4, 5 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
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.0790s ][ Queries: 12 (0.0103s) ][ GZIP on ]