From: Bob Power UT-Dallas/Space Sciences (power@utdssa.utdallas.edu)
Date: Wed Jan 08 2003 - 20:37:35 EST
Many thanks to:
Denise McCracken
Dr. Tom Blinn
Jay Leafey
Howard Arnold
Bryan Lavelle
Warren Sturm
Mohamed Ahmed
Pat O'Brien
Chris Bryant
I finally got v5.0a working and have now updated to v5.1a .
As most suggested I had a problem with the new disk naming convention
in v5 (dskx) vs. the old rzxx convention in v4.
Here is what I did:
I booted to single-user mode, then remounted the root file system for
RW operation (mount -u /). Next I changed the links in /etc/fdmns , for
example:
#cd /etc/fdmns/usr_domain
#rm rz24g
#rm rz24h
#ln -s /dev/disk/dsk5g dsk5g
#ln -s /dev/disk/dsk5h dsk5h
and ls -l shows
#ls -l
total 0
lrwxrwxrwx 1 root system 15 Jan 5 12:12 dsk5g -> /dev/disk/dsk5g
lrwxrwxrwx 1 root system 15 Jan 5 12:12 dsk5h -> /dev/disk/dsk5h
#cd /etc/fdmns/usr25g_domain
#rm rz25g
#rm rz25h
#ln -s /dev/disk/dsk6g dsk6g
#ln -s /dev/disk/dsk6h dsk6h
and ls -l shows
#ls -l
total 0
lrwxrwxrwx 1 root system 15 Jan 5 12:12 dsk6g -> /dev/disk/dsk6g
lrwxrwxrwx 1 root system 15 Jan 5 12:12 dsk6h -> /dev/disk/dsk6h
In order to set the symbolic links, I had to determine what each rzxx disk
in v4 translated to in dskx form in v5. This can be done by examining the
output of the console power-up command
P00>>>show device
and knowing that dsk0 is the 1st disk listed, dsk1 is the 2nd, and so on.
You also have to determine how the rzxx assignments correspond to these
disks (which I was able to do from saved v4 records of what disk was rz24,
rz25, rz32, etc. and which I could easily confirm since I have 2 drives
including the boot diskon one controller and 5 drives on a 2nd controller).
So for my configuration, rz24 is dsk5, rz25 is dsk6, rz32 is dsk0,
rz33 is dsk1, rz34 is dsk2, rz35 is dsk3, and rz36 is dsk4.
>From Tru64, hwmgr -view devices could also be used to show the v5 disk names.
After making these new links, all the advfs domains mounted correctly when
/sbin/bcheckrc executed, except unfortunately root_domain. I would get the
error message:
msfs_mount: mount device does not match the linked device .
So dsk5a -> /dev/disk/dsk5a in root_domain was not consistent with the
root_device. I could still use root_device which was the file system root / ,
but I was concerned that there might be other inconsistencies (as suggested
by Pat O'Brien) yet to be discovered if I did not take care of this problem
with the root_domain.
I thought I was going to have either:
restore my 4.0f system and update to v4.0g, then to v5.1, then 5.1a
(as suggested by Chris Bryant; btw, I had previously used the 4.0g/5.1/5.1a
upgrade path in updating an XP1000 and without any trouble, but I was trying
to save one update step by going 5.0a/5.1a; also this upgrade path may not
have worked out any better on the DS20 because of the extra Adaptec interface
-see Dr. Tom Blinn's idea below),
or do a new install of v5.1a after saving /etc/passwd, /etc/group, and
/var/adm/lmf so they could be restored after the install (as suggested by
Dr. Tom Blinn, who also offered that I might be having a problem with an
Adaptec SCSI interface that was not supported by v4.0f but is supported by
v5.0a and above; he thought I might have a DS20E that has this Adaptec
interface, but in fact I have a DS20 with an add-on Adaptec controller
that is used for 2 Cybernetics AIT-2 tape drives).
Before taking these more drastic steps, I found that
#disklabel -r root_device
would show what disk was linked to root_device and it was /dev/rz48a.
So I linked dsk5a to the root_domain with
#cd /etc/fdmns/root_domain
#rm dsk5a
#ln -s /dev/rz48a dsk5a
and ls -l shows
#ls -l
total 0
lrwxrwxrwx 1 root system 15 Jan 8 12:12 dsk5a -> /dev/rz48a
and sure enough root_domain mounted when I executed mount -u / .
NOTE: This root_domain link uses the old v4 style name rz48a (it is worth
commenting that the device is no longer rz24a as it had been under v4.0f).
All of this was performed in single-user mode.
I then booted to normal multi-user mode and everything mounted correctly.
I ran /sbin/advfs/verify -a for all domains to confirm that everything
was fine with the advfs domains. As several suggested, I could have also
made use of advscan if I needed to recover domains (except root_domain
could not be recovered with advscan) but fortunately I did not have to
recover any once the links were properly made. BTW, I did not change any
fileset names and I did not use mkfdmn or mkfset to recover.
I have now updated from v5.0a to v5.1a without any other problems.
Thanks again to everyone who responded to my request and if anyone wants to
obtain additional details I would be happy to provide them.
Bob Power
University of Texas at Dallas
Center for Space Sciences
power@utdallas.edu
--------------------------------------------------------------------------
-----Original Message-----
I have the following problem:
Tru64 UNIX v4.0f to v5.0a update on DS20 500MHz (2 cpu).
Update appeared to work without any errors, but system fails to boot due to
filesystem problems (see below). System can boot to single-user mode, but
has same filesystem problems when /sbin/bcheckrc is executed.
Is there a way to correct this problem or do I need to re-install the
operating system (if so, should I re-install 4.0f or 5.0a, or should I
install 5.1a, to which I was eventually updating) ?
Thanks.
Bob Power
University of Texas at Dallas
Center for Space Sciences
power@utdallas.edu
--------------------------------------------------------------------------
Hardware passes all initialization self-tests.
Abstracted startup output is:
AlphaServer DS20 500MHz Console V6.0-8 May 10,2001 16:26:23
UNIX boot - Wed Apr 5 01:30:19 EDT 2000
Firmware Revision 6.0-8
PALcode: UNIX version 1.87-69
Checking local filesystems
Mounting / (root)
nsfs_mount: The mount device does not match the linked device.
Check linked device in /etc/fdmns/domain
user_cfg_pt: reconfigured
root_mounted_rw: reconfigured
user_cfg_pt: reconfigured
root_mounted_rw: reconfigured
dsfmgr: Note: updating kernel basenames and old devnames for system at /
scp kevm tty00 tty01 lp0 dsk0 dsk1 dsk2 dsk3 dsk4 dsk5 dsk6 tape0 tape1 floppy0
Mounting local filesystems
exec: /sbin/mount_advfs -F 81920 root_domain#root /
ntfs_mount: The mount device does not match the linked device.
Check linked device in etc/fdmsn/domain
ntfs_mount: Setting root device name to root_device RW
root_domain#root on / type advfs (rw)
/proc on .proc type procfs (rw)
exec: /sbin/mount_advfs -F 16384 usr_domain#usr /usr
Error: /dev/rz24g is an invalid device or cannot be opened.
(NOTE: above 2 lines repeated for all domains)
Subsystem hwautoconfig was successfully configured.
Jan 3 12:58:26 update: started
/sbin/it: Directory /usr/sbin not found.
/sbin/it: Abort: not found
/sbin/it: getconf: not found
/sbin/it: getconf: not found
/sbin/it: getconf: not found
/sbin/it: getconf: not found
/sbin/it: message: not found
/sbin/itruns: /usr/share/lib/shell/libinstall: not found
/sbin/it: wc: not found
cat: cannot open /tmp/it.items
INIT: Command is responding too rapidly. Check for possible errors.
id: cons "/usr/sbin/getty console console vt100"
(NOTE: no further output to console)
--------------------------------------------------------------------------
>From single-user mode, ls -l /etc/fdmns/* gives
/etc/fdmns/root_domain:
total 0
lrwxr-xr-x 1 root system 10 May 14 1999 rz24a -> /dev/rz24a
/etc/fdmns/usr25g_domain:
total 0
lrwxr-xr-x 1 root system 10 Nov 8 1999 rz25g -> /dev/rz25g
lrwxrwxrwx 1 root system 10 Oct 15 16:36 rz25h -> /dev/rz25h
and so on.
-------------------------------------------------------------------------------
Thanks again for any help.
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:03 EDT