[OpenIndiana-discuss] OpenIndiana Zone refuses to boot, gives a core dump
dave.koelmeyer at davekoelmeyer.co.nz
Wed Oct 3 11:14:05 UTC 2012
On 21/09/12 19:38, Dave Koelmeyer wrote:
> On 18/09/12 06:12, Roel_D wrote:
>> A couple of things i suspect:
>> 1. Your zfs filesytem is full
>> 2. The path to the filesystem is already owned by an other process.
>> 3. /rpool/zones/zone_roots/ doesn't excist
>> 4. You need to check the ZFS filesystem for errors
> Thanks for your reply. My filesystem is at 83 percent capacity, the
> zone root path exists (confirmed when installing the zone) and I can't
> find any other process using the relevant path. I get the odd minor
> error turning up during ZFS scrubs but nothing that isn't fixed.
I noticed there was discussion on this list around early July ("Broken
pkg in ipkg zones since update to oi_151a5") that while not identical to
my case sounds close enough - as I'm otherwise completely stumped to
what's going on here. I can't successfully boot _any_ new Zones
currently on my system, and my system sure hasn't changed...whereas the
repositories are probably in a state of flux. So, I'm putting this down
to some interaction between what's in the development repositories and
the oi_151a image currently installed in my global Zone. Planned course
of action from here is to clone an existing zone and rebuild it as
>> Op 17 sep. 2012 om 03:08 heeft Dave Koelmeyer
>> <dave.koelmeyer at davekoelmeyer.co.nz> het volgende geschreven:
>>> Hi All,
>>> I have an oi_151a x86 system, and I've created a shared IP Zone in
>>> the same way I've always done in the past on this system (which
>>> currently has four other Zones installed).
>>> Once my zone has been created and installed, I get this when
>>> attempting to boot it (#zoneadm -z heliod-zone boot):
>>> dave at mymachine:/home/dave$ pfexec zlogin -C heliod-zone
>>> [Connected to zone 'heliod-zone' console]
>>> [NOTICE: Zone booting up]
>>> SunOS Release 5.11 Version oi_151a 64-bit
>>> Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights
>>> Loading smf(5) service descriptions: 102/102
>>> Hostname: heliod-zone
>>> Loading smf(5) service descriptions: 1/1
>>> svc:/system/filesystem/local:default: WARNING: /usr/sbin/zfs mount
>>> -a failed: exit status 267
>>> Sep 16 17:27:43 svc.startd:
>>> svc:/system/filesystem/local:default: Method
>>> "/lib/svc/method/fs-local" failed with exit status 95.
>>> Sep 16 17:27:43 svc.startd: system/filesystem/local:default
>>> failed fatally: transitioned to maintenance (see 'svcs -xv' for
>>> SUNW-MSG-ID: SMF-8000-YX, TYPE: defect, VER: 1, SEVERITY: major
>>> EVENT-TIME: Sun Sep 16 17:27:43 PDT 2012
>>> PLATFORM: i86pc, CSN: -, HOSTNAME: heliod-zone
>>> SOURCE: software-diagnosis, REV: 0.1
>>> EVENT-ID: 64d620e1-a05c-ce9d-a6b6-a9301d2cb519
>>> DESC: A service failed - a start, stop or refresh method failed.
>>> Refer to http://illumos.org/msg/SMF-8000-YX for more information.
>>> AUTO-RESPONSE: The service has been placed into the maintenance state.
>>> IMPACT: svc:/system/filesystem/local:default is unavailable.
>>> REC-ACTION: Run 'svcs -xv svc:/system/filesystem/local:default' to
>>> determine the generic reason why the service failed, the location of
>>> any logfiles, and a list of other services impacted.
>>> heliod-zone console login:
>>> Looking at the logfile output for the affected service in the zone,
>>> I get this:
>>> dave at mymachine:/rpool# svcs -xv -z heliod-zone
>>> svc:/system/filesystem/local:default (local file system mounts)
>>> Zone: heliod-zone
>>> State: maintenance since 17 September 2012 12:27:43 PM NZST
>>> Reason: Start method exited with $SMF_EXIT_ERR_FATAL.
>>> See: http://sun.com/msg/SMF-8000-KS
>>> Impact: 14 dependent services are not running:
>>> dave at mymachine:/rpool# more
>>> [ Sep 16 17:27:32 Enabled. ]
>>> [ Sep 16 17:27:42 Executing start method
>>> ("/lib/svc/method/fs-local"). ]
>>> /lib/svc/method/fs-local: line 90: 28565: Memory fault(coredump)
>>> WARNING: /usr/sbin/zfs mount -a failed: exit status 267
>>> [ Sep 16 17:27:43 Method "start" exited with status 95. ]
>>> Has anyone else encountered this behaviour before?
More information about the OpenIndiana-discuss