Differences

This shows you the differences between two versions of the page.

--- 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:04] (current) – [Dynamic Disk Reconfiguration in Tru64 5.x Horks AdvFS] 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.
+==== 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 "root_domain" and "usr_domain" in /etc/fdmns so that the proper disk slices will be symlinked there when the system boots up? You might know the slice letters such as "a", "h", or "g" but you don't know what disk Tru64 will assign to your cloned root disk once the auto-configuration scripts kick off. What you thought might be dsk1 could turn out to be dsk3, etc...
+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.
+Digital Unix users can ignore all that and just stick to bus, SCSI ID, and LUN identifiers with the confidence of knowing they will stay deterministic.
 ==== Fix AdvFS Domains in /etc/fdmns ====