[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] Cloning drives, no network or compression



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 redhat com
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]