"do_mkboot: Error in getting offset and length of rootvol" when installing HP-UX on BFS Disk

[noldi]

Hello,

I tried an Ignite-UX 11i v2 MCOE Sept. 2006 install (Ignite-Server
is an rp where the client is an rx type server) and
received this error during installation:
"do_mkboot: Error in getting offset and length of rootvol"
(see attached install.log output).

The system disk is residing on an EVA-4k and
the chosen VM was VxVM in order to fully
utilise the DMP to manage the available storage
paths.

What could be the problem here during the
preparation of the root FS (rootvol)?

Thanks for any hints on this & best Regards,

Arnold Sutter

[Sameer_Nirmal]

Check the Filesystems tab in the itool menu of the Ignite-UX for /stand vol.

If it's not there, then create it ( maybe about 500MB ) and see if it works.

[noldi]

Hello Sameer,

thanks for your response.

According to the log-file, the standvol has been created:
.
* Creating VxVM volume "rootdg/standvol" (/stand).
.
* Making VxFS filesystem for "/stand", (/dev/vx/rdsk/rootdg/standvol).

Best Regards,

Arnold

[Sameer_Nirmal]

Aahh! I missed that.

Increase the debug level to 3 in the advanced option ( Below Install HPUX option ) and post the result.

Maybe that will give some insight as what could be wrong encountered by VxVM.

I hope zoing is done at the SAN switch side.
The disk you are or being selecting does show proper size and details in the itool?

[noldi]

Sameer,

attached you find the dbg3-install.log as instructed.
The disks are ordinary EVA4k LUNs with HP-UX
personality. I see 4 of them, but I only select the first one
since the other ones are different views to the same device.

Can the installer deal with multipathed LUNs and configure
DMP correctly with it?

The disk is seen the same as any other disk
by itool.

Thanks & best Regards,

Arnold

[Sameer_Nirmal · Accepted solution]

The debug log shows that the LUN path c8t0d1s2 gets referenced by vxprint instead of c4t0d1s2 which was used for creating rootdg earlier.

The problem here is that vxprint should have used LUN path c4t0d1s2 ( DMP Metadevice) which will make loading software process to continue. It might be a bug or known issue with Ignite-UX and VxVM DMP.

I think you can try using another LUN path.
Select the LUN Path (DMP node) at the lowest
available hardware path as the root disk. This might resolve this issue.

Secondly, another workaround could be tried from the dubug shell in this case. If you run the vxprint command exactly the way it is shown in the debug log with c4t0d1s2 LUN path and then exit the shell with "exit 0". This I belive would all loading software to continue.

[noldi]

Hello Sameer,

after reducing the available SAN paths to 1,
the installation continued. The automatic
build of the kernel failed but a manual kernel build succeded.

Now I noticed that my FC-Adapter A6795A doesn't have the EFI-Code
to boot from SAN yet but I can load it from the local disks . . .

Now I'll add the SAN paths again in order
to finish the installation.

Thanks again & best Regards,

Arnold Sutter, redIT