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.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:waitdev=5 says to wait 5 seconds for devices to be found.Code: Select all
title Fatdog64 (sdc6/Fatdog64720b) uuid 6b517a5d-03c6-4635-96c5-659b29518c84 kernel /Fatdog64720b/vmlinuz waitdev=5 initrd /Fatdog64720b/initrd
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.
Tahrpup Can't find Save folder on Large USB Hard Drive
So I think that to add the delay all I have to do is this: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:waitdev=5 says to wait 5 seconds for devices to be found.Code: Select all
title Fatdog64 (sdc6/Fatdog64720b) uuid 6b517a5d-03c6-4635-96c5-659b29518c84 kernel /Fatdog64720b/vmlinuz waitdev=5 initrd /Fatdog64720b/initrd
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.
add on line 861 of /initrd/init
Code: Select all
[ $waitdev ] && WAITDEV=$waitdev #added by s243a
export WAITDEV=${WAITDEV:-3}
/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
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
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.
the default is three tries. Here is are my two new boot parameters:
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
where we replaced
with
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
}
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}"
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
Code: Select all
wait_for_usb
decode_id "$P_BP_ID"
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.
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?
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.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?
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:
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
Code: Select all
/usr/sbin/edit-initramfs
/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
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
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