zone failed to boot up

shyjack
zone failed to boot up

Hi guys,

I hit a problem that non-global zone won't boot up with a error something to do with devfsadm.

slave:/other/zones #zoneadm list -vc
  ID NAME             STATUS         PATH
   0 global           running        /
   - autonew          installed     /other/zones/autonew

slave:/other/zones #zoneadm -z autonew boot
zoneadm: zone 'autonew': /usr/sbin/devfsadm unexpectedly terminated due to signal 9
zoneadm: zone 'autonew': devfsadm call (/usr/sbin/devfsadm -Z autonew) unexpectedly returned 1
zoneadm: zone 'autonew': call to zoneadmd failed
slave:/other/zones #
slave:/other/zones #zoneadm -z autonew boot
zoneadm: zone 'autonew': zone is already booted
slave:/other/zones #
slave:/other/zones #zonecfg -z autonew delete -F
autonew: Zone state is invalid for the requested operation
slave:/other/zones #

Is anyone aware of something similar like this?

thanks.

kaiyi
Ò»°ãÀ´Ëµ, non-global zone´Óinstalled״̬Ïȵ½ready,È»ºóÔÙboot.
¿ÉÒÔÊÔÊÔÈçÏÂ:
   # zoneadm -z autonew ready
   Õâʱ, zoneµÄ״̬±äΪÁËready. ÔÙÖ´ÐÐ
  # zoneadm -z autonew boot
   zone¾ÍÓ¦¸ÃbootÆðÀ´ÁË,״̬½«±äΪrunning.

²»È·¶¨, ¿ÉÒÔÊÔÒ»ÊÔ.

shyjack
Yes kaiyi,

I had tried to boot the local zone bit by bit, exactly as you mentioned before.

but after the ready command issued, zone will fail and then go into down status due to the error with devfsadm.

slave:/egao #zoneadm list -vc
  ID NAME             STATUS         PATH
   0 global           running        /
   1 autonew          down           /other/zones/autonew
slave:/egao #

From my understanding, around step of ready or prior to booting, zoneadmd will coordinate with devfsadm to mount /dev within the local zone and populate all relevant dev files.

On the other working server, this is noticed with the following dtrace script, just on my particular damned machine, it failed at this step.

dtrace -qn 'proc:::exec-success { printf("%-14s %s/n",curthread->t_procp->p_parent->p_user.u_comm, curpsinfo->pr_psargs); }'


Further clue is that I installed SUNWjass to harden the system and then roll it back, not sure if this is causing the problem.

kaiyi
ÄÜ·ñ°ÑÄãzoneµÄÅäÖÃÌù³öÀ´¿´Ò»ÏÂ?

shyjack
the zone configuration is pretty simple and here it is.  it might not be related to the zone itself, seems something wrong with the global zone itself.

slave:/other/zones #zonecfg -z autonew
autonew: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:autonew> create -b
zonecfg:autonew> set zonepath=/other/zones/autonew
zonecfg:autonew> set autoboot=false
zonecfg:autonew> add net
zonecfg:autonew:net> set address=172.28.12.211/24
zonecfg:autonew:net> set physical=eri0
zonecfg:autonew:net> end
zonecfg:autonew> verify
zonecfg:autonew> commit
zonecfg:autonew> exit
slave:/other/zones #zoneadm list -vc
  ID NAME             STATUS         PATH
   0 global           running        /
   - autonew          configured     /other/zones/autonew
slave:/other/zones #zoneadm -z autonew install
Preparing to install zone <autonew>.
Creating list of files to copy from the global zone.
Copying <130355> files to the zone.
Initializing zone product registry.
Determining zone package initialization order.
Preparing to initialize <1107> packages on the zone.
Initialized <1107> packages on zone.
Zone <autonew> is initialized.
Installation of these packages generated errors: <SUNWcsu>
Installation of <86> packages was skipped.
Installation of these packages generated warnings: <VRTSat>
The file </other/zones/autonew/root/var/sadm/system/logs/install_log> contains a log of the zone installation.
slave:/other/zones #

whr25
zoneadm -z autonew install  ÓÐÌáʾ´íÎóÂð£¿

shyjack
nothing unusual for installation.