问题[sles](unix)

我想glib2-devel通过一些安装脚本将软件包安装在 sles15 SP4 docker 容器中。

由于zypper install -y glib2-devel未安静安装，脚本失败。这是例外：

Problem: the to be installed glib2-devel-2.70.4-150400.1.5.aarch64 requires 'libglib-2_0-0 = 2.70.4', but this requirement cannot be provided
  not installable providers: libglib-2_0-0-2.70.4-150400.1.5.aarch64[SLE_BCI]
 Solution 1: downgrade of libglib-2_0-0-2.70.5-150400.3.3.1.aarch64 to libglib-2_0-0-2.70.4-150400.1.5.aarch64
 Solution 2: do not install glib2-devel-2.70.4-150400.1.5.aarch64
 Solution 3: break glib2-devel-2.70.4-150400.1.5.aarch64 by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): c

问题基本上是它想要一个从 1 到 3 的解决方案，但失败了，因为提供了标志 -y（我猜），因此选择取消选项 c。

这会导致 docker 容器失败。

有没有办法Solution 1在上述包的安静安装过程中进行选择？

我在 SLES 方面遇到了一个严重的支持问题，但没有取得任何可衡量的进展（几个月以来）。所以我想自己看一下源代码；也许我可以发现问题。

（似乎在 Xen Hypervisor 中的 SLES15 SP2 和 SP3 之间添加了一个致命错误，导致由于 RAM 损坏而导致服务器频繁崩溃）

如我所见，您可以下载应该包含源代码的 DVD 映像，但这些映像与媒体一样古老。含义：您没有当前补丁的来源。

是否有一个公共 Git 存储库，我可以在其中检查从发布到发布或从补丁到补丁所做的更改？我不想下载 ISO 映像，解压缩它们，下载更多 RPM 源包并解压缩它们等，只是为了查看更改。

我看到商业模式在某种程度上反对这一点，但从支持的角度来看，这是至关重要的。

是否有可能我会发出：

qemu-img convert -f qcow2 -O raw sles12_3_custom.qcow2 /dev/sda

而原来的 SLES11 正在运行？

所以我会用 SLES12.3 qcow2 映像覆盖 SLES11 操作系统，而它正在运行（机器中只有 sda）。

或者 SLES11 会在中途崩溃？

当 qemu-img 命令完成时，我会发出关机（而不是重新启动）

如果我停止 SLES11 上的所有服务，是否会增加成功覆盖的机会？例如：应用程序或日志记录等？并将 qcow2 映像放入 /dev/shm/?

奇怪的事情发生了：

通过 systemctl 我无法启动 SSHD：

SERVER:~ # systemctl status sshd
● sshd.service - OpenSSH Daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
   Active: inactive (dead)

May 29 18:31:38 linux-uw9h systemd[1]: Stopped OpenSSH Daemon.
May 29 18:45:19 SERVER systemd[1]: Stopped OpenSSH Daemon.
May 29 18:48:09 SERVER systemd[1]: Stopped OpenSSH Daemon.
May 29 19:04:23 SERVER systemd[1]: Stopped OpenSSH Daemon.
May 29 19:09:51 SERVER systemd[1]: Stopped OpenSSH Daemon.
May 29 19:11:22 SERVER systemd[1]: Stopped OpenSSH Daemon.
May 29 19:12:53 SERVER systemd[1]: Stopped OpenSSH Daemon.
May 29 19:13:58 SERVER systemd[1]: Stopped OpenSSH Daemon.
May 29 19:15:09 SERVER systemd[1]: Stopped OpenSSH Daemon.
May 29 19:24:41 SERVER systemd[1]: Stopped OpenSSH Daemon.
SERVER:~ #
SERVER:~ # systemctl restart sshd

...它只是挂起

但是如果我手动输入“/usr/sbin/sshd”，它就会开始很棒！

Q：如何调试这个问题？

SERVER:~ # rpm -qf /usr/sbin/sshd
openssh-7.2p2-74.16.3.x86_64
SERVER:~ # rpm -V openssh-7.2p2-74.16.3.x86_64
SERVER:~ # echo $?
0
SERVER:~ #

• dmesg 没什么特别的
• /var/log/* 没什么特别的
• journalctl -xe 没什么特别的
• -f openssh 中的 zypper 没有帮助
• 没有 FS 开启 100%
• 控制台不显示硬件问题
• 已经重启了两次
• 网络/IP 看起来不错，如果 SSHD 运行，则可以正常工作。
• 尝试“systemctl disable sshd”并启用它，但没有帮助。

就像 systemctl 无法启动它，但手动我可以..

SLES 12.3。

2019 年 5 月 30 日更新：

sshd.service 文件的 cksum 与其他工作节点上的相同：

SERVER:~ # cat /usr/lib/systemd/system/sshd.service
[Unit]
Description=OpenSSH Daemon
After=network.target

[Service]
Type=notify
EnvironmentFile=-/etc/sysconfig/ssh
ExecStartPre=/usr/sbin/sshd-gen-keys-start
ExecStartPre=/usr/sbin/sshd -t $SSHD_OPTS
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always
TasksMax=infinity

[Install]
WantedBy=multi-user.target
SERVER:~ # ls -lah /usr/lib/systemd/system/sshd.service
-rw-r--r-- 1 root root 361 Jan 30 15:46 /usr/lib/systemd/system/sshd.service
SERVER:~ #

在最坏的情况下，我将不得不每分钟放置一个 cronjob 来检查 sshd，所以如果 systemctl 不能，它会启动它。

2019 年 5 月 31 日更新：

SERVER:~ # strace systemctl restart sshd
execve("/usr/bin/systemctl", ["systemctl", "restart", "sshd"], [/* 57 vars */]) = 0
brk(0)                                  = 0x562494677000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=102550, ...}) = 0
...
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"l\4\1\1H\0\0\0\3\0\0\0\206\0\0\0\1\1o\0!\0\0\0", 24}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"/org/freedesktop/systemd1/job/22"..., 200}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 200
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\0012\0\0\0\4\0\0\0\17\0\0\0\5\1u\0\2\0\0\0", 24}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"\10\1g\0\1o\0\0-\0\0\0/org/freedesktop/sys"..., 58}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 58
sendmsg(3, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\4\0019\0\0\0\3\0\0\0\240\0\0\0\1\1o\0-\0\0\0/org/fre"..., 176}, {"\35\0\0\0org.freedesktop.systemd1.Uni"..., 57}], msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 233
recvmsg(3, 0x7ffc4c442360, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
ppoll([{fd=3, events=POLLIN}], 1, {24, 999977000}, NULL, 8) = 1 ([{fd=3, revents=POLLIN}], left {24, 999901280})
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\1\10\0\0\0\5\0\0\0\17\0\0\0\5\1u\0\3\0\0\0", 24}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"\10\1g\0\1v\0\0\1b\0\0\0\0\0\0", 16}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 16
recvmsg(3, 0x7ffc4c442410, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
ppoll([{fd=3, events=POLLIN}], 1, NULL, NULL, 8

它只是挂在这里..几个小时后按CTRL + C'ed。sshd 不是通过 systemctl 启动的，只能手动启动，奇怪

SERVER:~ # cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline, IBPB, STIBP, RSB filling - vulnerable module loaded
SERVER:~ #

问题：但是如何检测lsmod（？）中的哪个模块容易受到spectre_v2的攻击？SLES 12.3。

我尝试了默认保留期，例如将保留日期设置为 2071。当我执行 WORMing 时，一切似乎都正常。从 FUSE 和 Brick-Level 开始，所有节点上的保留时间都设置为 2071。此外，我启用了该storage.ctime选项，以便时间戳也存储在 mdata xattr. 但过了一会儿我观察到，在 Brick-Level 上 atime（存储保留）已切换到 1934：

stat /gluster/brick1/glusterbrick/data/file3.txt
  File: /gluster/brick1/glusterbrick/data/file3.txt
  Size: 5             Blocks: 16         IO Block: 4096   regular file
Device: 830h/2096d    Inode: 115         Links: 2
Access: (0544/-r-xr--r--)  Uid: ( 2000/    gluster)   Gid: ( 2000/
gluster)
Access: 1934-12-13 20:45:51.000000000 +0000
Modify: 2019-04-10 09:50:09.000000000 +0000
Change: 2019-04-10 10:13:39.703623917 +0000
 Birth: -

从保险丝我得到正确的时间：\

stat /gluster/volume1/data/file3.txt
  File: /gluster/volume1/data/file3.txt
  Size: 5             Blocks: 1          IO Block: 131072 regular file
Device: 2eh/46d    Inode: 10812026387234582248  Links: 1
Access: (0544/-r-xr--r--)  Uid: ( 2000/    gluster)   Gid: ( 2000/
gluster)
Access: 2071-01-19 03:14:07.000000000 +0000
Modify: 2019-04-10 09:50:09.000000000 +0000
Change: 2019-04-10 10:13:39.705341476 +0000
 Birth: -

我发现 XFS 仅支持 32 位时间戳值。因此，在我的预期中，应该不可能将其设置atime为 2071。但起初它是 2071，后来由于 YEAR-2038 的问题，它被切换到了 1934。我在问自己：
1.为什么可以atime在XFS上设置大于2038？
2. 为什么这atime会在一段时间后切换到 1970 年更低的时间？

我在 SLES15 机器上完成了所有工作。xfsprogs 是 4.15 版，Gluster 是 v5.5

问题：

SERVER:~ # systemctl start kdump.service
Job for kdump.service failed because the control process exited with error code. See "systemctl status kdump.service" and "journalctl -xe" for details.
SERVER:~ # systemctl status kdump.service
● kdump.service - Load kdump kernel on startup
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2018-10-17 12:29:34 EDT; 1s ago
  Process: 59804 ExecStart=/lib/kdump/load.sh (code=exited, status=1/FAILURE)
 Main PID: 59804 (code=exited, status=1/FAILURE)

Oct 17 12:29:33 SERVER systemd[1]: Starting Load kdump kernel on startup...
Oct 17 12:29:34 SERVER load.sh[59804]: kexec_file_load failed: Cannot assign requested address
Oct 17 12:29:34 SERVER systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE
Oct 17 12:29:34 SERVER systemd[1]: Failed to start Load kdump kernel on startup.
Oct 17 12:29:34 SERVER systemd[1]: kdump.service: Unit entered failed state.
Oct 17 12:29:34 SERVER systemd[1]: kdump.service: Failed with result 'exit-code'.
SERVER:~ # 

日志：

SERVER:~ # tail /var/log/messages
2018-10-17T12:29:33.980232-04:00 SERVER systemd[1]: Starting Load kdump kernel on startup...
2018-10-17T12:29:34.133151-04:00 SERVER kdump[59974]: FAILED to load kdump kernel: /sbin/kexec -p /boot/vmlinuz-4.4.121-92.80-default --append="quiet console=tty0 console=ttyS0,9600 elevator=noop transparent_hugepage=never numa_balancing=disable intel_idle.max_cstate=1 elevator=deadline sysrq=yes reset_devices acpi_no_memhotplug cgroup_disable=memory irqpoll nr_cpus=1 root=kdump rootflags=bind rd.udev.children-max=8 disable_cpu_apicid=0   panic=1" --initrd=/boot/initrd-4.4.121-92.80-default-kdump  -s, Result: kexec_file_load failed: Cannot assign requested address
2018-10-17T12:29:34.133560-04:00 SERVER load.sh[59804]: kexec_file_load failed: Cannot assign requested address
2018-10-17T12:29:34.133726-04:00 SERVER systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE
2018-10-17T12:29:34.133958-04:00 SERVER systemd[1]: Failed to start Load kdump kernel on startup.
2018-10-17T12:29:34.134105-04:00 SERVER systemd[1]: kdump.service: Unit entered failed state.
2018-10-17T12:29:34.134233-04:00 SERVER systemd[1]: kdump.service: Failed with result 'exit-code'.
SERVER:~ #

版本信息：

SERVER:~ # rpm -qa|grep -i kdump
yast2-kdump-3.1.44-11.6.15.x86_64
kdump-0.8.15-28.5.x86_64
SERVER:~ # uname -a
Linux SERVER 4.4.121-92.80-default #1 SMP Mon May 21 14:40:10 UTC 2018 (2afdd00) x86_64 x86_64 x86_64 GNU/Linux
SERVER:~ #
SERVER:~ # cat /etc/SuSE-release
SUSE Linux Enterprise Server 12 (x86_64)
VERSION = 12
PATCHLEVEL = 2
# This file is deprecated and will be removed in a future service pack or release.
# Please check /etc/os-release for details about this release.
SERVER:~ #

问题：为什么kdump.service 不能启动？我错过了什么？

AFAIK SLES 12 不需要 kernel-kdump 包还是我错了？如果是，我可以从哪里获得 kernel-kdump 包？

基于https://distrowatch.com/table-mobile.php?distribution=sle&pkglist=true&version=12-sp2 kdump 版本看起来不错。

2018 年 12 月 5 日更新：

• rpm -V kdump-0.8.15-28.5.x86_64；回声$？-> 它是 0，没关系

• 我找到了一台具有相同内核版本的机器，但是在那里，kdump 可以工作！但是找不到健康与这个坏主机之间的区别..

• 试图替换 initrd，但没有帮助。

• 尝试重新安装 kdump，没有帮助： rpm -e yast2-kdump; rpm -e kdump；kdump 中的 zypper

• 尝试执行“systemctl unmask kdump；systemctl enable kdump；systemctl restart kdump”和“systemctl daemon-reload”，没有帮助。

2018 年 12 月 7 日更新：

cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.4.121-92.80-default root=/dev/mapper/vg00-lv_root splash=silent quiet showopts console=tty0 console=ttyS0,9600 elevator=noop transparent_hugepage=never crashkernel=768M numa_balancing=disable intel_idle.max_cstate=1

2018 年 12 月 11 日更新：从无法启动 kdump 的节点发布 /proc/iomem：

SERVER:~ # cat /proc/iomem
00000000-00000fff : reserved
00001000-0009bfff : System RAM
0009c000-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000c0000-000c7fff : Video ROM
000cd800-000d53ff : Adapter ROM
000e0000-000fffff : reserved
  000f0000-000fffff : System ROM
00100000-5eeb0fff : System RAM
  01000000-015fbb30 : Kernel code
  015fbb31-01d59b7f : Kernel data
  01f6b000-021e8fff : Kernel bss
5eeb1000-66eb8fff : reserved
66eb9000-6a733fff : System RAM
6a734000-6a742fff : reserved
6a743000-6a743fff : System RAM
6a744000-7a7c4fff : reserved
7a7c5000-7cc82fff : System RAM
7cc83000-7ccb4fff : reserved
7ccb5000-a41b7fff : System RAM
a41b8000-b93fefff : reserved
b93ff000-bb3fefff : ACPI Non-volatile Storage
bb3ff000-bb7fefff : ACPI Tables
bb7ff000-bb7fffff : System RAM
bb800000-cfffffff : reserved
  c0000000-cfffffff : PCI MMCONFIG 0000 [bus 00-ff]
d0000000-e7ffbfff : PCI Bus 0000:00
  d0000000-d01fffff : PCI Bus 0000:06
    d0000000-d00fffff : 0000:06:00.0
    d0100000-d01fffff : 0000:06:00.1
  d0200000-d020ffff : 0000:00:11.0
  d03fc000-d03fcfff : 0000:00:05.4
  d03fe000-d03fe3ff : 0000:00:1a.0
    d03fe000-d03fe3ff : ehci_hcd
  d03ff000-d03ff3ff : 0000:00:1d.0
    d03ff000-d03ff3ff : ehci_hcd
  d0400000-d05fffff : PCI Bus 0000:0b
    d04f0000-d04fffff : 0000:0b:00.0
      d04f0000-d04fffff : megasas: LSI
    d0500000-d05fffff : 0000:0b:00.0
  d0600000-d0ffffff : PCI Bus 0000:11
    d0600000-d0ffffff : PCI Bus 0000:12
      d0600000-d06fffff : PCI Bus 0000:15
        d06fe000-d06fefff : 0000:15:00.0
        d06ff000-d06fffff : 0000:15:00.0
      d0700000-d0ffffff : PCI Bus 0000:13
        d0700000-d0ffffff : PCI Bus 0000:14
          d07fc000-d07fffff : 0000:14:00.0
          d07fc000-d07fffff : mgadrmfb_mmio
          d0800000-d0ffffff : 0000:14:00.0
  d1000000-d1ffffff : PCI Bus 0000:11
    d1000000-d1ffffff : PCI Bus 0000:12
      d1000000-d1ffffff : PCI Bus 0000:13
        d1000000-d1ffffff : PCI Bus 0000:14
          d1000000-d1ffffff : 0000:14:00.0
          d1000000-d1ffffff : mgadrmfb_vram
  d2000000-d5ffffff : PCI Bus 0000:06
    d2000000-d3ffffff : 0000:06:00.0
      d2000000-d3ffffff : mlx5_core
    d4000000-d5ffffff : 0000:06:00.1
      d4000000-d5ffffff : mlx5_core
e7ffc000-e7ffcfff : dmar1
e8000000-fbffbfff : PCI Bus 0000:80
  e8000000-e81fffff : PCI Bus 0000:81
    e8000000-e80fffff : 0000:81:00.0
    e8100000-e81fffff : 0000:81:00.1
  e9fff000-e9ffffff : 0000:80:05.4
  ea000000-edffffff : PCI Bus 0000:81
    ea000000-ebffffff : 0000:81:00.0
      ea000000-ebffffff : mlx5_core
    ec000000-edffffff : 0000:81:00.1
      ec000000-edffffff : mlx5_core
fbffc000-fbffcfff : dmar0
fec00000-fecfffff : PNP0003:00
  fec00000-fec003ff : IOAPIC 0
  fec01000-fec013ff : IOAPIC 1
  fec40000-fec403ff : IOAPIC 2
fed00000-fed003ff : HPET 0
  fed00000-fed003ff : PNP0103:00
fed12000-fed1200f : pnp 00:01
fed12010-fed1201f : pnp 00:01
fed1b000-fed1bfff : pnp 00:01
fed1c000-fed1ffff : reserved
  fed1f410-fed1f414 : iTCO_wdt.0.auto
fed45000-fed8bfff : pnp 00:01
fee00000-feefffff : pnp 00:01
  fee00000-fee00fff : Local APIC
ff000000-ffffffff : reserved
  ff000000-ffffffff : pnp 00:01
100000000-1003fffffff : System RAM
38000000000-3bfffffffff : PCI Bus 0000:00
  38000000000-38000000fff : 0000:00:1f.6
  3800000c000-3800000c00f : 0000:00:16.0
  3800000d000-3800000d00f : 0000:00:16.1
  3800000e000-3800000e0ff : 0000:00:1f.3
  38000010000-3800001ffff : 0000:00:14.0
    38000010000-3800001ffff : xhci-hcd
3c000000000-3ffffffffff : PCI Bus 0000:80
SERVER:~ #

我试过了：

cpupower frequency-set -g performance

但是，频率仍然只有 1200 MHz。

只有当我在机器上加载负载时它才会上升，但它应该始终以 100% 的 cpu 频率运行。

使用 SLES 12.2。

SERVER:~ # cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.4.121-92.80-default root=/dev/mapper/vg00-lv_root splash=silent quiet showopts console=tty0 console=ttyS0,9600 elevator=noop transparent_hugepage=never crashkernel=768M numa_balancing=disable intel_idle.max_cstate=1
SERVER:~ #

我错过了什么？

如果可能是某些 UEFI 设置，是否有任何命令，例如：asu64 无需重启即可更新 UEFI 设置？

机器是“x3850 X6”，CPU 是：“Xeon(R) CPU E7-8880 v4 @ 2.20GHz”。

更新#1：找到了一些东西，也许是：

SERVER:~ # systemctl start cpupower
Failed to start cpupower.service: Unit cpupower.service failed to load: No such file or directory.
SERVER:~ # echo $?
5
SERVER:~ #
SERVER:~ # systemctl status cpupower
? cpupower.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
SERVER:~ #

更新#1 的更新：我遵循了https://www.suse.com/support/kb/doc/?id=7021316但没有帮助。

更新#2：尝试设置频率但没有帮助。

SERVER:~ # lscpu | awk '/Model name:/{print $NF}'
2.20GHz
SERVER:~ # cpupower frequency-set -u 2.20GHz
...
SERVER:~ # cpupower frequency-set -u 2.2GHz
...
SERVER:~ # lscpu |egrep  "CPU MHz|CPU(s)" | awk '{print $3}' | awk -F "." '{print $1}'
1200
SERVER:~ #

在新安装的 SLES 11.4 上，我们从 /var/crash 中看到了这个 dmesg：

<7>[   48.600847] storage: no IPv6 routers present
<6>[   63.725477] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
<6>[  310.226578] [Hardware Error]: Machine check events logged
<6>[ 3536.417543] lp: driver loaded but no devices found
<6>[ 3536.417582] ppdev: user-space parallel port driver
<6>[ 3536.983736] lp: driver loaded but no devices found
<6>[ 3537.005660] Uniform Multi-Platform E-IDE driver
<6>[ 3537.011756] ide-cd driver 5.00
<6>[ 3537.033960] st: Version 20101219, fixed bufsize 32768, s/g segs 256
<0>[ 3691.340041] Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 9
<4>[ 3691.447069] Pid: 0, comm: kworker/0:1 Tainted: G             X 3.0.101-107-default #1
<4>[ 3691.554690] Call Trace:
<4>[ 3691.590254]  [<ffffffff81004b35>] dump_trace+0x75/0x300
<4>[ 3691.664599]  [<ffffffff81467873>] dump_stack+0x69/0x6f
<4>[ 3691.738878]  [<ffffffff8146792f>] panic+0xb6/0x224
<4>[ 3691.804367]  [<ffffffff810c900c>] watchdog_overflow_callback+0xdc/0xe0
<4>[ 3691.896736]  [<ffffffff810f55fa>] __perf_event_overflow+0xaa/0x230
<4>[ 3691.980294]  [<ffffffff81018808>] intel_pmu_handle_irq+0x1a8/0x370
<4>[ 3692.069469]  [<ffffffff8146c8f1>] perf_event_nmi_handler+0x31/0xa0
<4>[ 3692.156027]  [<ffffffff8146ea47>] notifier_call_chain+0x37/0x70
<4>[ 3692.239630]  [<ffffffff8146ea8d>] __atomic_notifier_call_chain+0xd/0x20
<4>[ 3692.334749]  [<ffffffff8146eadd>] notify_die+0x2d/0x40
<4>[ 3692.409254]  [<ffffffff8146c073>] default_do_nmi+0x33/0xc0
<4>[ 3692.489610]  [<ffffffff8146c168>] do_nmi+0x68/0x80
<4>[ 3692.558033]  [<ffffffff8146b595>] restart_nmi+0x1e/0x2e

重新安装它以检查它是硬件问题还是软件问题，但是当我们运行 DSA 日志时它仍然崩溃（开始于约 3500 秒的正常运行时间）。

问题：从这个 dmesg（或任何其他信息）中，我们可以确定导致崩溃的原因是什么？cpu9错误？或驱动程序错误？

我有一个具有 NFS 挂载 /FOO 的服务器“A”。

我在服务器“A”上设置了 NFS 服务器来导出 NFS 挂载 /FOO。

我有其他服务器：“B”。但我无法从服务器“A”挂载 /FOO - 可能是因为它已经是 NFS 挂载。

我可以在服务器“A”上导出本地目录，但不能导出 NFS 挂载。

操作系统是 SLES 11。

问题：如何通过 NFS 将 NFS 挂载导出到其他服务器？:)