Dear archers,
I am running Arch Linux inside virtualbox, on a Ubuntu 12.04 host on
which I have very limited power (the only command I can run as root is
"apt-get install"). For this reason my virtualbox version is very
outdated (4.1.12, the last version being 4.3.28!). My main problem is
than when I ask to run "pacman -S ghc", the installation begins and then
the machine suddenly halts at approximately 25% (best case 50%), with
the following error log message:
00:02:06.072 !!Assertion Failed!!
00:02:06.072 Expression: pSgBuf->cbSegLeft <= 5 * _1M &&
(uintptr_t)pSgBuf->pvSegCur >=
(uintptr_t)pSgBuf->paSegs[pSgBuf->idxSeg].pvSeg &&
(uintptr_t)pSgBuf->pvSegCur + pSgBuf->cbSegLeft <=
(uintptr_t)pSgBuf->paSegs[pSgBuf->idxSeg].pvSeg +
pSgBuf->paSegs[pSgBuf->idxSeg].cbSeg
00:02:06.072 Location :
/build/buildd/virtualbox-4.1.12-dfsg/src/VBox/Runtime/common/misc/sg.cpp(54)
void* sgBufGet(PRTSGBUF, size_t*)
00:02:06.072 pSgBuf->idxSeg=0 pSgBuf->cSegs=1
pSgBuf->pvSegCur=00007fbd109e0000 pSgBuf->cbSegLeft=10321920
pSgBuf->paSegs[0].pvSeg=00007fbd109e0000 pSgBuf->paSegs[0].cbSeg=10321920
Following this ticket <https://www.virtualbox.org/ticket/10434> and ghc
being a huge package, I am assuming that the problem is the same: this
virtualbox bug is triggered because pacman performs too heavy IO when
installing ghc (speculative, but looks reasonable).
So, I tried to limit pacman's IO rate in the following way (after having
installed libcgroup from the AUR and cgmanager):
# cgcreate -g blkio:wlimit
# echo "8:0 1024"
>/sys/fs/cgroup/blkio/wlimit/blkio.throttle.write_bps_device
# cgexec -g blkio:wlimit pacman -S --force ghc
(8:0 is /dev/sda, which is the only disk, and 1024 the byte rate I want
to enforce)
However the machine still halts in the same way and doesn't seem to go
beyond 50% either. Even if I replace 1024 by, say, 1, pacman doesn't
seem to struggle more to write to the disk -- when I would expect it to
take forever to do 1% of the installation.
Is there something wrong in the commands I have written above? Is there
a way to check that the limitation is indeed enforced? (maybe the source
of the bug is elsewhere) Alternatively, can you think of another
solution to this problem?
Many thanks
-- Yannis
