Avoid "Searching for Puppy files" during bootup

[Wognath]

[Edited 5/19 for clarity and corrections]
I found that a few seconds are saved off bootup time by eliminating "Searching for Puppy files..." This is practical for me since I'm always on the same computer and the files are always in the same place. The idea is that once Puppy has been run, all the info found in the Searching... section is recorded in PUPSTATE.

Procedure: [Edit 2/14: please see modified procedure on page 3]
Back up initrd.gz
Unpack initrd.gz to folder initrd-tree
Copy /etc/rc.d/PUPSTATE to initrd-tree/
Edit init script by replacing the entire FINDING PUPPY FILES section:

Code: Select all

#######################FINDING PUPPY FILES###########################
. /PUPSTATE
[[ $pfix = "ram" ]] && PUPMODE=5
[[ $psave ]] && PUPSAVE=$PUPSAVE$psave
########################END FINDING PUPPY FILES############################

Be sure edited /initrd-tree/init is executable
Repack initrd

The second line allows the pfix=ram boot option to work

The third line is only needed if you have more than one save file and you want a separate grub entry for each. (The "Type a number to choose which personal file to use" menu won't be generated.) Thanks to CatDude and Crash for this.(link) In this case you also have to remove the save file name from PUPSAVE line in the PUPSTATE file and add psave=name of save file to the grub kernel line.
e..g. PUPSAVE='sda4,ext3,/slacko/slackosave1' becomes PUPSAVE='sda4,ext3,/slacko/' and psave=slackosave1 on grub kernel line.

This was done with suitable awe for the cleverness of the init script. I really didn't expect a simple change to work, but it does.

[mikeb]

PUPSAVE='sda4,ext3,/slacko/slackosave1'

why is this not specifying where the save is so avoiding searching or the need for an additional pfind parameter?

You could have reduced the search to top level only(-maxdepth 1) ...after all once you commit to a named folder its specified in the kernel line so there is no need to waste time searching sub folders.

All seems a bit odd really...again seems like the searching should not be happening anyway.

mike

[8Geee]

IMHO the skip searching for puppy files not worth it. /MHO

[MochiMoppel]

I admit that I've never paid much attention to my grub4dos configuration since speed seems to be OK even with a basic setting like
kernel /pup_slacko/vmlinuz pmedia=usbflash pfix=ram
initrd /pup_slacko/initrd.gz

What I don't understand: Why do I see Puppy "Searching for Puppy files" even though pfix=ram should have made it clear that I don't use a savefile? Or is Puppy searching for anything else?

[mikeb]

If the subfolder search happens to be where there are say windows installs then that to me is a little lump of wasted time and disk thrashing.
Its a hang over from root only of partition installs... since a folder is specified why search? The installers handle it all now so would only really apply to a messed up manual install attempt...oops the user forgot to include the subfolder name we had better make up for his/her oversight with a long search.

The search is for the main sfs as well as a save...pfix=ram just skips the latter.
Actually not quite true...puppy 4 plus searches and picks up anything that might possibly be puppy then sifts through the info to try and work out where it is... great fun if you have multiple installs for example. So yes all is searched..pfix=ram just ignores some of the information.
Someone got drunk after discovering the 'find' command.
Its can be the source of some interesting quirks.
It was fun when it did not skip a full install and used it for a save..that was my favourite bug

I prefer targeted searches for the needed files and continue as soon as found...but thats just me and my insane desire for speed and less boot parameters

mike

[jonnymcfly]

I could see the need to do this, I use PupRescue on occasion. Once in a while i get a pretty bad drive and all this searching just hangs the boot up process and causes issues. Especially if I am trying to get a file from the drive before it locks up completely.

Thanks for the info !!!

[ocpaul20]

So, after that small bit of discussion, is there a way to make it even quicker - if you know the name of the savefile you want to load and if it can be placed at the top level, etc? I mean without having to change initrd.gz?

Maybe just with kernel boot parameters or perhaps the grub(4dos) boot menu would not even be necessary if there was no Windows or other os on the disk.

[Wognath]

It's not this complicated.

Just use the following boot parameters (adjusted for your system of course):

pdev1=sda1
psubdir=puppy

http://www.murga-linux.com/puppy/viewtopic.php?t=60257
In my experience, these don't noticeably reduce "searching for..." time.

[mikeb]

No they wont..the search happens anyway..those parameters just filter the results....puppy 4+ is like that. I preferred the older targetted searches...much faster and I stuck to that.

mike

[shadower_sc]

..the search happens anyway..

Is there a way to skip the search entirely? I would be interested in this for a remastered CD that wouldn't have an install or save file. I.E. everything runs from the CD.

[mikeb]

Any improvements involve editing the init in initrd.gz.

Hint...its not nice which it why it hardly changes.

mike

[gyro]

In tahrpup 6, specifying "pdev1" as a boot parameter seems to narrow the search, at least when not booting from a CD.
1) There is code in the 'init' script to limit the list of partitions to search to only those matching "PDEV1", if it is specified.
2) When testing SAVEMARK, I had to remove the "pdev1" boot parameter, so it would find the savefolder on the other partition.
3) My disk has 2 ext4 partitions. My 'always fsck ext4 partitions' code only fscks a single partition when "pdev1" is specified, but both when it is not.

gyro

[mikeb]

I am rusty as i dumped the init from puppy 4 plus several years ago so not 100% on what does affect the seacrh in terms of parameters... ^gyro is yer man on this one.
Removing the sub folder search is a saver (maxdepth=3)...after all if you KNOW where puppy is why look thorugh windows?

mike

[gyro]

What I don't understand: Why do I see Puppy "Searching for Puppy files" even though pfix=ram should have made it clear that I don't use a savefile? Or is Puppy searching for anything else?

Yes, it searches for other puppy files as well, including the puppy...sfs, any zdrv, any adrv, any ydrv. Once these are found, the relevant information is stored in "PUPSTATE".

Without modifying "initrd.gz", specifying "pdev1" and "psubdir" is a good as it gets.

@Wognath,
Any adrv or ydrv would have to be in place before your modified 'init' script is used. Although existing ones could be replaced, because they are in the same place with the same name.

gyro

[Marv]

On some of my machines, particularly the Bay Trail boxes with usb media card readers installed, the search discussed above takes FOREVER. Even if pdev1 etc are specified, it still interrogates the USB system. The culprit is how long it takes the system to return a USB ready flag. On systems I install on those boxes I have modified the init script in initrd.gz to implement ignore=usb passed as a kernel parameter. The following is a general guide to what I have done:

Code: Select all

#line numbers based on init in Tahr 6.0

#added line 150 : 
141129 add support for ignore=usb kernel parameter. Note: kernelparam ignore returned as lowercase (kernel 3.14.20 anyway).

#modified line 866 :
while [ !-e /tmp/flag-usb-ready -a "$ignore" != "usb" ];do #110710 wait for usb process to complete.  #141129 if usb not ignored  

#modified line 870 :
if [ -s /tmp/flag-usb-ready -o "$ignore" = "usb" ];then #110710 has stuff in it if usb drives exist. #141129 or if usb ignored

Got my first Bay Trail box about a year ago and so this has been in use for about that long on those and incidentally on my core 2 duo and Pentium M laptops. Speeds up the boot immensely on the Bay Trails and noticeably on the others. I've done it for Tahr and Slacko based pups primarily. If the kernel parameter isn't passed, USB boots are normal.

[bigpup]

I have modified the init script in initrd.gz

How do you get into the initrd.gz to do this?
What program or right click option do you use?

[mikeb]

I took the slax approach dumping the usb distinction testing (anyone use usb 1 to run puppy ? ) plus newer pup kernels build in usb anyway.

That approach does a nice simple search for the sysem files and then repeats it say 6 times with a short delay after each.. if on say a hard drive booting is rapide..ie one search is enough...if system is on usb it usually gets it by the third loop. I suppose its how long before you give up that sets the figures used.

mike

[Marv]

I have modified the init script in initrd.gz

How do you get into the initrd.gz to do this?
What program or right click option do you use?

Lots of ways to skin that cat I use edit-initramfs. In Thunar in X-slacko or the recent Carolinas or VG Carolina (and probably in X-tahr) there is a right click to invoke that. It expands it into a directory in /root, you can edit init there, then click on the initrd.gz you expanded and it gives you the option to recompress using your altered directory.

If this is your first time doing this, set up a sacrificial pup in its own boot directory, have at least one other bootable pup on your system, and make a backup of the initrd.gz before proceding. You will (or at least I did) make mistakes and render that initrd.gz unusable. That's the beauty of Grub4Dos and multiple pups IMO.

[bigpup]

Thanks for the info!!

Using Tahrpup 6.0.3

I use edit-initramfs.

In Rox file manager.
I had to add edit-initramfs to the right click open with..... list.

After that, I can right click on initrd.gz.
Choose open with.....
Select edit-initramfs.

For messing with the initrd.gz. I would like to make it a little harder to openup by having to go the extra step of choosing open with.....

Why do I have the feeling we just opened up a big can of troubles with people modifying the initrd.gz.

[Marv]

Why do I have the feeling we just opened up a big can of troubles with people modifying the initrd.gz.

The core scripts have always been there to 'modify'. Guess I figure if you blow it up on your watch you own it Seriously, the closer I can stay to core the happier I am but sometimes other workarounds haven't gotten me running. Certainly that was true in the early days of flash memory and rc.sysinit. Not so often now.. pup has come a looong ways.