A colleague of mine came across this message during a bosboot on one of our AIX 6.1 LPARs:

# bosboot -a -d /dev/hdisk0

Error opening disk: There is an input or output error.

Error opening disk: There is an input or output error.

Error opening disk: There is an input or output error.

Error opening disk: There is an input or output error.

bosboot: Boot image is 40978 512 byte blocks.

# oslevel -s

6100-03-01-0921

I’d not seen this message before. I checked the system for any obvious errors in the AIX error report (errpt). I also checked that hdisk0 was identified as a bootable disk (ipl_varyon –i). No issues were found.

We found some hits for this message in the IBM support database.

“The bosboot script calls bootinfo and this binary has code in place which tries to identify the disk that the system was last booted off. In this case it is getting an error when trying to open some disk, not necessarily hdisk0. The boot image seems to have been successfully written to hdisk0.

To check what disk it is complaining about can you grab truss as follows:

# truss -eaf -o /tmp/bosboot.truss bosboot -ad /dev/hdisk0

and then:

# grep EIO /tmp/bosboot.truss”

The bootinfo command was reporting the same message on this system.

# bootinfo -v

Error opening disk: There is an input or output error.

hd5

I ran truss against the bosboot command and found that hdisk9 was the culprit.

802916: kopenx("/dev/hdisk9", O_RDONLY, , 8)Err#5EIO

It appeared that bootinfo was trying to reference hdisk9, which did not belong to a volume group?

# lspv

hdisk000c01c70a73dd4e4rootvgactive

hdisk900c01c70089b6ed3None

The system originally booted from hdisk9. Then the boot list was changed back to hdisk0. The system was migrated to AIX 6.1 on hdisk9. hdisk0 contained the previous version of AIX 5.3. After the migration, hdisk0 was added to rootvg and mirrored with hdisk9. Then hdisk9 was unmirrored and removed from rootvg.

# bootinfo -b

hdisk9

# bootlist -m normal -o

hdisk0 blv=hd5

hdisk0 blv=hd5

We later discovered that hdisk9 was removed from the VIO server and not from the client. Whoops! This resulted in the I/O error during the bosboot. Upon removing the disk from the client, the bosboot command returned the following message:

# bosboot -a -d /dev/hdisk0

unable to identify boot disk

unable to identify boot disk

unable to identify boot disk

unable to identify boot disk

bosboot: Boot image is 40978 512 byte blocks.

We had come across this message a few times already. It appeared to be related to the mirroring/unmirroring of disks in rootvg. However, based on our experience this message was OK to ignore. After a reboot this message will no longer appear. Others have also reported this problem.

This is not the first time that bosboot has displayed this message, refer to the following APAR:

APAR: IY96817: BOSBOOT DISPLAYS "UNABLE TO IDENTIFY BOOT DISK"

We’ve asked IBM support if there are any recent APARs for AIX 6.1 that might relate to this message. I’ll let you know if we find an answer.

The trace data shows that IVM is calling the migmover -m end command on the destination partition. That command in turn calls a system call. When everything is in the correct state, that system call will end the migration and cleanup. The problem is it is not being called because the mover has not yet been notified that VASI is in the END state as indicated by the mover's state being: MIG_STATE_COMPLETED. The trace shows this notification arriving a split second after the migmover -m end command was issued.

On a good migration, the mover is notified by VASI of the state change before IVM calls migmover -m. IVM runs migmover -m end once it gets a migration completed message from phyp. If this message is issued about the same time as the message that tells VASI that the migration has ended, a timing issue seems a real possibility.

The problem was fixed in the VIOS code. A new call was added when the "end" state change comes in from IVM/HMC. If the state is complete we are good to go, otherwise we issue an error.”

Installing this fix on my VIOS resolved the problem. My VIOS are running 2.1.1.10-FP21. If you are running FP22 for VIOS 2.1, then you must request a different ifix from IBM support.

I was attempting to install the new AIX Runtime Expert on an LPAR today. I found that the base level fileset for this new utility was not included with the supporting Technology Level i.e. TL4 for AIX 6.1.

I was presented with the following 'Requisite Failures' message:

Requisite Failures

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

SELECTED FILESETS:The following is a list of filesets that you asked to

install.They cannot be installed until all of their requisite filesets

are also installed.See subsequent lists for details of requisites.

artex.base.rte 6.1.4.1# AIX Runtime Expert

MISSING REQUISITES:The following filesets are required by one or more

of the selected filesets listed above.They are not currently installed

and could not be found on the installation media.

artex.base.rte 6.1.0.0# Base Level Fileset

However, I discovered that the base fileset IS included with the latest Fix Pack for the Virtual I/O Server i.e. FP22 for VIOS 2.1.

I was then able to install the base filesets i.e. the AIX Runtime Expert and the sample profiles. i.e.

artex.base

+ 6.1.4.0AIX Runtime Expert

+ 6.1.4.0AIX Runtime Expert sample profiles

After the filesets installed successfully I needed to then apply the latest level from TL4. e.g.

I was attempting booting a NIM
client from a new NIM master. The new master had been configured on an existing
LPAR, with a running application and had been hardened from an OS security
point of view. The following message was displayed on the console while
attempting to tftp the client info file:

Recently I came across a small but strange problem with an AIX 5.3 system running Oracle. When we tried to perform an offline filesystem backup of the sapdata1 filesystem, we received errors stating the certain files were not able to opened. I confirmed this by using the 'file' command on some of the database files. I received the following messages:

gibsonc@hxaix35 /oracle/TC0/sapdata1/sr3_6 $ file sr3.data6

sr3.data6: 0653-902 Cannot open the specified file for reading.

I discovered that the sapdata1 filesystem had not been mounted with the CIO (Concurrent I/O) option. CIO was enabled within the Oracle database, however.

Recently I came across a small but strange problem with an AIX 5.3 system running Oracle. When we tried to perform an offline filesystem backup of the sapdata1 filesystem, we received errors stating the certain files were not able to opened. I confirmed this by using the 'file' command on some of the database files. I received the following messages:

gibsonc@hxaix35 /oracle/TC0/sapdata1/sr3_6 $ file sr3.data6

sr3.data6: 0653-902 Cannot open the specified file for reading.

I discovered that the sapdata1 filesystem had not been mounted with the CIO (Concurrent I/O) option. CIO was enabled within the Oracle database, however.

Recently I came across a small but strange problem with an AIX 5.3 system running Oracle. When we tried to perform an offline filesystem backup of the sapdata1 filesystem, we received errors stating the certain files were not able to opened. I confirmed this by using the 'file' command on some of the database files. I received the following messages:

gibsonc@hxaix35 /oracle/TC0/sapdata1/sr3_6 $ file sr3.data6

sr3.data6: 0653-902 Cannot open the specified file for reading.

I discovered that the sapdata1 filesystem had not been mounted with the CIO (Concurrent I/O) option. CIO was enabled within the Oracle database, however.

Some of my favoritre AIX update and migration tools (nimadm and multibos) have been enhanced to perform cool new tricks! In particular, multibos now supports AIX migrations not just updates to newer TLs and SPs. Unfortunately, from what I've read, you need to be running AIX 6.1 first. So I won't be able to use multibos to migrate from AIX 5.3 to 6.1. So I'll use nimadm instead. Some brief details are provided below. Refer to the online AIX documentation for more information.

Enhanced nimadm command.

The nimadm command is enhanced to allow the system administrator to do the following:

- Use a NIM client’s rootvg to create a NIM mksysb resource that has been migrated to a new version or release level of AIX.

- Use a NIM mksysb resource to create a NIM mksysb resource that is migrated to a new version or release level of AIX.

- Use a NIM mksysb resource to restore to a free disk, or disks, on a NIM client and simultaneously migrate to a new version or release level of AIX.

- To create a migrated new mksysb resource of a client with the filename nim1, type the following: