Question about Ignite Restore

[GTownes]

Hi All,

My /stand filesystem is full on one of my servers. I have created an ignite archive of vg00 excluding some filesystems, and want to use it to increase /stand.


My question is:
Are all filesystems still going to be intact after using the archive to increase /stand, or will I have to restore the excluded filesystems from backup?

[James R. Ferguson · Accepted solution]

Hi:

From where did you exclude the filesystems in question? Ignite will re-create vg00 and the filesystems _you_ specified for it.

Good practice says that vg00 consists _only_ of the standard logical volumes (lvol1-lvol8) created during a cold-install.

In cases like that, you could let Ignite re-import your non-vg00 filesystems or perform the operation yourself (with 'vgimport').

Regards!

...JRF...

[Pete Randall]

The ignite "restore" is very similar to an initial install and will recreate vg00 from scratch. Anything in other volume groups will survive unscathed and can be recovered be using vgimport to reconnect. If other filesystems existed in vg00 (and they shouldn't in a properly setup system), they will have to be restored separately. One way to avoid this is to use the "-x inc_entire=vg00" option when creating the archive.


Pete

[Bala C]

/stand is the first lvol1,primary swap is second lvol. What you can do is reduce the size of the primary swap and increase the space for /stand.

stand,swap & root lvols are contiguously allocated.

Example:

if /stand currently is 1GB and swap is 4GB, Increase the /stand to 1.5GB and reduce the swap size to 3.5GB.

These modifications can be done while restoring the archive image from the ignite server, choose the advanced installation option and change the size.

[mobidyc]

Hello,

if you have a fresh backup, why do not try to extend your root filesystem online ?

it is not dangerous if you have a backup and you will win time.

some documentations on how to do it:
http://www.google.com/search?q=extend+root+fs+site%3Ahp.com

Regards,
Cedrick Gaillard

[GTownes]

Here are the filesystems in vg00. I have excluded filesystems like /galaxy, /foglight, /usr/local/tripwire, and /PatchDepot.

Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 524288 275288 247256 53% /
/dev/vg00/lvol1 327680 244112 82952 75% /stand
/dev/vg00/lvol8 12320768 4680055 7164713 40% /var
/dev/vg00/voignt 153616384 94517014 55405675 63% /var/opt/ignite
/dev/vg00/lvol7 5963776 2568944 3368536 43% /usr
/dev/vg00/Tripwire 1048576 273760 726406 27% /usr/local/tripwire
/dev/vg00/lvol4 262144 101240 159704 39% /tmp
/dev/vg00/lvol6 3866624 3679176 186248 95% /opt
/dev/vg00/lv_rsm 393216 325799 63212 84% /opt/hp_rsm
/dev/vg00/lvol5 262144 39024 221408 15% /home
/dev/vg00/galaxy 40960000 26993615 13094558 67% /galaxy
/dev/vg00/lv_foglight
524288 149550 351338 30% /foglight
/dev/vg00/PatchDepot
51773440 46908942 4560511 91% /PatchDepot

So If I understand correctly, I would need to restore the excluded filesystems from backup.

The reason I am trying to extend /stand is due to the error I received below when trying to install Fibre Channel driver on the server.

ERROR: Although the increase on the filesystem for the resulting new
kernel might be enough, building it, requires additional disk
space for the temporary kernel and the object files.There is
not enough disk space available on filesystem "/stand" to
allow creation of temporary files. You must free at least 135
Kbytes on this volume.

[Mel Burslan]

Increasing /stand the way you are planning to do is one way of addressing your problem but you have to consider that, your server will be down while this process runs, quite some time, then the restoring of the excluded filesystems from backup and so on.

Instead, did you check the /stand contents and see anything that you can delete ? Sometimes I have seen people keeping 4 different copies of vmunix.prev ? 135K should not be that hard to clean up unless you are running a very tight ship with no room to spare. Clean up your /stand from junk if you can and schedule the restore from ignite approach to a weekend or a holiday as a proactive maintenance if you ask my opinion.

[Steven E. Protter]

Shalom,

This is pretty simple.

You make an Ignite archive.

You boot off the archive and use the intervention prompt to restore and change the size of the /stand file system as part of the system restore process.

Then you restore non vg00 data and you are are done. You may not if careful not even need to restore anything else.

It is a BASIC Ignite function.

SEP

[Pete Randall]

As long as the system is still available, I would simply make another Ignite archive (you'll want a fresh one (or two) anyway) using the "-x inc_entire=vg00" option to ensure that EVERYTHING is captured. The you can rebuild and restore all your extraneous data all in one step.


Pete

[GTownes]

Mel,

I couldn't agree with more. Finding 135K shouldn't be that hard to find. But I have always been leiry about removing anything from /stand. I did a search for some obvious files that could be removed, however nothing stood out to me. Maybe there is something I can remove but just being paranoid about it.

sudo kconfig -v
Configuration backup
Title Automatic Backup
Save Time Tue May 19 15:33:54 2009
Modify Time Tue May 19 15:33:54 2009
Kernel Path /stand/backup/vmunix

Configuration crashconfig
Title booted from 'import.config'
Save Time Wed Apr 11 15:16:49 2007
Modify Time Wed Apr 11 15:17:15 2007
Kernel Path /stand/crashconfig/vmunix

Configuration last_install
Title Created by last OS install
Save Time Wed Sep 8 12:38:43 2004
Modify Time Wed Sep 8 12:38:43 2004
Kernel Path /stand/last_install/vmunix


Also,

-rwxr-xr-x 1 root sys 42755376 Sep 8 2004 /stand/last_install/vmunix
-rwxr-xr-x 2 root sys 60940920 May 19 15:33 /stand/current/vmunix
-r-xr-xr-x 1 root root 1736384 Nov 2 2007 /stand/current/mod/drmfglrx
-r-xr-xr-x 1 root root 1068792 Nov 21 2008 /stand/current/mod/gvid_him_cons
-rwxr-xr-x 2 root sys 60940920 May 19 15:33 /stand/vmunix
-rwxr-xr-x 1 root sys 60925056 Apr 29 15:15 /stand/backup/vmunix
-r-xr-xr-x 1 root root 1068792 Nov 21 2008 /stand/backup/mod/gvid_him_cons
-r-xr-xr-x 1 root root 1736384 Nov 2 2007 /stand/backup/mod/drmfglrx
-rwxr-xr-x 1 root sys 58849184 Apr 11 2007 /stand/crashconfig/vmunix
-r-xr-xr-x 1 root root 1736384 Mar 23 2007 /stand/crashconfig/mod/drmfglrx
-r-xr-xr-x 1 root root 1068792 Mar 23 2007 /stand/crashconfig/mod/gvid_him_cons

[Shailendran V Naidu]

The Flat answer to your original question is - No

All the File Systems that have been excluded will have to be recreated from the lvol level and restored.

[Shailendran V Naidu]

Besides i think there are a few irrelevent kernels which you may never need.
You may want to delete it or move it else where.

[Mel Burslan]

-rwxr-xr-x 1 root sys 42755376 Sep 8 2004 /stand/last_install/vmunix
-rwxr-xr-x 2 root sys 60940920 May 19 15:33 /stand/current/vmunix
-r-xr-xr-x 1 root root 1736384 Nov 2 2007 /stand/current/mod/drmfglrx
-r-xr-xr-x 1 root root 1068792 Nov 21 2008 /stand/current/mod/gvid_him_cons
-rwxr-xr-x 2 root sys 60940920 May 19 15:33 /stand/vmunix
-rwxr-xr-x 1 root sys 60925056 Apr 29 15:15 /stand/backup/vmunix
-r-xr-xr-x 1 root root 1068792 Nov 21 2008 /stand/backup/mod/gvid_him_cons
-r-xr-xr-x 1 root root 1736384 Nov 2 2007 /stand/backup/mod/drmfglrx
-rwxr-xr-x 1 root sys 58849184 Apr 11 2007 /stand/crashconfig/vmunix
-r-xr-xr-x 1 root root 1736384 Mar 23 2007 /stand/crashconfig/mod/drmfglrx
-r-xr-xr-x 1 root root 1068792 Mar 23 2007 /stand/crashconfig/mod/gvid_him_cons

Out of this list, the file sizes of /stand/vmunix and /stand/current/vmunix are strikingly same. Run a diff against these two files and if they are the same, you can move /stand/current/vmunix to a different filesystem, to give you the temporary breathing room. Upon successful completion of a newly compiled kernel, it will be replaced by this new kernel and you do not have to move back the /stand/current/vmunix into original place, instead just delete it. If it does not, i.e., problems in kernel compilation, you can always refer back to this copy after booting to a recovery media and copying it back to its original place.

Hope this helps

[GTownes]

Thanks all for your excellent responses and support.

[Steven E. Protter]

Shalom,

Just a final bit of advice.

/stand is a single purpose file system. The only information that needs to be there is what is required to compile a kernel.

The files on stand if they are not being regularly used to boot the system can be stored elsewhere. HP-UX 11.11 still requires /stand to be HFS, but the files are not damaged by being stored elsewhere.

You can avoid the difficulty of ignite rebuilding your system with a few decisions on what you really need to boot your system off of.

I mean lets say you have a special kernel for running oracle all by itself, does it really need to sit in /stand or can it sit elsewhere and be moved into position just prior to reboot.

SEP