Announcement

**capt-zero** · Apr 03, 2012, 07:46 PM

Woodsmoke,

This is a problem I've been wrestling with for a while now, with a little luck and a LOT of advice I've recieved here. I am a newbie to linux so while I'm dealing with this issue, I'm also having to dig through a lot of terminal jargon that's new to me. I never got very far with the old Dos 3.3 years ago, hopefully I'll do better with this.
I was ready to give up last week, but just shelved it for a couple of days instead. I've learned so much about the basics working with it, that even if I fail at making an installed USB distro, I will have gained a lot if insight into the way the language works. I'll keep everyone posted on my progress.

**woodsmoke** · Apr 03, 2012, 07:54 PM

Thanks very much for the kind reply capt-zero and I, for one, look forward to hearing of your progress.

woodsmoke

**woodsmoke** · Apr 11, 2012, 07:59 PM

Hi
I was hoping that others who had attempted this would hop in and post but I guess that I will go first.

SanDisk Cruzer 16 GB
Knoppix "saw" the SanDisk U3 files but would not remove them.
I used the approved SanDisk U3 removal utility. It operates in a very short and simple manner. It asks if you really want to remove the files and warns that it will reformat the flash drive. One then clicks "yes" and it "does it".

HOWEVER even though it "removes and formats" ....it leaves the original part of the physical drive in a completely UNreadable state.

Nothing, including Windblows, seems to be able to "see" that part of the physical drive. The "rest" of the drive, where the data one put on the drive was stored, is, indeed, there.

This seems to the old woodsmoker to be a "backhanded" "slap in the face" of the stupid people who want to remove the wonderful software that SanDisk provides.....which also provides wonderful linkys to other items of software which pay SanDisk to provide such links.

But....to get back to the install.

What one is left with is 14.91 GB from the 16 GB.

The latest "nightly build" of Kubuntu Precise was attempted.

A MAJOR CAVEAT BEFORE ATTEMPTING THE INSTALL;

#### remove ANY device that is a usb device, such as a printer, before attempting the install.
#### ESPECIALLY any other "flash" device, if one does not "pay attention".... just about ANY distro will try to ...install on any usb storage devices that it finds.... if there are two flash drives...it will hit both if one is not paying attention.

It went EXACTLY as one would expect an install on a "spinning disk" to proceed.

The resultant partitions were:

The "physical drive": /dev/sda is described as "msdos".

/dev/sda1 as ext4 mount point was "/" size 12.91 GB, 8.37 GB was used, the flag was "boot".
/dev/sda2 as "extended" size was 2.0GB with 2.0 GB used.
/dev/sda5 as linuxswap with 2.00 GB.

It runs flawlessly, updates were as normal, I did NOT use apt-get, but used Muon.

Notes:

A) As I have mentioned in other posts I save any and all data to BOTH the "hard drive" and a USB device when I save anything. It is an "extra step" but I have become used to it. So...
B) I am going to attempt installs of other distros on other spare usb drives to see what happens.
C) It may be that I will soon not install on spinning disks.

Question.

I am wondering if it would be possible to "just copy" the install that is on flash drive "A" to flash drive "B" and B "just work". If the situation holds....then the whole thing about trying to "back up" a system would be rendered moot. An intriguing question. :?

If anyone has attempted it, the old woodsmoker would like to read such a report.

woodsmoke

**Snowhog** · Apr 11, 2012, 08:04 PM

Originally posted by woodsmoke View Post

Hi
I used the approved SanDisk U3 removal utility. It operates in a very short and simple manner. It asks if you really want to remove the files and warns that it will reformat the flash drive. One then clicks "yes" and it "does it".

HOWEVER even though it "removes and formats" ....it leaves the original part of the physical drive in a completely UNreadable state.

Nothing, including Windblows, seems to be able to "see" that part of the physical drive. The "rest" of the drive, where the data one put on the drive was stored, is, indeed, there.

Me thinks you might have done the removal incorrectly?

Usage

Examples:

Removing U3 cd partition, making it a ordanarry UFD, under MS Windows where e:\ is one of the U3 device drives.

u3_tool.exe -p 0 E

Unlock secured data partition under Linux 2.6.20+

# ./u3_tool -u /dev/sg3

Replace /dev/sg3 with the scsi generic device associated with your device. The correct device can be deduced from the dmesg output.

**woodsmoke** · Apr 11, 2012, 08:09 PM

Hi SnowHot

I try to do things like a "new user" would attempt them.

But, yes, I did do the Linux "unlock" but did it using the Knoppix file system.

Probably/possibly, if I had done what you did then it would have produced the "whole disk" for use.

So...the question that arises in the old woodsmoker's old bean is that it "might be" that somebody who works with Knoppix, or possibly any distro, could produce a "script" that would be placed in the menu as "install to SanDisk" and the script would do what you posted and then do the install.

don't know, just an idea of somebody that is not too bright.

woodsmoke

**Snowhog** · Apr 11, 2012, 08:16 PM

You are more than bright enough! I won't say that the if you had utilized the u3-tool that your results would have been different -- I my self have not had the opportunity to have to use it (I don't purchase SanDisk USB sticks), but I think that you would have been able to recover the full space if you had.

Description-en: tool for controlling the special features of a U3 USB flash disk
Tool for controlling USB flash devices that conform to the U3 specifications.
You can do the following with your U3 flash:
* Replace the CD image
* Change the size of the virtual CD or completely remove it
* Enable and disable security
* Unlock and change the password of secured U3 device
* Obtain various device information

**james147** · Apr 11, 2012, 08:21 PM

I installed Archlinux on a 16gig usb without issue compared to a normal arch linux install (well, actually there where lots of issues, non related to the install media, just my stupidity of trying to do things the complicated way

).

I see no reason why an install to a usb should be any different from an install to a hdd. Linux basically treats both the same, or at least close enough for it to not be a problem.

There is only one problem (apart from the fact that usb drives are generally external and more likely to get damaged) I have found with doing this for something other then a recovery disk and that is speed. From what I can tell most usb(2.0) flash drives are horribally slow. I measured speed from dd in the order of 2-10mb/s writing on my various usbs, where as my internal disks measured about 60-90mb/s (newer ones tending towards 90mb/s). My usb3 drive rated in about 30mb/s on a usb2 port and about 60mb/s on a usb3 port (and is the drive I installed the archlinux install to). This is just from my experience and the tests I preformed were only meant to give me a ballpark figure and not test real world performance or in anyway used to judge the drives beyond basic read/write speeds.

I would guess that a 4gig stick is enough to install just about any system on, though you will be tight for space for additional applications, an 8 or 16gig should be plenty (considering you can only really buy them in those sizes).

**woodsmoke** · Apr 11, 2012, 08:45 PM

Hi James147

you wrote:

flash drives are horribally slow

The old woodsmoker is typing this using Kubu on a usb drive and I really cannot perceive any speed difference from that of a hard drive.

I've read similar comments to yours in many places...

So...if any other people attempt a usb install I, for one, would GREATLY appreciate folks posting their perceptions about "speed".

woodsmoke

**SteveRiley** · Apr 11, 2012, 11:23 PM

Originally posted by woodsmoke View Post

So...if any other people attempt a usb install I, for one, would GREATLY appreciate folks posting their perceptions about "speed".

No need to rely on perception, which is easily fooled. Measure it:

Code:

sudo hdparm -t /dev/sd[i]X[/i]

**woodsmoke** · Apr 12, 2012, 12:01 AM

Awww SR mathematically thingys like that take all the FUN out of it.....

It's kinda like playing Bocce..... everybody decides on a "standard foot" to use in measuring, but as the afternoon wears on....and more beer/vino is consumed....and the stomach becomes full with the wonderful food....

Perceptions about the length of this or that "foot" change! lol

woodsmoke

**james147** · Apr 12, 2012, 06:09 AM

Originally posted by woodsmoke View Post

The old woodsmoker is typing this using Kubu on a usb drive and I really cannot perceive any speed difference from that of a hard drive.

It can be hard to tell, since linux is smart with how it handles disk io and ends up caching allot of stuff in memory which speeds things up considerably. I have noticed a large difference (in boot time and first run application start up times and generally loading large amounts of data from the disk) when on a slower usb. I do note that the speed of flash drives varies quite allot, the better quality ones are much faster then the cheaper ones (at least from the tests I have done) so it might be worth running a quick speed test on your various disks to find out how good they actually are

.

**SteveRiley** · Apr 12, 2012, 12:22 PM

hdparm offers two measurement modes. From man hdparm:

-t
Perform timings of device reads for benchmark and comparison purposes. For meaningful results, this operation should be repeated 2-3 times on an otherwise inactive system (no other active processes) with at least a couple of megabytes of free memory. This displays the speed of reading through the buffer cache to the disk without any prior caching of data. This measurement is an indication of how fast the drive can sustain sequential data reads under Linux, without any filesystem overhead. To ensure accurate measurements, the buffer cache is flushed during the processing of -t using the BLKFLSBUF ioctl.

-T
Perform timings of cache reads for benchmark and comparison purposes. For meaningful results, this operation should be repeated 2-3 times on an otherwise inactive system (no other active processes) with at least a couple of megabytes of free memory. This displays the speed of reading directly from the Linux buffer cache without disk access. This measurement is essentially an indication of the throughput of the processor, cache, and memory of the system under test.

Using -t will give you a more useful output for comparing the true speeds of various USB drives.

**woodsmoke** · Apr 12, 2012, 08:34 PM

SR you are just sooo smart....all that CLI stuff..... but there is a nagging question in my mind...what little mind that I have after consuming so many Cuba Libres...but anyway.....

is -t in any way comparable to using the tea timer as a benchmark?

just askin'.

woodsmoke

**The Liquidator** · Apr 13, 2012, 06:06 AM

I'm having a look at xpud at the moment. 60 Mb download. Create with unetbootin. Additional drivers and codecs downloaded and copied to the opt partition.

Boot time 10 seconds on a 6 year old dell 630m laptop. Only hassle is it doesn't save the wireless passwords (any thoughts on that please?). Limited application set (although interestingly it includes gparted) but it's meant as an alternative to chromium OS which won't run on my laptop as it uses a PAE kernel.

Announcement

flash drive installs: read 1st post B4 posting

flash drive installs: read 1st post B4 posting

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment