服务器评测
在 IBM? System z 机器上启动 Linux? 非常简单，但也很容易出现问题。如果在 S/390 系统上启动 Linux 遇到难以解决的问题时，可以尝试考虑以下方面：显示消息 “未知路由”、不良网络服务行为、关机时造成文件系统损坏、冗长的引导-路径-设备过程和虚拟 LAN 硬件安装。额外收获：关于 SUSE bug 的警告（和解决办法）。
在 IBM S/390 平台（即 System z）上使用 Linux 操作系统是非常有用的，因为它增强了遗留应用程序、Linux 应用程序和中间件应用程序（比如 Web、邮件、应用服务器和防火墙等）之间的连接性。通过作为 “本地” 操作系统，Linux 可以利用 S/390 平台的所有硬件功能。
本文分享 5 个故障排除技巧，帮助您解决在 System z 系列机器上启动 Linux 系统时遇到的各种问题：
1.战胜火星人入侵：火星消息（Martians message）即路由来源不明的包。
2.在重启时调整网络服务：在 LPAR 上启动 Linux 映像时，网络服务可能不按预期工作。
3.在关机时避免损坏文件系统：有 3 种关机方式会导致文件系统损坏。
4.尽量使用 cio_ignore：或如何减少 “必须进行探测和分析” 的引导路径设备。
5.避免虚拟 LAN 带来麻烦：查找物理 安装文件。
本文引用了不同版本的 SUSE Linux，因此我将简单介绍不同版本的 SUSE 上的一些 bug，并为解决这些 bug 提供权宜之计。
1. 火星人与人类遭遇
“火星人”（Martian）是指路由来源不明的包。Linux 系统不欢迎这种包，尤其是考虑到它的来源时（比如通过外部接口进入内部主机的包）。
配置错误（比如将外部地址分配给 LAN 接口）、屏蔽问题或地址欺骗（他人试图入侵系统）都会导致火星消息入侵。必须检查并纠正配置，避免火星消息的入侵。
这些消息有时来自交换机，因为同一个交换机上连接许多不同的机器。在这种情况下，火星消息可能不是恶意的，但它们仍然可能大量占用操作系统消息控制台。为了避免这种消息，必须重启交换机；但是要记住，这个操作会影响到该交换机上的其他机器。该操作对一些重要的服务器损害非常大。
问题：操作系统消息控制台压力过大
操作系统消息控制台的调试可能会非常困难，因为您必须处理铺天盖地的火星消息（如图 1 所示）：
图 1. 火星消息充斥消息控制台
解决办法：隐藏 “绿色小矮人”
为了隐藏火星消息以获得更加干净的系统控制台，可以：
关闭包日志记录：
/proc/sys/net/ipv4/conf/eth0/log_martians
Ex: echo “0” > /proc/sys/net/ipv4/conf/eth0/log_martians
将内核日志记录调至级别 4：
yast -> system -> /etc/sysconfig Editor -> System -> Logging -> KERNEL_LOGLEVEL (7 to 4)
2. 潜在不良网络服务
在 LPAR 上启动 Linux 映像时，您可能会发现网络服务不能按预期工作；尽管分配了 IP 地址，网络仍然不能访问。
问题：ping 没问题，但无法登录
从操作系统消息控制台 ping 其他机器没有任何问题，并且 ipconfig 命令显示正确的信息，但通过 putty 登录（ssh/telnet）时，会话不成功。
解决办法：重启网络
根用户可以在操作系统消息控制台上使用命令 service network restart 重启网络，如清单 1 所示。
清单 1. 重启服务网络的输出
j8806_h117 (root): /opt/javabm/data >service network restart
Shutting down network interfaces:
eth0
eth0 configuration: qeth-bus-ccw-0.0.0420 done
Shutting down service network . . . . . . . . . . . . . done
Hint: you may set mandatory devices in /etc/sysconfig/network/config
Setting up network interfaces:
lo
lo IP address: 127.0.0.1/8 done
eth0
eth0 configuration: qeth-bus-ccw-0.0.0420
eth0 IP address: 9.12.22.25/24 done
vlan538
interface is not available
SIOCGIFFLAGS: No such device
Cannot enable interface vlan538.
interface vlan538 is not up failed
Setting up service network . . . . . . . . . . . . . . failed
SuSEfirewall2: Warning: ip6tables does not support state matching.
Extended IPv6 support disabled.
SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 …
SuSEfirewall2: batch committing…
SuSEfirewall2: Firewall rules successfully set
只有根用户能够发出这个命令。如果发现网关错误或丢失，则需要包含所需的细节来重启网络。这可以通过以下命令实现：
1.route add default gw 9.12.44.1
2.service network restart
清单 1 的输出显示了关闭和重启网络的所有步骤。如果网络无效，输出中就不会显示 IP 地址。IP 地址在文件 /etc/sysconfig/network/ifcfg-eth-id-XX:XX:XX:XX:XX 中定义 — 它显示 VLAN 配置和防火墙设置。如果网络出现问题，您可以使用这个输出检查所有步骤。
为了使更新信息在所有网络配置文件中生效（/etc/sysconfig/network/ifcfg-eth-id-XX:XX:XX:XX:XX，/etc/sysconfig/hardware/ifcfg-eth-id-XX:XX:XX:XX:XX 等），必须发出命令 service network restart（或 /etc/init.d/network restart）。
3. 文件系统损坏
有时在关闭系统的过程中可能会损坏文件系统，常见原因有：
没有正确停止 Linux 映像
没有正确卸载文件系统
根文件系统全部用完
在这些情况中，在下一次引导系统时不可能再成功启动同样的映像。
问题：是否出现登录提示
让我们看看两个文件系统损坏的场景：
1.根文件系统（/dev/dasda1）本身损坏。在这种情况下，操作系统信息控制台上不显示登录提示。
2.其他文件系统损坏，而不是根文件系统。在这种情况下，显示登录提示，并且仅装载正常的文件系统。
解决办法：无条件启用 fsck
运行 fsck 就能够解决这两个场景中出现的问题。如下所示：
1.对于第一个场景，可以在现有的 Linux 映像上在线启动根文件系统（使用命令 chccwdev -e <DASD address>），然后强制运行 fsck。这将强制检查文件系统，而不管它是否正常。例如：fsck -f /dev/dasdx1（其中 x 表示 fsck 针对其运行的、最新添加的 dasd 的设备盘符）。
2.在第二个场景中，成功登录之后通过操作系统消息控制台在损坏的文件系统上运行命令 fsck。 当 fsck 在所有损坏的 DASD 上运行时，必须重启系统。下一次重新引导时，该映像将成功启动。
4. 设备越少启动越快
cio_ignore 参数是一个内核参数，用于指定和分析附加到机器的所有可用设备。当开始引导 Linux 时，它将探测和分析所有可用的设备。
您可以使用 cio_ignore 来减少引导时需要探测和分析的设备。
问题：设备列表过多
在 System z 上，映像启动比较慢，由于机器附加有许多的设备（比如 DASD 和网络设备等），所以必须加载多个不同的映像。不管哪个映像使用这些设备，系统都会在引导时探测和分析每个设备，这导致引导过程比较慢。
解决办法：注释掉一些设备
在这种情况下，对于当前映像不使用的设备，可以在 zipl.conf 文件中定义这些设备的范围。这样，将忽略所有在 zipl.conf 文件中定义的设备，因此系统能够快速引导。为了实现这个目的，您需要运行：
cio_ignore=all：指定所有需要忽略的设备。
cio_ignore=all, !0.0.b100-0.0.b1ff, !0.0.a100：指定所有需要忽略的设备，但在 0.0.b100 到 0.0.b1ff 范围之内的设备和设备 0.0.a100 除外（定制能力非常强）。
5. 找到虚拟 LAN 的物理文件
虚拟 LAN 是在一个或多个 LAN 上的一组设备。由于使用管理软件将这些 LAN 设置为可通信的，因此它们好像被附加到同一物理连接（事实上，它们分布在大量不同的 LAN 区段上）。
由于它们基于逻辑连接（而不是物理连接），所以 VLAN 是非常灵活的。VLAN 框架几乎与以太框架一样；惟一的区别是 VLAN 框架有一个额外的字段，其中包含一个用于识别 VLAN 的号码。这个号码称为 VLAN 标记。
问题：在现实中标记位于何处？
第一次在 System z 机器上安装 Linux（SUSE 或 RedHat）时，如果该 Linux 配置为使用 VLAN 而不支持访问非 VLAN 的 OSA 端口（针对 System z 的以太网卡），那么安装就不会成功。
如果是在 LPAR 上安装新的 Linux（SUSE），则必须通过网络进行安装。您必须将 LPAR（z 机器）准确地连接到提供安装文件的服务器。安装之前将要求您提供各种类型的信息，以设置网络。这些提示信息并不告诉您如何设置才能在使用 VLAN 配置的 LAN 区段上工作。如果机器（z 服务器）已经带有 VLAN 标记，它将仅查找具有特定 VLAN 标记信息的包。
解决办法：先安装再配置
SUSE 和 RedHat 发行版都不支持在安装期间从网络接口设置 VLAN，因此惟一的解决办法就是先使用有效的非 VLAN 网络安装系统，然后将它配置为支持 VLAN。
在新的安装中，必须使用不带 VLAN 标记的硬件。安装期间，硬件不应配置为支持 VLAN。
额外收获：两个 SUSE bug
最后，您需要注意两个与 SUSE 相关的 bug。
Bug 1：某些 SLES9 中出现的 VLAN 标记问题
第一个 bug 出现在非常老的 GA 级别的内核 SLES9 上 — 带有 VLAN 标记的硬件不用担心这个 bug。该 bug 会导致内核失灵（系统将一个错误消息输出到控制台，并将内核内存的映像转储到磁盘供以后调试使用，然后要么等待手动重新引导系统，要么进行自动重新引导）。SLES9 SP4 内核不会出现这种情况。
Bug 2：SLES10 中出现 Awk 脚本错误
在 SLES10 和 SLES10 SP2 中执行 Awk 脚本将导致以下错误：
清单 2. 在 SLES10 和 SLES10 SP2 中执行 Awk 脚本
rapdistro7:~ # awk -f sample_test.awk get_build.messages
section 1
*** glibc detected *** awk: double free or corruption (fasttop):
0x0000000080055060 ***
======= Backtrace: =========
……
======= Memory map: ========
……
3ffff952000-3ffff967000 rw-p 3ffff952000 00:00 0
[stack]
Aborted
rapdistro7:~ #
这个脚本在 SLES9 表现正常。bugzilla 上已经报告这个 bug 导致的问题。另外，您可以使用 export LC_ALL = C 解决这个问题。SLES10/SP2 之后的内核版本修复了这个 bug。
