Operating System - HP-UX
1748232 Members
3513 Online
108759 Solutions
New Discussion юеВ

read of super-block on /dev/vg00/* failed

 
Seidel_1
Occasional Advisor

Re: read of super-block on /dev/vg00/* failed

Hi,

I am always booting from the good old disk which was not broken:

Boot
: disk(0/1/1/0.1.0.0.0.0.0;0)/stand/vmunix
12406784 + 2093056 + 15248016 start 0x202d68

I am quite sure that we replaced the right disk as we plugged the disk out when the system was running and this was fine until I started to reboot the wholoe server.

The system is not so critical as it is a cluster system and currently the whole stuff is runing on the second node.

Thanks for your help we will try to restore an Ignite tape(still need to find it somehow exactly that tape disappeared :-()

Thanks again

Andree
Seidel_1
Occasional Advisor

Re: read of super-block on /dev/vg00/* failed

Hi,

now I tried to restore an IGNITE tape from a different server and get the following:

HARD Booted.

ISL Revision A.00.43 Apr 12, 2000

ISL booting hpux (;0):INSTALL

Boot
: tape(0/1/1/1.5.0.0.0.0.0;0):WINSTALL
10850304 + 1794136 + 2598144 start 0x1ff0e8





Firmware Version 44.24

Duplex Console IO Dependent Code (IODC) revision 1



Stored message buffer up to panic:
PDC_MODEL_CPU_ID returned 0x14

System Panic:

linkstamp: Tue Apr 30 16:59:06 MDT 2002
_release_version: @(#) $Revision: vmunix: vw: -proj selectors: CUPI80_BL2000_1108 -c 'Vw for CUPI80_BL2000_1108 build' -- cupi80_bl2000_1108 'CUPI80
_BL2000_1108' Wed Nov 8 19:24:56 PST 2000 $
panic: set_machine_parameters_64: Unidentified cpu type returned from PDC_MODEL

PC-Offset Stack Trace (read across, top of stack is 1st):
0x00210028 0x002630e8 0x00262f08
0x004ab1ac 0x0020516c 0x001ff6b4
End Of Stack



*** A system crash has occurred. (See the above messages for details.)
*** The system is now preparing to dump physical memory to disk, for use
*** in debugging the crash.

ERROR: Your system crashed before I/O and dump configuration was complete.
A crash dump cannot be taken under these circumstances without
special configuration. Contact your HP support representative.


Is my problem eventual no disk problem ?

Thanks

Andree
Devender Khatana
Honored Contributor

Re: read of super-block on /dev/vg00/* failed

Hi,

The message indicates that probably you are not restoring the backup of this system to it. That is why it is giving unidentified CPU type now.

Have you replaced disk before trying restore?

HTH,
Devender
Impossible itself mentions "I m possible"
Seidel_1
Occasional Advisor

Re: read of super-block on /dev/vg00/* failed

Hi,

yes the root-disk is still replaced and as I couldn't find the Ignite tapes of the faulty system, now I tried to take an IGNITE backup of the other working server(just vg00) and want to restore that one to the faulty system.

Of course I would change the system parameter.

In the past that was possible, shouldn't that work ?

Thanks

Andree
Devender Khatana
Honored Contributor

Re: read of super-block on /dev/vg00/* failed

Hi,

Perhaps the other system has a different tyoe of hardware or the Ignite on the server is not updated. That is causing this.

Keep the recently removed disk also intact so that if required you can find some files from that.

HTH,
Devender
Impossible itself mentions "I m possible"
Dennis Robinson_2
New Member

Re: read of super-block on /dev/vg00/* failed

I recently recovered from a similar error. We had the following:

/sbin/ioinitrc:
Can't open /dev/vg00/lvol1, errno = 6
/dev/vg00/lvol1: CAN'T CHECK FILE SYSTEM.
/dev/vg00/lvol1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
/dev/vg00/lvol1: No such device or address
Unable to mount /stand - please check entries in /etc/fstab
Skipping KRS database initialization - /stand can't be mounted


Earlier in the boot the following error was shown:

panic: lv_fixrootlv: Stale extent array overflow
Stack Trace:


The problem was we had upgraded to HP-UX 11.31 from version 11.23.

We resolved the issue by:

1. Split the mirror on vg00
2. Reboot
3. Re-establish the mirror on vg00

We also had some critical volumes which where non-contigous ( lvol1, lvol2 ). We used pvmove to make them completely contigous.

In your case, I would attempt to reduce all the mirrors down to "0" on vg00. Then reboot and re-establish the mirrors.