Message-ID: <4315514C.21EB552A@att.net> From: Bela Lubkin
Newsgroups: comp.unix.sco.misc Subject: Re: Importat Sco 5 Openserver Bootproblem Date: 31 Aug 2005 03:47:01 -0400 Message-ID: <firstname.lastname@example.org> References: <email@example.com>
<4315514C.21EB552A@att.net> Steve Fabac wrote: > I have used Ghost to copy an SCO Openserver 5.0.5 system > disk to a new disk. This was on a client's Compaq Proliant > with 4G Compaq SCSI disk. I chose to Ghost the root disk > in order to preserve the Compaq utility partition and all > its files as Backup Edge will not restore non-UNIX partitions. > > I sold the client an Adapted 2110S RAID controller and two 36G > Hitachi SCSI disks to replace the two 4G Compaq disks on the > cha controller. > > The sequence I followed was to install the dpti5 btld driver > into the running kernel before taking the system down. I then > powered down and installed the 2110S controller without the > hard drives. I rebooted the system to make sure that it will boot > with the 2110S installed (no hang on boot, etc. ). > > Then I powered down and connected one of the 36G disks to the 2110S > and upon boot up, entered the Adaptec SMOR configuration utility > (Control-A) and verified that SMOR shows the 36G disk at ID0. > > When I rebooted with the unconfigured 36G disk, the system > displayed the message: "Insert bootable disk and hit any key" > indicating that the 2110S has boot priority over the onboard > Compaq SCSI controller. > > I then used a Ghost boot floppy and selected "image all" to > copy the Compaq root disk to the new 36G disk on the 2110S. > > Once Ghost finished, I rebooted and pressing F10 entered the > Compaq Utility without problems. I then booted the new disk > to maintenance mode by entering the defbootstr command: > boot: defbootstr Sdisk=dpti(0,0,0,0) and the 30G disk booted ok. > I entered the root password and ran fsck -ofull on all the divisions > and fsck completed without an error message. > > However, fdisk showed that the entire disk was configured as a UNIX > partition and dfspace showed only 4G (same size as the Compaq > root disk). I corrected this by running dparam and stamped the disk > as 4462 cyl by 255 heads by 63 sectors then after rebooting, fdisk > showed the unused space which I then configured as a second UNIX > partition (/dev/hd02). Divvy -m /dev/hd02 allowed me to create > additional divisions on the new partition. > > I then rebooted and used SMOR on the 2110S to disable the 2110S from > booting. Upon reboot, the original Compaq root disk booted and > I ran mkdev hd and added the 36G disk on the 2110S as another > disk. I did not allow the disk initialization to recreate any of the > divisions on the 36G disk and just named them nroot, nswap, nboot, etc. > I mounted nroot (the Ghosted root on the 36G disk) on /mnt. I then > ran "find . -type f -mount -print > /tmp/bob" from / and edited > /tmp/bob to create a script to run sum -r on the original file > on the 4G disk root and on the same file on the 36G disk root > (root files copied via Ghost and mounted as nroot on /mnt) to make > sure that there were no errors in the files copied by Ghost. > The only differences were in log files created upon boot up, and > the link kit files modified after Ghosting the root disk and running > mkdev hd to add the 36G disk to the kernel on the original disk. > > I used cpio to copy all the non-root file systems from the old > Compaq disks to the new 36G disk. > > I powered down, removed the old Compaq disks, then mounted the two > 36G disks and enabled the 2110S to boot. I used SMOR to create > a RAID1 mirrored array: copying data from ID0 to ID1. > > The customer is still using this system today and the above installation > was performed on 8/18/2004. > > Maybe I was lucky, but Ghost worked for me and it preserved the Compaq > utility partition and copied the SCO partition without error. > > And, if the OP only needs to replace an old disk with a new disk and > does not need the additional space, he would not have to re-stamp the > disk geometry to recover the unused space on the new disk. > > As to why he has the "stage 1" boot failure: He may not have used > the "image all" configuration in Ghost, and he may have failed to > issue the defbootstr Sdsk=wd(0,0,0) directive to boot the IDE disk. > (I can't remember the master vs slave vs primary vs secondary switches > to the wd(x,x,x) string and don't choose to look it up for this post.) That's a deliberate long quote. The short summary response is: you did in fact get lucky. But not very lucky. OSR5 is overly concerned about the "geometry" of a disk. On all modern disks, the geometry the OS is so worried about is an utter hallucination -- but it must be a _shared_ hallucination. The imaginary geometry used when the disk is created must match the figment of the current kernel's imagination, or it won't boot. Many OSR5 HBA drivers make up a fake geometry of 255 heads and 63 sectors/track, as you used above. You apparently transferred your Ghost image from one HBA to another, both of which use that geometry. (I'm oversimplifying the relationship of HBA to geometry: many drivers use different geometries depending on the actual size of the drive. By moving to a larger drive, you tempted fate by encouraging your driver to switch geometries.) There are things you can do to mitigate these issues. On releases before 5.0.7, the thing to do is: before you capture the drive image, boot the system up and run: # DRIVE=/dev/rhd00 # dparam -w $DRIVE # dparam $DRIVE `dparam $DRIVE` Let's break this down: # DRIVE=/dev/rhd00 /dev/rhd00 is the raw device node for the first (usually boot) drive. The first four drives in an OSR5 system are likely to have /dev/rhd?0 nodes. All drives (including both the first four and any higher ones) will have /dev/rdsk/?s0 nodes. So if you were migrating your 14th drive, you'd want to use "DRIVE=/dev/rdsk/13s0" ... # dparam -w $DRIVE This writes an OSR5 masterboot sector to the drive. Your boot drive likely already has this, but other drives won't. The OSR5 masterboot sector contains an optional structure that records the disk's geometry. We can't write that structure if it isn't present. Note: if you're doing this to the boot drive, and you use a different MBR-resident boot manager (like some configurations of LILO and GRUB), this will overwrite it. To overcome that you would need to do a different, non-geometry-dependent sort of backup (like a supertar). # dparam $DRIVE `dparam $DRIVE` This "stamps" the drive with the geometry by which the current kernel knows it. Now when you make an image backup of the drive, it will contain this embedded notion of the geometry. The kernel will know what to do with it even on a different drive or HBA. I said "before 5.0.7". That's because the situation improves in 5.0.7. Before doing the image backup, make sure you're updated to MP3 (and UP3 if you have a SCO Update license). The OSR507 MP series includes updates to how the geometry mechanism works. You may also need to separately install the "Wd Driver Supplement" that was issued with MP3; I forget whether it was 100% included in MP3. Adding the supplement on top of MP3 or UP3 won't hurt, so install it. Once all that is updated, the boot and kernel code will be able to figure out the right hallucinatory geometry no matter where you take the data... I don't know the situation in OSR6. The UW-based kernel also has a deep dependency on geometry, but the details are different. I don't know if the device-independent geometry feature was ported. >Bela<
Got something to add? Send me email.