how_to_clone_tru64_and_digital_unix
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revision | Next revisionBoth sides next revision | ||
how_to_clone_tru64_and_digital_unix [2018/12/11 16:02] – [Fix the rc.config] sgriggs | how_to_clone_tru64_and_digital_unix [2018/12/11 16:05] – sgriggs | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | == Cloning Digital Unix and Tru64 == | + | === Cloning Digital Unix and Tru64 === |
There are various places on The Net you can find how to clone a Tru64 system, but most of them are just discussions and hand waving. The complete process is documented here. | There are various places on The Net you can find how to clone a Tru64 system, but most of them are just discussions and hand waving. The complete process is documented here. | ||
- | === Process Overview === | + | ==== Process Overview |
Here is a quick and dirty view of this overall process. | Here is a quick and dirty view of this overall process. | ||
Line 26: | Line 26: | ||
- 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 |
Cloning can be complicated because of the different filesystems and storage layouts on your system. Before you begin, you need to know what kind of storage you are using and how it's laid out. We need to answer the following questions: | Cloning can be complicated because of the different filesystems and storage layouts on your system. Before you begin, you need to know what kind of storage you are using and how it's laid out. We need to answer the following questions: | ||
Line 63: | Line 63: | ||
- | === About LSM === | + | ==== About LSM ==== |
LSM is a volume management scheme which is pretty much identical to Veritas Volume Manager (VxVM). This is because, at the time, DEC was able to secure a one-shot licensed copy of VxVM but they agreed to change it's name. So, if you know VxVM, then all you do is replace the string " | LSM is a volume management scheme which is pretty much identical to Veritas Volume Manager (VxVM). This is because, at the time, DEC was able to secure a one-shot licensed copy of VxVM but they agreed to change it's name. So, if you know VxVM, then all you do is replace the string " | ||
Line 69: | Line 69: | ||
Systems using LSM are extremely hard to clone unless you can use dd alone to clone a single disk. This would not be a very common LSM configuration (what would be the point of a single-disk LSM config?). So, my advice on cloning LSM-based systems is "do not try". Instead, recreate the LSM RAID layout via a " | Systems using LSM are extremely hard to clone unless you can use dd alone to clone a single disk. This would not be a very common LSM configuration (what would be the point of a single-disk LSM config?). So, my advice on cloning LSM-based systems is "do not try". Instead, recreate the LSM RAID layout via a " | ||
- | === The Boot Sector === | + | ==== The Boot Sector |
In Tru64 and Digital Unix you need to make sure the disk has the proper boot blocks at the front of the disk. This is done using **disklabel** and it's not super-intuitive. You absolutely must use both the **-rw** and the **-t** flags when installing boot blocks. Without both sets of flags the procedure will fail. Also, the behavior of the tool is a bit odd sometimes and the boot blocks don't get properly installed or get clobbered later on. So, when starting a clone, I'd suggest zeroing out the disklabel and re-installing it from scratch using the exact-right syntax, then doing only edits (using **-e** to **disklabel**) after that point. Here is a couple of examples. I'll use a disk name of **rz0** in this case, but you should alter that to fit your system. Also, don't do all the steps, but just the ones that correspond with your file system type. Boot blocks have to be customized for the file system that you are using. | In Tru64 and Digital Unix you need to make sure the disk has the proper boot blocks at the front of the disk. This is done using **disklabel** and it's not super-intuitive. You absolutely must use both the **-rw** and the **-t** flags when installing boot blocks. Without both sets of flags the procedure will fail. Also, the behavior of the tool is a bit odd sometimes and the boot blocks don't get properly installed or get clobbered later on. So, when starting a clone, I'd suggest zeroing out the disklabel and re-installing it from scratch using the exact-right syntax, then doing only edits (using **-e** to **disklabel**) after that point. Here is a couple of examples. I'll use a disk name of **rz0** in this case, but you should alter that to fit your system. Also, don't do all the steps, but just the ones that correspond with your file system type. Boot blocks have to be customized for the file system that you are using. | ||
Line 104: | Line 104: | ||
</ | </ | ||
- | === Editing the Disklabel === | + | ==== Editing the Disklabel |
Tru64 and Digital Unix have a strong connection to BSD Unix. This is because OSF/1 which was the predecessor to Digital Unix (ie.. the 1.x - 3.x versions of the OS were called OSF/1) used BSD for the majority of it's user space programs. Why re-invent all that good stuff when BSD set the defacto standard everyone was following for TCP/IP programs? Yes, the kernel is still mostly a microkernel and is just DEC's own thing (but resembles the Carnagie Mellon [[https:// | Tru64 and Digital Unix have a strong connection to BSD Unix. This is because OSF/1 which was the predecessor to Digital Unix (ie.. the 1.x - 3.x versions of the OS were called OSF/1) used BSD for the majority of it's user space programs. Why re-invent all that good stuff when BSD set the defacto standard everyone was following for TCP/IP programs? Yes, the kernel is still mostly a microkernel and is just DEC's own thing (but resembles the Carnagie Mellon [[https:// | ||
Line 149: | Line 149: | ||
In general, if you are cloning a UFS based system, then be very careful that your disklabel is going to give you enough space for the **/** and **/usr** file systems. If you are using AdvFS make sure that the total slices you set aside can be used to add up to the sizes you need (ie.. remember that AdvFS can do concatination, | In general, if you are cloning a UFS based system, then be very careful that your disklabel is going to give you enough space for the **/** and **/usr** file systems. If you are using AdvFS make sure that the total slices you set aside can be used to add up to the sizes you need (ie.. remember that AdvFS can do concatination, | ||
- | === File Copy Steps === | + | ==== File Copy Steps ==== |
The UFS file system is BSD's native file system. It's very reliable and tough, but it also lacks features such as journaling, logging, and some other more esoteric stuff. It's maximums are also much lower than AdvFS. The upshot of UFS is that it's extremely reliable and stable, gives you reasonably high performance, | The UFS file system is BSD's native file system. It's very reliable and tough, but it also lacks features such as journaling, logging, and some other more esoteric stuff. It's maximums are also much lower than AdvFS. The upshot of UFS is that it's extremely reliable and stable, gives you reasonably high performance, |
how_to_clone_tru64_and_digital_unix.txt · Last modified: 2023/09/08 23:04 by sgriggs