how_to_clone_tru64_and_digital_unix
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
how_to_clone_tru64_and_digital_unix [2018/12/11 16:05] – sgriggs | how_to_clone_tru64_and_digital_unix [2019/06/25 06:40] – [It Boots but It's Horked Up] sgriggs | ||
---|---|---|---|
Line 24: | Line 24: | ||
- Do not try to eliminate the /usr file system for UFS __and__ AdvFS. Startup scripts in **/ | - Do not try to eliminate the /usr file system for UFS __and__ AdvFS. Startup scripts in **/ | ||
- You might have read about **sysman** clone features. Forget that. That tool is garbage and will cause you much more pain than it saves you. Plan on doing it manually yourself or have an expert do it for you using this process. | - You might have read about **sysman** clone features. Forget that. That tool is garbage and will cause you much more pain than it saves you. Plan on doing it manually yourself or have an expert do it for you using this process. | ||
- | - Do not plan on using the **dd** method unless you have completely identical disks. That has several major drawbacks otherwise. The worst include performance problems (due to bad geometry alignment on the disklabel) and loss of space if the target disk is larger (or loss of __data__ if the target disk is smaller). | + | - Do not plan on using the **dd** method unless you have completely identical disks. That has several major drawbacks otherwise. The worst include performance problems (due to bad geometry alignment on the disklabel) and loss of space if the target disk is larger (or loss of __data__ if the target disk is smaller). |
==== Take Inventory ==== | ==== Take Inventory ==== | ||
Line 212: | Line 212: | ||
Another file you //might// have to alter is your **/ | Another file you //might// have to alter is your **/ | ||
+ | |||
+ | |||
+ | === Final Steps === | ||
+ | |||
+ | Insure that you have completed these steps. | ||
+ | |||
+ | - Install the boot loader using disk label | ||
+ | - Edit the disklabel on your target disk | ||
+ | - Re-create UFS or AdvFS file systems | ||
+ | - Copy files over from the original | ||
+ | - Fix the **/ | ||
+ | |||
+ | You should have done all these steps before you attempt the new disk. | ||
+ | |||
+ | ==== Final Boot ==== | ||
+ | |||
+ | Now the system is ready to reboot. You probably want to understand a bit of interaction with what we call the SRM console. The main thing you want to do is to check the values of the following. | ||
+ | |||
+ | - **show dev** This will show you all the devices (NICs, HBAs, and of course disks). You need to know which disk is your target versus destination disk. The device list should have clues like the manufacturer name and the device model. | ||
+ | - The **boot** command takes the disk name as an argument. For example: "boot dka0" or "boot dqa0" would boot each of those disks respectively. Also, if you'd like to try single user mode you'll want to use the "-fl s" argument to boot into single user mode (if you do then remember to use **bcheckrc** command to make single user mode usable). | ||
+ | - The **show** command is the compliment of the **set** command. These allow you to view and alter the names of SRM variables which alter boot and system behavior. | ||
+ | - Understand the variables that matter most like **BOOTDEF_DEV** which points to the default boot device on the system. Another you might want to understand is **AUTO_ACTION** which governs if the system will automatically try to boot up the system or halts at the SRM chevron prompt. The action names are **boot** or **halt**. | ||
+ | |||
+ | So, what do you normally need to do? Try to boot the clone but don't yet change the default boot device until you are ready to completely switch over to the clone. | ||
+ | |||
+ | ==== Troubleshooting | ||
+ | |||
+ | Cloning was something that DEC intended folks to use **sysman** for. Unfortunately, | ||
+ | |||
+ | ===== The Drive will not Boot ===== | ||
+ | |||
+ | If you issue the **boot** command from the SRM console but you never see the kernel line saying "UNIX Boot" then you probably had an issue with the boot sector. Do the following. | ||
+ | |||
+ | - Re-mount the target disk and make double sure that you have the kernel on the root file system. These would be in the form of two files named **vmunix** and **genvmunix**. Without a kernel, you can't boot the system. They should be there as a result of your file copy effort. | ||
+ | - Unfortunately, | ||
+ | |||
+ | ===== It Hangs During Boot ===== | ||
+ | |||
+ | Depends on why and where it hangs. The most common issues are these. | ||
+ | |||
+ | - You forgot to edit out some kind of reference to the swap device. Check the post-copy steps again. One of the startup scripts probably tried to activate swap on a device that won't. Remember that you can use single user mode to fix these issues without doing a full re-install. References to swap could be in in the __/ | ||
+ | - You are using UFS and you forgot to fix the reference to the **/ | ||
+ | - Make sure your copy method preserved all the permissions, | ||
+ | - Do NOT try to eliminate one of the default AdvFS file domains (one for root and another for /usr). As mentioned earlier, the startup scripts reference both **root_domain** and **usr_domain** and if you change their names or eliminate one of them the startup scripts will fail. | ||
+ | - Make sure your SRM variables for __boot_file__ and or __boot_flags__ may be incorrect and have old VMS data in there or some other garbage. Your boot file should be your kernel, which is usually __/vmunix__ or __/ | ||
+ | |||
+ | ===== It Boots but It's Horked Up ===== | ||
+ | |||
+ | - Double check your swap is pointing to the right place and working (swapon -s) | ||
+ | - Make sure your filesystems are not showing up with weird or generic names. Double check your source and destination device and make sure that your old device name isn't still leftover in a config file somewhere. Most commonly it's the **/ | ||
+ | - Make sure if you use a new system type that any kernel tuning you do makes sense. Ie.. if you take parameters from a system that has 4GB of RAM and try to use them on a big GS1280 with 64GB of RAM then you are almost certainly going to have some bad tuning in there. Double check your __sysctl__ settings with **sysctl -a**. | ||
+ | |||
+ | If you have problems beyond the ones documented, then consider contacting PARSEC for some consulting work to help you! | ||
+ | |||
+ | |||
how_to_clone_tru64_and_digital_unix.txt · Last modified: 2023/09/08 23:04 by sgriggs