☰

自制数据库包上损坏的 debian 包档案

tag-icon • tag-icon ubuntu packaging
自制数据库包上损坏的 debian 包档案

我开始将几个大型数据库打包在一些非常基本的 Debian 软件包中，以便让我的工作变得更轻松。但是，我现在遇到了一些问题。大多数数据库都会顺利安装，但是最大的三个数据库会失败。

find . -name "*.deb" -exec du -h '{}' \; | sort -h
# These install fine
4.0K    ./hh-suite-data_1.0_all.deb
422M    ./hh-suite-data-env70/package/hh-suite-data-env70_1.0.0_amd64.deb
660M    ./hh-suite-data-env90/package/hh-suite-data-env90_1.0.0_amd64.deb
795M    ./hh-suite-data-env/package/hh-suite-data-env_1.0.0_amd64.deb
1.6G    ./hh-suite-data-scop70/package/hh-suite-data-scop70_1.0.0_amd64.deb
2.6G    ./hh-suite-data-nr70/package/hh-suite-data-nr70_1.0.0_amd64.deb
2.8G    ./hh-suite-data-pfamA/package/hh-suite-data-pfama_1.0.0_amd64.deb
3.2G    ./hh-suite-data-nr90/package/hh-suite-data-nr90_1.0.0_amd64.deb
# These fail to install
4.3G    ./hh-suite-data-nr20/package/hh-suite-data-nr20_1.0.0_amd64.deb
6.2G    ./hh-suite-data-pdb70/package/hh-suite-data-pdb70_1.0.0_amd64.deb
7.4G    ./hh-suite-data-nr/package/hh-suite-data-nr_1.0.0_amd64.deb

失败看起来像这样：

sudo dpkg -i package/hh-suite-data-nr20_1.0.0_amd64.deb 
[sudo] password for esr: 
(Reading database ... 276172 files and directories currently installed.)
Unpacking hh-suite-data-nr20 (from .../hh-suite-data-nr20_1.0.0_amd64.deb) ...
dpkg: error processing package/hh-suite-data-nr20_1.0.0_amd64.deb (--install):
 corrupted filesystem tarfile - corrupted package archive
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 package/hh-suite-data-nr20_1.0.0_amd64.deb

我有点确信这是因为档案的大小，大约在 3.2 到 4.3G 之间。

有谁有任何经验非常大型封装及其故障模式？任何人都知道为什么会发生这种情况？我没有理由相信 tar 存档已损坏，我已经多次构建了该软件包，但在安装时仍然看到此错误

我正在将我的包重写为仅wget来自镜像的文件，而不是实际包含数据库，因为这样可以解决 tar 问题。

使用 -D10 运行

# This file unpacks fine
D000010: tarobject ti->name='./usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db.index' mode=100644 owner=0.0 type=48(-) ti->linkname='' namenode='/usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db.index' flags=2 instead='<none>'
D000010: ensure_pathname_nonexisting `/usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db.index.dpkg-tmp'
D000010: ensure_pathname_nonexisting `/usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db.index.dpkg-new'
# This is a 16G file and fails IMMEDIATELY.
D000010: tarobject ti->name='./usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db' mode=100644 owner=0.0 type=48(-) ti->linkname='' namenode='/usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db' flags=2 instead='<none>'
D000010: ensure_pathname_nonexisting `/usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db.dpkg-tmp'
D000010: ensure_pathname_nonexisting `/usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db.dpkg-new'
dpkg: error processing hh-suite-data-pdb70_1.0.0_amd64.deb (--install):
 corrupted filesystem tarfile - corrupted package archive

使用 -D100 运行

这部分有两个条目，一个是好条目，一个是坏条目，还有一些是失败后的条目。让我担心的是“tarobject 文件打开大小=0”位。

D000100: setupvnamevbs main=`/usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db.index' tmp=`/usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db.index.dpkg-tmp' new=`/usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db.index.dpkg-new'
D000100: tarobject already exists
D000100: tarobject file open size=900749
D000100: tarobject nondirectory, `link' backup
D000100: tarobject done and installation deferred
D000100: setupvnamevbs main=`/usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db' tmp=`/usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db.dpkg-tmp' new=`/usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db.dpkg-new'
D000100: tarobject already exists
D000100: tarobject file open size=0
D000100: tarobject nondirectory, `link' backup
D000100: tarobject done and installation deferred
dpkg: error processing hh-suite-data-pdb70_1.0.0_amd64.deb (--install):
 corrupted filesystem tarfile - corrupted package archive
D000100: setupvnamevbs main=`//usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db' tmp=`//usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db.dpkg-tmp' new=`//usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db.dpkg-new'
D000100: cu_installnew restoring atomic
D000100: secure_remove '//usr/share/hh-suite-data/pdb70/pdb70_19Oct13_a3m_db.dpkg-new' unlink OK

答案1

您可能想仔细阅读此命令的输出：

$ apt-config dump | less

具体来说有这些选项：

$ apt-config dump|grep bzip
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "3";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-9";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
Dir::Bin::bzip2 "/bin/bzip2";

此输出中还有许多与压缩相关的其他命令。我会确保这些指向的工具可以处理大于您似乎遇到的 4+ GB 阈值的文件。确保它们都是 64 位版本。

32 位与 64 位

我几乎肯定这是根本原因。请参阅我对这个问题的回答，标题为：Linux 上的 32 位、64 位 CPU 操作模式，有关如何确定系统的 CPU 位宽和操作系统编译架构的示例。

操作系统

$ getconf LONG_BIT
64

中央处理器

$ hwinfo --cpu | grep Arch | tail -1
  Arch: X86-64

相关内容