This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Alan, On Sep 21, 8:02pm, alan anderson wrote: > Subject: Re: 20000913: solaris 8 at stc (cont.) > > ... > So, I think my first choice would be your suggestion of moving the current > root fs into /space. My questions are > > a) can /space then be renamed to / (root), or does this happen > automatically. I will read some more but did not see anything > about moving a file system. This would require a modification of /etc/vfstab after it was copied to the new partition. > b) what command(s) are used, mv cp or will a complete process > be in my docs. Again, I don't think I have seen it. > To do this, I am guessing I have to leave both / and /space > mounted. Sun's versions of dump and restore (ufsdump/ufsrestore) is what I recommend. Here's a rough procedure to follow (from my failing memory). If this is wrong, we'll still be OK since the original OS is not going to be corrupted or removed; - cd / - umount /space - newfs -i 8192 /dev/dsk/c0t0d0s0 - fsck /dev/rdsk/c0t0d0s0 - mount /dev/dsk/c0t0d0s0 /mnt - cd /mnt - ufsdump 0f - /dev/dsk/c0t0d0s7 | ufsrestore rf - (will take 1-2 hours) - rm restoresymtable - edit /mnt/etc/vfstab (change c0t0d0s7 to c0t0d0s0 and vise-versa throughout) note each occurs twice per line - cd / - umount /mnt - fsck /dev/rdsk/c0t0d0s0 - installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t0d0s0 - sync - halt at the eeprom prompt type - setenv boot-device disk:a - setenv diag-device disk:a - reset at which time the machine should reset and boot on the newly copied verison of the OS. Type "df -kl" to verify the partition sizes. mike