Re: [lmi] dpkg error on redhat server

[Vadim Zeitlin]

On Mon, 7 Oct 2019 20:27:28 +0000 Greg Chicares <address@hidden> wrote:

GC> Vadim--Please let me know your thoughts on the question at the
GC> bottom.
GC> 
GC> I've transplanted the proven lmi installation on centos to a
GC> corporate redhat server, and after these commands that succeed:
GC> 
GC> + dpkg --add-architecture i386
GC> + apt-get update
GC> 
GC> this one fails:
GC> 
GC> + apt-get --assume-yes install wget g++-mingw-w64 automake libtool make 
pkg-config git cvs zsh bzip2 unzip sudo wine default-jre jing trang 
g++-multilib libxml2-utils libxslt1-dev vim-gtk vim-doc shellcheck bc 
libarchive-tools xsltproc
GC> 
GC> as follows:
GC> 
GC> dpkg: error processing archive 
/tmp/apt-dpkg-install-g8ZMwE/216-iso-codes_4.3-1_all.deb (--unpack):
GC>  cannot copy extracted data for 
'./usr/share/locale/fo/LC_MESSAGES/iso_3166-1.mo' to '/usr/share/lo
GC> cale/fo/LC_MESSAGES/iso_3166-1.mo.dpkg-new': failed to write (No space left 
on device)
GC> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
GC> 
GC> and similarly for several other archives, then finally:
GC> 
GC> dpkg: unrecoveraE: Write error - write (28: No space left on device)
GC> E: Sub-process /usr/bin/dpkg returned an error code (2)
GC> 
GC> Investigating:
GC> 
GC> $df --si
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/19193
GC> tmpfs                              1.7G     0  1.7G   0% /run/user/0
GC> tmpfs                              1.7G     0  1.7G   0% /run/user/65345

 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.

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. 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.

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.

GC> or does this server just need to have a lot of disk capacity added?

 This would obviously be the best solution. This looks like a virtual
rather than a physical server, so attaching a bigger disk to it shouldn't
be a huge problem, but, of course, it's still easier said than done.

 Regards,
VZ

pgpsLf_FmAShK.pgp
Description: PGP signature