how_to_clone_tru64_and_digital_unix
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revision | Last revisionBoth sides next revision | ||
how_to_clone_tru64_and_digital_unix [2023/09/08 22:49] – [A Note About Alphaserver Compaq Smart Array Contollers] sgriggs | how_to_clone_tru64_and_digital_unix [2023/09/08 23:03] – [Fix AdvFS Domains in /etc/fdmns] sgriggs | ||
---|---|---|---|
Line 275: | Line 275: | ||
Once you've re-created your slices (partitions) and got your data copied over then you are ready to begin making the final tweaks that will make sure the system is bootable. | Once you've re-created your slices (partitions) and got your data copied over then you are ready to begin making the final tweaks that will make sure the system is bootable. | ||
+ | |||
+ | ==== Dynamic Disk Reconfiguration in Tru64 5.x Horks AdvFS ===== | ||
+ | |||
+ | There are a lot of situations in which your clone might fail to boot or might boot up crippled in single user mode after cloning a Tru64 system. For storage and other items, Tru64 has a dynamic hardware database it tries to keep updated on it's own. Rather than assign names based on absolute hardware locations, like in Digital Unix 4.x before, it does something completely new. I'm not sure why thought it was a good idea or why, but it turns out to be pretty sub-optimal in practice. One of many negative side effects of adopting this system was that it causes problems for anyone wanting to clone a root disk. You're in a chicken and egg scenario. How do you know what links to create for " | ||
+ | |||
+ | There are two strategies for addressing this issue: | ||
+ | |||
+ | - If you clone the OS image from the workstation you use to do the vrestore operations, you can safely assume the disk name will stay the same. Why? Because you are copying the same hardware database that the system has booted up with. Therefore, you're going to get the same disk name as when you had when you created the file domain, mounted the target file sets, and performed the restore. So, in this case, you should have a clean booting clone. This is especially true if you are booting the disk on the same physical system (ie.. you're clone was for a backup root disk should your primary fail). | ||
+ | - In other cases, you are restoring vdumps from a non-local system. In this case, you're getting the hardware database that came from those vdumps (the database files are in /etc). In this situation, you have literally no idea what the disk number will be. The best strategy is to boot the system into single user mode, then observe whatever disk name the root disk came up with. Then, if possible, run **bcheckrc** from your single-user session, and fix your links in /etc/fdmns to point to the new disk name. If that fails then do the same process after booting optical media or a different hard disk drive. Once you know the disk name the system is going to pick, it's just a matter of fixing /etc/fdmns sub-directories and updating their symlinks. | ||
+ | |||
==== Fix AdvFS Domains in /etc/fdmns ==== | ==== Fix AdvFS Domains in /etc/fdmns ==== |
how_to_clone_tru64_and_digital_unix.txt · Last modified: 2023/09/08 23:04 by sgriggs