[nflug] Live CD help

[Sam Stern]

Hi Joe,

>>>>>
<snip>
>>>
>> Totally cool.  When I get my DSL working, I'll be able to
>download it.
>> I used F2 & F3 and came up with
>> dsl vga=normal 2
>> That works great.
>> BTW, my first attempt bombed (after a bunch of hours) when
>the backup
>> file exceeded 2GB on the FAT32 partition.
>> Since I seem to remember something about that being a design
>> limitation (and because I didn't have time to figure out how

It is; Fat32 cannot create or access files bigger than 2 giga bytes in
size.

>to split
>> the file on the fly), I redid the usb drive as one big ext3
>partition
>> and started it up again.  It's still running after about 7 hours -
>> very old, very slow, usb 1.1 notebook.  But, if it's running this
>> long, there's a good chance it will successfully complete.
>>
>> Do you know how to apply split or some other filter that would allow
>> me to use a FAT32 partition in the future?  I'm somewhat
>competent in
>> bash, so if you tell me how to do it, I can figure out the rest.


Huh, I gave some thought but did not come up with much -- especially since
we are constrained to console commands. I would think that this job calls
out for a tidy little perl, tcl, python or similar script.

My first thought was something like:

Backup

 dd -f=/dev/hda | buffer | split -b 2000M

Restore
 cat file1 ..  filex | buffer | dd of=/dev/hda


That said, I think the idea of splitting the file is not wise. It's just a
work around for a fundamental limitation of the storage media. Thus adding
complexity to the project.

Since we are using Linux to make the file and restore the backup I am not
certain that using fat32 for the storage medium makes much sense. I think
that using Ext3 and not fat32 to store the backup image is a smarter move.


While it's not relevant to your use it's important to note, and note well,
that usb keys have some inherent limitations as to how many times they can
be written to. At work I just found out about this limit when three test
keys failed. The number of write cycles is high but finite -- you will not
encounter the ~10,000 cycle write failure limit in this project but you
might run into the limit if you store valuable documents that are frequently
accessed on your usb key. To learn more about this limit please google "usb
key write limit".



Good Luck!

Sam S.


_______________________________________________
nflug mailing list
nflug at nflug.org
http://www.nflug.org/mailman/listinfo/nflug