Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: qopit on June 28, 2023, 08:03:46 PM
-
I'm having trouble mounting two drives reliably with CorePure64, although it used to work quite well. This is likely a generic TinyCore question, so I'm posting here.
The situation is this:
- I have two persistent drives I want to mount reliably on boot
- This is a frugal install of CorePure64, with the kernel, rootfs, and modules all in /tce/boot on the main boot drive
- Both drives are labeled ("pbuilder_boot" and "pbuilder_data")
- I am using the `waitusb=30:LABEL=pbuilder_boot` boot code (I would like to wait for both drives with `waitusb`, but this does not seem possible)
- I have historically let Core do the autofstab thing and mount these drives as /mnt/sda1 and /mnt/sdb1, and it has been quite reliable in the past
- I recently updated the system this was running on, and bumped Core from 7.2 to 14.0 (a big jump, I know)
- Drive assignment to /mnt/sda1 and /mnt/sdb2 is now wildly intermittent. One problem is random assignment of drives to each. Another problem is that the drive that is not being waited on (with waitusb) is sometimes not ready come mount time
- I started trying to use the `nofstab` option and persisting `/etc/fstab` into `mydata./tgz`, but I can't persist the mount dirs with `/opt/.filetool.lst` because it will persist the entire dir structure... I think I'm misunderstanding nofstab usage
Details aside, my main question is:
How do I set Core up to reliably mount two labelled drives on boot?
I feel like I'm missing something dumb, since this has been quite difficult for me to solve, but must be a common issue.
-
Hi qopit
... This is a frugal install of CorePure64, with the kernel, rootfs, and modules all in /tce/boot on the main boot drive ...
Since that's the boot drive (pbuilder_boot) and contains your extensions
use the waitusb for that drive:
waitusb=30:LABEL=pbuilder_boot
Then use something like this in /opt/bootsync.sh to make sure the other drive is ready:
timeout=$((30 * 4))
while [ $timeout -gt 0 ]; do
timeout=$(($timeout - 1))
blkid -lt LABEL=pbuilder_data >/dev/null && timeout=0 || sleep 0.25
done
If you want to find out which device your data drive is, run this:
blkid -lt LABEL='pbuilder_data' | cut -d ':' -f1
-
Thanks, Rich.
I was also hacking around with similar drive detection code (following the model of the WAITUSB code in /etc/init.d/tc-config). I was kind of hoping that something less low level existed that I could not find.
I've settled on this function, which I invoke for my drives via /opt/bootlocal/sh:
waitForDriveAndMountIt() {
driveLabel=$1
mountDir=$2
mkdir -p "${mountDir}"
timeout=20
delay=0.25
counter=0
while [ $counter -lt $timeout ]; do
if blkid -lt "LABEL=$driveLabel" >/dev/null; then
devPath=$(blkid -lt LABEL="$driveLabel" | cut -d ':' -f1)
mount "$devPath" "$mountDir"
return 0
fi
sleep $delay
counter=$((counter + 1))
done
echo "Timeout! Drive with label ${driveLabel} not found."
}
That seems to be working pretty well so far.
-
Hi qopit
... ----- Snip -----
timeout=20
delay=0.25
----- Snip -----
...
You realize that results in a maximum delay of only 5 seconds, right?
-
You realize that results in a maximum delay of only 5 seconds, right?
Yes. By the time that code runs there has been quite a lot of time already. 5s should be more than enough in my experience with this system. I reluctantly made it that big!! :)
-
Hi qopit
Why reluctantly? It times out in 5 seconds or as soon as the drive
shows up, whichever comes first. The timeout is only there to allow
the function to exit if the device never shows up.
-
Why reluctantly?
Only joked about reluctantly adding the ENORMOUS 5 seconds ( :o ) just because I'm impatient. :) This is a system I hack on regularly. The drive is typically ready in far less than 5 seconds so it is much more than "needed".