记一次openGauss编译安装移植过程中踩到的坑

qq_45705658

已于 2024-05-10 14:06:07 修改

阅读量1.1k

点赞数 17

文章标签： gaussdb postgresql

于 2024-05-09 18:37:03 首次发布

本文链接：https://blog.csdn.net/qq_45705658/article/details/138625634

版权

文章目录

本文章从官方推荐的软硬件环境，编译移植到非推荐设备上，先是使用docker运行，然后脱离docker直接跑在系统上。主要记录了期间遇到几个问题。

大部分问题在官网的社区都能找到答案，官方提供的编译安装步骤如下:官方指导手册链接

一、工作环境

本次记录从编译服务器移植到嵌入式设备上步骤，二者软硬件环境如下：

编译服务器：鲲鹏920 cpu，arm架构， openEuler 20.03系统（官方推荐的软硬件环境）

[root@362f7ae16fc5 /]# lscpu
Architecture:                    aarch64
CPU op-mode(s):                  64-bit
Byte Order:                      Little Endian
CPU(s):                          96
On-line CPU(s) list:             0-95
Thread(s) per core:              1
Core(s) per socket:              48
Socket(s):                       2
NUMA node(s):                    4
Vendor ID:                       HiSilicon
Model:                           0
Model name:                      Kunpeng-920
Stepping:                        0x1
CPU max MHz:                     2600.0000
CPU min MHz:                     200.0000
BogoMIPS:                        200.00
L1d cache:                       6 MiB
L1i cache:                       6 MiB
L2 cache:                        48 MiB
L3 cache:                        192 MiB
NUMA node0 CPU(s):               0-23
NUMA node1 CPU(s):               24-47
NUMA node2 CPU(s):               48-71
NUMA node3 CPU(s):               72-95
Vulnerability Meltdown:          Mitigation; PTI
Vulnerability Spec store bypauss: Not affected
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Vulnerable
Flags:                           fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm js
                                 cvt fcma dcpop
[root@362f7ae16fc5 /]# cat /etc/os-release 
NAME="openEuler"
VERSION="20.03 (LTS)"
ID="openEuler"
VERSION_ID="20.03"
PRETTY_NAME="openEuler 20.03 (LTS)"
ANSI_COLOR="0;31"

目标设备：飞腾D2000, arm架构，centos 7系统

 Develop>lscpu 
Architecture:          aarch64
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    1
Core(s) per socket:    2
Socket(s):             4
NUMA node(s):          1
Model name:            Phytium,D2000/8
BogoMIPS:              3456.00
NUMA node0 CPU(s):     0-7
 Develop>
 Develop>
 Develop>cat /etc/os-release 
NAME="CNEOS"
VERSION=Wed Mar  6 14:52:25 CST 2019-svn9600
ID=CNEOS
VERSION_ID=Wed Mar  6 14:52:25 CST 2019
PRETTY_NAME="CNEOS Wed Mar  6 14:52:25 CST 2019"

二、目的设备docker启动

1、编译服务器编译测试

按照官方指导手册，提前准备好源码和第三方依赖库，官方已经清楚的告诉我们可以从哪里获取到，没有的朋友可以按照前面链接下载。

编译分为手动编译和一键编译两种方式，很显然，为了操作方便，当然选择一键编译，搭建好编译环境，操作如下：

一键式脚本编译

执行如下命令进入到软件代码编译脚本目录。
```
[user@linux sda]$ cd /sda/openGauss-server
```

执行如下命令，编译安装openGauss。

[user@linux openGauss-server]$ sh build.sh -m [debug | release | memcheck] -3rd [binarylibs path]

例如：

sh build.sh        # 编译安装release版本的openGauss。需代码目录下有binarylibs或者其软链接，否则将会失败。
sh build.sh -m debug -3rd /sdc/binarylibs            # 编译安装debug版本的openGauss

显示如下内容，表示编译成功。
```
make compile successfully!
```
- 编译后软件安装路径为：/sda/openGauss-server/mppdb_temp_install
- 编译后的二进制放置路径为：/sda/openGauss-server/mppdb_temp_install/bin
- 编译日志为：./build/script/makemppdb_pkg.log

导入环境变量，即可进行初始化和启动数据库。

export CODE_BASE=________     # openGauss-server的路径
export GAUSSHOME=$CODE_BASE/mppdb_temp_install/
export LD_LIBRARY_PATH=$GAUSSHOME/lib::$LD_LIBRARY_PATH
export PATH=$GAUSSHOME/bin:$PATH

按照官网操作，漫长的编译过程执行完毕后，编译成功了，首先在编译服务器上运行，没有问题，编译安装成功（这里就不做截图了，因为编译服务器环境完全和官网推荐一致，所以很容易就成功了），于是乎，将编译服务器上的安装包移植到目的设备上。

2、目的设备移植

a、第一个坑：openGauss需要工作在支持`IO_DIRECT`的磁盘上

因为目的设备和编译服务器存在软硬件差异，所以在目的设备上先构建了docker环境，确保程序能够正常启动。然而意外出现了，执行初始化命令时gs_initdb -D /home/opp/data2/ --nodename=db1，报错如下：

[ott@8133b10d6f3d opp]$ gs_initdb -D /home/opp/data2/ --nodename=db1
The files belonging to this database system will be owned by user "ott".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

fixing permissions on existing directory /home/opp/data2 ... ok
creating subdirectories ... in ordinary occasionok
creating configuration files ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 1024MB
Begin init undo subsystem meta.
[INIT UNDO] Init undo subsystem meta successfully.
creating template1 database in /home/opp/data2/base/1 ... 2024-05-09 06:15:10.730 [unknown] [unknown] localhost 548254040080 0[0:0#0]  [BACKEND] WARNING:  macAddr is 578/2886795268, sysidentifier is 37923857/316241, randomNum is 2360857425
2024-05-09 06:15:10.771 [unknown] [unknown] localhost 548254040080 0[0:0#0]  [DBL_WRT] PANIC:  Could not create file "global/pg_dw_meta": Invalid argument
2024-05-09 06:15:10.771 [unknown] [unknown] localhost 548254040080 0[0:0#0]  [DBL_WRT] BACKTRACELOG:  tid[758]'s backtrace:
        /home/ott/mppdb_temp_install/bin/gaussdb() [0x12c073c]
        /home/ott/mppdb_temp_install/bin/gaussdb(_Z9errfinishiz+0x334) [0x12b7470]
        /home/ott/mppdb_temp_install/bin/gaussdb(_Z14dw_create_filePKc+0xd4) [0x212c8b4]
        /home/ott/mppdb_temp_install/bin/gaussdb(_Z21dw_generate_meta_fileP21st_dw_batch_meta_file+0x20) [0x212af68]
        /home/ott/mppdb_temp_install/bin/gaussdb(_Z12dw_bootstrapv+0xb8) [0x212a6c4]
        /home/ott/mppdb_temp_install/bin/gaussdb(_Z13BootStrapXLOGv+0x16ec) [0x216bd44]
        /home/ott/mppdb_temp_install/bin/gaussdb(_Z20BootStrapProcessMainiPPc+0xae4) [0x143d14c]
        /home/ott/mppdb_temp_install/bin/gaussdb(main+0x5d4) [0x1a45a2c]
        /lib64/libc.so.6(__libc_start_main+0xe0) [0x7fa68bcf60]
        /home/ott/mppdb_temp_install/bin/gaussdb() [0xba53cc]
        Use addr2line to get pretty function name and line

could not write to child process: Broken pipe
gs_initdb: removing contents of data directory "/home/opp/data2"

看到关键一句Could not create file "global/pg_dw_meta": Invalid argument，一开始一脸懵，完全不知道为啥，在论坛和网上搜索了很久，终于，找到一篇博客，网友遇到过一模一样的问题。非常感谢这篇博客，节省了大量时间和人力，有兴趣的网友可以查看这篇博客，有详细的问题分析过程。

这里直接说一下结论：opengauss源码中，为了提升性能，在读写文件时，使用了IO_DIRECT这一参数，这个主要的功能就是，不经过缓存直接通过IO操作读取文件，这里通过这个操作可以减少数据复制和减少内核态和用户态之间的上下文切换次数。

fd = open(file_name, (O_RDWR | O_SYNC | O_DIRECT | PG_BINARY | O_CREAT), DW_FILE_PERM);

使用该参数，同时也需要数据库工作的硬盘支持该选项，如果工作目录不支持，很遗憾，opengauss无法工作。

总结以上，给出的解决方案就是：

给文件系统授予直接IO权限（需要重新挂载文件系统）；
把数据目录更改为其他有权限的目录即可。后面我把目录改成其他支持O_DIRECT这个权限的目录就可以部署成功了。

网友贴心的写了一个脚本，用于检测本设备上，哪些磁盘分区支持IO_DIRECT，代码如下，亲测有效。之前编译服务器能够正常工作，确实也是直接支持，在需要移植的目的设备上，开始选择的分区并不支持，更换后，可以正常启动。

#!/usr/bin/env python
# -*- coding:utf-8 -*-
import os
import subprocess

def check_o_direct_support(mount_point):
    try:
        # 创建一个临时文件路径
        temp_file_path = os.path.join(mount_point, "o_direct_test.tmp")
        os.system("touch %s" % temp_file_path)
        # 尝试以 O_DIRECT 标志打开文件
        fd = os.open(temp_file_path, os.O_RDONLY | os.O_DIRECT)
        os.close(fd)
        os.remove(temp_file_path)
        print("{}: 文件系统支持 O_DIRECT".format(mount_point))
    except OSError as e:
        if e.errno == 22:  # EINVAL - Invalid argument
            print("{}: 文件系统不支持 O_DIRECT".format(mount_point))
        elif e.errno == 20:  # ENOTDIR - Not a directory
            print("{}: 不是一个目录，无法创建文件".format(mount_point))
        elif e.errno == 13:  # EACCES - Permission denied
            print("权限不足，无法在 {} 中创建临时文件".format(mount_point))
        else:
            pauss
    finally:
        try:
            os.system("rm  %s > /dev/null 2>1&" % temp_file_path)
        except:
            pauss

if __name__ == "__main__":
    # 获取系统中的所有挂载点
    df_process = subprocess.Popen(["df", "-P"], stdout=subprocess.PIPE)
    df_output = df_process.communicate()[0]
    mount_points = [line.split()[5] for line in df_output.splitlines()[1:]]

    # 检查每个挂载点的文件系统是否支持 O_DIRECT
    for mount_point in mount_points:
        check_o_direct_support(mount_point)

b、第二个坑：注意cpu指令集优化

解决完上述问题后，初始化成功，以为可以正常启动数据库了，开开心心执行下一步启动命令 gs_ctl start -D /home/opp/data2 -Z single_node -l /home/opp/log/opengauss.log，然而，不出意外的话，意外还是来了。打印信息如下，提示启动失败。

[2024-05-08 07:13:46.919][1680103][][gs_ctl]: stopped waiting
[2024-05-08 07:13:46.919][1680103][][gs_ctl]: could not start server
Examine the log output.

查看启动日志：

0 LOG:  [Alarm Module]can not read GAUSS_WARNING_TYPE env.

0 LOG:  [Alarm Module]Host Name: aeafa34e5ae2 

0 LOG:  [Alarm Module]Host IP: aeafa34e5ae2. Copy hostname directly in case of taking 10s to use 'gethostbyname' when /etc/hosts does not contain <HOST IP>

0 LOG:  [Alarm Module]Cluster Name: dbCluster 

0 LOG:  [Alarm Module]Invalid data in AlarmItem file! Read alarm English name failed! line: 57

0 WARNING:  failed to open feature control file, please check whether it exists: FileName=gaussdb.version, Errno=2, Errmessage=No such file or directory.
0 WARNING:  failed to parse feature control file: gaussdb.version.
0 WARNING:  Failed to load the product control file, so gaussdb cannot distinguish product version.
2024-05-08 07:13:46.904 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  when starting as multi_standby mode, we couldn't support data replicaton.
2024-05-08 07:13:46.919 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  [Alarm Module]can not read GAUSS_WARNING_TYPE env.

2024-05-08 07:13:46.919 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  [Alarm Module]Host Name: aeafa34e5ae2 

2024-05-08 07:13:46.919 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  [Alarm Module]Host IP: aeafa34e5ae2. Copy hostname directly in case of taking 10s to use 'gethostbyname' when /etc/hosts does not contain <HOST IP>

2024-05-08 07:13:46.919 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  [Alarm Module]Cluster Name: dbCluster 

2024-05-08 07:13:46.919 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  [Alarm Module]Invalid data in AlarmItem file! Read alarm English name failed! line: 57

2024-05-08 07:13:46.919 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] FATAL:  could not lock file "postmaster.pid.lock": Resource temporarily unavailable
0 LOG:  [Alarm Module]can not read GAUSS_WARNING_TYPE env.

0 LOG:  [Alarm Module]Host Name: aeafa34e5ae2 

0 LOG:  [Alarm Module]Host IP: aeafa34e5ae2. Copy hostname directly in case of taking 10s to use 'gethostbyname' when /etc/hosts does not contain <HOST IP>

0 LOG:  [Alarm Module]Cluster Name: dbCluster 

0 LOG:  [Alarm Module]Invalid data in AlarmItem file! Read alarm English name failed! line: 57

0 WARNING:  failed to open feature control file, please check whether it exists: FileName=gaussdb.version, Errno=2, Errmessage=No such file or directory.
0 WARNING:  failed to parse feature control file: gaussdb.version.
0 WARNING:  Failed to load the product control file, so gaussdb cannot distinguish product version.
2024-05-08 07:15:43.260 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  when starting as multi_standby mode, we couldn't support data replicaton.
2024-05-08 07:15:43.277 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  [Alarm Module]can not read GAUSS_WARNING_TYPE env.

2024-05-08 07:15:43.278 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  [Alarm Module]Host Name: aeafa34e5ae2 

2024-05-08 07:15:43.278 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  [Alarm Module]Host IP: aeafa34e5ae2. Copy hostname directly in case of taking 10s to use 'gethostbyname' when /etc/hosts does not contain <HOST IP>

2024-05-08 07:15:43.278 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  [Alarm Module]Cluster Name: dbCluster 

2024-05-08 07:15:43.278 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  [Alarm Module]Invalid data in AlarmItem file! Read alarm English name failed! line: 57

2024-05-08 07:15:43.283 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  loaded library "security_plugin"
2024-05-08 07:15:43.284 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] WARNING:  could not create any HA TCP/IP sockets
2024-05-08 07:15:43.284 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] WARNING:  could not create any HA TCP/IP sockets
2024-05-08 07:15:43.295 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  InitNuma numaNodeNum: 1 numa_distribute_mode: none inheritThreadPool: 0.
2024-05-08 07:15:43.295 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  reserved memory for backend threads is: 220 MB
2024-05-08 07:15:43.295 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  reserved memory for WAL buffers is: 128 MB
2024-05-08 07:15:43.295 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  Set max backend reserve memory is: 348 MB, max dynamic memory is: 8086 MB
2024-05-08 07:15:43.295 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  shared memory 3341 Mbytes, memory context 8434 Mbytes, max process memory 12288 Mbytes
2024-05-08 07:15:43.415 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [CACHE] LOG:  set data cache  size(402653184)
2024-05-08 07:15:43.470 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [SEGMENT_PAGE] LOG:  Segment-page constants: DF_MAP_SIZE: 8156, DF_MAP_BIT_CNT: 65248, DF_MAP_GROUP_EXTENTS: 4175872, IPBLOCK_SIZE: 8168, EXTENTS_PER_IPBLOCK: 1021, IPBLOCK_GROUP_SIZE: 4090, BMT_HEADER_LEVEL0_TOTAL_PAGES: 8323072, BktMapEntryNumberPerBlock: 2038, BktMapBlockNumber: 25, BktBitMaxMapCnt: 512
2024-05-08 07:15:43.492 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  gaussdb: fsync file "/home/odd/data/single_node/gaussdb.state.temp" success
2024-05-08 07:15:43.492 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  create gaussdb state file success: db state(STARTING_STATE), server mode(Normal), connection index(1)
2024-05-08 07:15:43.552 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  max_safe_fds = 978, usable_fds = 1000, already_open = 12
2024-05-08 07:15:43.555 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  the configure file /home/odd/etc/gscgroup_odd.cfg doesn't exist or the size of configure file has changed. Please create it by root user!
2024-05-08 07:15:43.555 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [BACKEND] LOG:  Failed to parse cgroup config file.
2024-05-08 07:15:43.571 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [EXECUTOR] WARNING:  Failed to obtain environment value $GAUSSLOG!
2024-05-08 07:15:43.571 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [EXECUTOR] DETAIL:  N/A
2024-05-08 07:15:43.571 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [EXECUTOR] CAUSE:  Incorrect environment value.
2024-05-08 07:15:43.571 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [EXECUTOR] ACTION:  Please refer to backend log for more details.
2024-05-08 07:15:43.572 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [EXECUTOR] WARNING:  Failed to obtain environment value $GAUSSLOG!
2024-05-08 07:15:43.572 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [EXECUTOR] DETAIL:  N/A
2024-05-08 07:15:43.572 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [EXECUTOR] CAUSE:  Incorrect environment value.
2024-05-08 07:15:43.572 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [EXECUTOR] ACTION:  Please refer to backend log for more details.
2024-05-08 07:15:43.572 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [EXECUTOR] WARNING:  Failed to obtain environment value $GAUSSLOG!
2024-05-08 07:15:43.572 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [EXECUTOR] DETAIL:  N/A
2024-05-08 07:15:43.572 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [EXECUTOR] CAUSE:  Incorrect environment value.
2024-05-08 07:15:43.572 [unknown] [unknown] localhost 548254040080 0[0:0#0]  0 [EXECUTOR] ACTION:  Please refer to backend log for more details.

仔细对比过编译服务器上启动日志和本设备上的日志信息，居然没差，除了基础设备信息外，完全一致，没有明显的错误信息问题，以至于不知道从何查起。于是，本着问题一定不是我第一次发现的原则，又开始了网上冲浪，逛论坛，找博客，看是否有相关信息。果然，上天垂怜，还真有。原博客在这里，同样，直接说结论：

openGauss对鲲鹏920等armv8.1或者更高的平台上，有指令集优化，会打开ARM_LSE。巧了，我的编译服务器正是鲲鹏920的cpu，但是目的设备是飞腾的，没有这么高端，果然无法支持。官方社区已经提供了解决方案，编译时去掉优化即可。
arm_lse

官方提供的编译方法中，有一个-nopt参数，看描述，符合我们的需求，但是很遗憾，该参数无法执行。
编译脚本

报错如下：

[root@362f7ae16fc5 openGauss-server-5.0.0]# sh build.sh -m debug -3rd /sdc/binarylibs -nopt
ROOT_DIR : /home/openGauss-server-5.0.0
Internal Error: option processing error: -nopt
please input right paramtenter, the following command may help you
./build_opengauss.sh --help or ./build_opengauss.sh -h
build_opengauss.sh failed, aborting.

时间紧迫，没有花费太多时间研究为啥不支持这个参数，按照社区提供的方法，去掉build\script\utils\make_compile.sh脚本中的-D__ARM_LSE指令，然后重新执行文章开始的一键编译步骤，安装验证，但是，奇怪的事情发生了，一键编译后安装还是无法运行，错误依然存在。心灰意冷之际，按照手动方法编译安装，您猜怎么着，嘿，居然成功的在目的设备上跑起来了，数据正常运行。最后，回头分析了一波，查找了下代码，社区只是让去掉make_compile.sh脚本中的-D__ARM_LSE，但是除此之外还有一处，\cmake\src\build_options.cmake，cmake下也有使用到该参数，删掉后就可以使用一键编译了。

三、脱离docker直接工作在设备上

至此，目的设备已经可以正常在docker中运行openGauss数据库，但是，做为嵌入式设备，为了减少资源占用，实际工作时是不会安装docker环境的，需要在centos下直接运行openGauss。然而，屋漏偏逢连夜雨，我们设备的系统版本很低，glibc远不满足官方要求值，直接将安装包拷贝到设备上报各种动态库无法找到的问题，使用ldd可以查看到缺少很多依赖项。这里就不列举了。

方法一：使用`patchelf`（未成功）

为了在设备上直接运行，一开始想到将openGauss在容器内依赖的lib库，bin命令等拷贝出来，单独存放在一个目录，然后使用LD_LIBRARY_PATH指定环境变量、使用patchelf修改rpath和链接器就可以了。但是实操后发现，会报_dl_exception_create、_dl_starting_up未定义等错误，查了资料大概原因就是链接器版本和glbic版本不兼容所致。

 Develop>export LD_LIBRARY_PATH=/initrd/cf/output_local/lib64/lib/
date: relocation error: /initrd/cf/output_local/lib64/lib/libc.so.6: symbol _dl_exception_create, version GLIBC_PRIVATE not defined in file ld-linux-aarch64.so.1 with link time reference
date: relocation error: /initrd/cf/output_local/lib64/lib/libc.so.6: symbol _dl_exception_create, version GLIBC_PRIVATE not defined in file ld-linux-aarch64.so.1 with link time reference
wc: relocation error: /initrd/cf/output_local/lib64/lib/libc.so.6: symbol _dl_exception_create, version GLIBC_PRIVATE not defined in file ld-linux-aarch64.so.1 with link time reference
-bash: [: -ge: unary operator expected

./lib64/bin/ls: relocation error: /initrd/cf/output_local/lib64/lib/libc.so.6: symbol _dl_starting_up version GLIBC_PRIVATE not defined in file ld-linux-aarch64.so.1 with link time reference

于是乎，使用查看了容器环境中glibc版本，打算重新编译ld-linux-aarch64.so.1链接器指向的动态库路径。在GNU官网下载了对应版本的源码，并配置了链接器指向的路径，步骤如下：

glibc-glibc-2.28
mkdir build
../configure  --prefix=/root  --disable-werror

将编译好的ld-linux-aarch64.so.1拷贝到设备上，再次使用ldd命令查看依赖库是否存在，这次终于所有依赖库都能找到，但是执行数据库初始化程序时报段错误。然后还是尝试更换了很多依赖库，查了一些资料，但是没有解决。

因为时间紧迫，这个方法也就没有再继续研究，使用了方法二。

方法二：使用`chroot`命令，改变根路径

chroot，即 change root directory (更改 root 目录)。在 linux 系统中，系统默认的目录结构都是以 /，即以根 (root) 开始的。而在使用 chroot 之后，系统的目录结构将以指定的位置作为 / 位置。

关于chroot的介绍和使用，可以看这篇博客，简洁明了

了解了chroot的基本原理后，使用就很简单了，导出步骤如下：

先在设备上构建docker环境，使openGauss能够正常运行，这一步骤前面已经讲过；
使用docker export导出容器的文件系统；
创建chroot目录，将导出的文件系统压缩包解压到想要运行的目录下；
和docker中一样，安装运行openGauss就可以了；

chroot运行还有一点需要注意，从docker中导出的文件系统是不包含系统运行时数据的，如/proc、/sys等目录都是空的，需要挂载宿主机目录，否则会报错，挂载目录如下：

mount -t proc proc/ proc/
mount -t sysfs sysfs sys
mount --rbind /dev dev/

成功挂载之后，数据库即可在本设备上运行。

qq_45705658

关注

17
点赞
踩
19

收藏

觉得还不错? 一键收藏
0
评论
记一次openGauss编译安装移植过程中踩到的坑

本文章从官方推荐的软硬件环境，编译移植到非推荐设备上，先是使用docker运行，然后脱离docker直接跑在系统上。主要记录了期间遇到几个问题。
复制链接

扫一扫