How to Make a Bootable Flash Drive using ISObooter

[rcrsn51]

I cannot answer that. Ask the MintPup team.

But in the time it took to ask the question, you could have set up an ISObooter flash drive and tested it yourself.

[Mike Walsh]

@Mike Walsh: Have you tried one of these troublesome X-Puppies with ISObooter?

Sorry to be a while getting back to you, Bill.....I'd forgotten I'd posted in this thread. Too many irons in the fire..!

I have tried all three of them.....and every time I get the '.sfs file not found' error.

Any suggestions, or ideas? Like you, I, too, am increasingly convinced it's a timing issue with USB's in general. I know in my two present Pups, having plugged a USB stick in, it can take anything up to about 25 seconds before it shows up at the bottom of the screen. I don't, however, really understand how you would go about implementing the waitusb option. That's what I would like to try.

I'd really like to be able to carry X-Slacko around in my pocket....especially since your Slacko version of the 'r8188eu' Realtek driver works a treat with it!


Mike.

[davids45]

G'day rcrsn51 et al,

I have been testing several multi-Pup-on-USB options over the last few days on my range of computers.

And getting moderately confused.

From Pup-Forum threads, I set three 8GB USB drives up with multiple Pups: isobooter, MultiPup6.0 and an older version of Multipup.

The flash drives were all Imation Classics bought in a pack of 5 for $15.

My computers are all oldish:
2 HP Low Form 'newer' desktops ~2007
3 HP Low Form 'older' desktops ~2005
1 Samsung laptop ~2011
1 ASUS desktop "self-build" with cheap components ~2012 (the only one not offering USB boot from BIOS - all the others are set to boot first from a USB removable drive).

I created the 3 multiPup drives on my main computer, a ~2007 HP and found that the isobooter and MultiPup60 would not boot on this computer, even though the older Multipup did, as do single Pup USB drives I'd made previously.
I got 'not-bootable' messages or just a blinking cursor with the no-goers.

So I seemed to have two multiPups that did not work for me (isobooter and MultiPup60). But these two USBs were OK if set up as single Pup USB drives so the USBs themselves seemed not to be the problem.

By chance, I found that the isobooter multi would boot on an older HP so then I re-made the isobooter on the older HP. I also re-made the MultiPup60 on this older HP. These USBs worked on the old HPs and the Samsung laptop but not the newer HPs nor the Asus with the non-USB BIOS .

I next tried Plop (downloaded version 5.0.15.zip) and once I'd worked out where to put the plop bin file for the particular computer (Grub/Grub4Dos, sometimes sda2 (hd0,1) as boot partition), and how to read the fuzzy Plop dialog boxes, I could now get the MultiPups to boot the Asus directly and boot just one of the newer HPs (inserting the USB only after the Grub menu was displayed - booting with the USB inserted gave a flashing cursor - I have not tried to reset its BIOS to not boot from the USB).

So I am now left with just one non-booting computer for the two most recent MultiPup methods. Of course, this just had to be my 'main' desktop .

I have tried using most of its 6 USB ports including a hub - no difference in which USBs boot and which don't.

So I think there may be a variability/influence in the computer itself that affects USB bootability, both when creating the bootable multiPup and on booting with the multiPup. Posts from cthisbear have noted strange behaviour between USBs and computers.

And I would, like Mike Walsh, be interested to know if this could be a timing problem between the USB and the particular computer.

And I will be happy to try any suggestions that could clarify my present confusion with all these USB drives and computers.

Thanks as always,
David S.

[d4p]

If you boot to the desktop, ISObooter simulates a frugal install. So Puppy looks for the savefile close to the main SFS - ie. on the USB drive. But this search mechanism is constantly changing in Puppy, and there is no guarantee that the USB savefile will be picked before a hard drive savefile. Again, this has nothing to do with ISObooter.

You are right; it is nothing to do with ISobooter.
I did the test only on slacko with success.
You just need to change isolinux.cfg parameter in Slacko.ISO to pmedia=usbflash psavemark=partition number of your USB savefile.
Enjoy!

[starhawk]

Just dropping a note of feedback, since I know rc gets cantankerous when that doesn't happen.

Just booted Ubuntu 14.04 for a rare case when I needed the real thing, using Isobooter and a notebook IDE hard drive hooked to what eBay calls an "IDE SATA USB" adapter.

Works a treat. Thanks, rc!

[rcrsn51]

People like ISObooter for the easy way it builds bootable Linux flash drives, including Puppies. But if you want to keep your Puppy save file on the drive, it has the same limitation as other USB installers - save files on a FAT32 flash drive are SLOW.

But now that Puppy has the option of using a save folder, there is a better way.

1. Format your flash drive with two partitions - a FAT32 for your ISOs and an ext4 for storage.
2. Set up the first partition with ISObooter as usual. For "Choose a partition for Puppy savefiles", enter 2.
3. Select "Boot from splash screen = n".
4. Boot off the flash drive. At first shutdown, make a save folder. Puppy is smart enough to put it on the second partition.
5. On subsequent shutdowns, you should find the saving procedure to be much faster.

Update: In some Puppies, you can speed up the boot sequence by changing "pmedia=cd" to "pmedia=usbflash". This will also prevent a situation where Puppy accidentally finds its core files on the hard drive and uses them instead.

Update: Making the ext4 partition non-journaled may improve shut-down times. For example:

Code: Select all

umount /mnt/sdb2 #just in case
tune2fs -O ^has_journal /dev/sdb2

----------------------

[Mike7]

Hi, rcrsn51.

But now that Puppy has the option of using a save folder, there is a better way.

1. Format your flash drive with two partitions - a FAT32 for your ISOs and an ext4 for storage.

Do save folders get saved faster on ext partitions than save files?

M.

[rcrsn51]

Do save folders get saved faster on ext partitions than save files?

The whole point of the exercise is for you to test it yourself and report.

[Mike7]

It was just a theoretical query. The pups I use don't have a provision for making a save folder.

[Max Headroom]

Here is a Selection of Me menu.lst Nb. the Comments

timeout 10
default 0

title Budda_K9_217_final ( w/ E-17 eNlightenment )
partnew (hd0,3) 0x00 (hd0,0)/BuddaPup_217_final.iso
map --heads=0 --sectors-per-track=0 (hd0,0)/BuddaPup_217_final.iso (0xff)
map --hook
root (0xff)
kernel /vmlinuz pmedia=usbflash psavemark=1 pfix=fsck
initrd /initrd.gz
# ( known 2.17 initramfs issue! produces "/bin/sh: can't access tty; job control turned off."
# is there a Work around, Manual Edit Solution Please? I've Yet 2 Find any answers )

title Custom ( Dual Boots 1.09 or 2.0 )
partnew (hd0,3) 0x00 (hd0,0)/custom.iso
map --heads=0 --sectors-per-track=0 (hd0,0)/custom.iso (0xff)
map --hook
root (0xff)
kernel /vmlinuz pmedia=cd psavemark=1 pfix=fsck
initrd /initrd.gz
# Ke*nel Panic-not syncing: VFS: Unable to mount root fs on unknown-block (3,65 )

title Grub ( Dual Boots GrafK9 2.0 Opera or Mean Pup by John Murga )
partnew (hd0,3) 0x00 (hd0,0)/grub.iso
map --heads=0 --sectors-per-track=0 (hd0,0)/grub.iso (0xff)
map --hook
root (0xff)
chainloader (0xff)
# Only gets the Splash Screen 2 Choose, then Error 23, Error while Parsing

title Mac_K9_550
partnew (hd0,3) 0x00 (hd0,0)/Macpup_550.iso
map --heads=0 --sectors-per-track=0 (hd0,0)/Macpup_550.iso (0xff)
map --hook
root (0xff)
kernel /vmlinuz pmedia=cd psavemark=1 pfix=fsck
initrd /initrd.gz
# All Good!

title Media_Dingo1-0a ('Lfa ) ( based on Dingo 4.12 Retro ie. K2.6.21.7, Released Jan 2009 )
partnew (hd0,3) 0x00 (hd0,0)/MediaPup1-0a.iso
map --heads=0 --sectors-per-track=0 (hd0,0)/MediaPup1-0a.iso (0xff)
map --hook
root (0xff)
kernel /vmlinuz pmedia=cd psavemark=1 pfix=fsck
initrd /initrd.gz
# Boots 2 Desktop, But Missing Network Modules!

title New_Yea's_Dingo_MU-02-rc10-micro ( A Dingo 4.11 Favorite! )
partnew (hd0,3) 0x00 (hd0,0)/NewyearspupMU-02-rc10-micro.iso
map --heads=0 --sectors-per-track=0 (hd0,0)/NewyearspupMU-02-rc10-micro.iso (0xff)
map --hook
root (0xff)
kernel /vmlinuz pmedia=usbflash psavemark=1 pfix=fsck
initrd /initrd.gz
# Error 15, File Not Found ( This is SumWot Frustrating Because Most Other Dingoes Work, ie. Series 4 )

title Photon301 ( Tmxxine, w/ K2.6.18.1 )
partnew (hd0,3) 0x00 (hd0,0)/photon301.iso
map --heads=0 --sectors-per-track=0 (hd0,0)/photon301.iso (0xff)
map --hook
root (0xff)
kernel /vmlinuz pmedia=cd psavemark=1 pfix=fsck
initrd /initrd.gz
# All Good!

title Producer_DingoV1_1
partnew (hd0,3) 0x00 (hd0,0)/ProducerPupV1_1.iso
map --heads=0 --sectors-per-track=0 (hd0,0)/ProducerPupV1_1.iso (0xff)
map --hook
root (0xff)
kernel /vmlinuz pmedia=cd psavemark=1 pfix=fsck
initrd /initrd.gz
# All Good!

title Dingo_it_Up-V-1-2--412
partnew (hd0,3) 0x00 (hd0,0)/pupitup-v-1-2-puppy-412.iso
map --heads=0 --sectors-per-track=0 (hd0,0)/pupitup-v-1-2-puppy-412.iso (0xff)
map --hook
root (0xff)
kernel /vmlinuz pmedia=cd psavemark=1 pfix=fsck
initrd /initrd.gz
# All Good!

title P'Lite-5.0-K2.6.25.16 ( w/ Dingo Ke*nel )
partnew (hd0,3) 0x00 (hd0,0)/puplite-5.0-k2.6.25.16.iso
map --heads=0 --sectors-per-track=0 (hd0,0)/puplite-5.0-k2.6.25.16.iso (0xff)
map --hook
root (0xff)
kernel /vmlinuz pmedia=cd psavemark=1 pfix=fsck
initrd /initrd.gz
# All Good!

title Dingo-4.2.1-MULTIUSER-r3
partnew (hd0,3) 0x00 (hd0,0)/puppy-4.2.1-MULTIUSER-r3.iso
map --heads=0 --sectors-per-track=0 (hd0,0)/puppy-4.2.1-MULTIUSER-r3.iso (0xff)
map --hook
root (0xff)
kernel /vmlinuz pmedia=cd psavemark=1 pfix=fsck
initrd /initrd.gz
# All Good!

title P'Studio3.1
partnew (hd0,3) 0x00 (hd0,0)/PuppyStudio3.1.iso
map --heads=0 --sectors-per-track=0 (hd0,0)/PuppyStudio3.1.iso (0xff)
map --hook
root (0xff)
kernel /vmlinuz pmedia=cd psavemark=1 pfix=fsck
initrd /initrd.gz
# All Good!

title P'Rescue_2.5
partnew (hd0,3) 0x00 (hd0,0)/PupRescue_2.5.iso
map --heads=0 --sectors-per-track=0 (hd0,0)/PupRescue_2.5.iso (0xff)
map --hook
root (0xff)
kernel /vmlinuz pmedia=cd psavemark=1 pfix=fsck
initrd /initrd.gz
# All Good!

title Dingo_Server-435
partnew (hd0,3) 0x00 (hd0,0)/pupserver-435.iso
map --heads=0 --sectors-per-track=0 (hd0,0)/pupserver-435.iso (0xff)
map --hook
root (0xff)
kernel /vmlinuz pmedia=cd psavemark=1 pfix=fsck
initrd /initrd.gz
# All Good!

title Tmxxine_Prism
partnew (hd0,3) 0x00 (hd0,0)/tmxxine_prism.iso
map --heads=0 --sectors-per-track=0 (hd0,0)/tmxxine_prism.iso (0xff)
map --hook
root (0xff)
kernel /vmlinuz pmedia=usbflash psavemark=1 pfix=fsck
initrd /initrd.gz
# Same issue as BuddaPup

title More ISOs (see the instructions)
configfile (hd0,x)/menu.lst
commandline

[rcrsn51]

I tried ISObooter with a couple of 2-series Puppies and they didn't work at all.

Here's how ISObooter works. It creates a temporary fourth partition on the flash drive and mounts the ISO there. It then boots Puppy using its vmlinuz and initrd.gz. Puppy must then be smart enough to search for its SFS file in alternate locations - ie. the fourth partition of the flash drive. It would appear that old Puppies were not capable of doing this.

[Max Headroom]

Won't work Please?

[rcrsn51]

Error 15 is a GRUB error. It can't find the core file initrd.gz. Try setting up ISObooter using "splashscreen=y".

[Max Headroom]

Mate! :)K

[gyro]

But now that Puppy has the option of using a save folder, there is a better way.

I've tried this using a very slow 32GB stick with ext4 on the second partition. It works fine, but slow to save.
This is a great way to try a puppy iso, without burning to a cd, or disturbing the hard drive, thanks.

However I have 2 suggestions you might consider;

1) Use "pmedia=usbflash" instead of "pmedia=cd", so that puppy doesn't touch the internal drives, only searches the usb stick.

2) Support the second partition within isoBooter, perhaps with something like the following patch:

Code: Select all

--- isobooter.orig	2013-02-11 12:37:42.000000000 +1000
+++ isobooter	2016-01-30 07:40:45.034838215 +1000
@@ -29,6 +29,18 @@
   exit
 fi
 
+let SAVENO=PARTNO+1   #2,3,4
+if [ $SAVENO -gt 1 -a $SAVENO -lt 4 ]; then
+  if [ "$(grep ${DRV}${SAVENO} /proc/partitions)" ]; then
+    echo 
+    echo -n "Do you want puppy to save to ${DRV}${SAVENO} partition? [y/n] "
+    read REPLY
+    if [ "$REPLY" = "y" ]; then
+      PARTNO=$SAVENO
+    fi
+  fi
+fi
+
 rm -f menu.lst
 echo "timeout 10" >> menu.lst
 echo "default 0" >> menu.lst

Note: I intend to try again using f2fs instead of ext4 and report results.

gyro

[rcrsn51]

But now that Puppy has the option of using a save folder, there is a better way.

I've tried this using a very slow 32GB stick with ext4 on the second partition. It works fine, but slow to save.

How did it compare to the standard FAT32 save file?

1) Use "pmedia=usbflash" instead of "pmedia=cd", so that puppy doesn't touch the internal drives, only searches the usb stick.

When I started developing ISObooter, "pmedia=usbflash" was the obvious choice. But it didn't always work because the main SFS file is hiding on the phantom fourth partition. I needed "pmedia=cd" to make Puppy hunt for it. New Puppies may work better.

There were also some issues at shutdown. "Pmedia=usbflash" locked you into putting the save file on the flash media. "Pmedia=cd" gave you more flexibility. But this also may have changed.

[Edit] In the meantime, I have added an update here so users can make the change manually.

Support the second partition within isoBooter

I will give that some thought.

[Edit] If you implement this and run ISObooter with "splashscreen =N", you get a confusing result.

[gyro]

How did it compare to the standard FAT32 save file?

I don't know, I never use savefiles only savefolders.
I found that f2fs, might be slightly faster than ext4 but if so, hardly noticeable. ( I've seen benchmarks show f2fs is a bit faster than ext4 on an SSD.)
I've always found that any setup that saves to a usb stick is too slow for general use. (I might using a fast SDcard sometime.)
I tested using tahrpup64 5.0.3, and creating an f2fs partition is more difficult than ext4, because gparted would not create and f2fs partition, I had to create and unformatted partition and then format it.
Also the current 'initrd.gz' can only fsck ext2, ext3 and ext4, and I prefer to fsck my partitions before they are first mounted. (the Unix way).
So I will stick with ext4.

When I started developing ISObooter, "pmedia=usbflash" was the obvious choice. But it didn't always work because the main SFS file is hiding on the phantom fourth partition. I needed "pmedia=cd" to make Puppy hunt for it. New Puppies may work better.

Not a problem to me. if I want the main SFS on a hard drive, I'll do a normal frugal install.
I prefer an isoBooter that produces a puppy on a usb device that is completely portable, completely independent of any hard drives.

There were also some issues at shutdown. "Pmedia=usbflash" locked you into putting the save file on the flash media. "Pmedia=cd" gave you more flexibility.

Again, If I want any part of puppy on a hard drive, I'll use a normal frugal install.

As regards my suggestion to support partition 2;

[Edit] If you implement this and run ISObooter with "splashscreen =N", you get a confusing result.

I tested by answering 'n' to all isoBooter questions except for the new partition 2 one, and it produced a 'menu.lst' as expected that worked as expected.

Summary:
For now, I find isoBooter to be a wonderful alternative to burning an iso to a CD.
So I will use it optimised for that purpose.

gyro

[gyro]

I tested using tahrpup64 5.0.3, and creating an f2fs partition is more difficult than ext4, because gparted would not create and f2fs partition, I had to create and unformatted partition and then format it.

My bad, sorry.
I just did it again on tahrpup 6.0.5 and f2fs is there in the list of filesystems for partition creation. (Don't know how I missed it.)

Anyway, using a micro SDcard in a usb adapter seems significantly faster than the ordinary usb stick.

gyro

[bigpup]

What affects USB flash drive speed.

Counterfeit products

Counterfeit USB flash drives are sometimes sold with claims of having higher capacities than they actually have. These are typically low capacity USB drives which are modified so that they emulate larger capacity drives (for example, a 2 GB drive being marketed as a 64 GB drive). When plugged into a computer, they report themselves as being the larger capacity they were sold as, but when data is written to them, either the write fails, the drive freezes up, or it overwrites existing data. Software tools exist to check and detect fake USB drives,[48][49] and in some cases it is possible to repair these devices to remove the false capacity information and use them normally, as the low-capacity drives they are.[50][51]

File transfer speeds

Transfer speeds are technically determined by the slowest of two, sometimes three factors - the USB version used and the speed in which the USB controller device can read and write data onto the flash memory. Third factor is the speed of the hardware bus, in the case of add-on USB ports.

USB flash drives usually specify their read and write speeds in megabytes per second (MB/s); read speed is usually faster. These speeds are for optimal conditions; real-world speeds are usually slower. In particular, circumstances that often lead to speeds much lower than advertised are transfer (particularly writing) of many small files rather than a few very large ones, and mixed reading and writing to the same device.

In a typical well-conducted review of a number of high-performance USB 3.0 drives, a drive that could read large files at 68 MB/s and write at 46 MB/s, could only manage 14 MB/s and 0.3 MB/s with many small files. When combining streaming reads and writes the speed of another drive, that could read at 92 MB/s and write at 70 MB/s, was 8 MB/s. These differences differ radically from one drive to another; some drives could write small files at over 10% of the speed for large ones. The examples given are chosen to illustrate extremes.[52]

[gyro]

But now that Puppy has the option of using a save folder, there is a better way.

1. Format your flash drive with two partitions - a FAT32 for your ISOs and an ext4 for storage. Update: f2fs may be faster than ext4.
2. Set up the first partition with ISObooter as usual, but select "Boot from splash screen = n".
3. Edit the menu.lst file and change "psavemark=1" to "psavemark=2".
4. Boot off the flash drive. At first shutdown, make a save folder. Puppy is smart enough to put it on the second partition.
5. On subsequent shutdowns, you should find the saving procedure to be much faster.

But how do you get to here if you're starting with a windows only machine?
I did it the following way:
1) Follow the windows recipe for making an isoBooter usb stick, as provided earlier.
2) Boot, using this usb stick, but do not reboot or shutdown.
3) Create a new directory in the puppy home directory and copy the contents of the usb stick into it.
4) Now, use the linux recipe to format the usb stick, with 2 partitions. (You could also remove the usb stick and format a different one.)
5) Copy the 'grldr', 'isobooter' and 'linux.iso' files from step "3)" into the new, much smaller, fat32 partition on the usb stick.
6) You are now ready to continue the linux recipe in the first post at step "7b." and rcrsn51's recipe above at step "2."
In this case step "3." from rcrsn51's recipe above, means reboot the usb stick without 'saving'.

Basically, the first boot of an isoBooter usb stick created in windows is used as the host linux to implement the linux recipe.

gyro