sorensen@athena.mit.edu (Alma G. Sorensen) (04/20/91)
Howdy. Downloaded the 2.0.1 inc.cpio. Checksummed fine. Got to single user mode as instructed. Catted the update per the README. Got the following error message: cannot unlink current <shlib/libc1_s> (errno:26) Cannot create <shlib/libc1_s> (errno:26) 33586 blocks Errno 26 is something about a text file in use, I think, and I'm doing this as root and the file is writeable...what could be up? Thanks, Greg Sorensen sorensen@athena.mit.edu
alexis@panix.uucp (Alexis Rosen) (04/24/91)
sorensen@athena.mit.edu (Alma G. Sorensen) writes: >Howdy. Downloaded the 2.0.1 inc.cpio. Checksummed fine. >Got to single user mode as instructed. Catted the update >per the README. Got the following error message: > >cannot unlink current <shlib/libc1_s> (errno:26) >Cannot create <shlib/libc1_s> (errno:26) >33586 blocks > >Errno 26 is something about a text file in use, I think, and >I'm doing this as root and the file is writeable...what could be up? This is really obnoxious. I think this is a shared library which is used by some active program. I had similar though different problems with this same file. Move it somewhere else, like /tmp, and try again. --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NY {cmcl2,apple}!panix!alexis
ken@dali.cc.gatech.edu (Ken Seefried iii) (04/26/91)
In article <1991Apr24.053159.27641@panix.uucp> alexis@panix.uucp (Alexis Rosen) writes: >sorensen@athena.mit.edu (Alma G. Sorensen) writes: >> >>cannot unlink current <shlib/libc1_s> (errno:26) >>Cannot create <shlib/libc1_s> (errno:26) >>33586 blocks >> >>Errno 26 is something about a text file in use, I think, and >>I'm doing this as root and the file is writeable...what could be up? > >This is really obnoxious. I think this is a shared library which is used >by some active program. I had similar though different problems with this >same file. > Anyone who does an upgrade like this on a live system deserves anything and everything they get. It's not "obnoxious", it's the way shared libs work (you might try and figure it out some time). Try and do the upgrade from the A/UX startup shell. You might be suprised how easy it is. -- ken seefried iii "I'll have what the gentleman ken@dali.cc.gatech.edu on the floor is having..."
urlichs@smurf.sub.org (Matthias Urlichs) (04/27/91)
In comp.unix.aux, article <27342@hydra.gatech.EDU>,
ken@dali.gatech.edu (Ken Seefried iii) writes:
<
< Anyone who does an upgrade like this on a live system deserves
< anything and everything they get. It's not "obnoxious", it's the way
< shared libs work (you might try and figure it out some time).
<
Yes, but.
The "but" is the fact that BSD unix manages to open programs like any other
file, i.e. it's just an open file. Under any reasonable Unix, you can delete
a "normal" open file just fine and it will vanish if the last process that
has it open closes it.
I don't know the reason for making open demand-paged programs (and shared
libraries) a special case where the usual Unix semantics suddenly don't
apply, but it seems to me that it can't possibly be a very good one.
As for installing on top of a running system: Not everybody has enough free
space (remember sash doesn't have compress, and I don't think pipes work).
Myself, I had to pull the upgrade from another machine via NFS for exactly
this reason. Sash can't do that either.
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330) \o)/ken@dali.cc.gatech.edu (Ken Seefried iii) (04/27/91)
In article <-2.++F-@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: > >I don't know the reason for making open demand-paged programs (and shared >libraries) a special case where the usual Unix semantics suddenly don't >apply, but it seems to me that it can't possibly be a very good one. I agree with you 100%, it's not the best way to do things. However, it's the way it's done, and it's documented. Bitching because it doesn't work the way you *want* it to, as opposed to the way it really is, is not an excuse for botching an upgrade. >As for installing on top of a running system: Not everybody has enough free >space (remember sash doesn't have compress, and I don't think pipes work). >Myself, I had to pull the upgrade from another machine via NFS for exactly >this reason. Sash can't do that either. True, space can be a problem. I just uncompressed the file under older A/UX and split inc.cpio into smaller pieces for machine that had very small root partitions. Sorry...I'm not a super-genius, and doing this upgrade just wasn't that hard. On machines with root disks ranging from 86MB to 330MB. -- ken seefried iii "I'll have what the gentleman ken@dali.cc.gatech.edu on the floor is having..."
lat@snoopy.cs.vt.edu (Laurie Zirkle) (04/30/91)
In article <-2.++F-@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: > >As for installing on top of a running system: Not everybody has enough free >space (remember sash doesn't have compress, and I don't think pipes work). >Myself, I had to pull the upgrade from another machine via NFS for exactly >this reason. Sash can't do that either. I do not have the space to keep the 2.0.1 upgrade physically on the machine that I am upgrading - I have to mount it via NFS to access it. If you start with the machine in multi-user, shut it down to single user, and then follow the instructions, there is no problem with doing it from and NFS- mounted file system. Once in single-user mode (as opposed to the sash), you can mount and unmount NFS file systems (along with other network things). Laurie Zirkle COmputer Systems Engineer VPI&SU Computer Science Dept Blacksburg, VA 24061 Newsgroups: comp.unix.aux Subject: Re: 2.0.1 update error Summary: Expires: References: <-2.++F-@smurf.sub.org> Sender: Followup-To: Distribution: Organization: VA Tech Computer Science Department Keywords: In article <-2.++F-@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: > >As for installing on top of a running system: Not everybody has enough free >space (remember sash doesn't have compress, and I don't think pipes work). >Myself, I had to pull the upgrade from another machine via NFS for exactly >this reason. Sash can't do that either. I do not have the space to keep the 2.0.1 upgrade physically on the machine that I am upgrading - I have to mount it via NFS to access it. If you start with the machine in multi-user, shut it down to single user, and then follow the instructions, there is no problem with doing it from and NFS- mounted file system. Once in single-user mode (as opposed to the sash), you can mount and unmount NFS file systems (along with other network things). Laurie Zirkle COmputer Systems Engineer VPI&SU Computer Science Dept Blacksburg, VA 24061
antonio@Apple.COM (Antonio Ordonez) (04/30/91)
In article <1171@creatures.cs.vt.edu> lat@snoopy.cs.vt.edu (Laurie Zirkle) writes: >In article <-2.++F-@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: I didn't want to get involved in this but, the file libc1_s was not part of A/UX 2.0. A/UX 2.0 only included libc_s and libmac_s. The upgrade package was intended to upgrade 2.0 systems to 2.0.1. If this file exists in the system, it means that the system was either a 2.0.1 beta or the library was installed previously. I don't know of any other reason why that library would be present in the system and also be busy. Hope this helps (Please, no flames :-) Antonio -- ---------------------------------------------------------------------------- #include <disclaimer.h> /* I'll think of a better one later */ Antonio Ordonez amdahl \ Technical Communications/Direct Response Center pyramid!sun - apple!antonio Apple Computer, Inc. (408) 996-1010 decwrl / ----------------------------------------------------------------------------
liam@cs.qmw.ac.uk (William Roberts;) (04/30/91)
In <52157@apple.Apple.COM> antonio@Apple.COM (Antonio Ordonez) writes: >I didn't want to get involved in this but, the file libc1_s was not part >of A/UX 2.0. A/UX 2.0 only included libc_s and libmac_s. The upgrade >package was intended to upgrade 2.0 systems to 2.0.1. Perhaps you (or someone else) could clarify this a bit. The questions are: 1) Can A/UX 2.0 binaries complied with -lc_s or -lmac_s be used under the CD-ROM distribution of A/UX 2.0.1? 2) Can A/UX 2.0.1 binaries compiled with lc_s or -lmac_s be used with the original A/UX 2.0 distribution? 3) If either compatibility mode fails, how can we use something like "find" to identify all the out-of-date binaries? What changed? Weren't shared libraries intended (at least in part) to permit upgrades to the library without breaking existing binaries? -- William Roberts Internet: liam@dcs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-dcs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: +44 71-975 5234 (Fax: +44 81-980 6533)
sorensen@athena.mit.edu (Alma G. Sorensen) (04/30/91)
OK team, thanks for the help. It turns out the reason I had a problem with the 2.0.1 update was that the cpio archive was built to upgrade 2.0 to 2.0.1, and I was already using 2.0.1b2, which had some files present already that the upgrade wasn't expecting. I would have liked to use Ken's suggestion about sash, but the person who set up my disk made / a small partition (about 50Mb), and sash won't let me mount /usr or use uncompress. I ended up cpio-ing the archive into another subdirectory, then copying the unpacked file to its rightful spot. (And then Apple told me that there was no change in that file between 2.0.1b2 anbd 2.0.1, and so I shouldn't have worried about it in the first place...) Thanks again for the help, Greg Sorensen sorensen@nmr-r.mgh.harvard.edu
ksand@Apple.COM (Kent Sandvik, 120dB or more) (05/01/91)
In article <3072@redstar.cs.qmw.ac.uk> liam@cs.qmw.ac.uk (William Roberts;) writes: >1) Can A/UX 2.0 binaries complied with -lc_s or -lmac_s be used under > the CD-ROM distribution of A/UX 2.0.1? > >2) Can A/UX 2.0.1 binaries compiled with lc_s or -lmac_s be used with > the original A/UX 2.0 distribution? > >3) If either compatibility mode fails, how can we use something like "find" to > identify all the out-of-date binaries? Somehow it feels like I'm sticking my head to a beehive, but let's see if I manage to get out with no flaming hear. A/UX 2.0.1 contains two new versions of shared libraries: libc1_s and libmac1_s. If you want to run A/UX 2.0.1 binaries under 2.0 compiled with shared library flag, put these new shared libraries to the 2.0 system. That's it. Or compile binaries with no shared library support, and they run under 2.0. The old shared libraries from 2.0 are supported under 2.0.1, so 2.0 binaries should run with not problems. Shared libraries are fun, as long as vendors don't insert new functions that the old libraries do not contain. Kent Sandvik -- Kent Sandvik, DTS Rock Lobster Disclaimer: I am not working with Public Relations.