This is the Frequently Asked Questions (and their answers) about the Digital UNIX (formerly DEC OSF/1 AXP) operating system from Digital Equipment Corporation.
This FAQ is archived in the following locations:
The archive name for this FAQ is dec-faq/Digital-UNIX
This is the Frequently Asked Questions (FAQ) collection for the Digital UNIX (formerly DEC OSF/1 AXP) operating system and, to some degrees, the systems on wich it runs. Some information relevant to the RISC ULTRIX operating systems (for the DECstation systems based on MIPS pro cessor chips) can also be found here, though there is a separate FAQ specifically for RISC ULTRIX.
A separate FAQ describes how to get information about Digital products and interacting with Digital.
To make suggestions for changes or additions to this Frequently Asked Questions list, send mail to lionel@quark.enet.dec.com. Answers are especially appreciated.
The term "Alpha" generally refers to systems based on Digital's Alpha processor.
Unless otherwise specified, these answers refer to Digital UNIX V3.2c, which is the current release. "Digital UNIX" is used even for earlier versions which call themselves DEC OSF/1.
World-Wide Web Universal Resource Locator (URL) notation is used for FTP addresses.
Many people have contributed to this list, directly or indirectly. In some cases, an answer has been adapted from one or more postings on the comp.unix.ultrix or comp.unix.osf.osf1 newsgroups. Our thanks to all of those who post answers. The name (or names) at the end of an entry indicate that the information was taken from postings by those individuals; the text may have been edited for this FAQ. These citations are only given to acknowledge the contribution.
Although the editor of this FAQ is an employee of Digital Equipment Corporation, this posting is not an official statement from Digital Equipment Corporation.
AlphaGeneration, AlphaServer, AlphaStation, Alpha AXP, AXP, DEC, DECstation, DECsystem, OpenVMS, ULTRIX, VAX and VMS are trademarks of Digital Equipment Corporation. OSF/1 is a registered trademark of the Open Software Foundation. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Ltd. Other names are properties of their respective owners.
http://www.digital.com/info/software.html
A two-CD Freeware set shipped with Digital UNIX V4.0. For an online copy, as well as reference to other freeware sources, see:
http://www.unix.digital.com/demos/index.html
Digital actively maintains an "Alpha Applications Catalog" which lists commercial software products available for Alpha systems.
http://www.unix.digital.com/catalog/index.html
Patches to make Emacs version 19.22 run on Digital UNIX can be found at ftp://ftp.digital.com/pub/GNU. The files are
emacs-19.22-alpha-patch.README
emacs-19.22-alpha-patch.gz
but the current version of GNU emacs (any version at least as recent as
19.28) is said to build and run properly on Digital UNIX).
[Pete Kaiser, kaiser@acm.org]
[Rob McCool, robm@snail.ncsa.uiuc.edu]
Emacs 19.28 does NOT come with support for the DEC alpha, but the patches for
it are available from
ftp://ftp.digital.com/pub/GNU. So you have to get emacs-19.28
and then the patch as well. Once you get the patch, it builds flawlessly.
(Well, at least it did for me.) The documentation within emacs 19.28 says that
hopefully in 19.29 Alpha support will be built into the standard emacs
distribution.
[holt@cns.caltech.edu]
Communications of the ACM, February 1993 issue (4 Alpha articles)
Digital Technical Journal, Vol 4., No. 4 (200 pages of Alpha articles, including 4 above with fewer typos). Order info: dtj@crl.dec.com (Available from ftp://ftp.digital.com/pub/DEC/DECinfo/DTJ and http://www.digital.com/info/DTJ/dtj.html)
Jim Montanaro "The Design of the Alpha 21064 CPU Chip" (42 minutes)
Dick Sites and Dirk Meyer, "Alpha Architecture" (73 minutes)
University Video Communications P.O. BOx 5129 Stanford CA 94309 USA
(415) 813-0506
[Dick Sites,
sites@tallis.enet.dec.com]
The files available for FTP are located at:
ftp://ftp.digital.com/pub/Digital/Alpha/
The WWW pages are located at:
http://www.service.digital.com/alpha/server/
We hope that these pages will be useful. Please send your comments and
feedback to alpha_server@service.digital.com
The latest official version of top (3.3) supports single cpu Alphas running OSF/1 1.2, 1.3, 2.0, 3.0, and 3.2. It's at ftp://eecs.nwu.edu/pub/top It does not support multi-cpu alphas, because no-one with root access to a multi-cpu alpha has stepped forward to do the work. When compiling, note the warning about compiling with optimisation.
lsof, a utility for listing open files, is available from ftp://vic.cc.purdue.edu/pub/tools/unix/lsof.
vmubc is a graphical and tty-based tool for displaying statistics
on CPU, UBC, and virtual memory. Note that to compile on OSF/1 2.x,
add -DGSI_CPUS_IN_BOX=55 to the CFLAGS. vmubc is available from
ftp://gatekeeper.dec.com/pub/Digital/vmubc.tar.Z. It was written by
George Chaltas of DEC.
[Dave Sill, de5@ornl.gov]
[Anthony Baxter,
anthony@aaii.oz.au]
setenv MXR_TRACE_SYSCALLS open,stat,fstat,access
Running mxr -help will describe this environment variable along with
some other useful ones.
[Richard Gorton,
gorton@blorf.amt.ako.dec.com]
ftp://ftp.primate.wisc.edu/pub/csh-tcsh-book
or
Two software packages are available to drive audio on Alpha systems:
MME implements a Microsoft-style API and comes bundled with OSF/1.
AF, developed at Digital's Cambridge Research Laboratory runs on a wide range of platforms including DECstation, Alpha, Sun, SGI, and HP. It is available in source form from
ftp://ftp.digital.com/pub/DEC/AF
[Lance Berc, berc@src.dec.com]
Two other programs are Workman and xmcd, both of which can be found on
ftp.x.org. Of all these programs, xmcd seems to be the widest used and to
have the largest database of audio CD data.
[Anthony Baxter, anthony@aaii.oz.au]
[Peter Kaiser, kaiser@acm.org]
ftp://ftp.digital.com/pub/DEC/DECinfo/DECnews-UNIX/0117.txt
and the DECmigrate for Digital UNIX Software Product Description (SPD):
ftp://ftp.digital.com/pub/DEC/DECinfo/SPD/39-45-01.txt
[Russ Jones,
rjones@pa.dec.com]
The version of lint shipped with Digital UNIX has many checks to help port software to Alpha. In particular, the -Q option is very useful. See the manual page for more details.
There is also a document/book entitled: Interoperability, OpenVMS and DEC OSF/1 Interoperability Guide. EC-N3399-43.
A company called Sector 7 deals with porting software from OpenVMS to Digital UNIX : http://www.sector7.com.
A document entitled "SunOS to DEC OSF/1 Porting Guide" is available from ftp://ftp.digital.com/pub/DEC/DECinfo/document/EC-N0736-43.ps.Z
The -taso flag to cc will often help with making code work on the 64bit Alpha. This causes addresses to be 32-bits and should be used only as a last resort.
FreePort Express is a binary translator (running on Alpha) which permits you to convert your SunOS 4.1.x (same as Solaris 1.x) user executables into Digital UNIX executables in minutes. FreePort Express runs under Digital UNIX V3.0 or later, and is available FREE of charge (hence the name). http://fenris.novalink.com/freeport-express/
For more information, look in ftp://ftp.digital.com/pub/DEC/DECinfo/DECnews-UNIX for:
0104.txt Digital UNIX Developer's Extensions V1.2 article, 11/17/92
0603.txt Digital UNIX Developer's Toolkit V1.2 article, 03/23/93
0806.txt C Compiler for Digital UNIX Operating System article, 05/13/93
[Russ Jones,
rjones@pa.dec.com]
The usual solution is to recompile from scratch.
[John Kohl,
jtkohl@zk3.dec.com]
If you get the package, be sure to read the stuff in the file
contrib/dec_notes which explains how to replace malloc on the fly in
an existing program.
[Dave Hill,
ddhill@zk3.dec.com]
The ATOM tools with Digital UNIX 3.0 and later also help with debugging memory
allocation problems.
[Anthony Baxter, anthony.baxter@aaii.oz.au]
Sentinel, from AIB Software Corporation is a run-time analysis tool that supports
memory access error detection as well as leak detection on Digital UNIX.
More info, as well as free evaluation copies, is available from
info@aib.com, or by calling 800-296-3000 (703-787-7700).
[Conor P. Cahill, cpcahil@aib.com]
malloc(3) returns data aligned to the most restrictive alignment (8 byte boundaries on MIPS machines). If you are writing your own malloc wrapper (say to add a reference count) and you write code like this:
char *mymalloc(int size)
{
short *newmem;
newmem = (short *) malloc(size + sizeof(short));
*newmem = 1; /* initialize reference count */
return (char *) (newmem + 1);
}
you are then returning a pointer that is no longer 8-byte aligned. Now, code
like
int *i;
i = (int *) mymalloc(sizeof(int));
*i = 10;
will generate unaligned access messages whenever *i is used.
An example of dangerous casting would be something like
char buffer[100];
int i;
i = (int)*((int *)&buffer[3]);
The program will usually still run correctly, because an exception
handler in the kernel performs an unaligned read. There are some rare
cases, however, where the fixed read yields incorrect results. The
messages are printed by default because one usually wants to know when
a program is generating the unaligned accesses.
Now, if you're only getting a few of these messages, it might not matter, but if you're getting pages of them (or worse, have turned off the logger because you were getting so many unaligned access messages), you might consider correcting your program.
You can use the uac(1) (Unaligned Acces Message Control) command to turn off the messages.
If you want to find the the problem in the source code, you can use dbx. Suppose the message is:
Fixed up unaligned data access for pid 2337 (bozo) at pc 0x5ad364
This tells you that the problem occurs in the program "bozo". In dbx,
you would type, for example:
% dbx bozo
(dbx) 0x5ad364/i
*[main:206, 0x0x5ad364] lw r0,40(sp)
dbx prints the offending instruction, along with its location: line 206
in main().
REAL*4 X
REAL*8 Y
COMMON /CMN/ X,Y
Y will be at offset 4, which is not a multiple of its size (8). The best
solution is to rearrange variables in the COMMON so that real, complex
and integer variables are listed in order of decreasing size, followed by
CHARACTER variables. Put your declaration in an INCLUDE file to make sure
all uses are consistent! You can also ask the compiler to automatically
add padding to align variables through the -align dcommons switch, or
through a CDEC$ OPTIONS directive. See the DEC Fortran User Manual for
further details.
Answer: Normally, Digital UNIX updates its internal idea of the current time once per clock tick (1024 Hz, or about once per millisecond). In Digital UNIX V4.0 and later, it is possible to rebuild the kernel to support approximately microsecond resolution from the gettimeofday(2) system call, and from the various library routines that use this system call.
To enable this option, add the following line to the kernel configuration file and rebuild the kernel:
options MICRO_TIMEThe system clock (CLOCK_REALTIME) resolution as returned by clock_getres(3) will not change. Timer resolution remains the same. However, the granularity of the time returned by gettimeofday(2) and clock_gettime(3) will now be in microseconds. The time values returned are SMP safe and monotonically increasing.
The high-resolution clock can be used for timestamping and for
measuring durations on the order of microseconds, such as time spent in
some critical code path.
[Jeff Mogul]
XV 3.10a supports Digital UNIX. It can be obtained from: ftp://ftp.cis.upenn.edu/pub/xv xv is also included on the Freeware CD-ROM (see question A1).
host:0 host.sub.domain:0
to the file /etc/securettys to allow root to login.
[szabo_p@maths.su.oz.au]
If you get the error 'Cannot obtain database information on this terminal', Follow this advice from the DEC support people and change the files /etc/auth/system/ttys, /etc/auth/system/devassign and /etc/securettys as follows: In the following, replace host, host.sub.domain and n.n.n.n by the hostname, full domain name and IP address of the host(s) you are trying to connect from. Add lines like the following to /etc/auth/system/ttys :
host\:0:t_devname=host\:0:t_xdisplay:t_login_timeout#0:chkent:Add lines like the following to /etc/auth/system/devassign :
host\:0:v_devs=host\:0,host.sub.domain\:0,n.n.n.n\:0:v_type=xdisplay:chkent:Add lines like the following to /etc/securettys :
host.sub.domain:0 host:0
ftp-control tcp 0x0 ftp-data tcp 0x0
Reboot the Alpha system.
Note that as of OSF 1.3 DEC does not support this but it is quite
easy to do.
[Jon Forrest,
forrest@postgres.Berkeley.EDU]
set ethernet thick
or
set ethernet tenbt
- Reboot the system.
[Steve Imber,
stevei@anduril.fsc.qut.edu.au]
For the AlphaStation and AlphaServer systems, the syntax is different and depends on what Ethernet adapter you're using. For Digital EtherWorks adapters, they'll automatically select between AUI and 10 Base-T but you may have to use the console command:
set EWA0_MODE AUI
to have this happen.
http://s2k-ftp.cs.berkeley.edu:8000/sequoia/conferencing
or
ftp://s2k-ftp.CS.Berkeley.EDU/pub/sequoia/conferencing
[Fred Templin,
templin@postgres.Berkeley.EDU]
Binaries of the MBone application suite are also available at
http://chocolate.pa.dec.com/mbone
or
ftp://chocolate.pa.dec.com/mbone
[Lance Berc, berc@src.dec.com]
This is slightly misleading. xdr_long() can send -1, which in 32 bits is 0xffffffff. xdr_long() does range checking, insuring that the top 33 bits of its 64-bit argument are all ones or all zeroes. If this is not the case, then the signed long integer is beyond the range of representation within a signed 32-bit value, and xdr_long() rightly fails.
xdr_u_long() [note typo above!] insures that the top 32 bits of its 64-bit argument are all zero. If this is not the case, then the unsigned long integer is beyond ... blah blah.
So, the upshot is: If you're using signed values, use xdr_long(), and
DON'T use unsigned constants like 0xffffffff to set variables. If
you're using unsigned values, use xdr_u_long(). In both cases, make
sure you're within range for 32-bits, if you want to interoperate with
32-bit machines using native data types.
[John Kohl,jtk@atria.com]
# doconfig
*** KERNEL CONFIGURATION AND BUILD PROCEDURE ***
Enter a name for the kernel configuration file. [ALINGO]: FILTER
You want to name the configuration file 'FILTER'
Is that correct? (y/n) [y]: y
*** KERNEL OPTION SELECTION ***
Selection Kernel Option
---------------------------------------------------------------
1 System V Devices
2 Logical Volume Manager (LVM)
3 Kernel Breakpoint Debugger (KDEBUG)
4 Packetfilter driver (PACKETFILTER)
5 STREAMS pckt module (PCKT)
6 Data Link Bridge (DLPI V2.0 Service Class 1)
7 X/Open Transport Interface (XTISO, TIMOD, TIRDWR)
8 File on File File System (FFM)
9 ISO 9660 Compact Disc File System (CDFS)
10 Audit Subsystem
11 Local Area Transport Support
12 All of the above
13 None of the above
---------------------------------------------------------------
Enter the selection number for each kernel option you want.
For example, 1 3 : 4
You selected the following kernel options:
Packetfilter driver (PACKETFILTER)
Is that correct? (y/n) [y]:
...
Rebuild and boot the new kernel.
2) Create the packetfilter devices:
# cd /dev # ./MAKEDEV pfilt MAKEDEV: special file(s) for pfilt: pfilt0 pfilt1 pfilt2 pfilt3 pfilt4 pfilt5 pfilt6 ... pfilt633) Get a better tcpdump (pre V4.0 systems only) Email me for a compressed, uuencoded file of a tcpdump that decodes NFS V3 and several other Sun RPC protocols (MOUNT, NIS, NLM, PORTMAP, and STATMON). 4) Enable local copy promiscuous mode
# pfconfig +p +c ln0 (or tu0 or whatever)5) Run tcpdump Please read the man pages before doing serious monitoring! To look at some NFS traffic, try:
# tcpdump -s300 -c100 -Nt udp port 2049 [to look at all NFS traffic] # tcpdump -s300 -c100 -Nt host foo [to look at all to/from foo]-s300 "snaps" up the first 300 bytes of each message, generally enough to get lower level headers, RPC, and enough NFS protocol to make sense of the requests. -c100 says to capture 100 messages and exit. -N says to suppress the domain name (e.g. .zk3.dec.com) in hostnames. -t says to suppress printing timestamps. The result is usually still too long for a 80 column screen, I keep a wide xterm lying around for most of my tcpdump monitoring. The -m option splits some messages over multiple lines.
If you send people traces, I generally recommend that you capture data to a binary file and send that. If the recipient needs to, he can run tcpdump with extra filtering or -x (hex dump) to really dig into problems. Do something like:
# tcpdump -w /usr/tmp/foo.dmp -s300 udp port 2049 tcpdump: listening on ln0 Using kernel BPF filter ^C 1040 packets # compress foo.dmp # uuencode foo.dmp.Z < foo.dmp.Z > foo.uuCapturing to a file bypasses all the decoding code which can be very slow and can generate its own IP traffic (e.g. resolving host names).
# parallel connection lp3|3|fleet|post:\ :lf=/usr/adm/lpderrs:\ :lp=/dev/lp0:\ :mx#0:\ :pl#66:\ :pw#80:\ :sd=/usr/spool/lp3:\ :sh:\ :xf=/usr/lbin/xf:
BTW: That was for an HP Laserjet before we used its JetDirect (=Ethernet) card which supports lpd directly via TCP/IP. The entry for this usage is:
# ether connection lp3|3|fleet|post:\ :lf=/var/adm/lpderrs:\ :lp=:\ :rm=fleet:\ :rp=fleet:\ :sd=/var/spool/lp3:\ :mx#0:\ :sh:
The printer has an IP address of its own and is called "fleet".
I have seen for the "rp" tag names like "raw" or "text" to distinguish
between postscript or text but the above entry works as well. Users that
need to print text use "unix2dos" as filter but we'd rather discourage that
and favour dot matrix printers for that purpose.
[Michael Sternberg, sternberg@physik.tu-chemnitz.de]
DEC carries four DB-to-MMJ adaptors. They are internally wired as follows
Rdy Out TX+ TX- RX- RX+ Rdy In
Adaptor Gender 1 2 3 4 5 6 Use with:
--------------------------------------------------------------------------
H8575-A F 20 2 7 7 3 6&8 VTxxx terminal
H8571-C M 6 3 7 7 2 20 DEC printer
H8571-D M 6 3 7 7 2 20 Modem
H8571-E M 20 2 7 7 3 6&8 Female terminal
or LaserWriter
--------------------------------------------------------------------------
RS-232 using DB-25 connectors:
DTE DCE
Terminal Modem
or computer
Pin Number Signal Name
2 TD Transmit Data -->
3 RD Receive Data <--
7 GND Ground ---
6 DSR Data Set Ready <--
8 DCD Data Carrier Detect <--
20 DTR Data Terminal Ready -->
newfs /dev/rrz#x /dev/rrz#x
to do this.
For most uses, you don't need a disktab entry on Digital UNIX. The disklabel command can get the default partition table and geometry from the disk driver and will put that in the label. When the label is present, newfs doesn't need a disktab entry either.
A collection of contributed disktab entries is in /pub/DEC/ultrix-disktabs on the usual archive machines. Get a copy of the file for an up-to-date list. The disktab collection may also be used on Digital UNIX, but not all entries have been tested on all platforms.
When you build mtools, you need to find out which device your floppy
is (/dev/rrz2c is common). Then you can clone the SPARC definitions,
or #define SPARC and make /dev/rfd0c a symlink to the one you need.
[Win Treese, treese@lcs.mit.edu]
disklabel -rw /dev/rrzXc unknown
Where /dev/rrzXc is the device name of the disk.
[John Speno, speno@swarthmore.edu]
subscribe alpha-osf-managers
in the body to Majordomo@ornl.gov.
[Dave Sill, de5@ornl.gov]
Archives of alpha-osf-managers mailings are kept at:
http://www-archive.stanford.edu/lists/alpha-osf-managers/hyper/
and
http://www-archive.stanford.edu/cgi-bin/fwais.pl
-fl specifies the flags to the booted image.
[Boris Yost,
boris@msc.cornell.edu]
As part of its reorganization in March of 1994, the Open Software Foundation announced transition plans for its existing technologies. It has been well understood since then that the June 1994 release of OSF/1, the OSF's operating system source code, would be the last. The possibility remains open that OSF sponsors may choose to fund additional work in the operating system area, but no projects are underway.
It is important to understand what OSF/1 is and has always been. It is not a finished operating system but a set of operating system technology components, from which vendors can pick and choose pieces of technology that complement their product development strategies. Many UNIX system vendors use elements of OSF/1 code -- Hewlett-Packard in HP-UX, IBM in AIX, and many others, including Digital in Digital UNIX.
Digital uses components of OSF/1 technology, just as it integrates technology from other suppliers with its own internal development. By following this strategy of integrating needed components, Digital has been able to produce the best implementation of the UNIX operating system in the industry and to bring it to market quickly.
Since the initial releases, development of Digital's product has not been dependent on OSF code. Digital's plans for the future development of Digital UNIX are fully under Digital's control, and our plans for a fully SPEC 1170 compliant version, UNIX clusters, and other leading commercial enhancements are on course.
Internet: response@mkots3.enet.dec.com
Phone: 800-DEC-INFO or 603-884-0915
FAX: 603-884-4692
Mail: US Customer Relations
Digital Equipment Corporation
Digital Drive, MKO2-2/D15
P.O. Box 9501
Merrimack, NH 03054-9501
Non-US customers may also use these contacts; information will be directed to
the appropriate corporate office.
Please include your name, organization, address, phone number and Internet
address in all correspondence.
The newsgroup will be organized so that you can use a "kill" file with your newsreader to skip over (or ignore) classes of announcements that are not of interest. All postings will be organized along the following lines:
Subject: Press/... Digital Press Releases
Subject: Fact Sheet/... - Supporting Fact Sheets
Subject: Backgrounder/... - Supporting Editorial Backgrounders
Subject: Partner/... Press Releases from Digital's Partners
Subject: Seminar/... Seminars offered by Digital
Subject: Promotion/... Sales Promotions offered by Digital
Subject: Show/... Digital Tradeshow Activities
Subject: Training/... Digital Education & Training
The new biz.digital hierarchy is:
biz.digital.announce News and Announcements
biz.digital.articles Newsletters, Catalog, and Journal Articles
Digital UNIX has two paging modes, lazy and conservative. Conservative means
that paging space is allocated as memory is allocated, guaranteeing that there
is always somewhere to page to. This limits VM to the size of the paging
partitions, but makes for a very robust system. Lazy is more like what people
are used to with Unix - paging space is allocated when needed for paging out,
you can run more jobs, but you're in big trouble when everything fills up. By
default, Digital UNIX comes up in the conservative mode. Removing the
swapdefaults file changes the system to lazy mode.
[Lance Berc, berc@src.dec.com]
1. cp -p /upgrade0 /upgrade 2. copy /upgrade from another pre-V3.0 Digitial UNIX system. 3. Obtain the O/S distribution media and extract the /upgrade0 file. a. mount -r /dev/rzNOTE: the 200 in OSFBASE200 varies based on the O/S version.c /mnt b. cat /mnt/ALPHA/BASE/OSFBASE200 | uncompress | tar xvf - ./upgrade0 c. cp upgrade0 /upgrade
Digital UNIX V3.0 uses the OSF-BASE and OSF-USR PAKs to determine the amount of users allowed. A valid OSF-BASE PAK is required to activate the OSF-USR PAKs. By default, the OSF-BASE PAK alone provides 2 concurrent user support by activating an OSF-USR PAK which is automatically installed. If zero non-root users can login, then you probably have not installed your OSF-BASE PAK properly or it has expired. (Use the "lmf list" command to see the list of installed PAKs. A PAK is good if its status is "active".) Install a valid OSF-BASE PAK. If the problem still persists, then you likely do not have any OSF-USR PAK. Since one is automatically installed for you, this means that somebody inadvertantly deleted the PAK. You can recover this PAK by entering the following:
/sbin/it.d/bin/twouser
Two concurrent users should be allowed to login at at this time.
If your problem is that only two users are allowed to login at the same time,
then you probably need a larger or additional OSF-USR PAKs. If you have
installed an "unlimited user" OSF-USR PAK but are seeing a restriction on the
number of users allowed to login, delete all OSF-USR PAKs other than the PAK
which provides for unlimited users.
[Dave Parker, djp@unx.dec.com]
V2.0 240
V3.0 347
V3.0B 358.78
V3.2 214
V3.2A 17
V3.2B 214.61
V3.2C 148
V3.2D-1 41
V3.2D-2 41.64
V3.2F 69.73
V3.2G 62
V4.0 386
1) The update installation exits and indicates that additional space is needed in a particular file system (root, /usr, and/or /var) to perform the update.
2) The user deletes or moves files from the affected file system and/or removes subsets.
3) The user initiates another update attempt.
4) The update installation aborts again because of lack of space, even though the user believes that the space requested during the first attempt has been recovered.
There may be several reasons for this problem:
The proper methods for freeing disk space are as follows:
1) Remove any non-critical optional subsets using 'setld -d'. Deleting or moving individual system files without using the 'setld' command will not yield the additional space needed to continue.
Refer to the appropriate appendix of the Installation Guide containing the subset size information that corresponds to the version of Digital UNIX that you have currently installed to help you decide which subsets to remove.
2) Remove any non-critical user-added files which are not part of the base or layered product inventory. Typical large space consumers are left over core files and kernels that are no longer required.
3) For those who have previously performed Digital UNIX update installations, left over obsolete system files, .PreUPD files, and .PreMRG files can use significant amounts of file system space. Use the 'updadmin' utility to first back-up then delete these files. Refer to the installation guide for more information on using updadmin.
4) For AdvFS filesystems, it is possible to save approximately 3MB in root by building a mandatory only kernel (the default) rather than an interactive kernel (i.e. do not specify the "-i" flag to installupdate). Note that you must specify the "-i" flag if there are optional kernel selections that your system depends upon that cannot be satisfied by a mandatory kernel. Section 5.20 of the Digital UNIX 4.0 installation guide gives descriptions of each kernel option.
This bug has been fixed for Digital UNIX 4.0B.
When removing small files (less than 8K) from an AdvFS file system, additional free space may not be made available to the file system immediately. After the total amount of space consumed by these deleted files reaches a threshold value, all of the space is made available in one large block. This explains why deletion of several small files may not increase the available block count (as shown by "df", for example). In this case the user must continue to delete non-system user-added files until there is an adequate increase in the available block count to allow the update installation to continue.
[Brad Musolff, bdm@unx.dec.com]
If the old version of a file is removed without removing the entire subset in which it resides, the update installation will still put the new version on the system. In this situation the full size of the new file will be allocated instead of the difference between the size of the original and new versions.
For example, if /genvmunix was 7MB and a new version of /genvmunix was 8MB, update would need to reserve 1MB of free space for the new version. If /genvmunix was deleted before the update, the disk space calculation would then reserve the full 8MB for the new file. So although 7MB was freed before the update, 7MB more would be reserved during the update, which would result in no difference in the amount of additional space needed to continue the update.
[Brad Musolff, bdm@unx.dec.com]
This page is updated from time to time, as new information becomes available.
[End of FAQ]