Bug 6589 - update index fails with "no space left on device" traceback
: update index fails with "no space left on device" traceback
Status: ACCEPTED
Product: pkg
search
: os200811 (666742d60b75)
: VirtualBox/i386 OpenSolaris
: P5 minor (vote)
: ---
Assigned To: pkg/search watcher
: pkg/search watcher
:
:
:
:
:
  Show dependency treegraph
 
Reported: 2009-02-12 03:48 UTC by lyhin
Modified: 2009-02-12 11:38 UTC (History)
2 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description lyhin 2009-02-12 03:48:44 UTC
Dear experts,

1. I newly installed Open Solaris and running it on xVM with virtual hard disk 
allowed for this virtual OS set at 54GB. I try to install sunstudioexpress,
and it failed with the following screenshot:

jack@opensolaris:~$ pfexec pkg install sunstudioexpress
PHASE                                          ITEMS
Indexing Packages                            555/555 
pkg: An unexpected error happened while preparing for install:
Traceback (most recent call last):
  File "/usr/bin/pkg", line 2228, in ?
    __ret = main_func()
  File "/usr/bin/pkg", line 2177, in main_func
    return install(mydir, pargs)
  File "/usr/bin/pkg", line 752, in install
    api_inst.prepare()
  File "/usr/lib/python2.4/vendor-packages/pkg/client/api.py", line 425, in
prepare
    self.img.imageplan.preexecute()
  File "/usr/lib/python2.4/vendor-packages/pkg/client/imageplan.py", line 592,
in preexecute
    ind.rebuild_index_from_scratch(
  File "/usr/lib/python2.4/vendor-packages/pkg/indexer.py", line 731, in
rebuild_index_from_scratch
    IDX_INPUT_TYPE_FMRI, tmp_index_dir)
  File "/usr/lib/python2.4/vendor-packages/pkg/indexer.py", line 649, in
_generic_update_index
    self._update_index(dicts, tmp_index_dir)
  File "/usr/lib/python2.4/vendor-packages/pkg/indexer.py", line 572, in
_update_index
    remove_fmri_ids, remove_version_ids)
  File "/usr/lib/python2.4/vendor-packages/pkg/indexer.py", line 461, in
_write_main_dict_line
    token, tmp)
  File "/usr/lib/python2.4/vendor-packages/pkg/search_storage.py", line 281, in
write_main_dict_line
    file_handle.write(urllib.quote(token))
IOError: [Errno 28] No space left on device


pkg: This is an internal error.  Please let the developers know about this
problem by filing a bug at http://defect.opensolaris.org and including the
above traceback and this message.  The version of pkg(5) is '666742d60b75'.

jack@opensolaris:~$ 


2. The I checked my virtual hard disk using Disk Usage Analyzer. It showed
I had 5.3GB instad of the 54GB I set to allow it.


Kindly please advise.


Many thanks,

Best
Lin
Comment 1 Danek Duvall 2009-02-12 06:15:43 UTC
This may be bug 6392.
Comment 2 Rich Burridge 2009-02-12 07:07:30 UTC
From the:

jack@opensolaris:

prompt, this might be another case where the user is still booted from
the Live CD. I wonder whether that imposes any limits that you wouldn't
otherwise get.

lyhin, if that was the case, could you reboot from your hard disk 
installation and try the install again please.
Comment 3 Danek Duvall 2009-02-12 07:56:17 UTC
He did say that he was running it on xVM.  Also, if it were on the CD, the
open() of the file handle that caused this error would have come back with
EROFS, so I don't think this is a read-only CD issue.
Comment 4 Rich Burridge 2009-02-12 08:54:59 UTC
(In reply to comment #3)
> He did say that he was running it on xVM.  Also, if it were on the CD, the
> open() of the file handle that caused this error would have come back with
> EROFS, so I don't think this is a read-only CD issue.

No, I wasn't thinking that. I was thinking more of the slimed-down-environment
an initial Live CD boot (or in this case a boot-from-iso-image) would
give you as opposed to a booted-from-hard-disk scenerio. Maybe there is no
difference, but i thought it was worth mentioning.
Comment 5 lyhin 2009-02-12 10:21:00 UTC
Dear experts,

Thank you for your prompt help. I have resolved the issue.

The problem was that I booted Open Solaris in xVM using iso image of the Open
Solaris and was not booting from hard disk. Allow me to tabulate all steps I
went through from installing  xVM on a x86 chip with Windows Vista host and 
Open Solaris guest to complete installation of SunStudioExpress in the 
Open Solaris for future new users:

1. Download and setup xVM.
2. Download iso image of Open Solaris.
3. Activate xVM, click new to create Open Solaris virtual machine and HD.
4. On the "Details" page of the virtual OpenSolaris, click CD/DVD-ROM and
change mounting to iso image file option, adding the iso image downloaded.
5. Press "Start", then choose booting from top option, and choose language
on prompt.
6. Once inside Open Solaris, click the "Install" icon on the desktop, and 
follow instructions.
7. After reboot from hard disk (all subsequently boot-up will be from HD), 
click open "Terminal" icon. At the icon, it should show the prompt of 
username$Open-Solaris~$
8. At this prompt, type
pfexec pkg install sunstudioexpress
9. This will install the Sun Studio Express completely.
10. Then set MANPATH and PATH as follows, assuming the installation directory
is the default /opt by the following lines:
PATH=/opt/SunStudioExpress/bin:$PATH ; export PATH
follow by 
MANPATH=/opt/SunStudioExpress/man:$PATH ; export MANPATH

Then SunStudioExpress will be ready for use.

Many thanks again.

Best
Lin
Comment 6 Shawn Walker 2009-02-12 10:23:29 UTC
It looks like we may have an EROFS case to fix here then.

The traceback shouldn't happen.
Comment 7 Rich Burridge 2009-02-12 10:55:25 UTC
I think bug #6392 can probably be closed as a duplicate of this one.
Comment 8 Danek Duvall 2009-02-12 11:01:29 UTC
There is no EROFS, at least not in this stack.  It's a "disk is out of space"
error.  Now, perhaps xVM treats a filesystem backed by either read-only media
or a lofi-mounted read-only filesystem (such as hsfs) as not read-only, but
simply incapable of taking any writes.  We'd have to confirm that with the xVM
folks.  Adding johnlev to see if he can explain.
Comment 9 John Levon 2009-02-12 11:12:43 UTC
It's not entirely clear to me if this is VirtualBox or Xen.
Comment 10 Rich Burridge 2009-02-12 11:18:57 UTC
(In reply to comment #9)
> It's not entirely clear to me if this is VirtualBox or Xen.

In bug #6392, which generated a similar stack trace, it was VirtualBox.
Comment 11 John Levon 2009-02-12 11:38:50 UTC
ENOSPC is correct - on the live CD, the relevant directory is almost certainly
the live ramdisk. I checked and attempting to touch /.cdrom/foo does give EROFS
correctly.