I'm not sure who is going to step up and volunteer to become "Mr. USB Flash Drive" for Puppy, but we may need someone to take on that coordination role. Here are a few suggestions when collecting info on USB keys, that may help discover what the specific things are that make a particular drive able or unable to boot Puppy.
The idea is to boot Puppy from CD. Boot option 4 if you need to. Don't let Puppy use the USB key or seeit at boot, at all (just to be safe... actually it should be OK to even boot from it and then do these commands, but... play safe if you can reasonably do so). Then, once Puppy is booted and configured, you can open a console and run a few commands to collect some information about your USB flash drive. If we share this info (on the Wiki?), we can slowly gain enough examples to learn more about these drives and which aspects of them affect booting in Puppy. For some reason, Puppy does not seem to include the normal Linux "So, what's on my USB bus" command, lsusb. lspci is there, but not lsusb. seemsSo we have to work around the lack of it. We can use the /proc filesystem itself do to that, alongside fdisk and file and dd.
I'm going to assume there is probably some sort of Microsoft FAT partition on the drive; both drives I have here to test (KingMax 128MB and Sandisk Cruzer Micro 512MB) are like that... if we find many drives for which that assumption is incorrect, someone else can improve this initial list of ideas for us
(A) fdisk -l /dev/sda
This should output information about the drive geometry and any partitions on it. This is the first piece of information to keep.
(B) file -s /dev/sda
This will usually say just
/dev/sda: x86 boot sector
(C) file -s /dev/sda1
This is more interesting and shows (at least for me!) a lot more info about the FAT partition on the drive, and its first sector in particular. For example:
/dev/sda1: x86 boot sector, code offset 0x58, OEM-ID "MSDOS5.0", sectors/cluster 32, root entries 512, Media descriptor 0xf8, sectors/FAT 123, heads 16, hidden sectors 233, sectors 999703 (volumes > 32 MB) , serial number 0x3b691afd, unlabeled, FAT (16 bit)
(D) dd if=/dev/sda count=1 2>/dev/null |LANG=C strings -o
This looks inside the first 1K of the drive and outputs any USASCII strings it finds and their offsets into that 1K of data. I don't know if it will be useful, yet. Example output:
Invalid partition table
Error loading operating system
Missing operating system
(E) dd if=/dev/sda count=1 2>/dev/null |LANG=C hexdump
This outputs the entire MBR and partition table in hex, removing repeated lines to save space. I'm not sure if it is 100% legal to post this info, since it could possibly be copyrighted code. Publish this info at your own risk!
(F) egrep "^[PST]" /proc/bus/usb/devices
So, what's on your USB bus(es)? This is some of the raw data that lsusb would interpret for us, if we had it. Here's one chunk of the output I get here, as a partial example:
T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 4 Spd=480 MxCh= 0
P: Vendor=0781 ProdID=5151 Rev= 0.20
S: Manufacturer=SanDisk Corporation
S: Product=Cruzer Micro
S: SerialNumber=200411006309fc919c83
That's probably enough data to collect to start with
Rather than ask people to type in six commands.. here's a little script to do it for you, and format the output a bit in the process:
Code: Select all
#!/bin/sh
# usbreport.sh -- outputs various things about a USB drive
#
DEV=${1:-/dev/sda} # Device to probe, default to /dev/sda
if [ ! -b "$DEV" ]; then
echo "$0: Error: $DEV is not a block device"
exit 1
fi
newsection() { echo "-----$1-----" ;}
echo "$0: Report created at `date -u +%Y-%m-%d\ %H:%M:%S\ %Z`"
newsection
fdisk -l $DEV
newsection "$DEV and ${DEV}1 filetypes"
file -s $DEV
file -s ${DEV}1
newsection "Strings from first 1Kbtes"
dd if=$DEV count=2 2>/dev/null |LANG=C strings -o
newsection "Hex dump of first 1Kbytes"
dd if=$DEV count=2 2>/dev/null |LANG=C hexdump
newsection "Partial /proc/bus/usb output"
egrep "^[PST]" /proc/bus/usb/devices
newsection
In case it's not obvious: you can ask it to look at /dev/sdb or some other device by typing the /dev/sdb (or similar!) device name as a parameter to the script. The idea would be that people could redirect the output to a text file, and then post the results somewhere for "Mr. USB Flash Drive" (whoever he is!) to compare and analyze. Reporters should also say who they are, the make/model of their drive, and whether or not they have successfully booted Puppy from it, of course!
Hope this helps as you continue to work on figuring this stuff out
And no, I'm
not Mr. USB Flash Drive -- all of this except for looking at /proc/bus/usb would work for normal hard disk devices too, it's just your usual Unix/Linux tools in action. You can verify this by running it as
and see the results for your hard drive
This script is intended only to read things, not write to any devices or disks. It
should therefore be safe. I have run it on my system here with no problems (including running it against hda -- if I don't trust it, why should you!). However, if this somehow breaks your computer, your USB drive, or even causes your girlfriend or dog to run away from home and your house to fall down... I can't accept any responsibility for any of those things! Running code as root can have consequences. This code has no warranty, express or implied. It works for me. I hope it works for others too.
Would "Mr. USB Flash Drive" please step forward?
Jonathan