|Skip Navigation Links|
|Exit Print View|
|Oracle Solaris 11 Express Release Notes Oracle Solaris 11 Express 11/10|
The following bugs might occur during or after the installation of the Oracle Solaris 11 Express release.
Either or both, the primary user and the root user, might end up with an invalid password when using the text installer.
Workaround: During installation, you have to enter the root password and the user password before you get to the Summary screen. At this point, make sure you begin the installation without returning to the Users screen. If the installation has already been completed and you are unable to log in using the given password, use one of the following workarounds:
Re-install the OS.
Manually modify the /etc/passwd file on the newly installed ZFS pool by booting from an external media.
During installation, you might see an error message similar to the following:
$ more install_log <AI Oct 15 17:32:50> /tmp/ai_combined_manifest.xml is a valid manifest <AI Oct 15 17:32:50> Auto reboot enabled <AI Oct 15 17:33:11> Cannot find the specified disk c7t2d0 on the targetsystem. <AI Oct 15 17:33:11> Target validation failed <AI Oct 15 17:33:11> ai target device not found <AI Oct 15 17:33:11> Auto install failed /$
Workaround: Disconnect one of the dual-path SAS JBOD cables.
A Live CD installation might hang on systems that have 1 gigabyte of memory with an NVIDIA graphics card and multiple e1000g Ethernet drivers.
Workaround: Use one of the following workarounds while performing a Live CD installation:
Use the vesa option.
Disable the e1000g Ethernet drivers by adding the -B disable-e1000g=true string to the end of the kernel$ command in the GRUB menu.
Some of the console features used by the Text Installer are not fully supported on SPARC based systems that are equipped with XVR-2500 graphics cards. As a result, the Text Installer does not display properly on the console of these systems.
Workaround: Use one of the following workarounds:
Run the Text Installer through a remote console, if available, instead of a local frame buffer console.
Use the Automated Installer, either booted from media or from a network, to perform the installation.
Renaming a boot environment might fail if it has a dependent clone that is currently mounted or otherwise busy.
A typical example occurs after the live boot environment has been successfully upgraded. If you then try to rename the autogenerated and upgraded boot environment, the renaming fails. The renaming fails because the upgraded boot environment has been activated, and the live boot environment is now its clone.
Workaround: Use the following procedure:
Activate the live boot environment.
Rename the upgraded boot environment.
Activate the upgraded boot environment.
For example, if the live boot environment name is solaris, and the autogenerated name of the upgraded boot environment is solaris-1, use the following commands:
# beadm activate solaris # beadm rename solaris-1 new_name # beadm activate new_name
If a ZFS pool named rpool is already present on the system because it was manually imported or created by the user during the current boot of the Live CD, the installation process fails. The last message in the installation log file is as follows:
Root pool rpool exists, we can't proceed with the installation.
This behavior is intentional and ensures that the Automated Installer does not inadvertently corrupt your data.
The Automated Installer recognizes cases when rpool is created by the installer, but the installation process has failed or was interrupted. In such cases, the installer automatically destroys rpool after it is restarted.
Workaround: Choose one of the following workarounds:
To preserve data in rpool, reboot the system and do not import the pool. The pool remains invisible to the Automated Installer. However, if the pool was created on the target disk, then the pool cannot be preserved.
If you do not want to preserve data in rpool, destroy the pool before you start the Automated Installer by using the following command:
# zpool destroy -f rpool
If a system has an Oracle Solaris ZFS file system, the Distribution Constructor does not recognize or treat a build area as a ZFS file system in the following cases:
A new subdirectory of the ZFS file system is specified as a build area, but the mount point is specified instead of the zpool.
The build area already exists as a ZFS file system, but the mount point is specified instead of the zpool.
For example, consider the following zpool:
$ zfs list disk2_pool/ib/pia
If the following command is run, where the build area in slim_cd.xml is specified as <build_area>/export/home/ib/pia</build_area>:
# distro_const build -p 1 slim_cd.xml
The following message error message is displayed:
/export/home/ib/pia: No such file or directory /export/home/ib/pia: No such file or directory Checkpointing is not available Rerun the build without -p
Workaround: Make the following change in the Distribution Constructor manifest:
Change <build_area>/export/home/ib/pia</build_area> to <build_area>disk2_pool/ib/pia</build_area>.
When a new boot environment is created, it has only one entry in the GRUB menu.lst file regardless of how many entries the source boot environment has. The source boot environment's first menu.lst entry is used to create the entry for the new boot environment. All other entries are ignored. This issue occurs when you create the new boot environment either through the beadm command or the pkg update command.
If you need other entries for the new boot environment, they are not available.
Workaround: Edit the /rpool/boot/grub/menu.lst file and copy the desired entries from the original boot environment. Replace the boot environment name in the source entries with the name of the target boot environment.
The Distribution Constructor might display the following error message after successfully performing its function:
Unhandled exception in thread started by Error in sys.excepthook: Original exception was:
Workaround: This error message is displayed just before termination and can be safely ignored.
The Automated Installer always creates a ZFS root pool with the name rpool. The ZFS boot process becomes confused if more than one Oracle Solaris instance is installed on the same disk. Only the Automated Installer is affected by this bug. The GUI Installer does not support creating multiple Oracle Solaris instances on one disk.
Workaround: If you need to install more than one instance of Oracle Solaris on a system, make sure that each instance is installed on a separate disk.
The Automated Installer does not support multihomed servers.
Workaround: Do not use the Automated Installer on a server with multiple network connections. If you do need to use the Automated Installer, modify the following data sources:
Which subnet to configure
Which router to provide
Which boot file location to provide
Note - You must manually maintain the DHCP entries by modifying the macro values of BootSvrA and BootFile as needed.
Consider which IP address to advertise for the Automated Installer web server
Note - You must ensure client routing to the IP address advertised by the dns-sd process that is running on the Automated Installer server.
Which install_media IP address to provide
Which install_svc_address IP address to provide
Note - You must edit the /tftpboot/menu.lst.<service-name> file accurately.
Consider which network to place the wanboot.conf files.
Note - This issue can be resolved by creating symbolic links with ln -s <src> <tgt> for all networks served in the /etc/netboot directory.
See the following bugs for additional information:
installadm tools do not support installation servers that have mutiple subnets (6182).
Custom wanboot.conf files are ignored in Automated Installation servers with multiple NIC cards (7115).
installadm command should allow users to choose which subnets to use (7149).
If an Automated Installer service name is longer than 59 characters, the dns-sd process continues to run even after the delete-service command is executed. If the service name is longer than 64 characters, then the create-service command fails and leaves orphaned files that cannot be tracked by any of the Automated Installer services.
Workaround: Do not use Automated Installer service names longer than 59 characters.
The Automated Installation fails because it runs out of space in slice 0 of the target device. The following error message is displayed:
Auto install failed
Workaround: Choose one of the following workarounds:
Create slice 0 on the target device, and allocate more than 8 gigabytes of disk space to the slice.
If there is another slice with more than 8 gigabytes of disk space, change the Automated Installation manifest to use that slice. For example, to use slice 4 of your target device c0t0d0, add the following lines to your Automated Installation manifest:
<ai_target_device> <target_device_name>c0t0d0</target_device_name> <target_device_install_slice_number>4</target_device_install_slice_number> </ai_target_device>
The Automated Installer allows you to select a target disk for the installation by specifying the disk selection criteria in the Automated Installer manifest. One criteria that you can define in the manifest is the type of disk controller. To do so, use the target_device_type disk selection tag. The following values are currently supported:
Information about the controller type is currently not available for SATA drivers with a device name in c#t#d# format. Such drivers are managed by the Oracle Solaris SATA framework. Information about the disk controller type can be obtained from the Automated Installer client by running the Target Discovery test driver with root privileges when the Automated Installer is booted. In the following example, note that the controller type is under the ctype column:
# /opt/install-test/bin/test_td -dv Disk discovery Total number of disks: 1 ------------------------------------------------------------------------------- num | name| vendor| ctype| mtype| rem| lbl| bsize|#of blocks|size [MB]| ------------------------------------------------------------------------------- 1 |* c7d0| unknown| ata| FIXED| No| VF| 512|1953520128| 953867| -------------------------------------------------------------------------------
Workaround: Use other disk selection criteria to select the desired SATA disk. See the sata(7D) man page for information.
The XML manifest files used by the Automated Installer are readable by any user on the Automated Installer server. These files are openly accessible over the network through the Automated Installer HTTP manifest service. Passwords that are provided as part of the configuration manifest are not secure.
Workaround: Choose one of the following workarounds:
To limit readability of the manifests on the Automated Installer server, use the following command:
# chmod -R og-r /var/ai/*/AI_data
Access to manifests over HTTP can be restricted by using the IP Filter feature of Oracle Solaris, which helps limit access to the manifest service ports to only specific networks or clients.
During the first boot after installation of a system using the Automated Installer, log in and change the passwords that were configured by using the Automated Installer. For best security, boot the system to single-user mode. On SPARC based systems, add the-s option to the boot command. On x86 based systems and x64 based systems, edit the GRUB menu interactively, and append the -s option to the kernel$ command.