don@edison.UUCP (Don Kossman) (07/27/89)
we've been trying to get our hands on a 3.1 upgrade tape (to solve weekly "out of mbufs" messages on the console closely followed by total system death) and got the following strange tale from our local DEC maintenance contract support person: "the reason that 3.1 has not been shipping is a problem with tk50 media; dec got a bad batch and shipments have been on hold for the last TWO MONTHS for this reason." it was claimed that 9-TRACK media WAS shipping, and she offered to switch us to the 9-track ship list, in which case we would get a tape within 2 weeks. anyone out there gotten 3.1 on tk50? 9-track? also, what is the format of the 3.1 tape- if i get a 9-track tape, can i easily copy it to a tk-50? (my ris server isn't the one with the 9-track drive...) -- ------ don kossman, sei information technology, los angeles ...sun.com!suntzu!seila!don ...uunet!mahendo.jpl.nasa.gov!jplgodo!seila!don
stevem@pserv.UUCP (Steve Mestad) (07/27/89)
>In Message-ID: <288@edison.UUCP>, don@edison.UUCP (Don Kossman) asks >if anyone has received Ultrix 3.1 on TK-50..... We received our update today (7-26). Our sales rep gave us the bad TK-50 media story and tracked down our ship date. The rep said the update shipped during the last week of June (forget the exact date) so it took a *month* to reach us. Our rep was going to put in an exception ship order to get the update reshipped to us and said that would take a week or so. I suspect the rep went the extra mile because we are looking at buying another system and of course, they want us to buy theirs. Funny how responsive reps are during machine pick time. Steve Mestad (No signature defined yet....email to stevem%pserv@src.honeywell.com)
grr@cbmvax.UUCP (George Robbins) (07/27/89)
In article <288@edison.UUCP> don@edison.UUCP (Don Kossman) writes: > we've been trying to get our hands on a 3.1 upgrade tape > (to solve weekly "out of mbufs" messages on the console ... > "the reason that 3.1 has not been shipping is a problem > with tk50 media; dec got a bad batch and shipments have > been on hold for the last TWO MONTHS for this reason." > > anyone out there gotten 3.1 on tk50? 9-track? Well, I got it on 9-track, but only last week, so the out of TK50's story sounds a little wierd or at least questionably relevant as to why you haven't gotten the upgrade yet. On the other hand, you might end up waiting another few months if it be true... > also, what is the format of the 3.1 tape- if i > get a 9-track tape, can i easily copy it to a tk-50? > (my ris server isn't the one with the 9-track drive...) It's in setld format, with maybe 15-25 files on the tape for a total of about 20 M-bytes total. It's certainly copyable with something like a "copytape"* program or with dd, but doing so would be a moderate pain. You might also be able to use setld, either by letting it do it's RIS thing on the machine with a 9-track drive, then moving the data to RIS host, or via the "Reproducing stdld-Compatible kits" stuff in "Software Development, Volume 2" - "Guide to Preparing Software for Distribution on Ultrix Systems" in the little grey wall. (*) comp.sources.unix archives volume 10 The bottom line is you can do it, it'll take some mucking about and there's some risk they'll keep sending you 9-track tapes ever after. If the "out of mbufs" problem is the nfs related one, you might just a copy of the current 3.0 patch tape from the support center and apply the relevant one(s) and wait for your 3.1 update to eventually show up. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
fkittred@bbn.com (Fletcher Kittredge) (07/27/89)
In article <288@edison.UUCP> don@edison.UUCP (Don Kossman) writes: > >"the reason that 3.1 has not been shipping is a problem >with tk50 media; dec got a bad batch and shipments have >been on hold for the last TWO MONTHS for this reason." > >anyone out there gotten 3.1 on tk50? 9-track? > We received our copies of Ultrix 3.1 on a tk50 tape; it works splendidly. regards, fletcher Fletcher E. Kittredge fkittred@bbn.com
mikem+@andrew.cmu.edu (Michael Meyer) (07/27/89)
And my ultrix 3.1 distribution came on a CD ROM. --Mike
cks@white.toronto.edu (Chris Siebenmann) (07/28/89)
don@edison.UUCP (Don Kossman) writes: | anyone out there gotten 3.1 on tk50? 9-track? Our 3.1 upgrade (which came with our UWS 2.0 stuff for our new DECStation 3100s) came on a TK50 tape. Maybe they gave priority to new machines for some reason (we also got a server upgrade tape to let Vaxen serve DS3100's, so I assume the 3.1 tape isn't essential for DS3100 customers). | also, what is the format of the 3.1 tape- if i | get a 9-track tape, can i easily copy it to a tk-50? | (my ris server isn't the one with the 9-track drive...) The Vax tape has 3 almost-empty tar archives, one normal tar archive, and then 17 compressed tar archives. Should be fairly easy to copy with dd and a script. Which brings up a question: can someone mail me a list of what the 3.1 upgrade fixes (should anyone have such a list)? Our 3.1 upgrade came with zero instructions or documentation, and I'd like to find out what it fixed and how to install it. [There's no list on the tape itself; I checked. That's how I found out what all the tape files were :-).] -- "I shall clasp my hands together and bow to the corners of the world." Number Ten Ox, "Bridge of Birds" Chris Siebenmann ...!utgpu!{ncrcan,ontmoh!moore}!ziebmef!cks cks@white.toronto.edu or ...!utgpu!{,csri!}cks
grr@cbmvax.UUCP (George Robbins) (07/28/89)
In article <89Jul27.170604edt.30758@snow.white.toronto.edu> cks@white.toronto.edu (Chris Siebenmann) writes: > DECStation 3100s) came on a TK50 tape. Maybe they gave priority to new > machines for some reason (we also got a server upgrade tape to let > Vaxen serve DS3100's, so I assume the 3.1 tape isn't essential for > DS3100 customers). The 3.1 tapes include the UWS 2.1 upgrades. I'd assume the fixes here and and in 3.1 are probably more critical to the newer Risc Implementation than the more stable VAX base. New shipments probably do get priority over field updates in any case. > Which brings up a question: can someone mail me a list of what the > 3.1 upgrade fixes (should anyone have such a list)? Our 3.1 upgrade > came with zero instructions or documentation, and I'd like to find out > what it fixed and how to install it. Somewhere in the paperwork, you should have received a copy of the Ultrix 3.1/UWS 2.1 release notes. If not, I'd contact DEC. That is the only reasonably effective list of what's fixed/changed by the new release. It may also include support for new peripherals/systems. Install of the Ultrix 3.1 stuff is simple: backup, setld -l, rebuild kernel, reboot, replace customized files (if any) that were replaced. The UWS install sounds a lot messier. RIS adds complications. Highlights: Security fixes (hopefully) NFS Bugs/panics TSMCP fixes Terminal Driver Fixes Note that more is changed than is described in the release notes, they're fairly adequate as far as the utilities, but if you get a copy of the 3.0 patch tape readme file, you'll get a better description of the critical kernel/system problems that should have gotten fixed. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
ab@babcock.cerc.wvu.wvnet.edu (Alan Butcher) (07/29/89)
From article <288@edison.UUCP>, by don@edison.UUCP (Don Kossman): > we've been trying to get our hands on a 3.1 upgrade tape > anyone out there gotten 3.1 on tk50? 9-track? Received our 3.1 update tape a couple of days ago, on a TK50
graham@fuel.dec.com (kris graham) (07/31/89)
>Install of the Ultrix 3.1 stuff is simple: backup, setld -l, rebuild >kernel, reboot, replace customized files (if any) that were replaced. >The UWS install sounds a lot messier. RIS adds complications. UWS is also very simple. - Go into single-user mode - Run fsck - Unmount all file systems and remount all UFS file systems. #/etc/umount -a # /etc/mount -a -t ufs - Run /etc/update to keep file system consistent. - You may run the error logger... #/etc/eli -s - Use 'setld' to load UWS 2.1 software. #/etc/setld -l /dev/nrmt*h - run /etc/doconfig...after all desired UWS subsets are loaded. - Move the new kernel to root (after saving the old one). - /etc/reboot -- Christopher Graham Digital Equipment Corp Ultrix Resource Center New York
burzio@mmlai.UUCP (Anthony Burzio) (08/01/89)
In article <1410@riscy.dec.com>, graham@fuel.dec.com (kris graham) writes: > UWS is also very simple. > - Move the new kernel to root (after saving the old one). > - /etc/reboot A user should not have to do these operations manually. Ideally, it IS possible to have a program that lets you pop in a tape, press install all, and wait for the COMPUTER to do all the rest... ********************************************************************* Tony Burzio * Look Mom, there's a racoon, bear, and a Martin Marietta Labs * film crew in the woods! mmlai!burzio@uunet.uu.net * - The Muppet Show *********************************************************************
rusty@GARNET.BERKELEY.EDU (08/02/89)
According to the Software Product Description, for a VAXstation II/GPX, Ultrix 3.1 now requires 6 MB of memory. That's up 2 MB from Ultrix 3.0. This entry in the table has footnote number 9 next to it and footnote 9 says "SPD memory specifications reflect the minimum bootable memory configuration" so it sounds pretty grim. Does anybody know if I can boot Ultrix 3.1 with 5 MB? I know that DECwindows eats up a lot of memory so I've been running vanilla X11 Release 3.
graham@fuel.dec.com (kris graham) (08/02/89)
>A user should not have to do these operations manually. Ideally, it >IS possible to have a program that lets you pop in a tape, press >install all, and wait for the COMPUTER to do all the rest... Agreed.....remember. ..Digital makes this procedure look like an upgrade. You do not have to de-install the old environment (UWS 2.0) to upgrade to the new version. You forget to give credit to all the work done by the 'setld' and 'doconfig' utilities. They don't miss a beat in patching the old subsets and the kernel. You are not required to use raw utilities like 'tar'! ULTRIX will automatically move the new kernel to root and save the old one for you in any regular installation. Your point is well taken... "usual disclaimers apply" -- Christopher Graham Digital Equipment Corp Ultrix Resource Center New York City
grr@cbmvax.UUCP (George Robbins) (08/02/89)
In article <579@mmlai.UUCP> burzio@mmlai.UUCP (Anthony Burzio) writes: > In article <1410@riscy.dec.com>, graham@fuel.dec.com (kris graham) writes: > > UWS is also very simple. > > - Move the new kernel to root (after saving the old one). > > - /etc/reboot > > A user should not have to do these operations manually. Ideally, it > IS possible to have a program that lets you pop in a tape, press > install all, and wait for the COMPUTER to do all the rest... Sure, but requiring it to be so simple and devoid of intelligent intent sort of presupposes you needn't have anybody handy capable of picking up the pieces if something goes wrong, interpreting change notes, and preserving local color? I've complained before that Ultrix installation procedures are getting too user friendly of at least fail to provide an alternate track and documentation to enable an experienced administrator to his job in an efficient manner. Maybe this is only a reflection of some underlying need for job security...except I'm playing electrical engineer these days on only doing Unix administration to make sure the system serves me! -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
grr@cbmvax.UUCP (George Robbins) (08/02/89)
In article <8908012227.AA24357@garnet.berkeley.edu> rusty@GARNET.BERKELEY.EDU writes: > According to the Software Product Description, for a VAXstation > II/GPX, Ultrix 3.1 now requires 6 MB of memory. That's up 2 MB from > Ultrix 3.0. This entry in the table has footnote number 9 next to it > and footnote 9 says "SPD memory specifications reflect the minimum > bootable memory configuration" so it sounds pretty grim. > > Does anybody know if I can boot Ultrix 3.1 with 5 MB? I know that > DECwindows eats up a lot of memory so I've been running vanilla X11 > Release 3. Well, I wouldn't let it stop you from trying. Only DEC can really explain how they derive this number, but my interpretations is that "bootable" is a misnomer and what they are really giving is the amount of memory needed to adequately run the system software witout allowances for applications coding and multiple users. There are hard limits having to do with the size of the generic kernel, system utilities and swapping considerations, however I doubt these add up to 6 MB. You should ought to consider picking up some more memory so you can run or not run DECwindows as a matter of preference rather than necessity... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
grr@cbmvax.UUCP (George Robbins) (08/02/89)
In article <1422@riscy.dec.com> graham@fuel.dec.com (kris graham) writes: > > > You forget to give credit to all the work done by the > 'setld' and 'doconfig' utilities. They don't miss a beat in patching the old > subsets and the kernel. You are not required to use raw utilities like 'tar'! Then why did that tricksy little setld overwrite my locally customized version of /etc/disktab? Surely it could have done a checksum to verify it was or wasn't the virgin thing and at least told me it was up to something? -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
arosen@hen.ulowell.edu (MFHorn) (08/02/89)
In article <7505@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: In article <579@mmlai.UUCP> burzio@mmlai.UUCP (Anthony Burzio) writes: > A user should not have to do these operations manually. Ideally, it > IS possible to have a program that lets you pop in a tape, press > install all, and wait for the COMPUTER to do all the rest... Sure, but requiring it to be so simple and devoid of intelligent intent sort of presupposes you needn't have anybody handy capable of picking up the pieces if something goes wrong, interpreting change notes, and preserving local color? You might like something more like DG's installation procedures. It checks with the operator before any major step and does error checking on everything it does. If something goes wrong, it tells you about it, tells you where it put the errors and asks what you want to do. It'll also tell you if you have to do anything manually for changes to take effect. It does this thoroughly and consistently throughout all the administrative scripts it has, which cover ttys, printers, tapes, disks, files, kernels, users, uucp, tcp/ip, layered software, etc. -- Andy Rosen | arosen@swan.ulowell.edu | "I got this guitar and I ULowell, Box #3031 | ulowell!arosen | learned how to make it Lowell, Ma 01854 | | talk" -Thunder Road RD in '88 - The way it should've been
kennish@janus.uucp (Ken A. Nishimura) (08/03/89)
In article <8908012227.AA24357@garnet.berkeley.edu> rusty@GARNET.BERKELEY.EDU writes: >According to the Software Product Description, for a VAXstation >II/GPX, Ultrix 3.1 now requires 6 MB of memory. That's up 2 MB from >Ultrix 3.0. This entry in the table has footnote number 9 next to it >and footnote 9 says "SPD memory specifications reflect the minimum >bootable memory configuration" so it sounds pretty grim. > >Does anybody know if I can boot Ultrix 3.1 with 5 MB? I know that >DECwindows eats up a lot of memory so I've been running vanilla X11 >Release 3. Yes, you can do it. We have three machines here running 3.1/2.1 with only 5MB of core. Yes, it's VERY slow at times, and DecWindows is out of the question. With uwm, it's tolerable. But, if you can get some more memory, I'd try to get some more. The machine that has 9MB runs much better than the ones with 5MB. -ken
grunwald@flute.cs.uiuc.edu (Dirk Grunwald) (08/03/89)
How much does DECwindows take compare to e.g., the MIT X11R3 distribution? Why does it take more? Since the monochrome PMAX doesn't have a hardware accelerator, I assume that there's little performance improvement in using DECwindows over X11R3; am I right?
jg@max.crl.dec.com (Jim Gettys) (08/04/89)
The biggest issue is the toolkit, in particular, things like the fact that the help widget is built into all applications, which uses many/most other widgets. Shared libraries (as well as some dieting), are the right solution. As usual, though, you don't have to use the DECwindows applications you don't want to. Personally, I find the calendar program and the PostScript previewer the most useful DECwindows applications on the distribution (I'm an old stick in the mud, and still use xmh; lots of people prefer dxmail these days). There was a fair amount of work done on the monochrome server, so it is substantially faster than an R3 server, though not as dramatically as for color. I suspect you want to use the DECwindows server. There is also the same windowing performance work in it as in the color server, which was given back to MIT for R4 (which also goes much further in both the performance and memory usage areas). - Jim
kennish@janus.uucp (Ken A. Nishimura) (08/06/89)
In article <GRUNWALD.89Aug2153953@flute.cs.uiuc.edu> grunwald@flute.cs.uiuc.edu writes: > >How much does DECwindows take compare to e.g., the MIT X11R3 distribution? >Why does it take more? > >Since the monochrome PMAX doesn't have a hardware accelerator, I assume >that there's little performance improvement in using DECwindows over >X11R3; am I right? Well, the problem with DECwindows is worse on systems with little core memory. If there is one word to describe DECwindows or as a matter of fact any /usr/bin/dx*, it is HUGE. These are huge binaries, due to the enormous libraries associated with DECWindows. When running DECwindows on a memory starved machine, raising a window or doing any kind of context switch is painful, since it swaps anytime you do something. Plus, it costs a lot in terms of swap space. We found that we had to add another 12MB of swap to accomodate worst case DEC* usage. MIT X11R3 binaries are smaller, so the chance of things getting swapped out at every touch of the keyboard is smaller, plus it saves on virtual memory....plus I don't think it is as CPU intensive in the stuff it does behind the scenes, though I'm not sure about this. As for the PMAX, the color PMAX has no graphics accelerator either (e.g. no dragon chips). The graphics performance of the PMAX is entirely dependent on the R2000a processor. When unloaded, the PMAX will edge out the GPX, but when loaded, the display suffers. The problem with DECW* is worse on PMAXen for two reasons. (1) The binaries are larger. (2) DEC didn't use shared libraries.... Hence, every single /usr/bin/dx* application is 1MB of text. It gets really expensive after a while, especially if you are on an 8MB PMAXen. -ken
bobk@fred.colorado.edu (Bob Kinne) (09/14/89)
We are now running ultrix 3.0 on both VAX and RISC machines. We have obtained WS 2.1 (ultrix 3.1) upgrade tapes through the local CNS, which has an arrangement with our DEC salesperson that makes them the sole source for DEC SW (we can't get it through DEC without paying full list price). Unfortunately there is no documentation of any kind available. What I need to know is: 1. Is the 3.1 a replacement or an upgrade? In other words, when I put it on a network server, should I delete the 3.0 subsets in the client listing and replace them with 3.1, or should both be included? 2. What about the U01 'new processor upgrade' for 3.0 on the VS3100? Is it still needed? 3. Assuming 3.1 is an upgrade, what is the correct ordering? First 3.0, then 3.1, then U01, or 3.0, U01, then 3.1? 4. Can the microVAX 3500 server be upgraded using the WS 2.1 tapes, or is another version needed? Help with these questions and any other advice based on knowledge or experience (good or bad) will be very welcome. Thanks much. Bob Kinne Optoelectronics Computing Center UCB, Campus Box 525 VOICE (303) 492-3330 Boulder, CO 80309 INTERNET bobk@boulder.Colorado.EDU
frank@croton.dec.com (Frank Wortner) (09/15/89)
In article <11657@boulder.Colorado.EDU>, bobk@fred.colorado.edu (Bob Kinne) writes: > We are now running ultrix 3.0 on both VAX and RISC machines. We > have obtained WS 2.1 (ultrix 3.1) upgrade tapes through the local > CNS, which has an arrangement with our DEC salesperson that makes > them the sole source for DEC SW (we can't get it through DEC without > paying full list price). Unfortunately there is no documentation > of any kind available. It is available, but some tapes shipped without copies. This was an error. Tell CNS or the DEC salesperson that you need a copy. They are available and you *are* entitled to one. The DEC part number is AA-ME85-TE. > What I need to know is: > 1. Is the 3.1 a replacement or an upgrade? It's an upgrade. Keep the subsets you have now and use setld to load in upgraded versions. Be sure you upgrade ALL your loaded subsets, though. > 2. What about the U01 'new processor upgrade' for 3.0 on the VS3100? > Is it still needed? I believe 3.1 takes care of that problem. > 3. Assuming 3.1 is an upgrade, what is the correct ordering? > First 3.0, then 3.1, then U01, or 3.0, U01, then 3.1? 3.0, U01, and then 3.1 > 4. Can the microVAX 3500 server be upgraded using the WS 2.1 tapes, > or is another version needed? There is only one upgrade tape. It will upgrade either workstations or servers. Of course, you must use the proper tape for each architecture. VAX tape for VAXen, RISC tape for RISCen. :-) Regards, Frank
avolio@decuac.DEC.COM (Frederick M. Avolio) (09/15/89)
In article <11657@boulder.Colorado.EDU>, bobk@fred.colorado.edu (Bob Kinne) writes: > 1. Is the 3.1 a replacement or an upgrade? It is an upgrade. Shutdown to single user, make sure everything is *mounted*, and do the setld. > 2. What about the U01 'new processor upgrade' for 3.0 on the VS3100? You are not removing anything so I'm not sure this is germane. > 3. Assuming 3.1 is an upgrade, what is the correct ordering? > First 3.0, then 3.1, then U01, or 3.0, U01, then 3.1? I though U01 (you sure that is what it is labelled?) was a complete 3.0+. If so, it is U01 then 3.1. If not it is 3.0, U01, 3.1. > 4. Can the microVAX 3500 server be upgraded using the WS 2.1 tapes, YEs, 3.1 is on that as well as 2.1. Fred
shin@silk.c.u-tokyo.ac.jp (Shin Yoshimura) (09/16/90)
I am running Ultrix 3.1 with Japanese extension on a MicroVAX II. It has DHV11, 8 asynchronous port. I am using two modems(T-2000) for both of incoming/outgoing uucp. Sometimes, the system hangs. It is not panic down and no core dumps, just hang up. No answer comes by ping from other host, and DTR drops on modem port. It is completely down. On syslog and messages, no messages comes. But I found on LOGFILE of uucp, it occured just after dial-out uucp session. The log is as follows, On outgoing side(microVAX II) -------------------------------- uucp cotton (9/16-3:26-15743) using device (tty01, fd= 7, brand = tb-t - generic ) uucp cotton (9/16-3:26-15743) SUCCEEDED (call to cotton ) uucp cotton (9/16-3:26-15743) OK (startup) daemon cotton (9/16-3:26-15743) REQUEST (S D.komabab0RLW D.komabab0RLW daemon) daemon cotton (9/16-3:26-15743) REQUEST (S D.komabaX0RLU X.komabaX0RLU daemon) root cotton (9/16-3:26-15743) REQUEST (S D.komabab0RLg D.komabab0RLg root) uucp cotton (9/16-12:26-206) using device (tty01, fd= 8, brand = tb-t - generic) -------------------------- the session at 3:26 is not completed. On incoming side(Sun-3/80) ------------------------------------ uucp komaba (9/16-3:25-24159) OK (startup) uucp komaba (9/16-3:25-24159) REQUESTED (S D.komabab0RLW D.komabab0RLW daemon) daemon komaba (9/16-3:25-24159) COPY (SUCCEEDED) daemon komaba (9/16-3:25-24159) REQUESTED (S D.komabaX0RLU X.komabaX0RLU daemon) daemon komaba (9/16-3:25-24159) COPY (SUCCEEDED) daemon komaba (9/16-3:25-24159) REQUESTED (S D.komabab0RLg D.komabab0RLg root) root komaba (9/16-3:26-24159) COPY (SUCCEEDED) root komaba (9/16-3:26-24159) REQUESTED (S D.komabaX0RLe X.komabaX0RLe root) root komaba (9/16-3:26-24159) COPY (SUCCEEDED) root komaba (9/16-3:26-24159) OK (conversation complete) ------------------------------- The session complete normally. The system down occurs just after disconnection of phone. The drivers of tty have some problem. I need help for this problem. -- Shin Yoshimura Dept. of Chem., Coll. of Arts & Sci., The Univ. of Tokyo., JAPAN
D. Allen [CGL]" <idallen@watcgl.waterloo.edu> (04/15/91)
#!/bin/sh # Ultrix-32 V3.1 (Rev. 11) # Run this on Ultrix 3.1 and see how your #! path symlink messes up. # idallen@watcgl.waterloo.edu cd /tmp # Create an executable file using the "/tmp/2" interpreter. # cat >1 <<'EOF' #!/tmp/2 echo $0 hi there EOF chmod +x 1 # Create the "/tmp/2" interpreter as a symlink to a huge pathname. # long=/tmp/6789a123456789b123456789c123456789d ln -s $long 2 # And put sh into the long pathname. # cp /bin/sh $long # Try to execute the file. # On Ultrix 3.1 (VAX) you'll see "456789d: 456789d: cannot open" here. # No problem with other Unixes, or on other versions of Ultrix. # The conjecture is that Ultrix 3.1 is putting a 32-byte limit on the # *symlink* expansion of the #! interpreter. # ./1 rm 1 2 $long -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada
D. Allen [CGL]" <idallen@watcgl.waterloo.edu> (04/15/91)
$ wc /vmunix ^\Quit (core dumped) $ sleep 99 ^\Quit Why no core? Is there a patch for this? Ultrix-32 V3.1 (Rev. 11) -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada