Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multiple large (>1TB) usb hard drives over a slow USB 2.0 connection #1134

Open
s243a opened this issue Jan 28, 2018 · 7 comments
Open

multiple large (>1TB) usb hard drives over a slow USB 2.0 connection #1134

s243a opened this issue Jan 28, 2018 · 7 comments

Comments

@s243a
Copy link
Contributor

s243a commented Jan 28, 2018

I had an issue when connecting multiple large (>1TB) usb hard drives over a slow USB 2.0 connection.

I describe my solution in this thread:
Tahrpup Can't find Save folder on Large USB Hard Drive

My modified files are:
/initrd/init
/initd/sbin/wait4usb

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

My modified initrd.gz (for tahrpup 6.0.6) cab be found at:
https://www.dropbox.com/s/5p2mulcyv9w56o2/initrd.gz?dl=0

*Note that, one might want to make further speed optimizations before incorporating this into Wolf-CE.

@gyrog
Copy link
Contributor

gyrog commented Jan 28, 2018

The following is a copy of my post in the forum:

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.

@gyrog
Copy link
Contributor

gyrog commented Jan 28, 2018

Have you tried a patch like the following:

`--- /0initrd/init 2018-01-22 13:16:55.268537361 +1000
+++ init 2018-01-28 22:31:07.533062939 +1000
@@ -1036,6 +1036,12 @@
if [ "$Z_BP_ID" -o "$F_BP_ID" -o "$A_BP_ID" -o "$Y_BP_ID" -o "$SAVE_BP_ID" ];then
wait_for_usb
decode_other_ids

  • if [ "$Z_BP_ID" -o "$F_BP_ID" -o "$A_BP_ID" -o "$Y_BP_ID" -o "$SAVE_BP_ID" ];then
  • rm /tmp/flag-usb-ready
  • #maybe a sleep here as well
  • wait_for_usb
  • decode_other_ids
  • fi
    fi
    if [ "$P_PART" ];then
    BOOTDRV="$(echo -n "$P_PART" | grep -o -f /tmp/ALLDRVS0)" #110205 ex: sda1 becomes sda.
    `

@gyrog
Copy link
Contributor

gyrog commented Jan 28, 2018

Sorry, this git-hub stuffs up even "code".
All the "bullets" above should be "+" characters.

@gyrog
Copy link
Contributor

gyrog commented Jan 28, 2018

Or try simply commenting out this line in the "wait_for_usb" function:
[ -e /tmp/flag-usb-ready ] && return
i.e. the first line of the function, which is line 854 in woof-ce testing "init".

@s243a
Copy link
Contributor Author

s243a commented Jan 28, 2018

Hello gyrop,

You first solution just adds a delay. While this would work, it would slow down the boot in instances where this isn't needed. As a minimum the delay should be configurable as a boot parameter, which I did.


[ $waitdev ] && WAITDEV=$waitdev #added by s243a 
 export WAITDEV="${WAITDEV:-3}" 

I set the default delay to 3 seconds because that is what Barry did in his "wait4usb" function.

However, a default of 1 second may be preferred if my second boot parameter is tried

[ $USB_TRIES ] && USB_TRIES=$usb_tries
USBTRIES="${USBTRIES:-3}" 

Which is how many times to try the wait4usb function. The loop will exit when the partition is found that one specified as a boot parameter.

If waitdev defaults for one (1) then maybe usb_tries should default to six (6). However, I think there is an issue with doing for this. The wait4usb function may take longer then one second (1s) even with the delay removed. I think that some of the code in wait4usb is for debugging purposes and or legacy compatibility and could be bypassed based on boot parameters.

Now regarding your second solution. This may also work but it will slow down booting in instances where it isn't needed, since code will be re-executed, that may not need to be.

@gyrog
Copy link
Contributor

gyrog commented Jan 30, 2018

@s243a,
The wait4usb you are using is much older than the one currently in woof-ce.
If you want to suggest changes to woof-ce, then you need to base it on the currrent contents of woof-ce.
You could try the wait4usb from woof-ce 'testing' or the further updated one in the "initrd.gz" in http://www.fishprogs.software/puppy/initrd/overlay_init-0.2.tar

@wdlkmpx
Copy link
Contributor

wdlkmpx commented Jan 30, 2018

Hi s243a, you might want to perform your tests in Lxpupsc
https://sourceforge.net/projects/lxpup/files/Other/LxPupSc/

or Artfulpup (see the forum, i don't have links)

The current lxpupsc release is
https://sourceforge.net/projects/lxpup/files/Other/LxPupSc/LxPupSc-18.01T-k64.iso

apply this delta to update it to a version that was uploaded 9 hours ago according to SF
https://sourceforge.net/projects/lxpup/files/Other/LxPupSc/interims/LxPupSc-18.01T-k64.iso___LxPupSc-18.01%2B8T-k64.iso.delta

The only possible issue is that peebee is constantly using cutting edge kernels and apps and the results with older kernels and stuff may vary, you can change kernel of course.,,, if you want to test the latest changes in woofce without building an iso yourself, take a look at lxpupsc. Switch to the jwm desktop, or the rox desktop to be precise if you feel like

Sometimes there are bursts of activity that basically means i'm bored with nothing else to do, when major and large changes can happen in a couple of days, and that's when trying to contribute something can be a headache as some scripts differ too much, that's why you and everyone who wants to test the latest release have to download peebee's latest builds and interim deltas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants