LVM: PVG-strict/distributed allocation

It's a bit "incomplete". My goal is to make an example of creating an FS, a striped that is but, unfortunately, what was assigned to me covers only the PVG-strict/distributed allocation with 1TB in size. But still hoping that this will create an interest on your part. Btw, we usually do this sequence which a bit [again] proven. Enjoy.

================================
1. I first checked if the allocated LUNs are still available for this FS creation. [Of course, all here are available..].

[root@hpux01:/home/user17]
# for i in `more 20080429diskinfo.rpt | grep -i lvm | grep -v "0(" | sort -u | awk '{print $1}'`
> do
> strings /etc/lvmtab | grep ${i}
> echo "--------------"
> pvdisplay /dev/dsk/${i}
> echo "XXXXXXXXXXXXXXXXXXXXXXXXXXX"
> done
--------------
pvdisplay: Couldn't find the volume group to which
physical volume "/dev/dsk/c52t10d7" belongs.
pvdisplay: Cannot display physical volume "/dev/dsk/c52t10d7".
XXXXXXXXXXXXXXXXXXXXXXXXXXX
--------------
.....
pvdisplay: Couldn't find the volume group to which
physical volume "/dev/dsk/c82t2d7" belongs.
pvdisplay: Cannot display physical volume "/dev/dsk/c82t2d7".
XXXXXXXXXXXXXXXXXXXXXXXXXXX
--------------
pvdisplay: Couldn't find the volume group to which
physical volume "/dev/dsk/c82t3d0" belongs.
pvdisplay: Cannot display physical volume "/dev/dsk/c82t3d0".
XXXXXXXXXXXXXXXXXXXXXXXXXXX

[root@hpux01:/home/user17]
#

================================
2. Just like before, we will initialize the LUNs for LVM use.

[root@hpux01:/home/user17]
# for i in `cat LUNs.txt`
> do
> pvcreate /dev/rdsk/${i}
> echo "----------"
> done
Physical volume "/dev/rdsk/c52t3d0" has been successfully created.
----------
.....
Physical volume "/dev/rdsk/c82t2d7" has been successfully created.
----------
Physical volume "/dev/rdsk/c82t3d0" has been successfully created.
----------

[root@hpux01:/home/user17]
#
================================
3. Create the device file for the VG group.

[root@hpux01:/home/user17]
# mkdir -p /dev/vg_name

[root@hpux01:/home/user17]
# ll -d /dev/vg_name
drwxr-xr-x 2 root sys 96 Apr 30 03:43 /dev/vg_name

[root@hpux01:/home/user17]
# mknod /dev/vg_name/group c 64 0x330000

[root@hpux01:/home/user17]
# ll /dev/vg_name/group
crw-r--r-- 1 root sys 64 0x330000 Apr 30 03:44 /dev/vg_name/group

[root@hpux01:/home/user17]
#

================================
4. Let's make a VG with the following characteristics:

a. Maximum number of LUNs set to 64 - this limits the number of disk that can be added to the volume group to 64
b. PE size of 64MB
c. extent size of 15000 - this addresses the number of extents that can be created on a disk. If this is not specified, it'll take the maximum number of extents that can be created on the first disk joined to the VG. Which will limit the usage of other LUNs bigger [in capacity] than the initialized disk.
Ex: If you initialize a disk with size 8GB w/out specifying -e flag, when you join a disk bigger than 8GB, it'll limit only the usage of this disk to 8GB. I hope you get the picture, if NOT, leave a comment. I'd be happy to answer.
d. Create a PVG

4.1. This is just an initialization. I made a li'l script below which will add other disks.
# vgcreate -p 64 -s 64 -e 15000 -g PVG0 /dev/vg_name /dev/dsk/c52t3d0

4.2. Add the remaining primary disks.
# for i in `cat LUNs.txt`
> do
> vgextend -g PVG0 vg_name /dev/dsk/${i}
> echo "---"
> done

4.3. Add the alternate links.
# for i in `cat Alt_LUNs.txt`
> do
> vgextend /dev/vg_name /dev/dsk/${i}
> echo "---- PV Link added ----"
> done

================================
5. Create the LV with PVG-strict/distributed allocation.

[root@hpux01:/home/user17]
# lvcreate -L 1044480 -n lv_data7 -s g -D y /dev/vg_name
Logical volume "/dev/vg_name/lv_data7" has been successfully created with
character device "/dev/vg_name/rlv_data7".
Logical volume "/dev/vg_name/lv_data7" has been successfully extended.
Volume Group configuration for /dev/vg_name has been saved in /etc/lvmconf/vg_name.conf

[root@hpux01:/home/user17]
# lvdisplay /dev/vg_name/lv_data7
--- Logical volumes ---
LV Name /dev/vg_name/lv_data7
VG Name /dev/vg_name
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 1044480
Current LE 16320
Allocated PE 16320
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation PVG-strict/distributed
IO Timeout (Seconds) default

[root@hpux01:/home/user17]

================================
6. For comparison purpose [will be referenced for the creation].

# mkfs -m /dev/vg_old_name/lv_data6
mkfs -F vxfs -o ninode=unlimited,bsize=8192,version=4,inosize=256,logsize=256,largefiles /dev/vg_old_name/lv_data6 1069547520

================================
7. Format for FS usage [enabling large file support].

[root@hpux01:/home/user17]
# newfs -F vxfs -o largefiles /dev/vg_name/rlv_data7
version 4 layout
1069547520 sectors, 133693440 blocks of size 8192, log size 256 blocks
unlimited inodes, largefiles supported
133693440 data blocks, 133688056 free data blocks
4080 allocation units of 32768 blocks, 32768 data blocks

[root@hpux01:/home/user17]
# mkfs -m /dev/vg_name/lv_data7
mkfs: /etc/default/fs is used for determining the file system type
mkfs -F vxfs -o ninode=unlimited,bsize=8192,version=4,inosize=256,logsize=256,largefiles /dev/vg_name/lv_data7 1069547520

[root@hpux01:/home/user17]
#

================================
8. Create the mount point; add entry in the fstab, and mount.

[root@hpux01:/home/user17]
# mkdir -p /mount/point/sapdata7

[root@hpux01:/home/user17]
# ll -d /mount/point/sapdata7
drwxr-xr-x 2 root sys 96 Apr 30 04:23 /mount/point/sapdata7

[root@hpux01:/home/user17]
# vi /etc/fstab
...
/dev/vg_old_name/lv_data6 /mount/point/sapdata6 vxfs log 0 0
/dev/vg_name/lv_data7 /mount/point/sapdata7 vxfs log 0 0

[root@hpux01:/home/user17]
# mount /mount/point/sapdata7

[root@hpux01:/home/user17]
# bdf /mount/point/sapdata7
Filesystem kbytes used avail %used Mounted on
/dev/vg_name/lv_data7
1069547520 35032 1061156936 0% /mount/point/sapdata7

[root@hpux01:/home/user17]
#

================================
9. Change ownership and/or permissions as needed.

[root@hpux01:/home/user17]
# chown -R oraf6r:dba /mount/point/sapdata7

[root@hpux01:/home/user17]
# ll -d /mount/point/sapdata7
drwxr-xr-x 3 oraf6r dba 96 Apr 30 04:21 /mount/point/sapdata7

[root@hpux01:/home/user17]
#

================================
These were used when I have to re-create the VG.

A. Reducing the VG until 1 LUN is left.

for i in `cat /root/list_LUNs.txt`
do
echo "-----"
vgreduce /dev/vg_name $i
pvdisplay $i
echo "-----"
done

B. Removing the VG.
vgremove /dev/vg_name

C. Removing the LV.
lvremove /dev/vg_name/lv_data7

[SOLVED] Ubuntu 8.04 LTS - Hardy Heron has landed[!] and my NIC disappeared!

At last, it's here! Ok, it was released days ago but at least, the wait is over. :)

It took me about 18 hours to complete the upgrade online via SmartBro[ken]! That's correct, 18 hours. I'm tired of their service. "Konting tiis na lang, papa-putol ko rin 'yung service".

After 18 excruciating hours, my Ubuntu is now a Hardy Heron! Bwahahaha! Hmmm, there are 5 packages that we're not upgraded because of dependency issues, I'll try to fix it later. I rebooted to M$ XP [I'm having a dual-boot,. Need to access my work's email..] and boom! The network's gone! I mean, my NIC is not recognized both on M$ and Ubuntu. Oh sh*t! What happened? I'll check the forums bit later if the upgrade affected my hardware. I hope not [fingers crossed].

But for those who want to try Ubuntu, get it here - http://www.ubuntu.com/getubuntu/download.

Don't let my experience here shun you from trying Linux. It's an excellent OS. And it's free. If you want, I'd be happy to lend a hand. Going back, it could be a hardware issue either. This is just an isolated case! Nothing to worry. I'll update this one later, too! Wish me luck, I need them! Bye!

----------------------------------------------------------

Hello there, I decided to add my update here rather than create a new [notice the line above?].

Hoooooooooooooo! Finally, I got my NIC working! I read through the forums and I was reminded of Troubleshooting 101. Before blaming the OS or software for all the stupidity we have done, please check the hardware [issue] first. Just like in my case, it was a slot problem. I just moved my NIC to the other slot, and whoala, it's working again! Now that I'm back, it's time to fix the remaining packages.

Here are the error logs I got:


Setting up exim4-config (4.69-2) ...
/usr/sbin/dpkg-statoverride: non-existing group Debian-exim

Usage: dpkg-statoverride [ ...]

Commands:
--add
add a new entry into the database.
--remove remove file from the database.
--list [] list current overrides in the database.

Options:
--admindir set the directory with the statoverride file.
--update immediately update file permissions.
--force force an action even if a sanity check fails.
--quiet quiet operation, minimal output.
--help show this help message.
--version show the version.
dpkg: error processing exim4-config (--configure):
subprocess post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of exim4-base:
exim4-base depends on exim4-config (>= 4.30) | exim4-config-2; however:
Package exim4-config is not configured yet.
Package exim4-config-2 is not installed.
Package exim4-config which provides exim4-config-2 is not configured yet.
dpkg: error processing exim4-base (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of exim4-daemon-light:
exim4-daemon-light depends on exim4-base (>= 4.69); however:
Package exim4-base is not configured yet.
dpkg: error processing exim4-daemon-light (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of exim4:
exim4 depends on exim4-base (>= 4.69); however:
Package exim4-base is not configured yet.
exim4 depends on exim4-daemon-light | exim4-daemon-heavy | exim4-daemon-custom; however:
Package exim4-daemon-light is not configured yet.
Package exim4-daemon-heavy is not installed.
Package exim4-daemon-custom is not installed.
dpkg: error processing exim4 (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of rkhunter:
rkhunter depends on exim4 | postfix | sendmail | mail-transport-agent; however:
Package exim4 is not configured yet.
Package postfix is not installed.
Package sendmail is not installed.
Package mail-transport-agent is not installed.
Package exim4-daemon-light which provides mail-transport-agent is not configured yet.
dpkg: error processing rkhunter (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
exim4-config
exim4-base
exim4-daemon-light
exim4
rkhunter
E: Sub-process /usr/bin/dpkg returned an error code (1)


At first, I tried to build the dependencies.


root@rot:/house# apt-get build-dep exim4-config
...


'Though this might have corrected the dependencies, I still got the same error. How stupid of me to look ever simple things??? I may be better off joining the army or the police. I just shoot without asking. I checked again. Hmmmm, let's see... It seems the error is about the group Debian-exim, right?!? Haiz!

In the famous words of my Indian instructor, "Just do one thing..." well, I did two:


user1@rot:~$ sudo groupadd Debian-exim
user1@rot:~$ sudo /usr/sbin/dpkg-statoverride --add Debian-exim Debian-exim 640 /var/spool/exim4/
stripping trailing /
user1@rot:~$


And then ran again the update. and the rest is history...


root@rot:/house# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
5 not fully installed or removed.
After this operation, 0B of additional disk space will be used.
Do you want to continue [Y/n]? y
Setting up exim4-config (4.69-2) ...

Setting up exim4-base (4.69-2) ...
Installing new version of config file /etc/cron.daily/exim4-base ...
Installing new version of config file /etc/init.d/exim4 ...

Setting up exim4-daemon-light (4.69-2) ...
* Starting MTA [ OK ]

Setting up exim4 (4.69-2) ...

Setting up rkhunter (1.3.0-3) ...
Installing new version of config file /etc/rkhunter.conf ...
Installing new version of config file /etc/cron.daily/rkhunter ...
Installing new version of config file /etc/cron.weekly/rkhunter ...
Updating the file properties database:
[ Rootkit Hunter version 1.3.0 ]
File updated: searched for 151 files, found 125

root@rot:/house#

Basic LVM: VG, LV, and file system creation

It's been a while, and I think there is a need to add a new one here.

Knowledge sharing sessions were done last week with the other account and they discussed Logical Volume Management (LVM), HP-UX's style. As for my team, we have the privilege to eat, drink, and live with this everyday. I'm making a guide here on how it is done. Just check it out. And as a requirement, you must have a good understanding of LVM.

Basics: Have a unused and available disk ready on your system.

1. Ensure that the disk is not being used by other volume groups (VG). Any of these three will report IF the disk is in use by other VGs.

# vgdisplay -v | grep -i cXtYdZ
where: cXtYdZ is the disk represented by controller, target and LUN; or use `ioscan` to get the desired details
# strings /etc/lvmtab grep -i cXtYdZ
# pvdisplay /dev/dsk/cXtYdZ

2. If step 1 is ok, initialize the disk by creating LVM structures on the disk.

# pvcreate [-f] /dev/rdsk/cXtYdZ

3. We have to create a device file for the volume group.

# mkdir -p /dev/VG_name
# mknod /dev/VG_name/group c 64 <minor_number>
note: you can choose any minor number you want; good practice is to use the next available

4. Now, let's proceed with the VG creation [taking the default values].

# vgcreate /dev/VG_name /dev/dsk/cXtYdZ
note: alternate link can be specified here as well
# vgdisplay [-v] VG_name

5. Create the the logical volume (LV). And verify.

# lvcreate -L <LV_size_in_MB> -n LV_name VG_name
# lvdisplay /dev/VG_name/LV_name

6. Format the LV to be used as file system.

# newfs -F vxfs[specify_as_needed] /dev/VG_name/raw_LV_name

7. Create the mount point [commonly called directory] for the file system.

# mkdir /mount_point

8. Add the entry on the /etc/fstab which will ensure the it'll get mounted on succeeding reboot.

# vi /etc/fstab
...
/dev/VG_name/LV_name /mount_point [options_here]
...
:wq!

9. Mount the file system. Change the ownership and permissions as needed.

# mount /mount_point
# chown ...
# chmod ...

Basically, this is it. For more advance topics, we will have another time.

Ignite backup error - The list_expander command failed

Hello team, I'd like to share one of the common errors you will find during ignite backup.

[root@hpux02:/root]
# /opt/ignite/bin/make_net_recovery -s hpux03 -x inc_entire=vg00
* Creating NFS mount directories for configuration files.

======= 04/11/08 10:56:30 SST Started /opt/ignite/bin/make_net_recovery. (Fri
Apr 11 10:56:30 SST 2008)
@(#) Ignite-UX Revision B.5.4.50
@(#) net_recovery (opt) $Revision: 10.637 $

* Testing pax for needed patch
* Passed pax tests.
* Checking Versions of Recovery Tools
ERROR: Cannot stat device file: /dev/old_vg_apps/lv_mom: No such file or
directory (errno = 2). Check /etc/fstab for a bad entry.
ERROR: The list_expander command failed. This could be due to a problem with
the -x options specified - see messages above.

======= 04/11/08 10:57:11 SST make_net_recovery completed unsuccessfully

[root@hpux02:/root]
#

AND/OR

# /opt/ignite/lbin/list_expander
ERROR: Cannot stat device file: /dev/old_vg_hr03/lv_u01: No such file or
directory (errno = 2). Check /etc/fstab for a bad entry.

[root@hpux02:/root]
#

This occurs when certain FS is no longer in use and was not removed in /etc/fstab. I check it using:

# bdf <block_device_name>
# bdf /dev/old_vg_apps/lv_mom

OR

# mount -v grep -i <pattern>

AND/OR

# lvdisplay <block_device_name>
# lvdisplay /dev/old_vg_apps/lv_mom

If it does NOT return any of your expected result, then it is safe to say that the FS is NOT is use. From here, we can proceed by commenting [deleting] this but, make sure to have a backup just in case. Systems admins know this by heart. "He who laughs last, made a backup!". Proceeding..

# cp -p /etc/fstab /etc/fstab.backup1.20080411
# vi /etc/fstab
....
/dev/old_vg_hr03/lv_u01 /old/var/opt/vghr03/u01 vxfs delaylog,mincache=direct 0 2
/dev/old_vg_hr04/lv_u01 /old/var/opt/vghr04/u01 vxfs delaylog,mincache=direct 0 2
/dev/old_vg_hr05/lv_u01 /old/var/opt/vghr05/u01 vxfs delaylog,mincache=direct 0 2
/dev/old_vg_hr06/lv_u01 /old/var/opt/vghr06/u01 vxfs delaylog,mincache=direct 0 2
/dev/old_vg_hr07/lv_u01 /old/var/opt/vghr07/u01 vxfs delaylog,mincache=direct 0 2
....

So, our target here is to comment these lines so that it will not be read by ignite. For this case, we can comment it one by one. But for cases where we want to comment hundreds of lines, it'll take a lot of time. So I searched for some vi commands that will do this task for me. And I found it here: http://sparky.rice.edu/~hartigan/vi.html.

I executed this in command mode: :218,$s/^/\#

This means that, I'd like to insert a "#" character at the beginning of each line from line 218 to the last. Save and exit. Then re-ran ignite. As of this writing, it's running smoothly.

Interesting topic: http://forums12.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1207883792669+28353475&threadId=996179

MP [console] firmware upgrade

This is definitely an exciting day for me. I never expected that my wish will come true. (Be careful what you wish for) Of course, this change gave me a scare. I thought I was done. My last day on this work. But as they say, "Ang masamang damo, matagal mamatay!". Earlier during the change, when I got the error, I felt both excited and "nerbyos"! But, hey, if it is my time, so be it. Nah, I won't go down that easy. I followed the procedure specified in the SOP but after a reboot, I was not able to switch to root user. I thought I missed changing the root password. My first action was to try to boot to single user mode:

1. Interrupt the booting sequence
2. Type boot in the command prompt
3. Interact with ISL/IPL, answer "Y/yes"
4. When in ISL prompt, key-in hpux -is to boot to single user mode

I was thinking of changing the root password but I'm not too sure of the effect. I tried to copy the original root file from /tcb/files/auth/r/, which I made a backup but, then I'm getting an error that `cp` as unknown command (Any thought on this?). Hmmm, now this started to scare me a bit. But wait, how about booting it in rc level 1? OK, I entered init 1 in the CLI. Critical FSes were mounted and several processes were ran but, I was kicked out of the console access. Deym, it's useless, I just lost my root access.

I went for another reboot, this time, in consultation with my TL, I booted to default run level - 4 (specific for this environment; default rc level for HP-UX is 3, by the way). Great news! E-trust is up. I can switch to privileged user. I re-copied the root file, then change the password according. to SOP. Rebooted and waited for the server again to go to run level 2. Rc 2, here we go.

[user1@server1:/home/user1]
$ su - root
Password:
su: Unknown id: root

[user1@server1:/home/user1]
$ sesu -
System call not loaded.
Password:
su: Unknown id: root

[user1@server1:/home/user1]
$ grep -i root /etc/passwd
"root entry here..."

[user1@server1:/home/user1]
$ who -r
. run-level 2 Apr 10 05:54 2 0 S


I asked our security team to fix this, I mean run the E-trust so I can switch to privilege user, and then stop it, again, so I can proceed with the patching. Then patching goes... smoothly. Unknown to me, after the "autoreboot", the firmware got updated. And failed. And halted the system! OMG! Escalation, please assist! I handed over the console access to my L3 from which he tried to reset the box. But it seems, it has no effect. BTW, MP for rp4440 is built-in. We have no choice but to call on the onsite DM. I guess, he did a hard reboot and made a workaround to fix the MP issue. And whoala, the box is up! After some system validations, got the application team to start the SAP and Oracle.

Here's something greek (onsite DM):

Prior to updating the iLO MP firmware a MP reset needs to occur via the "XD-R" command in order to free up enough contiguous memory.

server1] MP:CM> xd
XD
Diagnostics Menu:
Non destructive tests:
P - Parameter checksum
I - I2C access (get BMC Device ID record)
L - LAN access (PING)
M - Modem selftests
Destructive tests:
R - Restart MP

Enter menu item or [Q] to Quit: r
r
Confirm? (Y/[N]): y
y
MP is now being reset...

MP MAIN MENU:
CO: Console
VFP: Virtual Front Panel
CM: Command Menu
CL: Console Log
SL: Show Event Logs
HE: Main Help Menu
X: Exit Connection
server1] MP>

A separate comment by HPCE (?):

In the procedure prior applying patch update, a reset of MP is needed to free up memory space on MP and permit firmware writing. BUT as the MP was not reachable, I guess it was not possible to perform the reset? Now the MP firmware is probably not updated, but you can do the MP upgrade on-line by using a FTP file.

New lesson learned! I need to read more about this. Perhaps consult Aadee. And for the SAP team's wrong template? Rejected!

Ignite backup

I was surprised to receive a PM from my colleague. As part of the process we follow, we need to make an ignite backup of system we do patching on. Most of the time, it goes smooth but they can never be perfect, 82-0 is just impossible. Anyway, I have encountered this issue a couple of times already. I've read some discussions on this but still trying to understand. Way to far, to many to learn! Going back, here's the error:

...
* Saving the information about archive to
/var/opt/ignite/recovery/previews
* Creating The Networking Archive

Permission denied
ERROR: Unable to mount or write
server1:/var/opt/ignite/recovery/archives/client_svr1
On server1 you may need to:
mkdir -p /var/opt/ignite/recovery/archives/client_svr1
chown bin:bin /var/opt/ignite/recovery/archives/client_svr1

vi /etc/exports (add or modify an entry). The /etc/exports file on
"server1" should contain the entry:
"/var/opt/ignite/recovery/archives/client_svr1 -anon=2,access=client_svr1".
After editing the /etc/exports file, run exportfs -av

If you need to change the owner of the directory,
you will also need to re-export the directory.

See make_net_recovery(1M) for more information.
ERROR: Failed to Create NFS mount Archive directory.

======= 04/10/08 09:07:54 SST make_net_recovery completed unsuccessfully

[root@server1:/var/opt/ignite/recovery]
#

I followed the suggestion here: `mkdir`; `chmod`; and `exportfs` but to no avail. Well, the workaround is NOT to limit access to the specific client, i.e., delete the entry "access=client_svr1" from /etc/exports; then run re-export the FSes. Now, it's working well. As mentioned earlier, it's just a workaround. So we need to restore the entries in the config files.

Read on: http://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=1017493&admit=109447627+1207790553782+28353475

Swap Space

After [some] reading topic on swap space, it crossed my mind if swap space, created through LVM, can be extended? This is in consideration to limited available physical disk to be attached to the system, and not having to use a file system swap. On the sidetrack, consider 2 small swap spaces [on faster disks, of course], than 1 large one; same priority for similar device swap spaces. After asking my colleague (which by the way, he refused to answer since he's not sure about it and I know he's sincere), and finally reading about it (not my first choice today since I'm too lazy), I came to know that it depends on how it was created. As reference to the book I was reading, it was created with basically default options. So extending it, is only subject to availability of free PEs/LEs. But, the more interesting idea was, what if, and I think this is how swap spaces should be created, it was created contiguous-ly [and usually the succeeding spaces are used], how are we going to proceed? As suggested by the manual from HP, you can re-create the swap space to retain the contiguous allocation and also increase the space you need.

# lvcreate -C y -L <new_size> -r n -n <lv_name> /dev/<vg_name>
# lvlnboot -s /dev/<vg_name>/<lv_name>

The second command above is used to set the swap as primary. Check /etc/fstab if it needs to be corrected. And of course, don't forget to reboot your system.

HTH. Open to suggestions/corrections... see ya' round.

[Part of] 24 hour challenge over [halo-halo] senseless topics

I'm just starting this not knowing where it'll bring me nor even complete it. Not even sure if it will make sense at all.

I'm a bit off than the usual since I'm challenging myself to go 24H, online. Lucky for me, I'm with my happy colleagues. I like this, well, going to enjoy I guess. Hmmm, challenging night, I mean morning! Approximately 5 hours left before the sun rises. A new day starts as my day ends. Sleep seems to be rare lately. Is it worth it? Well, it depends. I respect those who really love their work BUT do you think you're productive? I mean, can you sustain your focus over a period of time? There may be exceptions but generally? I don't think so!

Going to I-don't-know-where, I'm thinking what else to write .......
.......
.......
.......
.......
.......
.......
.......
.......

It's 1:28 SGT now.

[Not so] Strange as it is, what happens when system reboot/crash/panic? I think I found my reason to stay awake for few hours.

++ Checking...
++ Still checking...

An HP-UX system crash is an unusual event. When a system panic occurs, it means that HP-UX encountered a condition that it did not know how to handle (or could not handle).

When the system crashes, HP-UX tries to save the image of physical memory, or certain portions of it, to predefined locations called dump devices. Then, when you next reboot the system, a special utility copies the memory image from the dump devices to the HP-UX file system area.

Prior to HP-UX Release 11.0, devices to be used as dump devices had to be defined in the kernel configuration, and they still can be. However, beginning with Release 11.0, a new, more flexible method for defining dump devices is available.

There are now multiple ways that dump devices can be configured. Here are three commonly used ways to define dump devices:

* In the kernel (as with releases prior to Release 11.0)
* During system initialization when the initialization script for crashconf runs (and reads entries from the /etc/fstab file)
* During run time, by an operator or administrator manually running the /sbin/crashconf command.

The dump process exists so that you have a way of capturing what your system was doing at the time of a crash. This is not for recovery purposes; processes cannot resume where they left off, following a system crash. Rather this is for analysis purposes, to help you determine why the system crashed in order to prevent it from happening again.

If you want to be able to capture the memory image of your system when a crash occurs (for later analysis), you need to define in advance the location(s) where HP-UX puts that image at the time of the crash. This location can be on local disk devices, or logical volumes.

Wherever you decide that HP-UX should put the dump, it is important to have enough space at that location (see “How Much Dump Space Do I Need?”) If you do not have enough space, not every page will be saved and you might not capture the part of memory that contains the instruction or data that caused the crash. If necessary, you can define more than one dump device so that if the first one fills up, the next one is used to continue the dumping process until the dump is complete or no more defined space is available. To guarantee that you have enough dump space, define a dump area that is at least as big as your computer’s physical memory, plus one megabyte. If you are doing a selective dump (which is the default dump mode in most cases), much less dump space will actually be needed. Full dumps require dump space equal to the size of your computer’s memory plus a little extra for header information.

In HP-UX Release 11i compressed dumps are enabled by default. However, dump compression will only occur if conditions in the crash environment are favorable. Do not plan your dump storage space based on potential compression but allow enough space for an uncompressed full or selective dump. See “Compressed Dump(HP-UX version 1 (B.11.11) or later)”.

Re: http://docs.hp.com/en/B2355-90950/ch05s05.html#bajcidic

++ I guess this will suffice. For now...