for huge "recommended" patch, not enough room in /var/sadm/patch



  • 1. Automatic oracle startup scripts for solaris 10.....
    Hi I installed the Oracle 10g on Solaris 10 (SPARC). Everything is fine just i need the dbs & lsnr to start automatic when server will start. So please if anyone have any scripts please share with me... Thanks&Regards Mohammed Tanvir
  • 2. Directories Searched by the Runtime Linker
    I'm using Solaris 8. I have a shared object, whose the RUNPATH was set with -R <path> options at compile time. I'm using "ldd -s <>" to view its link directory search order. It tries: -"." -Each directory in $LD_LIBRARY_PATH -Each directory in the RUNPATH I don't understand why the "." is there. "." is not in $LD_LIBRARY_PATH. For a test, I set $LD_LIBRARY_PATH to nil. Now, "." is no longer tried, only RUNPATH Where is "." coming from when $LD_LIBRARY_PATH is not empty? And why is it gone when I first set $LD_LIBRARY_PATH to nil.
  • 3. Leaving a process running after log-off
    Hello NG, Can anybody tell me how to leave a process running after logging off? I have tried postfixing with '&', which leaves my terminal clear to do other stuff, but as soon as I close my terminal window, the process terminates (I can see this by watching the running processes with 'top' in another terminal window). How do I keep a process running after logging off? Thanks in advance! Best, M.L.

for huge "recommended" patch, not enough room in /var/sadm/patch

Postby dkcombs » Mon, 02 Jun 2008 15:22:24 GMT

Not enough room in /var/sadm/patch, the install-script

But on other partitions and disks I have *lots* of
space available.  Just not on the root partition,
which contains /var/sadm/patch (among much else,
of course).

Might this work.

Rename /var/sadm/patch to eg /var/sadm/patch2-original,
then create a patch dir in some partition that had
logs of space, and then make /var/sadm/patch
a symlink to there.

Or should I symlink either higher up the var/sadm tree,
or symlink *several* of those directories?

And is there any reason to *copy* those directories
to where I'm going to symlink to, so that if there's
already some contents, they'll still be "there"?

(That install-script doesn't explicitly check for
this trick -- I hope not.)


Or is there maybe some better way to do surmount this not-enough-disk pbm?


Of course I do down to single-user before doing
the   ./install_cluster,

but any reason I can't leave everything else

I mean, in recent years, has anyone *ever* gotten
hurt by doing that?   (If so, please say how, so we
can all get wised-up on this, uh, danger.)



Re: for huge "recommended" patch, not enough room in /var/sadm/patch

Postby Michael Vilain » Mon, 02 Jun 2008 15:37:03 GMT

In article <g1tf70$cog$ XXXX@XXXXX.COM >,

This will only get worse as you apply patches.  Make some time to backup 
and re-layout your system disk so that / and /var are separate 
filesystems.  Be sure to have lots of room for mail spool, patches, and 

DeeDee, don't press that button!  DeeDee!  NO!  Dee...
[I filter all Goggle Groups posts, so any reply may be automatically by ignored]

Re: for huge "recommended" patch, not enough room in /var/sadm/patch

Postby AGT » Mon, 02 Jun 2008 16:07:08 GMT

But you wont accept that. 

Then fix whats broke yah putz! : >

No no no - just do whats right

Was it not Dr. Johnston or Samuel Peyps that said
that symlinks were the last refuge for scoundrels...?

Do it right the first time. Failing that, backup and fix whats broke
then restore. Sys Admin 101 stuff

Making a mess messi-er is not the way to the truth and the light : <

Re: for huge "recommended" patch, not enough room in /var/sadm/patch

Postby Geoff Lane » Mon, 02 Jun 2008 17:18:53 GMT

As root, run the command

find /var/samd -type f -name obsolete.Z -print

On a system that has been extensively patched over some time, there will be
a large number of such files, many of which will be very big.  It is safe to
delete these files with the command

find /var/samd -type f -name obsolete.Z -exec rm {} \;

I've seen systems where hundreds of megs have been released to /var by
deleting these files.

Also check /var/tmp, it is not cleared out during reboots (whereas /tmp is.)

Of course, the best solution is not to skimp when sizing / or /var,
do NOT accept the minimum values that the installer suggests.

Pierre Laplace: The telescope sweeps the skies without finding God.

Re: for huge "recommended" patch, not enough room in /var/sadm/patch

Postby Ian Collins » Mon, 02 Jun 2008 19:02:00 GMT


Ian Collins.

Re: for huge "recommended" patch, not enough room in /var/sadm/patch

Postby dkcombs » Tue, 03 Jun 2008 08:50:30 GMT

Yes, I'll try the "find".

Now, supposing that doesn't work -- ie still not enough

What's so awful with the symlink thing?

I'd set it up, do the patches, reboot, see if the
system basically works (like for 20 minutes of stuff), 
and if so, undo the symlink, resetting it to what it was before,
of course *not* removing what the symlink pointed to (in case
I have to back out of the patches), and ufsdump.

What I need to know is not whether this is "good admin practice"
(it's horrible, and I already know it), but WILL IT WORK?

Assuming there's nothing *inherently* wrong with doing
it this way *this one time*, ie that it won't reformat
all my disks or something equally horrible, I want to do it --
just this ONCE.



Then, I plan to buy an untra-5 (ie sparc), with 10 already 
on it.

(Oh, I have 9 on this one, a blade-100).

(I think that's how the ultra-5 comes, with 10 on it already?
And some way for me to partition it in some more reasonable
way than I did for the blade100.)

Make sure all my stuff works on that new computer -- and THEN
put 10 or open or 11 or whatever they call it onto the blade,
repartitioning it at the same time.


My blade, which is on-line (internet) maybe 5 minutes a month
for large downloads from my kermit-accessed (phone-line, ie
safe from hackers) -- it has been a *long* time since
I did the last recommended-and-security monster.

Since it's virtually never on the net, and since it has
been working fine for me for the compiling and testing
and development I do, no big deal.

So, I just want to get up-to-date, save it all away on
dump tapes, and then go to 10 or whatever.

And wait until *then* (when I will also purchase more disks)
and properly arrange things.



So, for this one time, shouldn't the symlink scheme work ok?



Re: for huge "recommended" patch, not enough room in /var/sadm/patch

Postby jimp » Tue, 03 Jun 2008 09:25:03 GMT

There is also the old backout copies of stuff.

If you look in /var/sadm/patch you will see all the patches that have
been applied.

Look for ones where you have lots of old versions.

Then from /var/sadm

find . -type d -name ancientpatchrev -exec rm -r {} \;

Once you do that you can't backout the patch, but if it is more than
a couple of rev's back it is unlikely you'll ever want to.

Jim Pennino

Remove .spam.sux to reply.

Re: for huge "recommended" patch, not enough room in /var/sadm/patch

Postby Ian Collins » Tue, 03 Jun 2008 17:01:27 GMT

Nothing unless you leave it there and attempt an upgrade.

It'll work, but do you want this level of arse ache for each big patch?

Ultra 5s tend to come out of skips these days!

Ian Collins.

Re: for huge "recommended" patch, not enough room in /var/sadm/patch

Postby Richard B. Gilbert » Tue, 03 Jun 2008 21:09:38 GMT

If you have LOTS of space available, back up your system disk,
repartition it with more generous allocations, and restore.

And make a note for the future that, when setting up a system,
generous allocations will save future agony!  I like to allocate 4 GB to
/ and another 4 GB to /var.

With today's EIDE disks, disk space is CHEAP.  Your time is not!  And 
even if you are using a more expensive technology, disk space may STILL 
be cheap relative to the time spent trying to cope with too small 

Re: for huge "recommended" patch, not enough room in /var/sadm/patch

Postby dkcombs » Wed, 04 Jun 2008 05:53:51 GMT

In article < XXXX@XXXXX.COM >,

Anyone want to explain that?  (Does he mean "ships"?)


Re: for huge "recommended" patch, not enough room in /var/sadm/patch

Postby Colin B. » Wed, 04 Jun 2008 06:26:21 GMT


Skip = garbage can. Usually a big dumpster.


Re: for huge "recommended" patch, not enough room in /var/sadm/patch

Postby Richard B. Gilbert » Wed, 04 Jun 2008 20:33:46 GMT

I believe, that we would call a skip a "dumpster"!  Ultra 5s make high 
tech doorstops! I have one that I haven't powered up in several years! 
It was the first Sun box I ever owned but I have replaced it with an 
Ultra 10; same MOBO but bigger power supply and more physical space to 
install RAM (the 256 MB DIMMs won't fit in the Ultra 5), two hard drive 
bays instead of one, etc.

Re: for huge "recommended" patch, not enough room in /var/sadm/patch

Postby dkcombs » Fri, 06 Jun 2008 06:46:46 GMT

In article <1AZ0k.124$js6.109@pd7urf1no>,


Some 30 or more years ago Barnes and Nobel had a remainders
bookstore on 5th ave at 18th st, across the street from
their main one, and in it I got (cheap!) an illustrated
oxford dictionary.  Yep, skip was in there under that
(and of course many other) meanings.  But no such meaning
in my giant American Heritage dictionary.

Two different languages, British and American!


Re: for huge "recommended" patch, not enough room in /var/sadm/patch

Postby dkcombs » Fri, 06 Jun 2008 07:00:15 GMT

In article < XXXX@XXXXX.COM >,


OOPS!  Ultra TWENTY-5.  the one they came out with just last year
or so.

What do I know about these things?  Three names, so far: sun 3/160 (1986)
("rack" went up to the ceiling), then the wonderful sparstation 5,
and now the blade100, which just went past end of life (no sunservice
available any more).   And each time, only one of them.

Thanks so much for explaining that skip term, guys.  Would be a bit
embarrassing trying to order the "super-fast" ultra 5!

Back to the main question:  This symlink-scheme outta work, right?

I mean I will be able to back-out of those patches if I need to,

(I'm waiting for someone to say yes, even thought it's not the
way to operate in the future -- ie partition the thing right
in the first place, which I will when I go to the next level
os.  (And what should that be?  10?  11?  Open?   ))



Re: for huge "recommended" patch, not enough room in /var/sadm/patch

Postby Richard B. Gilbert » Fri, 06 Jun 2008 07:50:01 GMT


Similar Threads:

1./var/sadm/pkg is very huge


I noticed that my /var/sadm/pkg is rather big. It's currently about 1.7g.
Can I deleted no longer required "save" directories from there (like


Alexander Skwar

2.Solaris Live upgrade: questions about /var/sadm/patch

 According to the solaris FAQ:--------8<-----------------|3.40) Why does
installing patches take so much space in /var/sadm?    All the files that
are replaced by a patch are stored under    /var/sadm/patch/<patch-id>/save
so the patch can be safely    backed out.  Newer patches will save the old
files    under /var/sadm/pkg/<pkg>/save/<patch-id>/undo.Z, for each package
patches.    You can remove the <patchdir>/save directory provided you also
remove the <patchdir>/.oldfilessaved file.  Newer patches will not
install a .oldfilessaved file.    Alternatively, you can install a patch w/o
saving the old    files by using the "-d" flag to installpatch.|3.41) Do I
need to back out previous versions of a patch?    No, unless otherwise
stated in the patch README.    If the previous patch installation saved the
old    files, you may want to reclaim that space.    Patches can be backed
out with (Solaris 2.6+):     patchrm <patch-id>    or in earlier releases:
/var/sadm/patch/<patch-id>/backoutpatch <patch-id>    Backoutpatch can take
an awful long time, especially when the    patch contained a lot of files.
This is fixed in later versions    of
backoutpatch.---------------->8---------------------------Prior to doing the
live upgrade, I would like to minimize the size of my root partition
(containing /var in my case) Can I safely remove all patches (not just the
save directories)from /var/sadm/patches or will live upgrade do it
automatically ? I presume that after a solaris upgrade, the liste of
installed patches on the system will be NULL ?Another last point, does "back
out patch" mean to go back to the state BEFORE the patch was applied ? I
don't understand the 3.41 paragraph. What does it mean ? It seems to mean
that whenever you apply a newpatch, you should go back to the previous
version before installing ?Ex: Original package = blabla-01Apply patch
blabla-02  (BlaBla-01 saved)You now want to apply patch blabla-03.Does
question 3.41 ask: "if you need to install patch blabla-03 you should first
back ou to blabla-01 ?" If so, what do you do if the README tells you that
you have to, but you REMOVED the save directory ?Thanks !

3.default permission in /var/sadm/patch

Hi all,

does anybody know what the reason is that all directories
in /var/sadm/patch have the permission 0754. Like this
it is impossible to grep for the Synopsis of the patches
in the README files as a normal user. Like this you can
only look at the patchids, which give a user who wants
to hack a system enough information about missing
patches that might offer opportunities to attack.

So what is the point not setting the default permission
to either 0750 (including the directory /var/sadm/patch)
or to 0755 and give users the oportunity to read the
README files of the installed patches?


4.ld: not enough room for program headers


Please let me know if this is off-topic; I'm new to the group.

My problem is linker behavior.  The error message is:

     Not enough room for program headers (allocated 7, need 8)

The project is a port of a large number of legacy Fortran.  There is nothing
very exotic in the source or build except I am trying to use the linker

  --section-start   .bss=0x080ee000

I find that if I tweek the value, the message goes away (so far!).  I have
tried the option -Tbss with the same or worse result.

Is this a bug in ld?  The compilers are Absoft Fortran 95.  The OS is Suse

I am doing this because I need to align uninitialized data objects common to
several of my programs.  Objects don't need to occupy the same user address
from program to program, but they do need to appear at the same relative
page offset.


Neil Ferguson

5.Test Case : __attribute__ ((aligned (16384)))==>Not enough room for program headers

On Linux, I was unable to compile the below test case with cc, gcc, or
g++! Does anyone know how I can if it's possible?

/* test.c */
#include <stdio.h>

  int t1;
  int t2;
  float tx;
} shared_memory __attribute__ ((aligned (16384)));

int main ()
  printf ("hello\n");

%g++ test.c
/usr/bin/ld: a.out Not enough room for program headers (allocated 7,
need 8)
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status

Thank you,
Christopher Lusardi

Note: On SGI, I can use "pragma align_symbol (shared_memory, 16384)"
after the definition of the struct without the error. If I use the
pragma on Linux it does not align properly.

6. (patch for Bash) ${var|.strip0}, ${var|.strip}, ${var|.lrstrip}, ${var|.lstrip}, ${var|.rstrip}

7. frequency alphabet for files in /var/sadm/install/contents

8. /var/sadm/pkg

Return to unix


Who is online

Users browsing this forum: No registered users and 43 guest