Ошибка при сборке ядра 2.6.32-754.18.2 - Сбой самотестирования / usr / lib64 / hmaccalc - PullRequest
0 голосов
/ 10 февраля 2020

Я собираю ядро ​​rpm версии 2.6.32-754.18.2, которое не работает с сообщением «SELF TEST FAILED». Я попытался исследовать дальше и обнаружил, что либо есть какие-то возможности с разрешениями, либо это проблема предварительной ссылки.

Я пытаюсь собрать ядро ​​с пользователем, не являющимся root.

:

+ sha512hmac /scratchpad/workdirs/NeoUser/build/RPM/BUILDROOT/kernel-2.6.32-754.18.2.el6test1 .x86_64/boot/vmlinuz-2.6.32-754.18.2.el6test1.x86_64
+ sed -e s,/scratchpad/workdirs/NeoUser/build/RPM/BUILDROOT/kernel-2.6.32-754.18.2.el6test1.x 86_64
SELF TEST FAILED (/usr/lib64/hmaccalc/sha512hmac.hmac)

Чтобы найти найденное здесь исправление (конец страницы), в котором упоминается, что / tmp следует монтировать как 'exe c', а не 'noexe c 'и мой fstab имеет записи' tmp ', такие как:

/dev/mapper/vgroot-plat_tmp /tmp ext4 defaults 1 2
tmpfs /dev/shm tmpfs defaults 0 0

Если я не ошибаюсь, tmpfs / dev / shm означает, что он занимает место из оперативной памяти. Какое редактирование мне следует сделать здесь так, чтобы tmp использовал exe c как опцию, и я могу использовать его для сборки своего RPM.

Я попытался отредактировать разрешения tmp, но он не работает, предполагая, что мой fstab все еще правильно.

Также я читаю блог, в котором предлагалось использовать: '/ usr / sbin / prelink -av –mR', но команда генерирует огромный вывод со следующими строками:

/usr/sbin/prelink: /usr/lib64/librpm.so.1.0.0 has a dependency cycle
Laying out 4 libraries in virtual address space 0000003000000000-0000004000000000
Random base 0x00000038e7600000
Assigned virtual address space slots for 64-bit x86-64 ELF libraries:
/lib64/ld-linux-x86-64.so.2                                  0000003930a00000-0000003930c22190
/lib64/libaio.so.1                                           0000003930e00000-0000003931000a80
/lib64/libc.so.6                                             0000003931200000-0000003931593928
...