ISO image in USB Flash drive

This is very interesting. Syslinux version 3.72 introduced the ability to write an ISO file to a USB drive. The current version is 3.73, that I'm testing. What you do is create an ISO file in the normal way, then:

# isohybrid puppy.iso
# dd if=puppy.iso of=/dev/sdc

The 'puppy.iso' image is then recognised as /dev/sdc1, of iso9660 filesystem.

I was eager to find out if this is "the" solution for USB booting... but it isn't. It works on 2 of 4 PCs that I have tested so far. Actually, I've currently got 7 PCs setup as testbeds, but 2 of them have USB ports but the BIOS will not boot from USB, so I can only test on 4 at the moment (the 7th is ancient, pre-USB). I've got another computer that I left in Perth, and I'll test that soon, plus I'll setup the Presario soon.

Of the 2 that worked, I set the BIOS to boot from "USB HDD" (USB hard drive). Interesting, one that did not work has USB-HDD and USB-CDROM selections -- in the case of USB-HDD I suppose the BIOS did not expect it to have a iso9660 f.s. so became confused.

Anyway, this is another solution in our arsenal of USB boot techniques, and I will add it to the Universal Installer. However, I also need to modify the 'init' script as it too is confused by the iso9660 f.s. in a USB partition.

Also, as the iso9660 f.s. shows up as partition-1, the rest of the drive can be another partition, which can hold the pup_save file -- but again, I have to modify 'init' to recognise this.

The two computers that it works on are my Acer Aspire laptop and my Intel Classmate kid's laptop, both with fairly recent BIOSes.

It's nice, boots up just like from a CD, with the initial menu.

You will notice, from this post and an earlier one on Unionfs and saving direct to the 'pup_save'layer, that I'm currently taking an interest in booting from USB. Yeah, I like this way of running Puppy, and I intend to put some effort into improving it. I need to make up a little USB-booting to-do list. Some thoughts to start the list:

1. There is a problem with deleted files showing up at next boot?
2. Have another go at true flushing of RAM tmpfs down to pup_save file.
3. A problem with wrong desktop drive icons when bootup on a different PC?

Posted on 12 Mar 2009, 8:38


Posted on 12 Mar 2009, 11:51 by dogone
eSATA flash sticks
I've ordered an OCZ Throttle eSATA/USB flash stick to see how Puppy and Woof handle flash storage that looks like a conventional SATA hard drive. I suspect neither will detect the fact and not cache writes. I'll know in a week or two and will report.

Posted on 12 Mar 2009, 18:44 by amico
usb booting/using
Using puppy from a flash disk is very handy, I liked it from the start; I'm using it this way right now.

What I've found restrictive to me is the pup_save file. (Either I bypass it or make it the smallest possible).

The reason why is because I felt the need to keep my data-files outside (ie: on the key itself or another one) to make them accessible from any machine or any OS, but have one pup-save file per machine I use, to hold a needed specific config/hardware preferences.(those are usually done once, and rarely touched again).

This is very handy and flexible way to have puppy works the same from the same usb key on all.

(by the way I went through some interesting mini-distros to see how they handle this separation, like slax, Slitaz, cdlinux, tinycore...) the common approach is to keep packages (like an sfs file that can be read at boot-up), and config files in a dir on usbkey, open to the world to see.

So to boot-up from any of these distros in a way to match the machine we're using, some variables are provided on the kernel/boot command line that can hold the values needed, and the syslinux menu does the rest (allows us to choose).

but because I prefer puppylinux...

Ah by the way Barry (please read next message)

Posted on 12 Mar 2009, 18:51 by amico
woof name

the other day I discovered an *nix/win app called also WOOF (Web Offer One File):

I hope You were aware of it, otherwise it seems the name was choosen before 'our' promising woof_puppy.

(the app looks interesting too by the way...)
keep the good work

Posted on 12 Mar 2009, 23:26 by Dougal
I'm curious: how does the kernel detect that usb drive afterwards?
The reason I'm asking is that I've noticed that when you plug in an unmolested Sandisk Cruiser, it is detected both as a flash driver with a vfat partition _and_ as a cdrw drive!
And it's not an error, either: the cd "drive" is _mountable_ and contains all the Windows binaries, which are run when it is plugged into a Windows machine.
So maybe the Cruiser is just partitioned into two partitions (or has additional, small storage area) and that has some boot image on it?

Posted on 13 Mar 2009, 2:10 by playdayz
Two More Good Reasons for usb booting
I just built a quad core computer with 4GB ram ans was surprised that the Widows desktop was still not as responsive as I had expected. So I thought, "With all that memory, I can run a really big Puppy all in ram." So that is the first thing, a niche for Puppy even on a very fast computer with beaucoup ram. I have tried a couple of puppies and they work well--and the desktop is almost instantaneous (which is almost fast enough ;-)

Second thing however is that I had a problem with booting windows after playing around for a while--and storing the pup-sav on the ntfs partition. I would not again use an ntfs partition-so usb seems the way to go.

This also rings me back to woof, so that I might build a puplet to my specds, to take advantage of the multiple cores and perhaps the 64 bit architecture (but I am still not sure there is any significant advantage to that).

Posted on 13 Mar 2009, 8:33 by dgcom
Boot from USB and QEMU - from the same USB key

There were several guides before to make it possible to have one USB drive which can be booted to Puppy directly or have QEMU started from it and booted in there.
This worked for 2.x I think, but broke completely in 3.x - init script was rewritten and it required more knowledge than I have to fix myself.

So, while you are at USB booting and init script fixing - can you work out QEMU boot as well?
Just one parameter to kernel should be enough to tell init script how to lay down filesystem so everything will work properly...

(I worked on it when found how to make xorg initialize properly in QEMU - posted about it in forums some time ago...)