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 11.1.1.7.140114 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
ln -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/11.1.1.7.140114 -id 16569379,16913445,16997936,17300045,17300417,17922352,17922552,17922577,17922596 OPatch.SKIP_VERIFY_SPACE=true
Done.
(h/t @G_Ceresa for being picky and getting on my nerves with “That’s not proper.” … I said it’s a hack, mate ;-))
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).
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.
Yes, but this doesn't mean "picky", I will say "accurate" 😉
Bean counter 😛