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

Using applications, configuring, problems
Message
Author
User avatar
bigpup
Posts: 13886
Joined: Sun 11 Oct 2009, 18:15
Location: S.C. USA

#16 Post by bigpup »

If the Grub4dos bootloader is on the same USB hard drive, sdd1 the first partition.

Tahrpup 6.0.6 is all installed on partition sdd4.
Everything including the save.
Nothing is in a directory, just on the partition.

Try this for a save parameter in the boot menu entry.

Code: Select all

psave=sdd4:/tahrsave
This assumes the save is a save folder.

Or using the uuid.

Code: Select all

psave=fab3b011-746f-448b-85a3-5f7fb7f8e7f6/sdd4:/tahrsave
Last edited by bigpup on Wed 10 Jan 2018, 07:09, edited 1 time in total.
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)

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

#17 Post by s243a »

Anyway. Posting more source now. Part of my objective is to learn more about how puppy works, so I hope it doesn't bore anyone.

returning to the logs from the failed boot

Code: Select all

1: PDRV= P_BP_ID=fab3b011-746f-448b-85a3-5f7fb7f8e7f6 P_BP_FN= 
Comes from line 925 of

/initrd/init

Code: Select all

[ "$PDEBUG" ] && echo "1: PDRV=$PDRV P_BP_ID=$P_BP_ID P_BP_FN=$P_BP_FN"
we see this because it is the only echo statement which starts with "1:"

This statment always gets executed. However, the code to instead have PDEBUG as a boot parmater is commented out:

Lines 857 to 858

Code: Select all

#[ $pdebug ] && PDEBUG=$pdebug
PDEBUG=1
which makes since since there isn't really that much debugging information in this script. However, I suppose if it was a boot option one could have debug mode as one of their boot menu selections.

Here is the part where it searches for the USB Drives

Lines 947 to 959

Code: Select all

if [ "$LOOK_PUP" -o "$LOOK_SAVE" ];then #something to search for
 [ "${PMEDIA:0:3}" != "usb" ] && search_func
 if [ "$P_PART" = "" ];then
  wait_for_usb
  USBDRVS="$(find /sys/block -maxdepth 1 -name 'sd*' -o -name 'sr*' | xargs -n 1 readlink 2>/dev/null | grep '/usb[0-9]' | rev | cut -f 1 -d '/' | rev | tr '\n' '|')"
  [ "$PDEBUG" ] && echo "2: USBDRVS=$USBDRVS -> ${USBDRVS%|}"
  if [ "$USBDRVS" ] ; then
    search_func "${USBDRVS%|}"
  else
    search_func
  fi
 fi
fi
such_func (lines 742 to 783) will if they aren't already defined search for both the location of the main puppy files,

Lines 770 to 779

Code: Select all

   if [ "$LOOK_PUP" ];then
    find_drv_file "$P_BP_FN" "$P_DEF_FN"
    if [ "$ONE_FN" ];then
     PDRV="$ONE_PART,$ONE_FS,$ONE_FN"
     P_MP="$ONE_MP"
     P_PART="$ONE_PART"
     [ "$PDEBUG" ] && echo "5: ONE_PART=$ONE_PART PSUBDIR=$PSUBDIR P_BP_FN=$P_BP_FN P_DEF_FN=$P_DEF_FN"
     break;
    fi
   fi
and also the location of the save file

Lines 761 to 769

Code: Select all

  if [ "$ONE_MP" ];then
   if [ "$LOOK_SAVE" -a "$SAVEPART" = "" ];then
    set_fs_linux "$ONE_FS"
    find_save_file "$ONE_MP" "$ONE_PART" "$ONE_FS"
    if [ "$PUP_SAVES" ];then
     SAVEPART="$ONE_PART"
     [ "$PDEBUG" ] && echo "5: ONE_PART=$ONE_PART filename=${PSUBDIR}/${DISTRO_FILE_PREFIX}save"
    fi
   fi
I'm not sure if these have to be on the same partition


Here is the logic where puppy decides if and where to search for the puppy files and returns an error if it fails:

Lines 927 to 965

Code: Select all

#establish PDRV
P_PART=""; LOOK_PUP=""; LOOK_SAVE=""
if [ "$P_BP_ID" ];then #specified as parameter
 decode_id "$P_BP_ID"
 [ "$ONE_PART" ] && { P_PART="$ONE_PART"; P_BP_ID=""; }
 if [ "$P_PART"  = "" ];then
  wait_for_usb
  decode_id "$P_BP_ID"
  [ "$ONE_PART" ] && { P_PART="$ONE_PART"; P_BP_ID=""; }
 fi
 find_onepupdrv "$P_PART" "$P_BP_FN" "$P_DEF_FN" "p"
 [ "$ONE_FN" ] && { PDRV="$ONE_PART,$ONE_FS,$ONE_FN"; P_MP="$ONE_MP"; }
 [ "$PDEBUG" ] && echo "2: ONE_PART=$ONE_PART ONE_FN=$ONE_FN ONE_MP=$ONE_MP"
elif [ "$PDRV" = "" ];then #not specified anywhere
 #determine what to search for
 [ "$PMEDIA" = "cd" ] && LOOK_SAVE="yes"
 [ "$SAVE_BP_ID" -o "$PSAVEMARK" ] && LOOK_SAVE=""
 LOOK_PUP=yes
 [ "$PDEBUG" ] && echo "2: LOOK_PUP=$LOOK_PUP LOOK_SAVE=$LOOK_SAVE PMEDIA=$PMEDIA"
fi
if [ "$LOOK_PUP" -o "$LOOK_SAVE" ];then #something to search for
 [ "${PMEDIA:0:3}" != "usb" ] && search_func
 if [ "$P_PART" = "" ];then
  wait_for_usb
  USBDRVS="$(find /sys/block -maxdepth 1 -name 'sd*' -o -name 'sr*' | xargs -n 1 readlink 2>/dev/null | grep '/usb[0-9]' | rev | cut -f 1 -d '/' | rev | tr '\n' '|')"
  [ "$PDEBUG" ] && echo "2: USBDRVS=$USBDRVS -> ${USBDRVS%|}"
  if [ "$USBDRVS" ] ; then
    search_func "${USBDRVS%|}"
  else
    search_func
  fi
 fi
fi
[ "$P_BP_ID" ] && { log_part_id "$P_BP_ID"; ONE_PART="$P_BP_ID"; }
[ "$PDEBUG" ] && echo "6: ONE_PART=$ONE_PART ONE_TRY_FN=$ONE_TRY_FN PDRV=$PDRV"
if [ "$PDRV" = "" ];then
 [ "$ONE_TRY_FN" ] || ONE_TRY_FN="$PSUBDIR/$P_DEF_FN"
 fatal_error "$ONE_PART $ONE_TRY_FN not found." "Finding puppy main sfs file."
fi

Again these are just notes to myself but maybe someone else will find it useful. When I learn more there will be more explanation and less code snippets.

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

#18 Post by s243a »

bigpup wrote:If the Grub4dos bootloader is on the same USB hard drive, sdd1 the first partition.

Tahrpup 6.0.6 is all installed on partition sdd4.
Everything including the save.
Nothing is in a directory, just on the partition.

Try this for a save parameter in the boot menu entry.

Code: Select all

psave=sdd4:/tahrsave
This assumes the save is a save folder.

Or using the uuid.

Code: Select all

psave=fab3b011-746f-448b-85a3-5f7fb7f8e7f6/sdd4:/tahrsave
If you use the uuid then you leave out the sdd4. A big downside of using sdd4 is that it won't work if I move the hard drive from one computer to another. I don't want to reboot now because I decompressed initrd.gz as noted above. I must learn how to remake initrd.gz. I found some links to read:

https://www.ibm.com/developerworks/library/l-initrd/
https://www.linuxquestions.org/question ... ost2305513
https://askubuntu.com/questions/777260/ ... img/777374
https://www.thegeekstuff.com/2009/07/ho ... nitrd-img/
https://linux.die.net/man/1/cpio
https://openvz.org/Modifying_initrd_image

I was just making some sourcecode notes tonight because I don't have time tonight to try to modify the script and even if I did I wouldn't know how to repack it yet.

P.S. I doubt that putting sdd4 instead of the uuid would make a difference. If you look at the log in my first post you see:

Code: Select all

mount: can't read '/etc/fstab': No such file or directory
sdd4 on /mnt/pdrv as  mount failed. 
So the init script was able to identify the partition from the uuid but the partion wasn't mounted fast enough in the puppy boot process.

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

#19 Post by bigpup »

OK,

Wish you luck.

If you come up with anything that makes stuff work better.

Put a post about what you did at Woof-CE on Github.
https://github.com/puppylinux-woof-CE/woof-CE
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)

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

#20 Post by bigpup »

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

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