Thursday, February 27, 2014

Working around opatch - Prerequisite check "CheckSystemSpace" failed.

I recently ran into the situation where the primary mount for a Linux tech account running an OBI install was just way too small to get OBIEE through.
Prerequisite check "CheckSystemSpace" failed.
The details are:
Required amount of space(17499.766MB) is not available.
So with a bit of hacking I got around it by displacing the ./patch_storage directory and forcing opatch to stop doing a file system check (basically no "df -h" )

1.) displace ./patch_storage to a mount with enough space (but keep a backup in place just in case...)
cp -r /FMWH/Oracle_BI1/.patch_storage /data/NASmnt00001/

mv /FMWH/Oracle_BI1/.patch_storage_bkp

2.) create a symbolic link to take the place of ./patch_storage
ls -s /data/NASmnt00001/.patch_storage ./.patch_storage
After this step if you execute opatch normally, it will still fail with "CheckSystemSpace" failed.

3.) Have opatch omit the space check:

opatch napply -silent /data/NASmnt00001/ -id 16569379,16913445,16997936,17300045,17300417,17922352,17922552,17922577,17922596 OPatch.SKIP_VERIFY_SPACE=true


(h/t @G_Ceresa for being picky and getting on my nerves with "That's not proper." ... I said it's a hack, mate ;-))


  1. I will not say "picky" ...
    My point is that we had to use this option because the linux account we have on the server has no privileges at all (more or less). If possible I will personally first do a mount to load a new volume inside .patch_storage and move content into this new place, if no new volume is available try a mount --bind to mount another directory in .patch_storage, last option the ln -s (if allowed).

  2. Gianni,

    Obviously a real mount is the proper way to go, but as you already hinted: if you don't have enough access rights and/or time is of the essence, then it's just fine to use a more quick&dirty approach to validate things.

    1. Yes, but this doesn't mean "picky", I will say "accurate" ;-)