Suggestion: Set CONFIG_SCSI_MULTI_LUN in future kernel update

[fellow]

I installed TC2.10 on a SD-card plugged into an USB2.0 INternal _MULTI_ card reader.
After successful booting I wondered why  fdisk -l  did NOT show a device corresponding to the SD-card 

During thinking (and surfing) on this topic quite a bit of time I realized the following:

1. The BIOS detects the USB2.0 INternal _MULTI_ card reader and each of its 4 slots.
2. The BIOS lists only those slots with plugged-in SD-cards in a special boot menu, when I hold down F8 key during boot.
3. Choosing to boot the SD-card with installed TC then grub boot loader is started.
4. Grub loads bzImage and tinycore.gz into memory (RAM) and TC takes over to rule the PC.
5. Now TCLinux is on its own to care about devices ... but it seems to be not so equipped as the BIOS ...

Finally I found a very illuminating discourse on  Using a USB Card Reader in Linux 

It explains that the kernel option “Probe all LUNs on each SCSI device” (CONFIG_SCSI_MULTI_LUN) must be enabled so that a linux OS is able to detect ALL card slots of a MULTI card reader during the OS' boot process.

I haven't yet tried the alternative method (also mentioned therein) of adding the line

      options scsi_mod max_scsi_luns=8

to  /etc/modules.conf  (which then had to be made persistent in order to substitute its original copy on each boot ...)

But I can confirm that the also mentioned third method of kinda "deferred" setting of a certain kernel parameter is successful:

      echo 8 > /sys/module/scsi_mod/parameters/max_luns

Having issued this command I just plugged in an USB2.0 EXternal MULTI card reader equipped with a SD-card and now  fdisk -l  DID show up the SD-card as  /dev/sdd1   

Note: Booting with this second reader+card being ALREADY plugged-in will provide the device ONLY IF you plug out the reader's USB cable, then issue the above command and then plug it in again !
(I don't know if there might be a method of soft re-initialization of the USB system ...)

So after all SETting the respective kernel parameter  CONFIG_SCSI_MULTI_LUN  in the future kernel config seems to be the most effective way.

Thanks in advance for considering ...

P.S.
      cat  /sys/module/scsi_mod/parameters/max_luns

reveals the default value  1 .

So IMHO TC would be able to automatically provide a device during its boot if the logically FIRST slot of the INternal MULTI card reader was the one equipped with the SD-card ... with 4 slots the probability of success is obviously 25 % 

[curaga]

Sure, will do. Though the help text mentions some devices do not like it, it shouldn't cause much harm.

As a side note, I have several usb multicard readers, and none have needed that option. One shows as a single device, only capable of using one card at a time, the others have one device per card slot. Likely depends on the chip inside.

[fellow]

Thanks for providing the  CONFIG_SCSI_MULTI_LUN  option in the next kernel config. 

Only now I realized the bitter consequencies of missing this option :

Supposed I've booted my SD-card installed TC.
Then I use the above mentioned
    echo 8 > /sys/module/scsi_mod/parameters/max_luns
to get access to the SD-card as a device (after plugging-out-and-in multicard reader's USB cable).

Then I put the same  echo command  into  /opt/bootlocal.sh  and also some kind of "soft" re-initialization for the USB system (BTW does anybody know of such a "soft" USB re-init command ?).

This just would NOT help TC to recognize the SD-card as a device during further boots !
Because now we have a classical paradox :
Only the execution of  /opt/bootlocal.sh  on the SD-card would make the kernel capable of accessing  /opt/bootlocal.sh  on the SD-card 

In short :
      Using persistence requires the detectability of persistence.

Fortunately my SD-card is in fact an SD-card adapter equipped with a 2GB Micro SD-card and I also have an USB-to-Micro-SD adapter stick ... 

It seems to me somewhat mysterious that all of curaga's multicard readers behave as smart, whereas my two readers being each of totally different brand are both such nasty candidates 
Maybe my desktop's BIOS is the common culprit supposed that linux' SCSI/USB system might depend on some basic BIOS calls 
 

[curaga]

Heh, all of them are el cheapos from DX

Since scsi is built in, you can add that as a boot code. That way it should be detected from the start.

It's either "scsi.max_luns=8", or "scsi_mod.max_luns=8", I'm not 100% sure which one.

edit: My bets would be on scsi_mod.