因为某项目的需要，我被要求在一个工作站上安装 CentOS 7 和 Windows 10/11 双系统。考虑到自从研究生毕业先是参加工作后是重回学校读博，很久没有搞过太应用的东西了，而且印象中 Linux 和 Windows 10 系统两者安装起来并不是那么的一帆风顺，因此考虑认真看看具体的步骤。经过一下午的尝试和研究，发现整个安装过程中还是收获蛮大的，遂考虑将这一经历整理一下，供后续自己遇到类似问题能更快结果，当然如果能帮助到其他读者那我更是倍感欣慰。

XFS 并不支持缩小空间！

首先，在网上找到一个相关的教程非常容易，尤其是这种 Linux 和 Windows双系统混装的场景更是非常常见，我没花多少功夫便找到一个非常详尽的博客：centos7中安装win10搭建双系统。

由于我在开始着手这一工作时还没有拿到最终需要安装的机器，因此我考虑直接在一个 VMware Workstation 的虚拟机中安装测试。首先是比较顺利的下载CentOS 7 安装 ISO，导入到 VMware Workstation 中安装，所有配置均选择默认选项，磁盘分配了 100 GB 。因为我想完整模拟从一个仅安装了 CentOS 7 系统的机器到双系统的过程，所以我在磁盘配置里选择让 CentOS 安装程序自动为我分区。

按照博客内容，我应该在第二步的时候将 100 GB 的空间缩小，然后把空余的空间分配到 Windows。然而，我在这一步就首先遇到了问题：CentOS 安装程序默认情况下会采用 LVM 的存储管理方法，一共分配了 3 个逻辑卷（Logical Volume），分别是 swap、root和 home，其中 root 和 home 采用 xfs 文件系统。结果当我用 gparted LiveCD 引导 gparted 图形程序打算缩小 LVM 分区时，发现完全无法缩小。使用命令行 lvreduce --resizefs -L -50G centos 命令手动缩放（https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/lv_reduce#LV_reduce），发现直接报错file system reduce is required and not supported (xfs)，即xfs 不能执行 reduce 操作。因为对 xfs 并不是那么了解（经常用 Ubuntu/Debian 这类发行版的更多的和 ext4/3 等文件系统接触更多），我搜索了相关资料（https://unix.stackexchange.com/questions/619099/why-cant-we-reduce-xfs-filesystem），发现结论是

XFS 并不支持缩小空间！

之所以没有这样做，是因为基本上没有缩小大型文件系统的需求。存储很便宜，而且在大多数环境中，数据集和容量只会增长。

大致意思就是说，xfs 的开发人员认为目前而言磁盘空间应该不是太大问题了，所以他们并不是很愿意增加这个功能，虽然按照 StackOverflow 的说法后续的一些 xfsutils 工具提供了体验版的缩小功能，但是我看到这个回复的时间（2021 年）后我决定直接放弃这一想法了，因为我只是做测试环境，环境应当是完全可控的。但是这里就留下来一个未来需要考虑的问题，假如**碰到那种xfs 占据了整个硬盘的系统该如何解决呢？**将所有文件全部备份再安装到一个新系统里固然可行，但是非常繁琐麻烦，如果以后有时间的话可以看看后续的新工具是否有效。

Resizefs 选项在很多场景下不可用

我决定绕过 xfs 的这一障碍，因此我开始重新安装了 CentOS 系统，这次我选择先让 CentOS 安装程序默认为我规划一个分区过程，然后我手动删除了 home 逻辑区，用 root 做 Linux 的根目录。安装过程非常顺利，anaconda 提供的安装程序界面也非常简洁美观。安装完毕后我顺利打开了 gparted LiveCD，结果发现 LVM 管理的磁盘分区仍然不支持直接用 gparted 来缩小，所以这次我先运行 lvreduce 命令，结果再一次碰到了问题：

/usr/libexec/lvresize_fs_helper: execvp failed: No such file or directory

看起来是缺少某个具体做 resize 工作的可执行文件，如果是在联网且系统安装完毕的环境中这个问题应该不大，但是在目前这个 LiveCD 的环境下面对这个问题是有些棘手的。我认为这个问题应当是 lvm 软件包可能缺失了一些非必需文件，讲道理不应当在这种一应俱全的 LiveCD 里出现。直接搜索这一问题有很多解决方案，可见这个问题并不是一个罕见问题，多数需要重新安装包或者做一些 patch 工作等，但是显然这些在 LiveCD 里执行太麻烦了，好在我在某个 maillist 下找到了最快的解决方案（https://bugs-devel.debian.org/cgi-bin/bugreport.cgi?bug=1065606）：使用 –fs resize_fsadm 而不是 –resizefs。

VMware SCSI 控制器大敌

完成了 CentOS 7 的安装，也为 Windows 系统留足了存储空间，只要完成Windows 安装这一最简单的步骤，是否很快就能开始做引导调整这一核心工作了呢？答案是否定的，因为一直到这里我才了解到一个收获最大的难点。

按照步骤打开Windows 安装程序，选择刚才分配好的 NTFS 分区安装！界面马上坡上冷水：

嗯？这什么情况？硬盘没了？我立马重新引导 CentOS，结果一切正常啊，那看来问题应该不在硬盘这里。搜索下 Vmware、Windows、no drive等关键词，一些链接提到 ESXi下安装 Windows 可能出现这一情况，且最终答案是 SCSI 控制器的类型问题（https://answers.microsoft.com/en-us/insider/forum/all/win-10-doesnt-seem-to-install-on-vmware-it-doesnt/d277bcc1-9edf-431d-bb05-dd940ab7dbe3），但是没有找到和 Workstation 有关的。这时候我突然想到，因为我这次使用虚拟机的逻辑和往常有很大不同，一般而言虚拟机在安装后操作系统就已经确定了，一般也没有人会选择在虚拟机里装一个双系统，会不会是因为VMWare 给 CentOS 选择的支持的 SCSI 控制器和 Windows 并不那么无缝兼容（比如需要借助一些驱动程序），因此导致我换成 Windows 安装程序后无法读到原有的磁盘。经过一番查找我终于发现了https://www.nakivo.com/blog/scsi-controller-and-other-vmware-controller-types/这篇帖子，到这里我终于明白了，VMware Workstation 默认给 CentOS 7 准备的 SCSI 控制器是LSI Logic Parallel，但是 Windows 系统在 2008 版本后最佳支持的是LSI Logic SAS，这就是为什么找不到磁盘的原因。由于 ESXI 同样作为 VMware 的虚拟化产品，所以我猜想类似的解决方案应当能直接应用在 Workstation 上。最直接的解决方法当然是用额外的驱动找到原有的 SCSI 控制器（可参考这个帖子https://blog.csdn.net/weixin_42376940/article/details/113322604 ，虽然他是缺少RST 驱动），但是这样做要麻烦很多，由于在测试环境下我采用直接更改 SCSI 控制器类型的方法，由于Workstation 的管理界面并不支持直接指定类型，我直接修改vmx 文件中的scsi0:0.deviceType，根据博客信息：

• buslogic – BusLogic SCSI
• lsilogic – LSI Logic SCSI
• lsisas1068 – LSI Logic SAS
• pvscsi – VMware Paravirtual SCSI

所以从 lsilogic 改成 lsisas1068。修改后重新开机，完美！Windows 安装程序已经能够正常运作了，但是这里就会留下另一个隐患：CentOS7 那边是不是就不能正常引导了呢？暂时不考虑这个问题，我们先按部就班把双系统引导工作做了。

按照双系统安装博客的内容，安装好 Windows 后果然 CentOS 的引导被 Windows 覆盖了，此时系统只能进入 Windows。我重新用 CentOS 7 LiveCD 引导，选择 Troubleshooting — Rescue a CentOS System选项，让 LiveCD 自动找到CentOS 安装位置并挂载到/mnt/sysimage 目录下，然后就是chroot 操作切换到根，执行 grub2-install 和 grub2-mkconfig 操作，将 grub 和 initramdisk 问题解决。操作完成后，此时只看到了 CentOS的两个启动项，Windows 启动项没有出现，这个问题先放一下，我们先进入 CentOS 来看看。

结果果然没那么简单，点击 CentOS 后系统迟迟没有进入，等待很久后出现了报错：

dracut-initqueue[1697]: Warning: dracut-initqueue timeout - staring timeout scripts
dracut-initqueue[1697]: Warning: Could not boot. 
dracut-initqueue[1697]: Warning: dev/centos/root does not exist 
dracut-initqueue[1697]: Warning: dev/centos/swap does not exist
Starting Dracut Emergency Shell...

也就是说，本应存在的两个LVM 分区找不到了。不算太出乎预料，我猜测应当是因为我改了 SCSI 设备的原因，导致 CentOS 已有的驱动并不能识别出来LSI Logic SAS。经过一番搜索，我找到了类似情况https://blog.csdn.net/Micha_Lu/article/details/125063992，但是帖子里对/etc/dracut.conf 文件进行了修改，然而在我的 Dracut 这个紧急情况终端下（我猜测是只有 initramfs ），根本没有/etc/、/boot 这些目录的挂载，甚至也没有大部分终端命令，只能用 journalctl 看看崩溃日志等等。

因此这里我想到了，如果我进入到刚才用 LiveCD 引导后找到的根目录，chroot 后再执行这些功能应当可行。这样操作后我确实能够直接访问根系统了，但是发现没有/etc/dracut.conf 文件，这个我认为可能是发行版的差异问题。我在https://serverfault.com/questions/296015/change-vmware-scsi-in-redhat 这里终于知道了最终解决方案，帖子里提到 RHEL 7.0（猜想和 CentOS 7 仅仅有商业版和社区版的差别）没法通过 modprobe.conf 来应用驱动，所以应当用dracut -f -v --add-drivers mptsas 命令实现驱动在 initramfs加载，如此操作后问题终于得以解决，重启后 CentOS 7 成功引导。

最为简单的双系统引导

结果，我认为可能是最复杂的一个步骤反而没有遇到太大问题。成功进入 CentOS 后确实无论怎么执行 grub-install 和 grub-mkconfig 都没办法自动找到 Windows，因此我根据双系统安装帖子的方法，手动编辑/etc/grub.d/40_custem 文件，根据引导方式（BIOS 还是 UEFI）来决定添加内容。

UEFI

menuentry 'Windows 10' { 
  insmod part_gpt 
  insmod ntfs 
  set root='UUID=YOUR_WINDOWS_PARTITION_UUID' 
  chainloader EFI/Microsoft/Boot/bootmgfw.efi
}

UUID 可以通过 blkid 命令找到指定分区。

BIOS

menuentry 'Windows 10' {
  insmod part_msdos
  insmod ntfs
  set root='hd0,msdos3'
  chainloader +1
}

hd0,msdos3 指/dev/sda3，如果是其他分区则修改数字即可。

自定义 Windows 位置后执行grub2-mkconfig -o /boot/grub2/grub.cfg 即可。

结语

没有想到双系统本身需要做的引导工作并不多，大部分时间竟然花在了测试环境所使用的SCSI 驱动问题上，不过总的来说还是收获不少的😄。