lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] dpkg error on redhat server


From: Vadim Zeitlin
Subject: Re: [lmi] dpkg error on redhat server
Date: Tue, 8 Oct 2019 01:10:55 +0200

On Mon, 7 Oct 2019 22:56:24 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2019-10-07 20:40, Vadim Zeitlin wrote:
GC> > On Mon, 7 Oct 2019 20:27:28 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> dpkg: unrecoveraE: Write error - write (28: No space left on device)
GC> > GC> E: Sub-process /usr/bin/dpkg returned an error code (2)
GC> [...]
GC> >  Do I understand correctly that there is just 30GiB of disk space in total
GC> > but, judging from the tmpfs size, there is more than 8GiB of RAM? This
GC> > looks like a rather strange configuration, but at least the good news is
GC> > that there is a decent amount of RAM. The bad news is that not only there
GC> > is not much disk space, but that it's also partitioned amount many
GC> > different logical volumes, meaning that there will probably not be enough
GC> > space on either of them.
GC> 
GC> [server]$free -bt
GC>               total        used        free      shared  buff/cache   
available
GC> Mem:    16637714432  4749615104   294146048   436011008 11593953280 
10883760128
GC> Swap:   17179865088   262144000 16917721088
GC> Total:  33817579520  5011759104 17211867136
GC> 
GC> Server has a respectable 32G RAM.

 Looks like 16 to me (the other half is swap, so it doesn't really count).

GC> However, it looks like the biggest drive chunk is 8.4GB, although
GC> there's a total of 69G:
GC> 
GC> $df --si --total
GC> Filesystem                         Size  Used Avail Use% Mounted on
GC> /dev/mapper/VolGroup00-lv_root     4.3G  4.3G  377k 100% /
GC> devtmpfs                           8.4G     0  8.4G   0% /dev
GC> tmpfs                              8.4G     0  8.4G   0% /dev/shm
GC> tmpfs                              8.4G  458M  7.9G   6% /run
GC> tmpfs                              8.4G     0  8.4G   0% /sys/fs/cgroup
GC> /dev/mapper/VolGroup00-lv_usr      7.6G  6.5G  1.1G  87% /usr
GC> /dev/sda1                          1.1G  186M  768M  20% /boot
GC> /dev/mapper/VolGroup00-lv_var      4.3G  1.4G  3.0G  31% /var
GC> /dev/mapper/VolGroup00-lv_home     2.2G  195M  2.0G  10% /home
GC> /dev/mapper/VolGroup00-lv_var_log  2.2G  174M  2.0G   9% /var/log
GC> /dev/mapper/VolGroup00-lv_tmp      4.3G  1.4G  3.0G  32% /tmp
GC> /dev/mapper/VolGroup00-lv_opt      4.3G  1.5G  2.9G  33% /opt
GC> tmpfs                              1.7G     0  1.7G   0% /run/user/REDACTED1
GC> tmpfs                              1.7G     0  1.7G   0% /run/user/0
GC> tmpfs                              1.7G     0  1.7G   0% /run/user/REDACTED2
GC> total                               69G   16G   53G  24% -

 This is weird, even with the understanding that there is an at least 16GiB
swap partition, I don't understand where is the rest of this space. If
you're curious about this too, could you please run "fdisk -l" and check
what it says?

GC> Agreed. We'll have to petition TPTB for more space. But that could take
GC> a long time, and I'm eager to get lmi built soon, by whatever temporary
GC> expedient is necessary, as a proof of concept.

 As root, you have it in your power to reformat the swap partition and use
it for the chroot. 16GiB isn't that much, but it should definitely be
enough for a single build.

GC> On this server, $(nproc) returns eight, so I don't think building lmi
GC> in parallel will consume 8 GB of RAM, and a 24 GB ramdisk should be
GC> big enough for a proof of concept, so I guess I'll try again with:
GC>   mount -t tmpfs -o size=75% tmpfs /srv

 This might indeed work, although it risks being a bit funny, in an unfunny
sort of way, if you end up swapping out the compiler processes because
you've taken too much RAM for the build directory.

 Good luck in any case!
VZ

Attachment: pgpe8YLhcw9sz.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]