site  contact  subhomenews

PCMCIA mystery

January 13, 2011 — BarryK
Wary 5.0 testers have been reporting strange behaviour with USB sticks plugged in via a PCMCIA socket adaptor.

Testing on my laptop, yeah, it sure is weird. If I have a USB stick plugged in at power-on, after bootup the USB drive is not accessable. In my test it is /dev/sdc1, and 'probepart' recognizes the existence of /dev/sdc1, however it cannot be read from. Both "disktype /dev/sdc" and "guess_fstype /dev/sdc1" report failure.

However, and this is the mystery, in the initrd, before the switch_root, the USB drive is recognised, and identified as ext2 and able to be read from.

I put in a test near the beginning of, so just after the switch_root, and the USB drive can no longer be read.

I tested the same thing with an earlier Wary built with the kernel, and no problem, the USB drive is correctly recognised after bootup.

Note, with Wary 5.0 (and kernel), if I replug the USB drive after bootup, then it is recognised.


drive recognition
Username: shinobar
Sometimes /dev/sdc and/or /de/sdc1 may be missing. The LupQ-511 has a code for this issue in /etc/rc.sysinit. Try it if you are interested in. [code]# make all block device files, 3oct09 add drive device echo "Making all block device files" for ONELINE in $(probepart);do PART=$(echo "$ONELINE"|cut -d'|' -f1|cut -d'/' -f3) DRIVE=$(echo $PART|cut -b 1-3) if [ ! -b /dev/$DRIVE ] ;then UEVENT=/sys/block/$DRIVE/uevent echo $UEVENT [ -e $UEVENT ] && echo > $UEVENT sleep 0.2 fi [ -b /dev/$PART ] && continue UEVENT=/sys/block/$DRIVE/$PART/uevent echo $UEVENT [ -e $UEVENT ] && echo > $UEVENT done[/code]

Re missing device node
Username: BarryK
"Ah, that's it! Thanks shinobar. My mind was cloudy on the issue. It is not a kernel problem, it is a specific sequence of drive removal and plugging in. If I unplug my pen drive, the device node gets deleted. If I shutdown, plugin my pen drive, poweron, the device node exists in the initrd (or gets created) however it is missing after the switch-root. That's what Jemimah meant. She sent me a pm -- her solution is to remove all the whiteout files in /initrd/pup_rw/dev so that the device-nodes in the read-only Squashfs will appear on top. Ok, I have implemented a different solution in Woof. At line 1652 in the 'init' script in the initramfs, I have inserted: [i]#110114 if a drive unplugged in previous boot, but plugged in at bootup, device-nodes will be missing in main f.s... cp -a -u -f /dev/* /pup_new/dev/[/i] Shinobar, note that some memory cards are /dev/mmcblk* (ex: drive /dev/mmcblk0 partitition /dev/mmcblk0p1) which your code will not catch. Jemimah's solution also has a limitation, as if any required device-node does not exist in the squashfs layer, deleting the whiteout files won't help. When a memory drive is plugged in, device-nodes are created dynamically if they don't already exist, for example /dev/sdj1, which does not exist in the squashfs layer.

making device-node
Username: shinobar
"> cp -a -u -f /dev/* /pup_new/dev/ I tried the code in the inotrd, but no success or worse. Got 'input/ouput error' when i access to the device-node. Finally i implemented next code in /etc/rc.d/rc.sysinit at wary-500m06. [code]#19jan11 shinobar: make all block device files for ONELINE in $(probepart);do PART=$(echo "$ONELINE"|cut -d'|' -f1|cut -d'/' -f3) DRIVE=$(echo $PART|cut -b 1-3) if [ ! -b /dev/$DRIVE ] ;then UEVENT=/sys/block/$DRIVE/uevent [ -e $UEVENT ] && echo "add" > $UEVENT sleep 0.2 fi [ -b /dev/$PART ] && continue UEVENT=/sys/block/$DRIVE/$PART/uevent [ -e $UEVENT ] && echo "add" > $UEVENT done[/code] i don't know how we should treat /dev/mmcblk* files.

Tags: wary