[K12OSN] Cloning drives, no network or compression

[Peter Scheie]

Actually, this sounds like a good case for using LTSP with the machines, cable 
plant aside.  Would stringing some cat6 cable to these machines, one by one, be 
out of the question?  Considering a modest server can be had for $500, you could 
then show how those old machines can be given new life just by having a new wire 
pulled.  I think it would be cheaper than trying to buy RAM for such old 
machines.  Just a thought.

Peter

Scott S. wrote:
> Terrell, you hit several nails right on the head, and gave me some good 
> clues!
> 
> Terrell Prudé Jr. wrote:
>> I've used dd to clone Debian boxes before, but in my case, it was to 
>> identical hardware.  You're right in that dd does overwrite the entire 
>> disk, MBR and all, provided that you use correct syntax, of course.  :-)
> 
> dd will clone any possible readable disk, even if the host OS can't 
> mount it. For data recovery with possible bad disks, dd_rhelp: 
> http://vaab.free.fr/utilities/dd_rhelp/index.en.html is great, it can 
> reduce time by weeks from a dd clone with bad sectors.
> 
>> You have a true cluster-flock of a network.  IBM type 2?  I haven't 
>> seen that in well over a decade.
> 
> Agreed, not my choice. It's legacy-ville all the way. Mission-critical 
> servers have nice spiffy new things with big pipes, but not the old things.
> 
>> First off, to which MS Windows would you convert? 
> 
> This scenario is my employment, and I am fortunate that my immediate 
> boss has heard of Linux and is encouraging me. Above him, I have pointed 
> out the TCO, and they just shrug it off as "the cost of doing business". 
> I am a thorn in their side, and hopefully a wedge to FOSS.
> 
> 
>> 1.)  Upgrade each of those boxes to *AT LEAST* 512MB DRAM. 
> 
> There is a limited subset of apps needed, and aside from slow loading, 
> 256 is acceptable so far.
> 
>> 2.)  Take a look at "preseeding" with Debian/Ubuntu. 
> 
> I did, for some time. I couldn't get everything to work like I thought 
> it should.
> 
>> For EIDE disks (I'm guessing that's what type you have in these boxes), 
> 
> Yes, I did not mention there were no SATA or SCSI.
> 
>> yep, I always tell the BIOS to use LBA.  But if you do that, then make 
>> sure that the box on which you made the original image also had its 
>> BIOS set to use LBA. 
> 
> Aha, this was what caught my attention. Thank you very much! The very 
> original start was a VMware instance, with the default generic Phoenix 
> BIOS stuff. It started out as generating a bootable liveCD via 
> remastersys. The problem there was that the original Ubuntu required 384 
> meg to boot to liveCD, even when the completed install ran in 256 OK. It 
> was very trimmed down, one desktop, no visual effects, etc. Adding 128MB 
> of RAM to all the machines for install was a big slowdown.
> 
> I then used one of the fresh liveCDs to install to a 4 gig drive, 
> initially thinking about using dd, and keeping it down to DVD size. 
> After factoring in some realities about size, I knew that each of the 
> destination machines would never install another app, never generate any 
> local info, and email was all stored on the email server. I trimmed it 
> down to the 2.6 gig size on the real physical 4 gig drive. Here's the 
> punch line... I used default BIOS stuff on everything, both VMware and 
> the physical drive. I may need to back up and check at the BIOS in the 
> actual machine that had the 4 gig drive.
> 
>> What is the specific GRUB error that you're seeing?  The GRUB 
>> documentation lists 34 possible error codes.
> 
> I will check it on Monday.
> 
> Thanks!
> Scott S.
> 
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
>