On 11/18/10 12:38 PM, Ian Collins wrote:
On 11/19/10 09:12 AM, Steve Lawrence wrote:
 What build are you upgrading from?

134 through 134b as recommended in the release notes.

Is this during the "attach -u" portion of the upgrade for each zone?

It happens after rebooting into the new BE. I didn't detach the zones before upgrading.

Oh. I that case, you're zones are still downrev at build 134. You need to detach them, and attach them again with -u.

I'm not sure if you'll be able to detach them successfully with zoneadm detach. If not, you'll need to boot back to the 134 BE, detach them, and upgrade again.


Can you gather any core files (or pstacks of core files)? These might be at <zonepath>/root/

pstack is short:

core '/tmp/xx/zoneRoot/webhost/root/core' of 3094:    /sbin/init
 feef3c97 _fxstat  (0, 8047560, 180, 8058927) + 7
 08058973 st_init  (fee201a8, 38, 0, fefccc54, 0, feffb804) + 8f
 080543dc main     (1, 8047f6c, 8047f74, feffb804) + 150
 0805418d _start   (1, 8047fe0, 0, 0, 7d8, 8047feb) + 7d

I can send the core (it's only 2MB) if that helps.

My "guess" is that init (in the zone) is starting using a downrev libc (aka libc not upgraded yet), and is making a system call that has changed. 12 is SIGSYS.


On 11/18/10 11:14 AM, Ian Collins wrote:
I run through the upgrade process on a system with half a dozen zones and on restart, they all get locked into a core dump/restart loop:

Nov 19 07:57:50 i7 genunix: [ID 729207 kern.warning] WARNING: init(1M) for zone webhost (pid 3094) core dumped on signal 12: restarting automatically

They all run through this cycle in tight loops.


zones-discuss mailing list

zones-discuss mailing list

Reply via email to