ArchLinux离线伪安装逐步

几天前，我下载了ArchLinux ISO进行家庭安装。 以前曾使用过其他发行版，使您可以从CD上安装至少一个最小的数据库，但我想做类似的事情，但是奇怪的是，Arch的安装过程不是为无法访问Internet的计算机设计的（开发人员的副作用在第一世界）。

就我而言，我的磁盘上已经装有Windows 7（具有引导和系统分区）和Fedora（具有交换和专用/引导分区）。 当时的想法是设法将Arch安装在Fedora以前的位置，而不会破坏Windows。

ArchLinux离线伪安装

好吧，我从Arch CD启动，选择了x86_64，并且毫不费力地将我留在控制台上。 我以为，“哇，这些家伙很认真，不想成为新秀发行人……好吧，让我们一起玩，然后看看会发生什么。”

我列出了要查看是否有任何文档的目录，并且发现确实存在带有基本安装指南的文本。 我在一张纸上写了相关的东西（我家里没有打印机），然后开始工作。

我所做的第一件事是将键盘布局从西班牙更改为西班牙语，这比我预期的要容易（甚至有一个奇怪的叫我们口音）：

loadkeys es

接下来的事情是安装外部磁盘以在出现问题时保存MBR的副本，并顺便保存了我在Fedora中拥有的重要信息：

mkdir -p / mnt / tmp1 && mount / dev / sdb1 / mnt / tmp1 dd if = / dev / sda = / mnt / tmp1 / mbr.bin bs = 512 count = 1

幸运的是，Arch的LiveCD支持NTFS并具有内置功能 午夜战友 （MC），所以我很快就完成了其余信息的保存。

然后，我卸载了磁盘，删除了临时目录，并物理删除了外部磁盘，以减少潜在的“ catroptrophes”风险。

umount /mnt/tmp1 && rmdir /mnt/tmp1

所以我格式化了分区，挂载了根分区和启动分区，并打开了swap：

mkfs -t ext4 / dev / sda3 mkfs -t ext4 / dev / sda6 mount / dev / sda6 / mnt mkdir -p / mnt /引导安装/ dev / sda3 / mnt /引导swapon / dev / sda5

下一步是我的第一步：

pacstrap /mnt base

Arch很自然地尝试在其中一个镜像上寻找存储库数据库，但无法找到任何内容 包子 确实是在/ mnt中创建了一个目录结构，非常有条理，但显然是空的。

我通过电话问了几个使用Arch的朋友，如果没有互联网访问，是否无法安装至少与LiveCD上相同的软件包，也没有将存储库复制到磁盘上的方法，他们告诉我，至少他们不知道该怎么做。

我发现技术“挑战”很有趣，因此我想，“如果Arch能够以LiveCD模式登录，那么它至少应该能够以相同的模式安装到硬盘上”，因此我尝试通过手动复制文件，然后按照本教程的其余部分（进行一些其他小的更改）来查看发生了什么：

rsync -avl / {bin等，home，lib，lib64，opt，root，sbin，srv，usr，var} / mnt arch-chroot / mnt genfstab -p / >> / etc / fstab echo hpc> / etc /主机名ln -sf / usr / share / zoneinfo / Cuba / etc / localtime locale-gen

下一步是我的下一个障碍：

mkinitcpio -p linux

阅读命令手册和文件内容后，此命令产生了一些错误 /etc/mkinitcpio.conf y /etc/mkinitcpio.d/linux.preset，我知道该命令找不到该文件 vmlinuz-Linux，所以我按Ctrl + D退出chroot环境，并查找任何看起来像它的文件：

find / -type f -iname "*vmlinuz*"

Arch的LiveCD可能将启动文件挂载在目录下 / 跑 /，所以我决定将它们复制给我 /启动/ 使它们在我的chroot环境中方便使用：

cp /run/archiso/bootmnt/arch/boot/[memtest,intel_ucode.img} / mnt /引导/ cp /运行/ archiso / bootmnt /拱/引导/ x86_64 / * / mnt /引导/ arch-chroot / mnt

我发现尝试使用mkinitcpio的另一个错误是找不到根分区的标签，因此我写下了它的UUID（我使用blkid命令确定）以与命令一起使用，最终看起来像这样：

mkinitcpio -p linux -k /boot/vmlinuz root=UUID=d85938aa-83b8-431c-becb-9b5735264912

这次，构建成功结束，仅出现了一些未找到模块的警告，但在我的情况下则不需要。 以防万一，我重新生成了fstab，但是这次指定了UUID：

genfstab -U -p / > /etc/fstab

我以为：哦，好，终于进步了。 然后我继续更改密码并安装了引导程序。

passwd grub-install --target = i386-pc --recheck / dev / sda grub-mkconfig -o /boot/grub/grub.cfg

最后，有条不紊地，我再次按Ctrl + D退出chroot环境，分解所有内容并重新启动以查看发生了什么：

umount / mnt /启动umount / mnt重新启动

计算机重新启动，显示带有Arch的Grub菜单（Windows没出现在任何地方），因此我选择了它，并且一切似乎都可以正常加载，直到...系统指出我应该使用以下命令检查错误：

journalctl -xb

分析错误后，我发现大多数错误可以忽略，但是最后一个错误，告诉我找不到普利茅斯。

我立刻想到，“普利茅斯？？？ 为什么控制台启动环境需要这样的东西？ 这似乎不太吻。 我当然没有说，也不需要。”

但实际上，我想：“嗯，但至少应该在某些文件中引用它，让我们看一下……”：

find /etc -type f -print0 | xargs -0 grep -i "plymouth"

令人惊讶的是，配置目录中没有出现带有文本字符串“ plymouth”的文件。 我当时想：“哦，所以……你强迫我自己吗？ 然后让我们看看您是如何吸收“大炮”的（就像我们在古巴所说的），然后“我从头开始建造”普利茅斯：

vi / usr / bin /普利茅斯chmod 755 / usr / bin /普利茅斯

对于那些想知道我在该文件中放入什么内容的人，以下是其全部内容：

＃！ / bin / sh退出

我再次重新启动，并期望出现一些错误，并且……令人惊讶的是，systemd很高兴找到了这个“基本组件”，因为它完成了启动过程，并且没有再拖延，将我留在了控制台中。 由于我不敢相信自己的眼睛，我决定“卸载”普利茅斯并重新启动，以查看发生了什么事情：

rm -fr / usr / bin /普利茅斯重启

奇怪的是，这一次系统安静地启动，而没有因为Plymouth的缺席而使我烦恼。 （没有意见）

将Windows添加到GRUB

然后将Windows条目添加到GRUB。 由于传统路线无效（ grub-mkconfig 同 操作系统探测器 似乎运行不正常），我决定手动创建该条目，为此我需要检测Windows引导程序字符串和引导分区的UUID：

mkdir -p / mnt / winboot && mount / dev / sda1 / mnt / winboot grub-probe --target = hints_string / mnt / winboot / bootmgr grub-probe --target = fs_uuid / mnt / winboot / bootmgr

这分别返回了我这两个字符串：

--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1
DC788F27788EFF8E

这样，我验证了返回的UUID与执行blkid命令时为该分区获得的UUID相同。 然后有必要使用所述数据生成一个定制的grub条目：

vi /etc/grub.d/40_custom

在其内容中：

＃！/ bin / sh exec tail -n +3 $ 0＃该文件提供了一种添加自定义菜单项的简便方法。 只需在此注释后键入要添加的＃菜单项。 注意不要更改上面的“ exec尾”行。 菜单项“ Microsoft Windows 7 SP1” --class windows --class os { hd0，msdos1-提示裸机= ahci0，msdos1 DC0F1EFF788E ntldr / bootmgr}

完成此步骤后，我决定将Windows设置为默认操作系统，这样我的妻子就不会惊慌，我的侄女在她来的时候可以玩她的芭比娃娃。 为此，我只是编辑了文件 / etc / default / grub 并且我将输入设置为默认启动，并且超时仅为3秒。

GRUB_DEFAULT = 2 GRUB_TIMEOUT = 3

只需要再次重新生成GRUB配置，然后重新启动即可：

grub-mkconfig -o /启动/grub/grub.cfg重新启动

幸运的是，一切都按预期进行。 我选择了Windows条目，然后它愉快地启动了。

因此，您可以看到，如果可以逐步完成至少一个ArchLinux脱机伪安装，而不必仅与CD联机，尽管显然，将要安装在硬盘上的实际上是LiveCD，但是至少可以引导系统，复制文件并运行某些应用程序。

幸运的是，桑迪（KZKG ^ Gaara）停下来复制了Arch存储库（对此我非常感激），因此我计划尽快完成真正的脱机安装，但这将是另一个故事。 我可以向您保证的是，一段时间以来，我一直在丢失这种有趣的实验。 实际上，如果我有时间，可以保证房子的连通性并确保某些材料条件，我可能会尝试基于LFS进行自定义分发，这将是一个更加有趣的项目。 😉