The system time in the /var/adm/messages file is inaccurate when displaying boot-related information for the first boot after a netinstall. In the following excerpt from the /var/adm/messages file, you will see that the system time gets set to a later time.
Jun 1 22:05:07 sunergy2 unix: mem = 49152K (0x3000000) Jun 1 22:05:07 sunergy2 unix: avail mem = 44359680 Jun 1 22:05:07 sunergy2 unix: root nexus = SUNW,SPARCclassic Jun 1 17:39:59 sunergy2 unix: iommu0 at root Jun 1 17:39:59 sunergy2 unix: : Jun 1 17:39:59 sunergy2 unix: obio 0x10000000 Jun 1 17:39:59 sunergy2 unix: Jun 1 17:39:59 sunergy2 unix: sbus0 at iommu0
Workaround: You may delete the innaccurate messages.
If you have UFS file systems listed in /etc/vfstab with quotas enabled, you must apply the following workaround. Otherwise, quotas are not enabled automatically after booting a system.
Workaround: You must run quotacheck -a and quotaon -a for quotas to be correctly enabled. Otherwise, quotas remain disabled.
The following bugs occur when the Remote Console feature is enabled.
If you lose the carrier, for example, become disconnected from the serial port that is not located on the default console or on an auxiliary console through which you are logged in, and then bring the system to single-user or administrative mode by executing the init command from that port, you must ensure that the carrier is reestablished on that serial port before bringing the system back up. The system then prompts you for a run level to which you want to boot the system (only on the port where the init command was initiated).
Workaround: Reconnect to the serial ports when you lose the carrier before rebooting the system.
A misleading message is sometimes displayed on the device on which you initiated the init state transition when administering a system using the init command even though you executed the reboot command. When executing init s, a single-user shell is established on a remote console and the subsequent rebooting of the system can cause the following message to be displayed:
Enter run level
Workaround: Ignore the misleading message.
If you press Control--D as a superuser or after logging in as root from the superuser login prompt and then issue an exit command to be at the default run level, you are prompted for the default run level. The prompt is displayed on a console on which the init command was initially executed instead of the console on which Control--D or the exit command were originally issued.
If you execute the init command from a pty, /dev/console becomes the default device on which you are prompted for a run level. If you are running a remote console and log in as a superuser and then type Control--D to boot the system, the run level prompt is then displayed on the console instead of the auxiliary console.
If a configuration includes one or more auxiliary consoles and the carrier drops the connection for the auxiliary console on which the init command was run, and the sulogin shell has exited from another auxiliary or default console, then the following prompt will not be displayed after reestablishing the connection on the port from which the carrier dropped the connection:
Enter Run Level
Although you are never prompted for the run level, the system is still waiting for the run level to be entered.
Workaround: Reestablish the connection on the port from the carrier has dropped the connection and enter the desired run level even though you are not prompted for the run level.
Daemons or commands may use /dev/console explicitly to display messages. The frequency of such messages is low among the set of messages that the console may display.
Workaround: All messages are still printed to /dev/console and can therefore be monitored. You can also monitor syslog log files.
If syslogd needs to display error messages on a console, these messages will be directed to the default location /dev/syscon. The error messages are not displayed on any configured auxiliary consoles in this feature patch.