I get loads of errors after a while when booting from usb stick (Cruzer
128Mb), -this known errors :
cp_FULL <wants to create many hidden directories like

/root/.usr etc,

which arguments are seen as invalid). After that, a red [failed] appears,
and i'm asked for password/login for ever. Is there a solution ?
I have installed puppy from the script with default arguments, then booted
from floppy, (no cdrom drive in the machine).

We would love to help you, but we need some more information. (I personally use Cruzer Mini 1GB with no problems... I do not think your problem is the size of yours unless you have other things on it too.)

Same happens with a valide CD. Now i can boot from
the CD (normal boot) so i'm sure it's ok. But i think puppy can't
find the usr cram.fs from the usb. There was a page how to help
puppy to find the cram.fs somewhere ...

i tried to copy usr_cram.fs in pup100, then in pup001, and
there it is completely hidden ! Then when i press ENTER to continue,
i get the same error as in my first post, and NO PROMPT.
so i cannot tell puppy where is usr_cram.fs

Trying this WAKEUP11C gave a nice, clean boot, contrary to the
BOOT2PUP disk. NICE ! awaiting that for 2 years, thanks to this
amazing improved puppy i can boot this pitiful laptop without usb BIOS
support.
I must say, Puppy improved a lot since last time i gave it a try,
prior version 1, as it was only 32Mb. Now it's usable, fast, smart, etc.
Also nice to have a lot of *readable* documentation answering questions
that one have, -not like xemacs documentation.

Had exactly the same problem with 1.08R1 and this made it work:
I use a Sandisk cruzer mini 256 and this worked for me:
Format USB FAT32
Run syslinux z: (Win32 version for me under XP) z: = USB drive letter.
Copy these files from the Puppy CD to the key:
image.gz
usr_cram.fs
vmlinuz
Create syslinux.cfg (use an editor that respects UNIX conventions) EditPad or VIM - My syslinux.cfg =
default vmlinuz root=/dev/ram0 initrd=image.gz
append PSLEEP=25 PHOME=sda1 PFILE=pup100-none-131072

Maybe the problem is that your drive is too small. Puppy itself only uses ~60MB, but it tries to create a 256MB pup001/100 file. If your drive is 128MB, it probably doesn't have enough space even for a smaller pup100. There are some files that have to be in the pup100. Maybe there's not enough space on the drive to store them.

I'm not entirely sure that this problem has anything to do with the USB stick, since I had exactly the same issue when booting off a multisession CD (please see my posts in this thread).

As I say in that thread I have no clue why this happens. Can someone more familiar with Linux / Puppy help out with this bug? I've seen several different posters complain of it, but not sure if there are any solutions yet...

I'm certain there is a solution, since i succesfuly used another Small linux distribution, "the System rescue CD" from a usb stick (http://www.sysresccd.org) with the same machine.

I do not know the HowTo, but they made it work. So there must be way to make it work with Puppy also.

The Puppy FAQ says that if we know how to make it work with a usb hub....to send them the info, i do not know how....but system rescue CD knows how, maybe puppy could ask them?

Hello khisanth,

I wrote the USB hub, let me know bit.

I once had a Verbatim, 256MB USB thumb drive. The last version of Puppy that I made bootable on it was 1.0.4. Back then, I did not have any equipment that would allow me to boot from USB (no provisions for it in the BIOS), so I had a boot floppy. With that boot floppy, I had no problems booting the Verbatim drive.

I don't know how small the pup001 file can be, but I also saved the pup001 file to the same Verbatim drive as the boot files. I remember that it was pretty small, but functioned (I suspect that it was greater than 128MB, but not sure/can't remember). I chose to not use this configuration since the port was USB 1.1 and I was too impatient. I put a new pup001 on the C:\ drive and booted to CD. I replaced this USB drive with a SanDisk Cruzer Mini 1GB and made the Verbatim drive just a disk for files.

Have you tried to use your thumb drive in different USB ports, on the front and back of the computer? See if you have different results. Do you have an internal USB port (my USB 2.0, PCI expansion card has four ports on the back plain plus one internal)?

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:

(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:

(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:

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

Code:

sh usbreport.sh /dev/hda |more

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.

The main difference is that the s150 has USB 1.1 ports instead of 2.0
The S150 has only 2 usb ports, while the one that works, the S170 has 4 (2 fronts, 2 back).

So i do not think the usb key format is a problem here(fat 16), since the same key works with one and not with the other pc. The same key also boots with another linux distribution. Problem should be in the puppy usb drivers somewhere.

I'd love to help you with running the usbreport.sh you posted. I saved it on the usb key under the name usbreport.sh and tried to run it in puppy with the command ./usbreport.sh

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum