☰

图像完整！！

tag-icon • tag-icon linux java boot daemon runlevel
图像完整！！

请发表您的想法或任何您想到的东西。我很想知道其他人的想法。

总体问题

当我通过 /etc/init.d/ 安装一个简单的 Java 应用程序（我编写的）以在启动时（在后台）运行时，它可以在我明确安装它的 liveUSB 上运行。当我复制该记忆棒时，它从未成功启动。在启动 liveUSB 副本时，当 liveUSB 启动过程到达我的脚本时，Java 应用程序将始终挂起。我的脚本确实做了它应该做的事情，甚至每 5 分钟一次，并且将一直运行，直到您关闭机器。

  1. 我的脚本阻止了其他所有脚本
  2. 脚本之外的内容均无法加载
  3. 你不能取消我的脚本
  4. 没有 GUI
  5. 您唯一能看到的文本是我的脚本的命令行输出

设置与测试- 一切顺利 ：）

我有一个带有 3 个分区的 Linux liveUSB。已加载简单的标准 Xubuntu 映像。

  • sda1 > 2gb 存储
  • sda2 > 2gb 系统
  • sda3 > Casper 剩余的 GB

我创建了一个简单的 Java 应用程序，它在启动时在后台运行。为了实现这一点，我遵循了以下步骤：

  1. 将 Java 应用程序编译成类
  2. 将类文件放在 /home/user/folder/ 中
  3. 将我的 startup.sh 脚本复制到 /etc/init.d/
  4. 在 /etc/init.d/ 内部
    • 输入“update-rc.d startup.sh start 20 2 5 . stop 20 0 1 6 ”。
    • 成功更新运行级别
  5. 现在我可以重新启动/重启/关闭任何操作，一切都运行正常！

副本——这就是事情变得棘手的地方！

创建此棒的副本时，我遵循以下步骤：

  1. 挂载 sda2
    • 将所有内容从该文件​​夹复制到 /home/user/Desktop/tmp-system/
  2. 挂载 sda3
    • 将该文件夹中的所有内容复制到 /home/user/Desktop/tmp-casper/
  3. 进入 /home/user/Desktop/tmp-system/
    • 输入“tar -cvf system.tar”。
  4. 进入 /home/user/Desktop/tmp-casper/
    • 输入“tar -cvf casper.tar”。
  5. 卸载
    • sda2
    • sda3
  6. 插入空的 USB（例如 sdb）
    • 设置分区（与您要复制的磁盘相同）
    • 解压到各个分区
      • tar -xvf system.tar ... 进入 sdb2
      • tar -xvf casper.tar ... 进入 sdb3

测试- 一切都出错了！

  1. 将新创建的 liveUSB 插入计算机
  2. 从 USB 启动
  3. 一切开始正常启动
  4. 我编写的 Java 应用程序被触发
    • 启动过程永远挂起
    • 没有可用的 cmd 提示符
    • 没有可用的 GUI
    • 就像线程正在运行一样（确实如此！每 5 分钟可以查看一次输出 - 这正是应该的方式）

解决方案尝试和陷阱

1

我可以挂载复制的 liveUSB，编辑 startup.sh 以不启动我的 Java 应用程序，但它仍然无法启动（正如我所怀疑的那样？）。

2

如果我使用“dd if=sda of=sdb”，liveUSB 的复制将完全正常工作。然而，这不是一个可接受的解决方案。如果我使用 dd 将 16gb 的棒复制到 64gb 的棒，这会将 64gb 的棒变成 16gb。这也会使更改每个分区中需要更改的值变得更加困难。

3

测试了 startup.sh 和 Java 应用程序本身的多种变体。所有这些都会产生相同的错误。

4

我用来复制的方法适用于所有其他形式的应用程序、文件或其他任何东西。

5

我还想尝试避免使用任何额外的库或程序来帮助运行 Java 应用程序。

6

我还安装了 sda2 和 sdb2，使用 cp 将所有内容直接从一个复制到另一个，然后对 sda3 和 sdb3 执行相同操作。这会产生相同的错误。

附加点

  1. sda3 分区使用 cryptsetup 加密
  2. system.tar 中有 2 个文件（将是 sdb2，来自 sda2），在写入 USB 后它们的值将会发生变化。
    • 这两个值在过去没有引起任何问题，并且每次创建新的 liveUSB 时都会更改
  3. casper.tar 中有 1 个文件（将是 sdb3，来自 sda3），其值在写入 USB 后会发生变化。
    • 此值在过去没有引起任何问题，并且随着每个新的 liveUSB 的创建而不断改变。

校验和测试过程

原始 liveUSB 图像

工作 liveUSB > sda 空 usb > sdb

脚步：

  1. 挂载、复制并校验 sda2
    • 输入“mount /dev/sda2 /media/sda2”
    • 输入“tar -C /media/sda2 -cvf ~/Desktop/system.tar ”。
    • 输入“find . -type f -exec sha1sum {} ';' > /tmp/sda2_checksum.txt”
    • 输入“umount /media/sda2”
  2. 挂载、复制并校验 sda3
    • 输入“mount /dev/sda3 /media/sda3”
    • 输入“tar -C /media/sda3 -cvf ~/Desktop/casper.tar”。
    • 输入“find . -type f -exec sha1sum {} ';' > /tmp/sda3_checksum.txt”
    • 输入“umount /media/sda3”
  3. 为sdb创建分区
  4. 挂载、写入并校验 sdb2
    • 输入“mount /dev/sdb2 /media/sdb2”
    • 输入“tar -C /media/sdb2 -xvf ~/Desktop/system.tar”
    • 输入“find . -type f -exec sha1sum {} ';' > /tmp/sdb2_checksum.txt”
    • 输入“umount /media/sdb2”
  5. 挂载、写入并校验 sdb3
    • 输入“mount /dev/sdb3 /media/sdb3”
    • 输入“tar -C /media/sdb3 -xvf ~/Desktop/casper.tar”
    • 输入“find . -type f -exec sha1sum {} ';' > /tmp/sdb3_checksum.txt”
    • 输入“umount /media/sdb3”
  6. 比较校验和
    • 排序 /tmp/sda2_checksum.txt -o /tmp/sda2_checksum.txt.sort
    • 排序 /tmp/sda3_checksum.txt -o /tmp/sda3_checksum.txt.sort
    • 排序 /tmp/sdb2_checksum.txt -o /tmp/sdb2_checksum.txt.sort
    • 排序 /tmp/sdb3_checksum.txt -o /tmp/sdb3_checksum.txt.sort
  7. 结果

sda2 和 sdb2

输入“diff sda2_checksum.txt.sort sdb2_checksum.txt.sort”

45d44
< 2ddf9802c9c15ac6e4575cc9de32e3530eae6b7d  ./efi/boot/grub.cfg
82d80
< 59bb2775a8e7e499e0590b7b8c2492eb250fb7d8  ./syslinux/txt.cfg
154a153
> ae6c127713e01fc5fb4a2e4e28f6bbddc6bd6af5  ./efi/boot/grub.cfg
158a158
> b78090b66b4e3fa04ca9d466ee78c9060adf744e  ./syslinux/txt.cfg

这两个文件各包含 1 个更改的值。其他内容相同。结果正是应有的。

sda3 和 sdb3

输入“diff sda3_checksum.txt.sort sdb3_checksum.txt.sort”

相同——请记住这是原始的 liveUSB 图像。

我将在下一部分中发布进一步的比较结果。

下一步——又称行动计划

从 liveUSB 映像启动，无需运行脚本。

步骤1- 成功 / 失败？

成功 - 校验和匹配

  1. 将 liveUSB 上的 Java 从 6 更新至 7
  2. 重新创建 tar
  3. 从 tar 创建新的 liveUSB
  4. 测试 liveUSB

第2步- 成功 / 失败？

成功 - 校验和匹配

  1. 创建 /home/user/folder/
  2. 将 Java 应用程序的类文件复制到 /home/user/folder/
  3. 重新创建 tar
  4. 从 tar 创建新的 liveUSB
  5. 测试 liveUSB

步骤3- 成功 / 失败？

成功 - 校验和匹配

  1. 将startup.sh添加到/etc/init.d/
  2. 无需调用 update-rc.d
  3. 重新创建 tar
  4. 从 tar 创建新的 liveUSB
  5. 测试 liveUSB

步骤4- 成功 / 失败？

成功 - 校验和匹配

（我之前从来没有成功做到过这么远）——但是需要写入的值尚未插入到 casper（sda3）分区中。

  1. 输入“update-rc.d startup.sh start 21 2 5”。
  2. 重新创建 tar
  3. 从 tar 创建新的 liveUSB
  4. 测试 liveUSB

步骤5- 成功 / 失败？

成功 - 校验和匹配

我简直不敢相信这竟然有效！这让我想到……（用好听的话说）为什么以前它不起作用？

— 巧合的是，版本 13 起作用了。

  1. 启动 liveUSB
  2. 在创建 tar 之前，在 casper（sda3）中插入要覆盖的值
    • 从 liveUSB 运行时
    • 编辑 /home/user/folder/config.properties 中的配置文件
  3. 关闭 liveUSB
  4. 重新创建 tar
  5. 从 tar 创建新的 liveUSB
  6. 测试 liveUSB

图像完整！！

我还没有完成这件事！

*写入USB的过程从未改变。

为什么之前不起作用？

  1. Tar 方法？——仅略有变化……
    • 来自“tar -cvf casper.tar”。
    • 至“tar -C /media/sda3/-cvf ~/Desktop/casper.tar。
    • 这些线条难道不是在完成同一件事吗？
    • 我很快就会测试一下。——我认为没有什么区别。
  2. 将流程分解为单独的步骤？
    • 前：
      • 在下一步（又称行动计划）下，我会在制作新图像之前完成所有这些步骤。
    • 后：
      • 下一步行动计划严格遵循
    • 这就是差异吗？
    • 我很快就会对此进行测试。
  3. 从 casper（sda3）分区中的 /home/ 目录中删除大文件（或小文件）是否会导致某种损坏？
    • 我不知道..？
    • 我很快就会对此进行测试。

进一步测试——我想要我的答案！

从原始 liveUSB 图像开始。

  1. 将 liveUSB 上的 Java 从 6 更新至 7
  2. 创建 /home/user/folder/
  3. 将 Java 应用程序的类文件复制到 /home/user/folder/
  4. 将startup.sh添加到/etc/init.d/
  5. 输入“update-rc.d startup.sh start 21 2 5”。
  6. 编辑 /home/user/folder/config.properties 中的配置文件

这次一次性全部完成——会起作用吗？

测试 1- 成功 / 失败？

失败！

  1. 旧焦油法

测试 2- 成功 / 失败？

  1. 旧焦油法
  2. 删除 /boot/ 中生成的文件
    • 该文件是我的脚本在写入 casper（sda3）分区时创建的，仅包含一个用于验证的 id，对启动过程没有影响。

测试 3- 成功 / 失败？

  1. 新焦油法

测试 4- 成功 / 失败？

  1. 新焦油法
  2. 删除 /boot/ 中生成的文件
    • 该文件是我的脚本在写入 casper（sda3）分区时创建的，仅包含一个用于验证的 id，对启动过程没有影响。

结果

我将按以下顺序进行测试：

测试 1 -> 测试 3 -> 测试 4 -> 测试 2

如果测试 1 有效...我会跳出窗外！——我不知道为什么它现在能工作，因为我已经测试过很多次了，但每次都启动失败。——也许 cp 或 tar 过程以某种方式被破坏了。

什么时候测试 1 失败：如果测试 3 有效... - tar 方法导致了错误。 - 我不明白旧的 tar 方法与新的 tar 方法相比有什么问题。

待定……

答案1

根据您对问题的描述，我怀疑发生了您描述以外的情况。无论如何，请尝试以下操作：

# sda2
mount /dev/sda2 /mnt/tmp
tar -C /mnt/tmp -cf ~/Desktop/sda2.tar .
umount /dev/sda2 
# ... repeat for sda3 ...
# do your create partition shenanigans
mount /dev/newsda2 /mnt/tmp
tar -C /mnt/tmp -xpf ~/Desktop/sda2.tar
umount /dev/newsda2
# repeat ...
# test ..

如果可行，那么很有可能您的 /home 是以 noexec 方式挂载的，或者是某些文件系统出了问题，因为问题在于执行位被删除了。

如果它不起作用，请编辑您的启动脚本以向您提供调试信息，例如 mount 的输出、syslog 的内容等，并在那里寻求帮助。

您还可以为每个文件生成校验和，并使用以下命令比较副本与原始文件：

find . -type f -exec sha1sum {} ';' > /tmp/sda2_checksums.txt

对于每个已安装的分区并比较 /tmp/*_checksums.txt 文件

答案2

针对有关使用 dd 命令的解决方案尝试和陷阱 #2：

使用 dd 命令克隆原始 Live USB 不会永久地将 64gb 棒变成 16gb 棒。只有在您选择在使用 dd 命令后不重新分区 64gb 棒时，它才会这样做。使用 dd 命令后，您可以调整分区大小以恢复 64gb 棒上剩余的所有可用（未分配）空间。

您可以使用 GParted 或 Parted Magic 分区编辑器之一修改分区，以在使用 dd 命令后恢复克隆的 USB 闪存驱动器上从 16GB 到 64GB 的任意可用空间。

最终结果是，在启动 dd 命令回收 64gb 硬盘的剩余部分后，dd 命令不会通过使用 GParted 或 Parted Magic 将 64gb 硬盘永久地变成 16gb 硬盘。

使用适用于 Linux 发行版的 Linux 磁盘实用程序程序来验证分区空间是可用还是已分配。

您可以从教程“GParted 分区软件 - 完整教程”中了解 GParted：http://www.dedoimedo.com/computers/gparted.html

有关 Parted Magic 的信息可以在以下位置找到：https://en.wikipedia.org/wiki/PartedMagic 但根据我的经验，我会推荐 GParted，因为 Parted Magic 是一个完整的工具发行版，除非你从了解的情况来看更喜欢后一种方法。

简而言之，您已经找到了解决问题的最简单的方法，如果您在帖子末尾计划的所有测试都不起作用，那么只需调整分区大小即可。

相关内容