fuat@cunixc.columbia.edu (Fuat C. Baran) (04/06/88)
Does anyone know why DEC decided to move /etc/init to /bin/init in Ultrix 2.2? I didn't run across this in the release notes or anywhere else. We tried booting a 2.2 /vmunix on a 2.0 filesystem, and it hung after the autosizer output. We were wondering what might be causing that and decided to cmp init, and that's when we noticed the init had moved... Linking /etc/init to /bin/init solved that problem. Of course /etc/mount, /etc/umount, etc. don't work right since the getmnt system call seems to have been changed. (This wasn't in the release notes either...) Seems like DEC thinks that when you upgrade from one release to another you should just totally blank out all your disks. They don't even bother to completely document what the changes are, so its trial and error trying to put your system back to the way it was... --Fuat Baran Academic Systems Group -- ARPANET: fuat@columbia.edu U.S. MAIL: Columbia University BITNET: fuat@cunixc.columbia.edu Center for Computing Activities USENET: ...!rutgers!columbia!cunixc!fuat 712 Watson Labs, 612 W115th St. PHONE: (212) 280-5128 New York, NY 10025
avolio@decuac.DEC.COM (Frederick M. Avolio) (04/14/88)
In article <27815@felix.UUCP>, fuat@cunixc.columbia.edu (Fuat C. Baran) writes: > > > Does anyone know why DEC decided to move /etc/init to /bin/init in > Ultrix 2.2? I didn't run across this in the release notes or anywhere > else. Check out the release notes page 1-2 under the heading "FIle System Reorganization." While I'll admit it doesn't go into as much detail as one would like, it does warn about the file system reorg and give some reasons for it. There are other notes in the release notes which should have given you ample warning as to why a 2.2 kernel cannot exist with many 2.0 system programs. Fred
wenger@crta.UUCP (Barry Wenger) (04/14/88)
in article <27815@felix.UUCP>, fuat@cunixc.columbia.edu (Fuat C. Baran) says: > > Seems like DEC thinks that when you upgrade from one release to > another you should just totally blank out all your disks. They don't > even bother to completely document what the changes are, so its trial > and error trying to put your system back to the way it was... > This information is greatly appreciated at this site. We are now running 8+ systems on 2.0. Last November we went through an extremely painful upgrade from 1.2 to 2.0. This consisted of a weekend marathon beginning about 5:00pm on a Friday nite, and lasted until sometime Monday morning around 10:00 am. (Talk about couple of zombie processes by then :-)) It took us the better part of the next two months to realize that all the changes were not documented fully. Now I learn the same is true on 2.2. GASP!!!. We are currently fortunate to have a spare system to experiment with, and we were trying to figure out how we could overlay 2.2 on the production systems. It is evident that we cannot. I do wonder why DEC assumes that, as is noted above, that customers can indeed just wipe out the the current work, which has taken us years to put in place and refine, and start over. This is essentially what we have to do. And do you think the users understand ? NOOOOOO WAY!! We are expected to do in a matter of days what has taken years to put together, and have everything work as before.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (04/21/88)
Following up the discussion of how Ultrix upgrades wipe out the
entire disk, here is a comment from a 4.3BSD user.
The nice thing about 4.3BSD is that there are no upgrades. None! No
revisions, no bug fixes, nothing. Other than a minor patch or two
obtained from Usenet, our system has been running without changes since
September 1986.
This solves all upgrade problems. All who can get a source license
should try this.
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesifuat@cunixc.columbia.edu (Fuat C. Baran) (04/22/88)
In article <29929@felix.UUCP> avolio@decuac.DEC.COM (Frederick M. Avolio) writes: >Check out the release notes page 1-2 under the heading "FIle >System Reorganization." While I'll admit it doesn't go into as much >detail as one would like, it does warn about the file system reorg and >give some reasons for it. > >There are other notes in the release notes which should have given you >ample warning as to why a 2.2 kernel cannot exist with many 2.0 system >programs. The release notes are definitely insufficient. The section you mention mainly discusses reorganization due to diskless workstations, especially the distinction between /usr/bin and /bin, /usr/lib and /lib, etc. It did not warn me that init was moved so trying to boot with a 2.2 kernel on a 2.0 filesystem, would not work at all. Checking for init wasn't the first thing we thought to look for when the the machine hung right after all the autosizer output. (We tried to bring 2.2 up on a microvax first before annoying all the users on the 8700.) In general, I do not find the release notes very helpful at all. If you want a laugh, try reading section 2.5.17 on page 2-22... Not exactly the most useful paragraph I've seen. Wasn't 2.2 supposed to be a "maintenance" release to mostly fix bugs? There should be a way to upgrade from one minor versions to another without a complete installation. --Fuat P.S. Do you by any chance know where in the release notes they mention that getmnt(2) was incompatibly modified so that things like the old mount/umount/df and any user program using getmnt(2) would no longer work? I didn't notice it when I read through the notes. -- ARPANET: fuat@columbia.edu U.S. MAIL: Columbia University BITNET: fuat@cunixc.columbia.edu Center for Computing Activities USENET: ...!rutgers!columbia!cunixc!fuat 712 Watson Labs, 612 W115th St. PHONE: (212) 280-5128 New York, NY 10025
avolio@decuac.dec.com (Frederick M. Avolio) (04/23/88)
In article <31574@felix.UUCP> fuat@cunixc.columbia.edu (Fuat C. Baran) writes: >The release notes are definitely insufficient. The section you >mention mainly discusses reorganization due to diskless workstations, >especially the distinction between /usr/bin and /bin, /usr/lib and >/lib, etc. It did not warn me that init was moved so trying to boot >with a 2.2 kernel on a 2.0 filesystem, would not work at all. Yes, this is true they do not cover every possible contingency. >In general, I do not find the release notes very helpful at all. ... I strongly suggest you fill out the READER'S COMMENTS card found in the back of every manual. That's the best way to affect a change in this regard. > Wasn't 2.2 supposed to be a "maintenance" release to mostly fix bugs? No. Maintenance releases (shoud they ever happen :-) ) would be "odd numbered" releases (e.g., 2.3). ... >P.S. Do you by any chance know where in the release notes they >mention that getmnt(2) was incompatibly modified so that things like >the old mount/umount/df and any user program using getmnt(2) would no >longer work? I didn't notice it when I read through the notes. Yeah, that is a tough one. Release notes currently do not list every subroutine and system call that has changed. The general rule is when you receive a full installation, do a full installation unless told specifically that you can do otherwise. Fred
bin@rhesus.primate.wisc.edu (Brain in Neutral) (04/27/88)
>From article <31098@felix.UUCP>, by dhesi@bsu-cs.UUCP (Rahul Dhesi):
<
< This solves all upgrade problems. All who can get a source license
< should try this [running 4.3 BSD instead of Ultrix].
Doesn't work too well for VAXBI systems, though, unless someone's figured
how how to hack BSD to understand the BI bus. Anyone?nes@prcrs.UUCP (Nancy Shoemaker) (05/04/88)
fuat@columbia.edu: > > In general, I do not find the release notes very helpful at all. If > you want a laugh, try reading section 2.5.17 on page 2-22... Not > exactly the most useful paragraph I've seen. > Actually, my favorite was 2.5.18, "Regular Expression Handling". To date, that's the only response I've seen to the SPR ICA-6498 that we filed on 5/5/87 (though on 4/4/88 SPR administration told me that the reply was sent on 3/31). Section 2.5.18 reports that there are limits to the length of the regular expression that can be handled by ed, ex and the grep type commands. [Surprise?] The SPR reported that the limit will sometimes be exceeded by the command /usr/bin/calendar. When the month ends on a Saturday or Sunday, the regular expression generated on the last Friday will be longer than egrep can handle and calendar will abort. Don't expect Ultrix v{1.1,1.2,2.0,2.2} "calendar" to remind you of anything important on Friday, April 29, 1988!
chris@mimsy.UUCP (Chris Torek) (05/04/88)
>>From article <31098@felix.UUCP>, by dhesi@bsu-cs.UUCP (Rahul Dhesi): ><This solves all upgrade problems. All who can get a source license ><should try this [running 4.3 BSD instead of Ultrix]. In article <32290@felix.UUCP> bin@rhesus.primate.wisc.edu (Brain in Neutral) writes: >Doesn't work too well for VAXBI systems, though, unless someone's figured >how how to hack BSD to understand the BI bus. Anyone? Not too difficult. The problem is that only the 8[23][05]0 are simple BI machines. The more interesting machines---the 8700, 8800, and the recently-released whatever-they-are-called---have an internal CPU/ memory bus and get at BI buses via adapters. Making 4.3BSD run on the 8250 was relatively easy, since all I had to do was lie about the bus structure (and claim the KDB50 adapter was on the Unibus!). Even doing an 8800 with two BIs would be possible, since the 86x0 can have two SBIAs and has IOA maps. Still, the whole autoconfiguration system needs to be rewritten with the new hardware in mind. Debugging my KDB50 adapter code was harder.... (Did you know the VM code assumes that the pageout driver has copied the PTEs, and that it is safe to smash them? Oops! I found out with a `host buffer memory access error'.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
tim@mtxinu.UUCP (Tim Wood - Sybase Inc.) (05/04/88)
In article <32290@felix.UUCP> you write: > >>From article <31098@felix.UUCP>, by dhesi@bsu-cs.UUCP (Rahul Dhesi): >< >< This solves all upgrade problems. All who can get a source license >< should try this [running 4.3 BSD instead of Ultrix]. > >Doesn't work too well for VAXBI systems, though, unless someone's figured >how how to hack BSD to understand the BI bus. Anyone? MtXinu, of Berkeley, CA, is working on their 4.3 BSD system for the Microvax 3x00 (i know, not BI) and the 8[35]xx line (BI). Supposed to be ready this summer. -TW -- {ihnp4!pacbell,pyramid,{uunet,ucbvax}!mtxinu}!sybase!tim
ado@elsie.UUCP (Arthur David Olson) (05/17/88)
In article <33321@felix.UUCP>, nes@prcrs.UUCP (Nancy Shoemaker) writes: > . . . > Section 2.5.18 reports that there are limits to the length of the > regular expression that can be handled by ed, ex and the grep type > commands. [Surprise?] The SPR reported that the limit will sometimes > be exceeded by the command /usr/bin/calendar. When the month ends on > a Saturday or Sunday, the regular expression generated on the last > Friday will be longer than egrep can handle and calendar will abort. > Don't expect Ultrix v{1.1,1.2,2.0,2.2} "calendar" to remind you of > anything important on Friday, April 29, 1988! Don't know if this will work around your April bug; in any event. . . !From ado Sun Nov 30 19:16:40 1986 !... !Subject: MORE/bsd 4.3 /usr/lib/calendar foils egrep on Fridays late in the year !... ! !Index: usr.bin/calendar/calendar.c MORE/bsd 4.3 Fix ! !Description: ! The "egrep" scripts generated by "/usr/lib/calendar" are rejected ! by "egrep" on Fridays late in the year. ! !Repeat-By: ! Run the commands ! date 8611281200 ! /usr/lib/calendar > /tmp/try ! egrep -f /tmp/try < /dev/null ! and note the result: ! egrep: regular expression too long ! !Fix: ! Here are context differences between the version of "calendar.c" ! distributed with MORE/bsd 4.3 and a version that produces a ! different regular expression that egrep can handle. The different ! regular expression does not accept "011" as a synonym for "November" ! but does still accept "01" (. . ."09") as a synonym for "January" ! (. . ."September"). ! !*** old/calendar.c Sun Nov 30 19:08:44 1986 !--- new/calendar.c Sat Nov 29 10:42:20 1986 !*************** !*** 1,3 **** !--- 1,8 ---- !+ #ifndef ASWAS !+ #ifdef OBJECTID !+ static char elsieid[] = "@(#)calendar.c 3.2"; !+ #endif /* OBJECTID */ !+ #endif /* !ASWAS */ ! static char *sccsid = "@(#)calendar.c 4.5 (Berkeley) 84/05/07"; ! /* /usr/lib/calendar produces an egrep -f file ! that will select today's and tomorrow's !*************** !*** 30,35 **** !--- 35,51 ---- ! { ! struct tm *tm; ! tm = localtime(&t); !+ #ifndef ASWAS !+ /* !+ ** Prevent "egrep: regular expression too long" error. !+ */ !+ if ((tm->tm_mon + 1) >= 10) !+ (void) printf( !+ "(^|[ (,;])((%s[^ \t]*[ \t]*|%d/)0*%d)([^0123456789]|$)\n", !+ month[tm->tm_mon], !+ tm->tm_mon + 1, tm->tm_mday); !+ else !+ #endif /* !ASWAS */ ! printf("(^|[ (,;])((%s[^ \t]*[ \t]*|(0%d|%d)/)0*%d)([^0123456789]|$)\n", ! month[tm->tm_mon], ! tm->tm_mon + 1, tm->tm_mon + 1, tm->tm_mday); -- ado@ncifcrf.gov ADO is a trademark of Ampex.