Re: [lmi] dpkg error on redhat server

[Greg Chicares]

On 2019-10-07 20:40, Vadim Zeitlin wrote:
> On Mon, 7 Oct 2019 20:27:28 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> dpkg: unrecoveraE: Write error - write (28: No space left on device)
> GC> E: Sub-process /usr/bin/dpkg returned an error code (2)
[...]
>  Do I understand correctly that there is just 30GiB of disk space in total
> but, judging from the tmpfs size, there is more than 8GiB of RAM? This
> looks like a rather strange configuration, but at least the good news is
> that there is a decent amount of RAM. The bad news is that not only there
> is not much disk space, but that it's also partitioned amount many
> different logical volumes, meaning that there will probably not be enough
> space on either of them.

[server]$free -bt
              total        used        free      shared  buff/cache   available
Mem:    16637714432  4749615104   294146048   436011008 11593953280 10883760128
Swap:   17179865088   262144000 16917721088
Total:  33817579520  5011759104 17211867136

Server has a respectable 32G RAM. However, it looks like
the biggest drive chunk is 8.4GB, although there's a
total of 69G:

$df --si --total
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-lv_root     4.3G  4.3G  377k 100% /
devtmpfs                           8.4G     0  8.4G   0% /dev
tmpfs                              8.4G     0  8.4G   0% /dev/shm
tmpfs                              8.4G  458M  7.9G   6% /run
tmpfs                              8.4G     0  8.4G   0% /sys/fs/cgroup
/dev/mapper/VolGroup00-lv_usr      7.6G  6.5G  1.1G  87% /usr
/dev/sda1                          1.1G  186M  768M  20% /boot
/dev/mapper/VolGroup00-lv_var      4.3G  1.4G  3.0G  31% /var
/dev/mapper/VolGroup00-lv_home     2.2G  195M  2.0G  10% /home
/dev/mapper/VolGroup00-lv_var_log  2.2G  174M  2.0G   9% /var/log
/dev/mapper/VolGroup00-lv_tmp      4.3G  1.4G  3.0G  32% /tmp
/dev/mapper/VolGroup00-lv_opt      4.3G  1.5G  2.9G  33% /opt
tmpfs                              1.7G     0  1.7G   0% /run/user/REDACTED1
tmpfs                              1.7G     0  1.7G   0% /run/user/0
tmpfs                              1.7G     0  1.7G   0% /run/user/REDACTED2
total                               69G   16G   53G  24% -

> GC> and it looks like a freshly-constructed bullseye chroot where
> GC> lmi has been built needs more than nine gibibytes:
> GC> 
> GC> /root[0]# du -sb /srv/chroot/lmi_bullseyeeraseme            
> GC> 9315886040      /srv/chroot/lmi_bullseyeeraseme
> 
>  This is not really surprising. The chroot files themselves don't take up
> that much, but building software requires quite a lot of space, especially
> with debug information.
> 
> GC> Vadim--do you suppose it's worth trying to work around this, e.g.
> GC> by replacing
> GC>   apt-get install pkg1 pkg2 pkg3
> GC> with
> GC>   apt-get install pkg1
> GC>   apt-get install pkg2
> GC>   apt-get install pkg3
> 
>  This doesn't seem promising, there clearly isn't enough space for anything
> on /. And if you installed these packages somewhere under /opt, it should
> work even with the current command.

I thought I was trying to do that under /var . But I filled up / while
/var has plenty of free space, so I'll have to reexamine my assumptions.
Oh, wait--I'm using /srv, not /var, and /srv doesn't have its own mount.

> But building lmi will probably still
> run out of space. You could play with symlinks/bind mounts or just resize
> logical volumes (or even combine them) to get some more space, but I'm
> afraid this will be a never ending source of problems in the best case.

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

> GC> after perhaps cd'ing to /tmp (tmpfs seems to have some space),
> 
>  This space is transient however, so it won't pertain after reboot. You
> could use tmpfs for building lmi, but this will mean that you won't have a
> lot of RAM left for the compiler, so I don't know if it's a good idea.

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