Tahrpup Can't find Save folder on Large USB Hard Drive

Using applications, configuring, problems
Message
Author
s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#21 Post by s243a »

bigpup wrote:I kind of had a problem with Fatdog 720 not giving time for the drives to be found and identified when trying to find the save.

They have a waitdev= option that can be put into the boot menu entry.
But I do not think it is an option in normal Puppies.

So you can see how to use it.
Here is the menu entry:

Code: Select all

title Fatdog64 (sdc6/Fatdog64720b)
  uuid 6b517a5d-03c6-4635-96c5-659b29518c84
  kernel /Fatdog64720b/vmlinuz   waitdev=5
  initrd /Fatdog64720b/initrd
waitdev=5 says to wait 5 seconds for devices to be found.

Without it, the process goes too fast and all the drives do not get loaded before the save is searched for.
Maybe see what they did to add this optional parameter.
Thanks for the info. :) I didn't know about this boot parameter for Fatdog64. If I add a similar parameter then I'll probably give it the same name to make it easier for people switching between puppy and Fatdog64 and visa versa.

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

#22 Post by s243a »

bigpup wrote:I kind of had a problem with Fatdog 720 not giving time for the drives to be found and identified when trying to find the save.

They have a waitdev= option that can be put into the boot menu entry.
But I do not think it is an option in normal Puppies.

So you can see how to use it.
Here is the menu entry:

Code: Select all

title Fatdog64 (sdc6/Fatdog64720b)
  uuid 6b517a5d-03c6-4635-96c5-659b29518c84
  kernel /Fatdog64720b/vmlinuz   waitdev=5
  initrd /Fatdog64720b/initrd
waitdev=5 says to wait 5 seconds for devices to be found.

Without it, the process goes too fast and all the drives do not get loaded before the save is searched for.
Maybe see what they did to add this optional parameter.
So I think that to add the delay all I have to do is this:
add on line 861 of /initrd/init

Code: Select all

[ $waitdev ] && WAITDEV=$waitdev #added by s243a
 export WAITDEV=${WAITDEV:-3} 
change lies #21 to #26 of
/initrd/sbin/wait4usb

from

Code: Select all

#i want this to work with kernel that does not have my usb-storage patch, feedback is that 3 secs is enough...
while [ $CNTUSB -lt 3 ];do
 sleep 1
 CNTUSB=$(($CNTUSB+1))
 echo -en "\\033[1;33m.\\033[0;39m" >/dev/console #yellow dot
done
to

Code: Select all

#i want this to work with kernel that does not have my usb-storage patch, feedback is that 3 secs is enough...
while [ $CNTUSB -lt  $WAITDEV ];do
 sleep 1
 CNTUSB=$(($CNTUSB+1))
 echo -en "\\033[1;33m.\\033[0;39m" >/dev/console #yellow dot
done
So that it includes the variable variable waitdev as the condition for the first line of while loop. However, this is a bad hack. I'll come up with some better code hopefully soon.

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

#23 Post by s243a »

Okay here is my proposal which I'll try.

I created a function which will repeat the "wait_for_usb" function until the required partition is ready.

Code: Select all

function wait_for_usb_part(){
  echo "entering wait_for_usb_part() " #s243a remove
  xIFS=$IFS
  IFS=' ' #This should be the default but just to be double certain
  [ -e /tmp/flag-usb-ready ] || wait_for_usb #Call wait_for_usb if it hasn't been called yet.
  for i in $(seq 1 $USB_TRIES); do
     echo "i=$1 < $USB_TRIES" #s243a remove     
     BLKIDOUT='' #not sure if this is necessary but it will force blkid to be called again.
     decode_id $1 #Convert uuid's to partition name
     part_name="$ONE_PART" #this is the result (i.e. the partiation name) returned from decode_id.
     echo "part_name=$part_name"
     if [ $part_name ]; then
       for p in cat /tmp/flag-usb-ready; do #flag-usb-ready conatins the name of all the partitions which are ready for use
         [ $p != $part_name ] || break 2
       done;
     fi
     rm /tmp/flag-usb-ready #we got to clear this flag or wait_for_usb won't do anything.
     wait_for_usb     
  done
  IFS=$xIFS
} 
the default is three tries. Here is are my two new boot parameters:

Code: Select all

#Specifies how long to wait for the USB drive
[ $waitdev ] && WAITDEV=$waitdev #added by s243a
 export WAITDEV="${WAITDEV:-3}" 
#Specifies how how many times to try finding all USB drives
[ $USB_TRIES ] && USB_TRIES=$usb_tries
USBTRIES="${USBTRIES:-3}" 
waitdev was already explained. usbtries as just mentioned is how many times to try the wait_for_usb function. I'll report on the results when I'm actually able to test this and probably update the code in this post if no one comments and I detect any errors.

Edit:
I forgot to put where to call this script from:

Starting at line 927 of /initrd/init

Code: Select all

#establish PDRV
P_PART=""; LOOK_PUP=""; LOOK_SAVE=""
if [ "$P_BP_ID" ];then #specified as parameter
 wait_for_usb_part  "$P_BP_ID" 
 #decode_id "$P_BP_ID"
 [ "$ONE_PART" ] && { P_PART="$ONE_PART"; P_BP_ID=""; }
 if [ "$P_PART"  = "" ];then
   wait_for_usb_part  "$P_BP_ID" 
  [ "$ONE_PART" ] && { P_PART="$ONE_PART"; P_BP_ID=""; }
 fi
where we replaced

Code: Select all

wait_for_usb
  decode_id "$P_BP_ID"
with

Code: Select all

  wait_for_usb_part  "$P_BP_ID"
Last edited by s243a on Sun 28 Jan 2018, 09:04, edited 1 time in total.

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

#24 Post by greengeek »

Are your findings implying that some puppies fail to find important sfs files on usb drives because they do not wait long enough for the usb drive to come online?

If so, is this implying that the boot process fails to include some checks that a normal running system performs? After all - you never see "file not found" when you try to copy files to or from a usb drive normally.

Surely the running system does not include various random waits or sleeps when copying files - surely there must be some signal that flags a ready drive?

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

#25 Post by s243a »

greengeek wrote:Are your findings implying that some puppies fail to find important sfs files on usb drives because they do not wait long enough for the usb drive to come online?

If so, is this implying that the boot process fails to include some checks that a normal running system performs? After all - you never see "file not found" when you try to copy files to or from a usb drive normally.

Surely the running system does not include various random waits or sleeps when copying files - surely there must be some signal that flags a ready drive?
On a normally running system if you try to copy a file from a partition that isn't yet mounted. Then you will get a "file not found error" if you try to reference it from a yet non existent mount point.

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

#26 Post by s243a »

I got it to work. I had no luck making my own script to edit initrd.gz but I found the built-in one that Barry created:

Code: Select all

/usr/sbin/edit-initramfs
My successfully update initrd files are:
/initrd/init
/initd/sbin/wait4usb

The patch (aka delta) files are
/initird/init.patch
/initrd/sbin/wait4usb.patch

To use the patch files one has to edit the first two lines so that the source and destination reflect the locations on ones system.

I also edited my previous post to correctly show the changes that I made.

Edit My modified initrd.gz can be downloaded from dropbox at link

Anyone can test it but it is mostly intended for people with large drives over slow connections (like usb2.0)

Edit2: I also posted my solution as a WolfCE github issue
https://github.com/puppylinux-woof-CE/w ... ssues/1134

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

#27 Post by gyro »

There is a problem with the "wait4usb" script in woof-ce,
It finishes as soon as any single usb drive is ready.
This is usually not a problem since there is usually only 1 usb drive.
When there is more that 1 usb drive, the one it finishes on may be the wrong one, and the needed one gets ignored by the following "get_part_info".
Sometimes this can be worked around by plugging them in in the opposite order, or if one is not required for booting, remove it, and plug it in after the boot.

gyro

User avatar
bigpup
Posts: 13886
Joined: Sun 11 Oct 2009, 18:15
Location: S.C. USA

#28 Post by bigpup »

s243a,

Thanks for working on this!
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected :shock:
YaPI(any iso installer)

Post Reply