统信UOS从虚拟机（BIOS引导）迁移到本机物理机加UEFI改造

统信UOS从虚拟机（BIOS引导）迁移到本机物理机加UEFI改造

1、工具和资料

参考资料：https://wiki.archlinux.org/index.php/GRUB_(%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87)
“将 GRUB EFI 应用 grubx64.efi 安装到 esp/EFI/GRUB/，并将其模块安装到 /boot/grub/x86_64-efi/”
工具：DiskGenius 5.3.0.1066 x64
笔记本电脑 5800U

2、现状：

Windows 10 家庭中文版 20H2
C盘和D盘都是ntfs分区，暂时没有新建linux分区。
DiskGenius查看，在原有的EFI分区下，win10在\EFI\Boot目录已有bootx64.efi文件
UOS安装光盘文件G:\BOOT\GRUB\GRUB.CFG的内容
if loadfont /boot/grub/font.pf2 ; then 可选
background_image /boot/grub/background.png 可选

menuentry “Install UnionTech OS 20 Home with kernel 5.4” {
set gfxpayload=keep
linux /live/vmlinuz boot=live union=overlay livecd-installer locale=zh_CN console=tty splash –
initrd /live/initrd.lz
}

3、创建EFI配置

从UOS安装光盘中拷贝G:\EFI\BOOT\GRUBX64.EFI文件到EFI分区的\EFI\Boot目录
暂时把启动文件放在EFI分区，拷贝如下内容
G:\LIVE\vmlinuz
G:\LIVE\initrd.lz
G:\BOOT\GRUB\目录下GRUB.CFG font.pf2 background.png 三个文件
G:\BOOT\GRUB\X86_64_E整个目录，并修改目录为X86_64_EFI
光盘的文件和目录都是大写，而且最多只有8个字符，比如background.png对应的文件名是BACKGROU.PNG
可能会出现找不到文件的问题。

验证EFI启动

重启HP电脑，按ESC选择启动菜单，从文件启动。
ps：可以关闭快速启动避免无法进入启动菜单；直接按F9进入启动菜单。
选择\EFI\BOOT\GRUBX64.EFI可以进入grub菜单提示符。
手工指定linux、initrd后boot无反应。

4、文件名8个字符问题

这之前对iso文件操作，是在win10下用自带的浏览器装载的，用UltraISO.v.9.6.2.3059也是文件名最多只有8个字符。
拷贝到linux下mount发现是长字符的，大小写也有差异。
映像制作工具 DAEMON Tools Lite 10挂载也是一样的8个字符，只能从linux的挂载里面拷贝出来了。
ps：linux的boot/efi.img是二层套娃，mount后发现有boot EFI live三个目录；boot里面还有efi.img文件。

5、修改EFI配置

EFI分区下的文件：
重命名为小写
\EFI\Boot\grubx64.efi 目录BOOT在linux下挂载是全大写，其他iso文件。
\live\vmlinuz
\live\initrd.lz
删除\GRUB
[root@wtstb mnt]# tar -zcvf /tmp/grub.tar.gz ./boot/grub
在win下解压，删除无关的boot\grub\i386-efi
把boot目录拉到EFI分区，之前少了boot目录。

验证EFI启动

还是需要boot from file来指定grubx64.efi 文件，自动出现背景图案和grub菜单，选择后无反应（应该加载内核才对）
从fossapup64-9.5.iso拷贝vmlinuz和initrd.gz，需要修改grub.cfg把initrd.lz修改为initrd.gz.

6、EFI文件来源及验证

以下验证针对puppyLinux（fossapup64-9.5.iso）安装好的U盘中的内核和initram

bootx64.efi文件

PhoenixOSInstaller_v3.6.1.564_x64.iso 的G:\efi\boot\bootx64.efi
和统信UOS的uniontechos-desktop-home-1030-amd64.iso的H:\EFI\BOOT\BOOTX64.EFI
文件大小相同，CRC64相同，数字签名都是Microsoft Windows UEFI Driver Publisher（‎2015‎年‎6‎月‎6‎日 8:02:37）
但grubx64.efi文件大小相同，CRC64不同：
PhoenixOS的正常引导进入puppyLinux。
UOS不能引导（出现grub shell，指定linux和initrd后boot无反应）

grubx64.efi文件

2个U盘的bootx64.efi文件CRC64相同2333F0F468697522，和PhoenixOS.iso、UOS.iso里的文件都相同，和PhoenixOS.iso安装后的U盘文件相同；
2个U盘的grubx64.efi文件CRC64相同，和和PhoenixOS.iso、UOS.iso里的文件都不同，而是来自于PhoenixOS.iso安装后的U盘。
但SanDisk U盘用UOS的文件替换后不能引导，把BOOTx64.EFI改名为bootx64.efi，必须手动输入文件名，粘贴会出现大小写不同；修改后引导正常。
说明grub会用到bootx64.efi文件且必须全部为小写。
用PhoenixOS.iso中的grubx64.efi拷贝到U盘，引导出现启动菜单，回车后黑屏。
用UOS.iso中的grubx64.efi改名为全小写后拷贝到U盘，不能引导（出现grub shell，指定linux和initrd后boot无反应）。

小结：

grub启动要求文件名必须全部小写为bootx64.efi；而windows启动则无此要求；
grubx64.efi也必须全部小写，同一个内核，有的grubx64.efi是无法启动的。
用PhoenixOSInstaller_v3.6.1.564_x64.iso安装后的U盘中的2个efi文件，可以正常引导fossapup64-9.5.iso安装好的U盘中的内核和initram。

7、更换UOS内核测试

从UOS.iso拷贝到U盘，改名为vmlinuz、initrd.gz，出现引导菜单和内核启动提示，报错找不到根文件系统：
No root device specified. Boot arguments must include a root= parameter.
BusyBox
v1.30.1 …
…
(initramfs)

把iso文件的grub内容拷贝过来修改如下
set timeout=2
set gfxmode=auto,1024x768

menuentry “Install UnionTech OS 20 Home with kernel 5.4” {
linux /live/vmlinuz boot=live union=overlay livecd-installer locale=zh_CN console=tty splash –
initrd /live/initrd.lz
}
出现有图形界面的引导菜单和内核启动提示，和正常iso引导相同，出现统信UOS闪烁。

这次已经正确识别到sda移动盘。
I 3.3532311 xor: automatically using best checksumming function avx
1 3.3541991 async_tx: api initialized (async)
done.
Begin: Rumning/scripts/init-premount …
3.3838551 sda: sdal
1 3.385822] sd 0:0:0:0: [ sda] Attached SCSI removable disk
1 3.4824781 EXT4-fs (nvme0n1p5): mounted filesystem with ordered data mode. Opts: (null)

Busybox v1.30.1 (Debian 1:1.30.1-4) bullt-in shell (ash)
Enter "help for a list of bullt-in commands.
(initranfs)

至此，EFI测试基本成功，下一步把虚拟机的VDI文件迁移到物理硬盘分区。

8、把虚拟机的VDI文件迁移到物理硬盘分区

参考：https://blog.csdn.net/weixin_43869959/article/details/115364286

9、调试UOS启动

（1）修改grub.cfg

准备修改grub.cfg，把UUID修改为新盘的实际值。
root# blkid
/dev/nvme0n1p5: LABEL=“linux” UUID=“c664dd10-7cb6-8e4b-a72f-634dc6c08ba2” TYPE=“ext4” PARTLABEL=“Linux data partition” PARTUUID=“1356d9f2-b602-4d0a-8900-8d63237fb4aa”

vi替换 :%s/dda62293-2eb9-4042-a392-23d87ae68900/c664dd10-7cb6-8e4b-a72f-634dc6c08ba2/g
修改好之后，替换掉EFI分区下的gurb.cfg文件。还需要把root根文件系统替换为实际的比如nvme0n1p5，EFI分区修改为nvme0n1p0，可能对应为gpt1。

正常引导图形菜单，启动内核后报错：
0.398314] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PEP._STA.TPOS], AE_NOT_FOUND (20200326/psargs-330)
0.398319] ACPI Error: Aborting method _SB. PEP._STA due to previous error (AE_NOT_FOUND) (20200326/psparse-531)
上面2行反复出现
0.890399] pci 0000:00:00.2: AMD-Vi: Unable to read/write to IOMMU perf counter.
0.948623] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000005) is beyond end of object (length 0x05) 20200326/exoparag2-396)
0.948659] ACPI Error: Aborting method TZ. GTTP due to previous error (AE_AML_PACKAGE_LIMIT) (20200326/psparse-531)
0.948676] ACPI Error: Aborting method TZ. CHGZ._TYP due to previous error (AE_AML_PACKAGE_LIMIT) (20200326/psparse-531)

对于报错：

AMD-Vi: Unable to read/write to IOMMU perf counter. 网上搜索貌似影响不大
ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT 这个报错后面正常启动也存在。

更新微码尝试

参考 https://wiki.archlinux.org/index.php/Microcode_(%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87)
/boot/grub/grub.cfg
…
echo ‘Loading initial ramdisk’
initrd /boot/cpu_manufacturer-ucode.img /boot/initramfs-linux.img
…

在initrd 行加上 /boot/microcode_amd_fam17h.bin
回到Windows，用DiskGenius编辑grub.cfg，也可以继续到puppyLinux下去编辑。

在虚拟机用lscpu看到AMD 5800U对应的family是25，但amd-ucode下只找到17的
下载固件 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/amd-ucode/microcode_amd_fam17h.bin
保存到 linux的 /boot目录，DiskGenius需要专业版才能写ext4分区，还得去puppyLinux

在grub菜单下按e直接编辑启动项添加microcode，能失败成笔记本型号和CPU了，但没有找到root根文件系统。

尝试用iso写U盘启动

balenaEtcher-Portable-1.5.45.exe工具把uniontechos-desktop-home-1030-amd64.iso写入U盘来启动看看。
无法引导5800U CPU，出现grub菜单，回车后没有反应。

从archlinux获取uboot文件启动正常

尝试用archlinux-2021.01.01-x86_64a.iso的F:\arch\boot\x86_64\initramfs-linux.img、vmlinuz-linux外加F:\arch\boot\amd-ucode.img文件，可以正常引导。
后来恢复为UOS的内核和initrd，加上F:\arch\boot\amd-ucode.img，引导正常，最后打包一个可以正常引导的启动文件。

总结：

1、UOS个人版的iso及安装后均不支持AMD 5800U，可以通过在grub.cfg中增加ucode微码识别该CPU，从而实现正常引导。
2、从虚拟机到物理机的迁移，对一切皆文件的linux来说，只是格式识别和文件拷贝的事情而已。
3、暂时没有打算以UOS为主系统，每次还得从EFI选择boot from file选择grubx64.efi来实现linux的引导，希望有大神能提供解决方法，谢谢。