[K12OSN] Cloning drives, no network or compression
peter at scheie.homedns.org
Sat Nov 29 15:34:07 UTC 2008
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.
Scott S. wrote:
> Terrell, you hit several nails right on the head, and gave me some good
> 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.
> Scott S.
> K12OSN mailing list
> K12OSN at redhat.com
> For more info see <http://www.k12os.org>
More information about the K12OSN