Having issues with waitusb option

[caracalla]

I am running Tinycore Linux 9.x from an USB flash drive (https://www.amazon.com/SanDisk-Ultra-Transfer-Speeds-s-SDCZ48-032G-UAM46/dp/B00KYK2AKO). The thing is that most of the time waiting for the partition labeled SYSTEM is successful and partition is identified in two to three seconds, while sometimes timer will expire before partition is identified. This is really frustrating and it doesn't make much sense, since this is one of the fastest USB flash drives on the market.

These are the GRUB bootloader options I am using to run the Linux kernel

Code: [Select]

linux  /boot/vmlinuz loglevel=3 waitusb=10:LABEL=SYSTEM base syslog cron norestore nofstab noswap nolocal noautologin logo.nologo rootwait
initrd /boot/initrd.gz

To resolve this problem it sometimes helps if I insert USB flash drive to another USB port available on the computer. But it helps only temporarily because after a few power cycles it will happen again. I did make various tests using different USB flash drives on different computers and what I can conclude is that it seems this is an issue with faster USB flash drives (https://www.amazon.com/dp/B01NARBPI7/ref=emc_b_5_t, https://www.amazon.com/Kingston-Digital-16GB-Traveler-Flash/dp/B00G9WHMCW).

This is getting really annoying and I really can't get a sense of it.

Please share some ideas if you have any.  Thanks!

    [EDIT]: Added code tags.  Rich

[Rich]

Hi caracalla

... The thing is that most of the time waiting for the partition labeled SYSTEM is successful and partition is identified in two to three seconds, while sometimes timer will expire before partition is identified. ...

Then the first thing to do is increases that wait time from 10 to 30. It only uses the amount of time it really needs anyway. If 10
seconds is sometimes too short, there's no point in leaving it at 10, right?

To resolve this problem it sometimes helps if I insert USB flash drive to another USB port available on the computer. But it helps only temporarily because after a few power cycles it will happen again.

Neither the system nor USB device has any knowledge of what's plugged in where between power cycles (or reboots).

You might want to boot up using a different device, then plug in your USB flash drive, and run a file system check on it to check its
integrity. I use  gparted  to run this kind of check. Right click on the partition, select  Check  from the popup menu.

I don't know what that  nolocal  boot code was supposed to do, but it was dropped in 2009:
http://forum.tinycorelinux.net/index.php/topic,2833.msg14509.html#msg14509

[coreplayer2]

Hey Rich

regarding this bootcode

Code: [Select]

linux  /boot/vmlinuz loglevel=3 waitusb=10:LABEL=SYSTEM base syslog cron norestore nofstab noswap nolocal noautologin logo.nologo rootwait
initrd /boot/initrd.gz
"rootwait"  I know this is not a TC bootcode per se but how valid is this in our kernel?

[Rich]

Hi coreplayer2
It's been in the kernel since at least 2013 and is not a config option as near as I can tell. My understanding is it tells the kernel
to wait until the device it's booting from is ready, if that makes any sense. The OP probably placed it there in act of desperation
to solve his/her problem. Some of those other boot codes may have been placed there for the same reason.

[Rich]

Hi coreplayer2
The kernel is already loaded by the time the OP gets the error. The error comes from  /etc/init.d/tc-config.

[coreplayer2]

Hello Rich

Interesting thanks


Also the read speed has nothing to do with time for detection.  Besides, AIUI the label is read from the filesystem so I think UUID would be much faster solution, no?

 

[Rich]

Hi coreplayer2
Speed (USB3 vs USB2) should not be an issue, but you never know. The file system is rooted in RAM and everything is
connected to it (keyboard, terminals, drives, network, you name it). The script issues this command in a loop until a timeout or match:

Code: [Select]

blkid -lt $dev$dev  contains either LABEL or UUID,  depending on which you used.

-l  means  lookup the the first device with arguments specified by -t
-t <token>  find device with a specific token (NAME=value pair)
$dev  is the  token

[PDP-8]

Your syntax for wait implies waiting just for a specific device - have you seen any difference with the normal syntax

Code: [Select]

waitusb=10  tce=LABEL=SYSTEM
That stick contains security software on it, and may have some funky pre-partitioning.  Have you reformatted the stick with a standard utility, and/or gotten rid of the security stuff?

And although it may not matter, I try to avoid names that might be sharing global system variables, like SYSTEM when you format it.

[caracalla]

What is interesting is that when system boots up with timer expired, the not identified partition will be missing as well if I manually execute blkid tool.

[Rich]

Hi caracalla

... The thing is that most of the time waiting for the partition labeled SYSTEM is successful and partition is identified in two to three seconds, while sometimes timer will expire before partition is identified. ...

Then the first thing to do is increases that wait time from 10 to 30. It only uses the amount of time it really needs anyway. If 10
seconds is sometimes too short, there's no point in leaving it at 10, right?

 ... You might want to boot up using a different device, then plug in your USB flash drive, and run a file system check on it to check its
integrity. I use  gparted  to run this kind of check. Right click on the partition, select  Check  from the popup menu. ...

Did try increasing the wait time to see if that makes any difference? Did you run a file system check on the device?

What is interesting is that when system boots up with timer expired, the not identified partition will be missing as well if I manually execute blkid tool.

Probably because it's not listed in the blkid cache (/run/blkid/blkid.tab).