小编Her*_*ann的帖子

很多时候，尤其是在使用引导加载程序时，我会看到使用的数字驱动器和分区号。例如，在我的/boot/grub/grub.cfgI see 中set root='hd0,gpt2'，我的 UEFI 引导条目通常引用驱动器/分区编号，并且它似乎出现在几乎所有涉及引导加载程序的上下文中。

现在我们有了 UUID 和 PARTUUID，以这种方式寻址分区似乎非常不稳定（afaik，不能保证驱动器总是以相同的顺序安装，用户可能会移动插入其主板的驱动器的顺序，等等）

因此，我的问题是双重的：

这个寻址方案是否像我上面概述的那样不稳定？我是否遗漏了标准中的某些内容，这意味着该方案比我预期的要可靠得多，还是因为您的驱动器只是在不同的顺序或将它们插入主板上的不同插槽？
如果上述问题的答案是肯定的，那么为什么还要继续使用这种寻址方案？对所有内容使用 UUID 或 PARTUUID 会不会更加稳定和一致？

14
推荐指数

3
解决办法

2295
查看次数

我正在尝试自动化一个过程，该过程涉及通过 ssh 在各种机器上运行脚本。捕获输出和返回代码（用于检测错误）至关重要。

设置退出代码按预期工作：

~$ ssh host exit 5 && echo OK || echo FAIL
FAIL

但是，如果有 shell 脚本发出不干净的退出信号，ssh 总是返回 0（通过字符串执行模拟的脚本）：

~$ ssh host sh -c 'exit 5' && echo OK || echo FAIL
OK

在交互式 shell 中的主机上运行完全相同的脚本工作正常：

~$ sh -c 'exit 5' && echo OK || echo FAIL
FAIL

我很困惑为什么会发生这种情况。如何告诉 ssh 传播 bash 的返回码？我可能不会更改远程脚本。

我使用的是公钥认证，私钥是解锁的——不需要用户交互。所有系统都是 Ubuntu 18.04。应用程序版本是：

注意：这个问题与这些看似相似的问题不同：

7
推荐指数

2
解决办法

5573
查看次数

ssh ×1

小编Her_ann的帖子