grr@cbmvax.UUCP (George Robbins) (04/06/88)
Well, I've just completed (I hope) upgrading our 785 from Ultrix 1.2 to release 2.2. Things didn't go too badly, execept for one problem of my own creation. However there were a few strange things not evident in the release notes that might be worth mentioning. Some of this stuff may be ancient history for people runing 2.x... 1) The new boot procedure relies on having appropriate boot code in the boot blocks of the system disk. If the code isn't there, the boot procedure dies after displaying the message about how many bytes of code were loaded. The bootrap code will be inserted by newfs'ing the the a or c partions under 2.2, however this is painful if you've already built the disk. dd'ing the first 16 blocks of the raw a partition of a similar disk init'd under 2.2 to the system disk solved the problem for me. 2) The procedure for updating the console floppy assumes that you can lay claws on a virgin console floppy for your system. If all you have handy are configured VMS or Ultrix console floppys, the new stuff may not fit and it's fairly painful to figure out what is and isn't needed. 3) The df utility no longer works on raw devices. If you try it, it treats the device as a normal file and give you information about the amount of free space on the partition containing the /dev directory. 4) The /bin/mail program is actually in /usr/bin, with a soft-link in /bin. If your users have search paths like /usr/bin /usr/ucb /bin, they will get /bin/mail after the upgrade where before they would get /usr/ucb/mail. Best thing is to delete the link then move /usr/bin/mail back to /bin/mail, taking care to preserve the setuid bits. 5) The DECnet ncp program doesn't give a meaningful error when you attempt to use it on a system that doesn't have DECnet support properly configured into the kernel. I screwed up the DECnet installation, then spent two days trying to figure out why ncp kept giving me a "listenter: invalid identification format, node:" message when you tried to "set executor state on". This is especially painful, since the first thing the verification script does is "set executor state on". 6) The "args on dev" entry in the config file has been deleted and now causes a syntax error. The man entry for config however still makes allusions to specifying the location for "argument processing". 7) The default line characteristics for outgoing uucp calls seems to have changed to even parity. This may cause problems with auto- baud detection or logging into systems that you call. 8) The new IOCTL's for dealing with LAT terminal connections are present in ioctl.h, however there is no documentation and even the few header files that were present in /sys/lat and /sys/dli in Ultrix release 1.2 have been removed. Somebody should take a big club to DEC and make them understand it isn't proper unix form to provide system services and then refuse to document the user interface. 9) The man entry for dmf(4) mentions that the flags entry with respect to modem control, but doesn't make clear that the flags for the 6 lines without modem control should always be set to avoid unpredictable interface operation. 10) As usual, /usr/lib/games/fortune.dat file provided is corrupted and and /usr/game/fortune gets a floating point error, rather than printing out either of the entries in the fortunes.dat file. It's also less that obvious that you have to look in the fortunes.dat file for the instructions on creating a valid fortunes database. 11) The installation procedure diverges significantly from the traditional 4.x Berekely installation process. Providing a small section in the installation manual describing the installation process in unix terms in addition to the step-by-step instructions would be a great help to experienced installers and people trying to plan an upgrade for an existing system.
avolio@decuac.dec.com (Frederick M. Avolio) (04/14/88)
In article <27822@felix.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >4) The /bin/mail program is actually in /usr/bin, with a soft-link > in /bin. If your users have search paths like /usr/bin /usr/ucb > /bin, they will get /bin/mail after the upgrade where before they > would get /usr/ucb/mail. Best thing is to delete the link then > move /usr/bin/mail back to /bin/mail, taking care to preserve the > setuid bits. Negative. Best thing is to tell them to change their paths. 4.4 Berkeley is changing their directory set-up also, I believe. Some day (not fast enough for me) all of those ugly symbolic links will disappear. The cleanup of the directory structure is long overdue. You'll only find other things end up breaking in the future. Leave mail in /usr/bin and tell people to look in ucb first. (This should have been done all along anyway... You should always look in local bin first, then ucb bin, then usr/bin. Where you place /usr/new is up for grabs, but perhaps this discussion doesn't belong here.) Fred