Bug finding USB drives at bootup
October 03, 2011 —
BarryK
Forum member ldolse sent me a pm explaining a problem with double-finding of save-files at bootup. Here is part of ldolse's pm:
I've been working on a puplet which is using a 2.6.39 kernel, and this issue seems to be common across 2.6.39 kernels as Pemasu's puplets behave similarly.
Basically the same save file gets discovered multiple times during bootup with the latest kernels and USB flash. This forces the savefile selection menu to pop up during all reboots.
On a related note, also discussed in the thread, Woof only seems to be supporting kernels that have USB built into the kernel, as the keyboard doesn't work until after the init script. I don't know if this is intentional.
ldolse posted a fix here:
http://www.murga-linux.com/puppy/viewtopic.php?t=72087#568841
I have put this fix into Woof, however, I am surprised as I do not have this problem with my 2.6.39.4 kernel. Puppy kernels used to be built with USB drivers as modules, my latest kernels have them builtin to the kernel -- however the 'init' script should work for both.
Anyway, I will do a test build with an older kernel to verify.
Comments
2.6.39.4 with usb modulesUsername: BarryK
Right now I am recompiling the kernel with usb and usbhid as modules. I will build a pup with this and test the finding of usb save-file at bootup.
Re usb save-file problem
Username: BarryK
"This is not making any sense to me. I cannot reproduce the problem that ldolse has described. A drive is either a USB interface or it isn't. This code in the 'init' script finds all drives that are not USB: [i]find /sys/block -maxdepth 1 -name 'mmc*' -o -name 'sd*' -o -name 'sr*' | xargs -l readlink 2>/dev/null | grep -v '/usb[0-9]' | rev | cut -f 1 -d '/' | rev[/i] When the sr* drives are taken out of the above, it becomes variable ATADRIVES in file /etc/rc.d/PUPSTATE. The problem that was described in the forum was a drive showing up as both a non-USB and a USB drive, but I don't see how that can happen. For those people who have the problem, does the ATADRIVES variable contain the drive letters of the USB drive? Secondly, try that code snippet above, it should list drives but not USB drives.
portable drive code
Username: technosaurus
"find, grep, xargs, and rev aren't necessary [code]for x in /sys/block/m* /sys/block/s*; do case `readlink $x` in *usb*) continue ;; *) echo ${x##*/} ;; esac done[/code] also readline $x/removable (instead of ...readlink/case *usb*) would pick up other removable drives
usb bot no probs 2.6.37.6
Username: 01micko
"Hi Barry I have been using 2.6.37.6 with usb_storage compiled as a module for some time now without issue in usb installs with Slacko, note that even with no HDD it boots successfully. Variety of hardware tested, ranging from a lowly eee-701SD with 512 RAM to an intel P4 (early) with 1G RAM, Brookdale video (possibly the worst machine I have owned :)). HTH
ERRORUSBSCAN Output
Username: ldolse
"Hi, just tried out your modified script. This is the data that was put into ERRORUSBSCAN:[code]AN ERROR HAS OCCURRED. The 'init' script has found this twice: sda1 vfat /mpdpupsave-rt.2fs search_func param=usb ATADRIVES= PCPARTS= LESSPARTS=sda1|vfat [/code] Note when I said it was being seen as an ATA drive what I meant is that search_func is only called twice in the init script - the first time it's called is with 'ata' as the first parameter, the second time is with 'usb'. On my system (only with the 2.6.39 kernel), the function gets called both times when a USB booted from a USB stick. Do you need to see the same debug information for the first time search_func is called?
ldolse
Username: 'find' output
"I tried Barry's and Technosaurus' find function/script, neither one produced any usable results. I kept pulling piped functions off the find command until it looked like this: [i]find /sys/block -maxdepth 1 -name 'mmc*' -o -name 'sd*' -o -name 'sr*' | xargs -l readlink 2>/dev/null [/i] And that gave me this output: [i]../devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4:1.0/host4/target4:0:0/4:0:0:0/block/sda[/i] Didn't work, but manually searching those drives the only thing that matched the pattern was /sys/block/sda, and readlink gives me the same thing as above. Clearly shows up as a usb drive, but somehow it's being searched twice.
search_func calls
Username: ldolse
"Apologize for the flood of posts - just reading through the code and trying to understand things better. The first search function call: [i]search_func ata[/i] doesn't seem to explicitly have any connection to the ALLDRIVES variable or the ATADRIVES variable. The only thing the 'ata' argument does is check the pmedia attribute, which in this case I have set to PMEDIA=CD. I know this is incorrect, but historically this has worked with Puppy, and this is what a typical newbie would do anyway when they transfer an ISO to USB. There is a change note - 110425 - next to this search function, indicating that the ATA search will be done while USB is initializing. Later when the second search is called [i]search_func usb[/i], there is an explicit check to see if it's not an ATADRIVE, but since it's actually a USB drive it gets searched again. Is the issue that USB is initializing faster than ever seen before in 2.6.39.4?
Computer hardware
Username: BarryK
"ldolse, Could you explain about your hardware and what you are booting off: Are you booting from a USB Flash stick? Does the computer have internal hard drive, or any drive other than the USB drive you are booting off? Ok, I have examined the 'init' script some more, I think I know what is going wrong. Try this: [code]search_func() { #110425 case $1 in ata) [ "$PMEDIA" = "usbflash" -o "$PMEDIA" = "usbhd" ] && return #only probe usb drives. LESSPARTS0="`echo "$PCPARTS0" | grep -f /tmp/ATADRIVES0`" #111003 only probe non-usb drives. ;; *) #usb LESSPARTS0="`echo "$PCPARTS0" | grep -v -f /tmp/ATADRIVES0`" #only probe usb drives. ;; esac[/code] That code existed before I started compiling kernels with builtin usb drivers. I think the above will fix it. Note, if booting from USB, you should not have pmedia=cd. You should have pmedia=usbflash or pmedia=usbhd. You can have pmedia=cd if booting from a USB optical drive however.
Works, Thanks!
Username: ldolse
"That change did the trick, thanks! I'm only booting from a usb flash, no internal hard disk or any other drives. My application is a jukebox/music server and for now the audio files are all network attached, so no need for more than a USB stick or some type of flash media. Please note I'm not defending my mis-use of the incorrect PMEDIA setting, if it was purely for my own personal use I would have changed it to usbflash and forgotten about it, but since ISO is the defacto way of delivering a puplet it creates a support scenario I was hoping to avoid, so I appreciate the fix. Beyond that I've been modifying the init scripts on my remaster to force PUPMODE=13, so the PMEDIA setting until this kernel didn't really do much. Really appreciate the OS you've put together and the community you've got here encouraging experimentation and modifications, thanks again for the help!
now I understand
Username: 01micko
"I could not understand this bug until I booted Slacko on my wife's macbook (off cd). It all worked perfectly running in RAM then I made a save to a usb flash stick. When I rebooted indeed there were multiple save files of the same name. (note I booted off cd, saved to flash, about the only way to do it on a macbook without disturbing the HDD). I also noted that PETS would not install once the save was made. Other than that puppy should replace OSX on intel macs! Thanks [b]ldolse[/b] for pointing out this issue. Cheers.
New fix for multiple save files
Username: BarryK
"Oops, I got it wrong. The inserted line should be: [code]search_func() { #110425 case $1 in ata) [ "$PMEDIA" = "usbflash" -o "$PMEDIA" = "usbhd" ] && return #only probe usb drives. LESSPARTS0="`echo "$PCPARTS0" | grep -f /tmp/ALLDRVS0`" #111003 only probe non-usb drives. need for kernels builtin usb drvr. ;;[/code] The earlier solution excluded optical drives. In other words, it would not work if boot from CD.
Tags: woof