Thanks much @~s-chriscollins! For me that setting in virtualbox was it.
When I started reading this thread and see similar issues since 2012 I
wasnt very optimistic... but 7 years later you provide a solution! I
don't understand if it's a problem in virtualbox or problem with dkpg,
but this is
I encountered the same problem in Ubuntu 20.04 and 20.10. This
fundamental dpkg deficit has been there for 8 years! How ridiculous a
system like this!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I've also encountered problem recently.
I'm installing headers 4.15.0-112.113. Progress is stuck on unpacking stage at
4%. I've tried clearing cache but this didn't seem to help. dpkg is disk sleep
in htop.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I tried it by comparing the same VM with and without that setting. Here
is what I found:
With "Use Host I/O Cache" disabled, booting took 40 seconds.
With "Use Host I/O Cache" enabled, booting took 12 seconds.
With "Use Host I/O Cache" disabled, doing a mini update took a few minutes.
With
I think you are on to something here.
I will try this solution on next kernel update.
I also found some information why this setting is not turned on by default:
https://www.electricmonk.nl/log/2016/03/14/terrible-virtualbox-disk-performance/
I have also created an issue at the VirtualBox forum
Good news! I was able to work around the issue by enabling host I/O
cache in the virtual machine settings. Go to "Storage", select
"Controller: SATA", and enable "Use Host I/O Cache".
I'm not sure what changed in the Linux kernel to make this change
necessary, but I wonder if kernels earlier than
I have noticed this issue also S. Christian Collins.
I have an Ubuntu host running Ubuntu Budgie 18.04 with three different VMs -
one Ubuntu 16.04, one Ubuntu Budgie 18.04 and one Ubuntu Budgie 19.04 (the last
two are running Linux kernel 5.0).
Had no problems with kernel updates until three
Okay, so I have narrowed this down a bit. The issue is the kernel
version on the HOST system, not the GUEST. I tested this by installing
the package "linux-headers-5.0.0-23" on a Xubuntu 18.04 guest in
VirtualBox using two different kernels on the host PC. I used the
command "time sudo apt install
I am running into this bug in all of my Ubuntu (and variants) VirtualBox
VMs as well. I didn't notice this issue with vanilla 18.04 installs, but
only since upgrading the VMs to the hardware enablement stack, so
perhaps this bug only happens with the newer kernels?
--
You received this bug
" ali nagi (alin43958) on 2016-05-06
Changed in dpkg (Ubuntu):
status: Confirmed → Fix Released "
What was the fix?
I continue to have this same problem (various Linux versions on Xubuntu
18.04.2 hosts).
--
You received this bug notification because you are a member of Ubuntu
Bugs,
** Changed in: dpkg (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/947664
Title:
Unpacking linux-headers unbelievably slow in Lubuntu Precise (Beta
I am confirming this bug. Ubuntu Server 14.04.1 x64 running in
VirtualBox 4.3.26 (host OS is Windows). VM specs are 1024 MB RAM, 1 CPU
(out of 8 cores on Xeon CPU), hardware acceleration enabled.
Unpacking of linux headers takes on average 20-30 minutes.
--
You received this bug notification
For the record, I used to have this problem and neither force-unsafe-
io nor nodelalloc nor discard option in fstab solved the problem.
Because... my problem was that I was using a very old SSD model that did
not even have TRIM. Every write required an erase cycle and obviously
that killed
Anyone experiencing this issue may wish to try these and report back on
what, if any, differences they make:
- Use dpkg's force-unsafe-io. Put force-unsafe-io in
/etc/dpkg/dpkg.cfg.d/unsafe_io
- If using ext4, mount with the nodelalloc option. Either add it in
/etc/fstab or remount with 'mount
so i just decided to grit my teeth and wait for the update to finish.
it slowly does make progress.
this is the ps output
root 757 0.5 0.2 109944 86956 pts/4Ds+ 14:34 0:06
/usr/bin/dpkg --status-fd 59 --unpack --auto-deconfigure
i see this problem.
i have an ssd and ext4 which i have seen mentioned a few times in other places.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/947664
Title:
Unpacking linux-headers unbelievably
I can also confirm this issue.
I'm running vanilla Ubuntu Server 12.03 LTS in a Hyper-V VM.
durr@monsrv:~$ uname -a
Linux monsrv 3.2.0-51-generic #77-Ubuntu SMP Wed Jul 24 20:18:19 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux
durr@monsrv:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
Forgot to mention. I'm using a plain-old ext4 partition.
Hyper-V instrumentation is showing a pretty static ~25-35 KB/sec read
*and* write from the vhd disk.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Also affects: dpkg
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/947664
Title:
Unpacking linux-headers unbelievably slow in Lubuntu Precise (Beta 1)
I can confirm this bug.
The following operations took about 15 minutes.
sudo apt-get install linux-generic linux-headers-generic
linux-headers-generic-lts-quantal linux-image-generic
linux-image-generic-lts-quantal linux-tools linux-tools-lts-quantal
[...]
Unpacking linux-headers-3.2.0-53
On crucial v4 ssd 128 Gb, Ubuntu 13.04, FS etx4 with TRIM, extracting
linux-headers-3.8.0-25-generic take ower 40 min.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/947664
Title:
Unpacking
I have the same issue. One package that took about 50 minutes to extract was
the webmin .deb file, using the Ubuntu Archive Manager it extracted within 4
seconds.
I'm using 12.10 on a 32GB SSD from A-DATA with ext-4. Going by previous reports
that might have something to do with SSDs?
Using the
I'm experiencing this problem as well. I suggest all of those with the
problem post some information to help narrow the issue down. In my case
I'm using a newly installed SSD and have a feeling the slow linux-
headers unpacking is just a side effect of slow write speeds.
Hard drive: SSD
I have this problem in Xubuntu 12.10, ext4 on a SSD (no discard option
in fstab)
I had a previous Xubuntu 12.04 install on this machine previously
(different mechanical hard drive ext4) and had no problem.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
i see the same behaviour , xubuutu 12.04
ext4 hard drive, no NFS involved
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/947664
Title:
Unpacking linux-headers unbelievably slow in Lubuntu Precise
On our Precise amd64 nfs-root systems, installing linux-headers is
definitely what takes ages -- the rest of the package upgrades are
always zippy. For some reason, I see 3 different dpkg-deb instances
kicked off:
root 21184 0.0 0.0 16868 772 pts/1S+ 22:05 0:00 dpkg-deb
Hello,
On Sun, 16 Sep 2012, Benedikt wrote:
I can confirm this bug in a quantal vbox. In a Precise vbox the unpack
process takes under one minute. Under quantal it takes longer than 5
min. Linux Headers is the only package that has this problem.
Are you using btrfs in quantal but ext4 in
** Changed in: dpkg (Ubuntu)
Importance: Undecided = High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/947664
Title:
Unpacking linux-headers unbelievably slow in Lubuntu Precise (Beta 1)
To
I can confirm this bug in a quantal vbox. In a Precise vbox the unpack
process takes under one minute. Under quantal it takes longer than 5
min. Linux Headers is the only package that has this problem.
** Changed in: dpkg (Ubuntu)
Status: Expired = Confirmed
--
You received this bug
[Expired for dpkg (Ubuntu) because there has been no activity for 60
days.]
** Changed in: dpkg (Ubuntu)
Status: Incomplete = Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/947664
have been waiting for 20 minutes now. guest: Stock 12.04 LTS server,
host: 12.04 lts lubuntu desktop. 8gb disk, 2gb out of 6gb memory. the
whole dist-upgrade process is rather slow, but these headers really kill
me.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
On 12-05-30 12:18 AM, Launchpad Bug Tracker wrote:
[Expired for dpkg (Ubuntu) because there has been no activity for 60
days.]
This is BS. Just because Ubuntu ignore a bug for 60 days does not make
it eligible for Expriy. The bug still exists and will exist until
somebody does something about
** Changed in: dpkg (Ubuntu)
Status: Expired = Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/947664
Title:
Unpacking linux-headers unbelievably slow in Lubuntu Precise (Beta 1)
The filesystem being used here is, no surprise, ext3. I really don't
think this is a particular filesystem problem.
I'm currently testing dpkg's --force-unsafe-io. I expect it will speed
things up, yes. But what if it does? Will Ubuntu actually use it in
it's package managers given that it's
Hrm. Something's awry here. The baseline control package install only
took 27 seconds. In fact it only takes 10 seconds on subsequent
installations (i.e. after a dpkg -P). This really did take much much
longer previously.
However, the same operation over NFS on Gige does take 25 minutes.
On Wed, 30 May 2012, Brian J. Murrell wrote:
Over the same NFS with --force-unsafe-io it takes 26 minutes and that's
probably because in analysing with strace, I don't see dpkg doing
anything different per file being installed:
That's because the fsync() are done in a batch at the end of the
On 12-05-30 01:11 PM, Raphaël Hertzog wrote:
sync_file_range() is something different, it just tells the filesystem to
start the writeback, it doesn't wait for it to have happened (contrary to
fsync()).
So it should be irrelevant for the time lost, unless Linux's NFS driver
has a poor
[Expired for dpkg (Ubuntu) because there has been no activity for 60
days.]
** Changed in: dpkg (Ubuntu)
Status: Incomplete = Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/947664
The process just seems to be very metadata heavy. For example at one
point in the transaction:
open(/usr/src/linux-headers-3.2.0-20/arch/arm/mach-davinci/include/mach/cpuidle.h.dpkg-new,
O_WRONLY|O_LARGEFILE) = 7
fsync(7)= 0
close(7)
** Changed in: dpkg (Ubuntu)
Status: New = Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/947664
Title:
Unpacking linux-headers unbelievably slow in Lubuntu Precise (Beta 1)
To
The build is a stock Lubuntu Precise installed one its own, taking up
the whole disk with no special partitioning or formatting options. It's
an 8GB expandable virtual disk provided by Oracle Virtualbox.
It's hard to tell for sure what the process is which is taking so long.
It could in principle
Well, you should definitely give more information about your
configuration.
What filesystem are you using ?
Is it significantly faster if you use dpkg's --force-unsafe-io ?
What's the process state in the ps output ?
--
You received this bug notification because you are a member of Ubuntu
42 matches
Mail list logo
