陆伟峰
wave
关注数: 68
粉丝数: 125
发帖数: 51
关注贴吧数: 6
云固件小课堂:镜像系统的分区大小调整 云固件镜像通常使用VHDx格式作为镜像容器。需要对镜像系统的分区进行大小调整,通常需要分成两个步骤,包括分区和镜像文件。 需要缩小分区,对于Windows 10/11系统来说,可以直接在磁盘管理里面操作,选中C盘点击右键,会出现“压缩卷”的菜单,按照提示操作即可。 由于缩小分区,那么多余出来的空间就不会有数据写入,这时候调整镜像大小其实无所谓了。 需要放大分区,第一步就需要突破VHDx镜像文件的天花板限制。 在PE系统下,使用bootice工具,选中需要调整大小的VHDx镜像文件,选择“VHD文件信息”,可以看到“重设容量(扩展/缩减)”按钮,按照提示就可以重新设置大小了。这里要放大,选择一个合适的大小输入数字即可。 放大分区的第二步,可以启动镜像后,在磁盘管理中间,选中C盘,点击右键,就会出现“扩展卷”菜单,按照提示操作,就可以放大分区了。 以上就是Windows系统上的放大/缩小分区的操作。Linux平台上也类似,但工具就比较复杂一些了。
突发奇想:差分镜像能不能硬(强制)关联 云固件《突发奇想》专栏用来记录各种奇思妙想、脑洞大开或者天马行空类的想法,有可能实现也有可能就是黄粱美梦,总之就是头脑风暴。 云固件使用VHDx格式作为推荐镜像格式,使用镜像最大的优势就是可以动态或者差分镜像,所谓差分镜像就是父子关联镜像,核心数据在父镜像,修改数据在子镜像。 不使用差分功能,好比吃面不吃蒜,味道少一半。 但是,差分镜像父镜像一旦有写入,那么子镜像全部报废。 虽然,借助bootice这样的工具能够强制重新关联父镜像,但是子镜像设计上有扇区的数据被记录下来了,很容易发生奔溃的情况。 有没有一种设计,父镜像可以写入数据,子镜像也可以写入数据,两者还能重新关联到一起,还不会发生数据错误? 谈一个设想,要想数据不出现错误,那么必然要让两个镜像文件的数据不发生重叠,第一个想到的方法就是通过分区把数据分离,父镜像写A分区,子镜像写B分区,是不是就能成功? 如上图,父镜像处理Systems分区,子镜像处理Data分区。 大家觉得是否可行,欢迎大家讨论和留言,把想法用留言记录下来一起讨论。
Linux镜像的内核模块编码即将结束 针对Linux系统的云固件镜像,之前由于systemd在关机和重启时,直接杀死qemu-nbd服务进程,导致镜像不能正确关闭问题,将随着内核模块启用成为历史。
【高级教程】300.教程概述 云固件初级教程讲述了云固件的基本安装方法,云固件中级教程讲述了云固件镜像的各种玩法,云固件高级教程将会讲述云固件主程序与云固件镜像的原理。 在初级教程中,云固件被明确分成了云固件主程序和云固件镜像两个部分,高级教程将会对这两者进行详细的讲述。 云固件镜像,是指包含了操作系统和应用软件的镜像文件,通常使用VHD和VHDx两种格式。在高级教程中,会具体讲解常见镜像格式,以及启动这些镜像的原理。这些镜像包括云固件原生支持的VHD、VHDx、ISO和RAW格式,还包括云固件不支持的QCOW、QCOW2、VMDK、VDI等等。即使云固件不支持,使用这些格式的Linux系统镜像依旧可以被启动起来。 云固件主程序,是指云固件引导程序。高级教程会讲解云固件引导程序的基本架构,以及如何使用Helper辅助引导镜像来扩展云固件启动能力。 最后,对于动手能力强的爱好者,将会提供一个UEFI例子,从代码讲解如何解析镜像格式并引导进入镜像内系统。例子可以在实际环境编译和使用。
UEFI开发的应用 云固件是UEFI下开发的镜像引导程序,能够直接启动镜像文件里面的系统,镜像文件支持VHD和VHDX,系统支持Windows 7 - 11,各种Linux和国产操作系统。
镜像差分功能来了 云固件主程序108.25022支持手动差分和自动差分,可以测试了。 软件包在测试版beta文件夹下。
Windows 10,再见! 2025年10月14日,微软将停止Windows 10的更新服务。 Windows 10,再见!
默认启动镜像设置操作 简单说一下默认启动镜像设置的操作。 在选中的镜像上,按F3键,可以设置或者取消默认镜像。 设置的镜像,会在图标左上角显示一个特殊标记。取消设置后,特殊标记会取消。
最新严重bug:Windows重置功能失效 前不久,微软为受支持的 Windows 版本推送了 8 月的“周二补丁日”安全更新(KB5063709)。更新本该带来修复和增强,但现在却被发现引入了一个相对严重的Bug。 微软最新确认:在安装 KB5063709 更新后,尝试重置或恢复设备可能会失败。 触发方式包括: 进入 设置 > 系统 > 恢复 > 重置此电脑 进入 设置 > 系统 > 恢复 > 使用 Windows 更新解决问题 使用 RemoteWipe CSP 远程清除 无论哪种方式,都会导致操作失败。 目前受影响的平台包括: Windows 11 23H2、22H2 Windows 10 22H2 Windows 10 企业版 LTSC 2021 / IoT 企业版 LTSC 2021 Windows 10 企业版 LTSC 2019 / IoT 企业版 LTSC 2019 换句话说,范围相当广泛,涉及到家庭用户、企业用户乃至 IoT 场景。 尽管使用云固件镜像就没必要使用重置功能,但不排除当前bug是否还有严重后果,建议所有云固件用户备份全部镜像文件包括差分镜像的父镜像,并且保存到其他存储设备,避免数据丢失等意外情况。 三哥越来越不靠谱!!!
镜像应用:复制镜像 云固件镜像的虚拟磁盘VHDx镜像文件,本质上就可以认为是一块硬盘,通过DiskGenius复制硬盘的功能,就可以实现物理硬盘《==》虚拟硬盘的相互复制。 通过复制得到的硬盘,本质上会出现引导分区里面的BCD设置与实际硬盘参数无法对应的情况,所以需要更改配置参数,或者简单的说就是修复引导来修正后才能启动。但是,从物理硬盘复制到虚拟硬盘,让云固件启动时,云固件并不会使用虚拟硬盘里面的BCD设置,所以可以无须更改。但是,源硬盘和虚拟硬盘并存会出现UUID冲突,所以需要注意。
云固件混合模式下开启安全启动 云固件混合模式下,云固件引导程序没有获得微软数字签名,因此无法开启“安全模式”,那有没有办法开启安全启动而且还能使用云固件呢? 安全启动是各个行业巨头为了保障计算机从硬件到软件各个层级都受控于安全监管而设计的。但是,实际使用过程中,很多层面是无法满足安全要求的。比如,云固件引导程序就没有获得微软的数字签名。 为什么没有获取数字签名,说到底,还是钱的问题。每次发布的版本都需要缴纳99美金才能获取数字签名,成本不低。 云固件的外置模式、移动模式和独占模式(标准模式),目前使用了第三方获得数字签名的引导程序绕过了安全启动。这三种模式,ESP引导分区都是云固件主程序独占,因此可以使用第三方的方式。但是,云固件混合模式通常和Windows共享引导分区,其中/EFI/BOOT/bootx64.efi存在冲突的情况,导致无法启用安全启动。 那有没有办法来启用“安全启动”呢?咱们先来分析一下混合模式下ESP引导分区内的文件。 本例子采用常见的Windows混合模式,Linux的混合模式比较少,而且和Linux混合通常就不需要开启安全启动。 ESP分区下,EFI文件夹下包含了UEFI的引导程序。 先说Microsoft文件夹。 从名称上就知道这是微软的引导程序,也就是Windows引导程序。这个文件夹下就只有Boot文件夹。在Boot下,文件就很多,通常包含bootmgfw.efi、bootmgr.efi、BCD等。 其中bootmgfw.efij就是Windows的引导程序,BCD就是引导配置文件。 再说MW文件夹。 这个文件夹就是云固件的引导程序,通常包含MW.efi和BootUI.efi这两个引导程序。 最后来说/EFI/Boot。这个文件夹下通常就只有bootx64.efi这个文件。 这个文件就是UEFi规范定义的x64架构下默认引导程序文件。如果是x86架构,那么规范定义的文件名就是bootia32.efi,由于FAT16/32分区忽略文件名大小写,所以文件名大写也可以的。 规范只定义了文件名和文件路径,文件内容是不定义的。因此,这个文件在Windows引导时,其实就是bootmgfw.efi的复制。云固件主程序用的第三方引导程序就是shim.efi。 由于UEFI规范定义了默认的引导程序文件,因此只要默认文件存在,那么就不需要手动添加引导项。 混合模式下,由于Windows已经占用了/EFI/Boot/bootx64.efi,因此云固件的引导项是单独添加的。通过上面的分析,我们知道Windows混合模式下/EFI/Boot/bootx64.efi就是Windows的bootmgfw.efi。 同时,很多主板都会默认添加/EFI/Microsoft/Boot/bootmgfw.efi作为Windows Boot Manager的启动项。 由此可见,/EFI/Boot/bootx64.efi其实可以不使用。 这就是混合模式下启用“安全启动”的突破口。 把这个文件夹下全部内容替换为云固件主程序提供的/EFI/Boot文件夹内容。由于这个文件夹下引导程序已经完成了数字签名,因此无须关闭“安全启动”。 说一下修改后的引导过程。 混合模式引导时需要切换引导项,Windows引导使用bootmgfw.efi对应的引导项;云固件使用默认引导项,通常会出现UEFI OS这样的名称。 这样就可以实现混合模式下开启安全启动。 但是,缺点也存在。我们知道Windows向来是霸主,不管用户死活,强制默认启动项就是Windows。上述设置后,Windows更新后,通常/EFI/Boot文件夹就会被覆盖,为什么,答案是没有为什么,三哥就想这么干。绝大多数情况下,用户不明所以就会认为云固件坏掉了,事实上是大佬抢了小弟的饭碗。 大家现在明白处理了吧,包括更新出现问题后如何恢复了吧。 最后说一下,云固件主程序下/EFI/Boot文件夹内容。这里面文件很多,核心通过UEFI规范的链式引导,bootx64.efi引导最终的grubx64_real.efi。这个文件其实就是MW.efi,大家理解了吧。
如何对Windows VHD本地启动做改进和优化? 在前面的文章《Windows VHD本地启动是什么?》里讲述了一下Windows VHD本地启动的基本概念和原理,在文末也做了一个灵魂拷问。 “VHD本地启动这项技术推出了快15年了,那你知道它的不足在哪里,又能如何弥补吗?”VHD本地启动涉及操作系统启动原理,能够深入了解的网友还是比较少的,现在来公布一下答案。 Windows VHD本地启动的方式有以下几个显而易见的不足: 1 只能支持Windows; 2 VHD或者VHDx文件只有系统分区,缺少引导分区,无法在虚拟机里面重复利用; 3 添加到引导菜单比较复杂,需要使用专用工具; 4 VHD系统受限于Windows策略,无法跨版本升级; 5 镜像文件路径受限于启动设置,更换分区或者硬盘就会造成配置实效,无法启动; 云固件的物理机启动虚拟磁盘的技术创新源于Windows 7带来的VHD本地启动(VHD Native Boot)想法。与之不同的是,云固件做了不少创新、增强和扩展。 云固件主程序是UEFI应用,不依赖具体操作系统,能够独立运行,可以保存在各种可引导的存储设备上,也可以刷入BIOS芯片。 对比Windows的VHD本地启动: • 使用了完整磁盘镜像,而不是半吊子的系统文件分区 • 使用明文的纯文本配置文件,简单直观 • 支持VHD/VHDx镜像文件内操作系统大版本升级 • 直接使用虚拟机镜像文件,不需要特殊制作 • 能够支持Windows以外的操作系统 对比基于GRUB的VHD启动扩展: • 无须改动grub配置文件 • initrd脚本可固化,和镜像文件名称和路径无关 • 支持内核升级 • 支持多种镜像文件格式,包括VHD、VHDx、IMG、VMDK、VDI、QCOW2等等 • 支持动态磁盘格式 • 使用软件仓库软件,不使用定制软件 另外,云固件主程序可任意部署到各种可引导的存储设备上,不人为制造麻烦。云固件镜像统一封装形式,统一使用方式,把复杂性留在镜像和配置内,使用者无需关心具体实现方式。
Windows VHD本地启动是什么? Windows VHD Native Boot是微软在Windows 7和Windows Server 2008 R2中引入的一项技术,允许操作系统直接从物理硬盘上的VHD(Virtual Hard Disk)文件启动。VHD是微软开发的虚拟磁盘格式,通过文件形式模拟物理硬盘的存储结构。当系统从VHD启动时,操作系统直接访问硬件资源(如显卡、驱动程序),而非运行在虚拟机环境中,其性能与物理硬盘启动相近。主要用途 1. 多系统共存与灵活部署 • 支持在同一台物理机上部署多个Windows系统(如Windows 7/Server 2008 R2的不同版本),通过VHD文件实现系统隔离,避免重新分区或破坏现有数据。 • 适用于开发、测试场景,可在单一硬件上快速切换不同环境,提升效率。 2. 系统备份与恢复 • 可将操作系统镜像保存为VHD文件,作为即时备份。结合Windows部署服务(WDS),可快速将VHD部署到多台计算机,简化系统部署与维护。 3. 无损安装与迁移 • 无需对现有硬盘重新分区,直接在VHD中安装新系统,降低操作风险。支持将VHD文件存储在本地硬盘、移动硬盘或网络存储中,方便迁移。 4. 虚拟化替代方案 • 为轻量级虚拟化需求提供替代,利用物理硬件资源,减少虚拟化软件的性能开销,适合资源受限的场景。 技术特点与限制 • 支持的系统版本:仅Windows 7 Enterprise、Ultimate,以及Windows Server 2008 R2(除Foundation版),当然后续的Windows 8/8.1/10/11各个版本都支持(VHD/VHDx)。 • 硬件与配置要求: • 硬盘引导需包含Windows 7的Boot Environment Files和BCD存储; • VHD文件类型推荐使用固定大小(性能更稳定),动态扩展需确保磁盘空间充足。 • 不支持的功能: • 系统休眠(Hibernation)、SMB共享保存的VHD卷、BitLocker加密、动态磁盘配置、软件RAID、父分区卷快照等。 关键工具与操作 • BCDboot:用于将启动文件复制到系统分区,创建BCD存储(启动配置数据)。 • Bcdedit:编辑启动菜单,添加VHD启动项。 • DiskPart:命令行工具,用于创建、分区、格式化VHD文件。 • Imagex:释放WIM镜像到VHD中,完成系统安装。 性能与注意事项 • 读写性能:读操作接近物理硬盘,写操作因缺乏缓存可能稍慢,但可通过优化配置缓解。 • 安全性与维护:需注意VHD文件所在卷无法加密,且父分区不支持快照,建议定期备份文件以防数据丢失。 总结 Windows VHD Native Boot通过将操作系统与虚拟磁盘结合,提供了灵活、高效的多系统管理方案,尤其适用于开发测试、快速部署及资源受限的场景。尽管存在功能限制,但其无损安装、硬件直通特性使其成为微软生态中实用的技术工具。 VHD本地启动这项技术推出了快15年了,那你知道它的不足在哪里,又能如何弥补吗?
UEFI引导过程分析 云固件支持复制主程序和复制镜像文件,就实现了电脑操作系统的安装。没有使用专用的安装程序,仅仅依靠最简单的复制文件实现操作系统安装,在传统BIOS和MBR磁盘分区表情况下是不可实现,但是UEFI为什么能够实现,这就离不开UEFI标准中对引导操作系统方式的规范定义。本文来说明一下UEFI引导操作系统的过程。UEFI全称为“统一可扩展固件接口”,启动操作系统的过程涉及几个关键步骤,如下所述: 1. 上电自检 (POST) 当计算机电源打开时,UEFI固件首先执行上电自检(Power-On Self-Test, POST)。这个过程检查并初始化基本硬件组件,确保它们正常工作,例如内存、硬盘、显卡等。 2. 初始化设备和驱动 UEFI固件会加载并初始化UEFI驱动程序,这些驱动程序允许固件与系统中的各种设备进行通信,比如存储设备、网络适配器等。 3. 读取启动配置 UEFI固件读取存储在固件中的启动配置数据。这些配置数据决定了启动顺序和启动选项。用户可以通过UEFI设置界面配置这些选项,例如选择启动设备、启用或禁用安全启动等。 4. 寻找启动分区 UEFI固件会按照配置的启动顺序查找启动设备。对于现代操作系统,通常使用GPT(GUID分区表)分区方案,UEFI会识别并定位到EFI系统分区(ESP)。 5. 加载启动文件 在EFI系统分区中,UEFI固件会寻找启动文件,通常是位于\EFI\Boot\bootx64.efi(对于64位系统)或者 \EFI\Microsoft\Boot\bootmgfw.efi(对于Windows系统)的启动加载程序。 这些启动文件是UEFI应用程序,负责加载操作系统的引导加载程序。 6. 加载操作系统引导加载程序 启动加载程序(如GRUB、Windows Boot Manager等)被加载并执行。这些引导加载程序负责加载操作系统的内核和初始化所需的驱动程序。 7. 传递控制权给操作系统 引导加载程序将控制权传递给操作系统的内核。此时,操作系统开始初始化其自身的驱动程序和系统服务,最终完成启动过程,用户界面出现,系统准备就绪。 8. 安全启动(可选) 如果启用了安全启动(Secure Boot),UEFI固件会验证启动文件和引导加载程序的数字签名,确保它们没有被篡改。只有经过认证的启动文件才能被加载,从而提供额外的安全层。 总结 UEFI启动过程是一个模块化和标准化的过程,它取代了传统的BIOS启动方式,提供了更高的灵活性、安全性和性能。UEFI通过读取启动配置、定位启动分区、加载启动文件和引导加载程序,最终将控制权传递给操作系统,从而完成启动过程。 在上面的启动过程中,可以看到UEFI BIOS不再读取硬盘的0扇区查找操作系统引导程序,改成查找ESP下的特定文件名的文件就可以引导。同时,引导程序还可以通过链式调用不断加载引导程序和需要的UEFI驱动程序。在这个引导方式的支持下,操作系统只需要复制成功对应的引导程序文件就可以启动了。 类似云固件这样的第三方引导程序也非常容易接入启动过程,在操作系统前先启动,从而实现引导VHD/VHDx镜像文件中的操作系统。
复制文件装电脑操作系统 通常情况下,安装电脑操作系统和应用软件都需要准备安装盘,包括ISO文件和PE工具盘,安装过程耗时也较长,也需要一定的技术能力。有没有更简单的方法来安装电脑操作系统呢? 云固件就是这样的方法,只需要复制文件就可以完成电脑操作系统的安装。 云固件分成两个部分。第一部分,就是操作系统的镜像文件,可以是Windows 10操作系统的文件,也可以是Linux操作系统的文件;第二部分,是云固件主程序,为启动镜像文件的操作系统专门开发的引导程序。 神奇的地方,这两个部分都可以通过简单的复制文件到对应的分区就可以完成安装。复制文件这个操作,可以在现有系统里面执行,也可以使用PE启动盘来执行,操作起来非常简单。 另外,主程序、镜像文件,可以安装到内置硬盘、移动硬盘、U盘或者移动固态硬盘。 云固件的镜像文件,一个镜像文件就是一个操作系统,多个镜像文件就是多个系统,这些系统不需要单独分区,共用一个分区都可以。 这就是云固件与众不同的地方!
学习和使用“云固件”要付费吗? 最近一直在折腾Linux下systemd的initrd和exitrd功能,systemd的文档和实际配置的效果对不上,花了大量时间查找解决方案,云固件文章和视频也就没有及时更新和录制。这段期间,云固件公众号上私信有很多询问云固件是否要收费的问题。 今天统一回复一下。首先,学习和使用云固件不需要付费! 云固件的主程序可以免费获取,常见的云固件镜像也可以在公众号上获取百度网盘、夸克网盘、123云盘的网盘分享链接。 以上三家网盘已经覆盖90%以上的用户群体,其他的网盘比如迅雷、蓝奏云、三大电信运营商等等,维护起来精力有限而且也需要成本支持,所以短期内不会增加其他网盘来分享资源。 当然,自建下载站点,提供网站下载和P2P下载,目前来看成本也是居高不下,因此也不会提供。 其次,云固件专业版授权为什么需要购买? 云固件主程序分成免费版和专业版,专业版是要收费的。软件属于知识产权,属于智力劳动成果。成果都意味着劳动付出,云固件的开发和维护都是需要付出巨大精力和成本的。在欧洲很多高福利的国家,有很多软件工程师可以免费分享软件成果。但是,在咱们国情下,大多数软件工程师都需要养活自己。因此,免费版和专业版这样的方式也是非常常见的。 对于绝大多数用户来说,免费版已经足够日常使用了。免费版和专业版目前来看,只有VHD/VHDx镜像数量上三个限制这个区别。只有当你需要使用超过3个以上VHD/VHDx镜像时才需要考虑购买专业版授权。甚至,你手动调整一下vd配置文件中镜像顺序,不购买授权也可以解决问题的,并非强制。 从目前售出的授权来看,绝大多数支持者都是觉得云固件使用体验好,支持我本人继续开发和维护云固件才购买授权。还有用户,购买了授权,然而并不提供待授权文件,纯纯的赞助! 第三,云固件镜像不是全部免费提供。 云固件镜像是云固件这种方式里面的核心资产。云固件主程序只是一个工具,真正的操作系统和应用都在云固件镜像里面。云固件镜像可以包罗各种操作系统,只要符合云固件主程序的启动逻辑就可以被云固件主程序启动。而且,云固件镜像也完全可以自制。因此,云固件镜像,不仅可以由我制作并提供,而且可以由爱好者自己制作自己使用,甚至可以由爱好者制作并销售。 制作云固件镜像的过程,需要耗费制作者的时间和精力,同时有些镜像制作还有技术难度。就像去电脑城找人装操作系统,一般情况便宜也付款30元。云固件镜像这样直接拿来就用的成果,付费获取也是对劳动的认可! 综上所述,云固件完全可以免费使用,玩得更简单可以支持小额费用,玩🉐好还可以从云固件镜像制作上赚钱,这就是云固件的商业逻辑!
Linux的云固件镜像vhdx文件启动之后再次启动失败原因分析 什么原因造成Linux的云固件镜像vhdx文件启动之后再次启动会失败? 核心原因是支持vhdx读写qemu-nbd程序在系统关机过程中被提前杀死,导致vhdx文件未能正确关闭。 那如何才能保证qemu-nbd不被杀? 目前看,需要满足systemd关闭系统时的设置要求,比如将进程名称的第一个字母改成@符合。 其次,qemu-nbd进程要不处理SIGTERM信号。 第三,在exitrd阶段,能进入这个阶段,同时shutdown脚本要主动关闭qemu-nbd进程,之后再安全卸载VDs分区。 以上这些内容完全实现,最终才能解决vhdx未正确关闭问题。
云固件吧吧主竞选:NO.0001号候选人
不能发文了吗? 发帖之后怎么都看不见了?
计算机操作系统“霸权主义”的滋味 今天咱们来讲一个计算机操作系统霸权的故事。 安装过云固件的朋友们,都知道云固件的部署模式分成四种,分别是外置模式、移动模式、独占模式和混合模式。这个故事和云固件独占模式有关系。云固件独占模式,就是计算机硬盘上只有云固件主程序这个唯一的引导程序,操作系统都是安装到了VHDx镜像文件里面,操作系统自己的引导程序也在VHDx镜像文件的ESP分区,注意是镜像文件的ESP分区,不是物理硬盘的ESP引导分区。 然后,有云固件微信群群友开始报告,说用得好好的云固件,Windows更新之后,重新启动,然后报错无法启动了,截屏发我一看,显示Windows引导程序的BCD文件丢失。 好嘛,云固件启动Windows镜像的BCD文件是云固件自动生成的,怎么可能丢失,让群友录像整个启动过程,竟然云固件启动界面都没有了,直接启动Windows,然后报错。 通过分析启动过程,可以发现云固件独占模式的计算机本来就应该只有云固件一个启动项,但是现在凭空多出来了Windows的引导启动项,并且还调整启动顺序,让Windows启动项排在第一位。 这是怎么回事呢? 这里面包含了两个关键点,第一,凭空多出来的Windows引导程序,第二,自动修改了启动顺序,这两个点缺一不可,只有这两个点都出现了,云固件独占模式下的第一顺序才会被改变。 咱们接下来分析,Windows引导程序怎么来的?聪明的网友,一定就猜出来了,肯定是Windows更新自动安装的。没错,必须是Windows自动更新带来的。可是,Windows更新,为什么外置模式、移动模式和混合模式不产生这种问题呢?外置模式和移动模式,云固件主程序是安装在外置存储设备上,内置硬盘应该包含Windows引导程序,所以Windows自动更新发现存在Windows引导程序,因此不会重新写入引导文件。混合模式,本身就是Windows引导程序和云固件主程序混用,而且云固件主程序还是单独添加的启动项,没有抢夺Windows的第一引导项,Windows自动更新也就不会再写入Windows引导文件。 通过这个分析,可以看到外置模式、移动模式和混合模式没有威胁到Windows的第一启动顺序项的地位。 但是,独占模式不一样了。桌面操作系统第一占有率的市场霸主,一看,TMD这台计算机竟然没有老子的引导项,这岂能忍受?哗哗哗的,不由分辨就给你把Windows引导程序写入内置硬盘的ESP分区了。当然,云固件的引导程序本身提供了/EFI/BOOT文件夹,三哥再过分,也不能覆盖/EFI/BOOT文件夹下云固件提供的引导文件。但是,为什么Windows却成了第一顺序引导呢? 这得说一下第二点,启动顺序的调整。 持续担当操作系统第一占有率的市场霸主,几十年下来,小弟无数。市场也默认计算机必须要安装Windows了。于是,各种主板厂商也是默认安装Windows是必须的。装机市场也是竞争激烈,而且电脑装系统还有各种不规范操作,为了降低售后服务成本,主板厂商甚至在BIOS里面做了调整,自动设置Windows为第一优先启动项。如果这台计算机没有安装windows,那么显然不能把Windows设置为第一启动项。那主板是如何判断的呢?就是通过检测ESP分区下是否有windows的引导程序文件bootmgfw.efi这个文件来实现的。 好巧不巧,上面第一点,霸权的三哥通过Windows自动更新强制给你写入了bootmgfw.efi,然后俯首甘为孺子牛的主板厂商就检测到了bootmgfw.efi,直接把Windows提升为第一启动顺序,管什么用户配置的云固件引导项,老子不认识你,不鸟你。 于是,Windows就成了这台计算机的第一引导项。 说到这里,大家明白整个过程了吧。话说,三哥和主板小弟把这启动的活整好了,也就没事了。可惜,偏偏三哥又掉链子了。Windows的引导程序文件都添加了,但是引导程序需要的配置文件BCD文件却没有添加。好端端凭空造了一辆法拉利,上路却发现没加油,让人笑掉大牙。至于为什么没有BCD文件,这里只能猜测了。云固件启动Windows后,Windows是运行在虚拟磁盘里面的,也就是不存在BCD配置文件需要的物理分区。于是,Windows自动更新程序发现无法创建成功BCD配置文件,估计多次尝试后,也无法成功,然后自动放弃创建了,留下了缺斤少两的Windows引导程序。 计算机重启的时候,阴差阳错的启动了缺少BCD配置文件的Windows引导程序,然后报错卡死在缺少BCD配置文件的Windows启动黑屏上了。 这计算机操作系统的大哥,遇到了初出茅庐的云固件,不给个下马威就不是大哥了,结果就坑惨了云固件用户了。 现在您明白了整个事情的来龙去脉,知道怎么解决这个问题了吗? 首先调整BIOS启动顺序,选择云固件启动项优先,就可以正常进入云固件了。其次,删除三哥创建的无效Windows引导程序文件。这样,就恢复如初了。 这时候,聪明的你就会问,Windows下次更新还会不会再出现这个问题呢?答案是,还会。那怎么办?有没有一劳永逸的解决方法?有的,咱们下个视频继续讲这个问题,挑战霸权主义!
计算机操作系统的霸权主义 安装过云固件的朋友们,都知道云固件的部署模式分成四种,分别是外置模式、移动模式、独占模式和混合模式。这个故事和云固件独占模式有关系。云固件独占模式,就是计算机硬盘上只有云固件主程序这个唯一的引导程序,操作系统都是安装到了VHDx镜像文件里面,操作系统自己的引导程序也在VHDx镜像文件的ESP分区,注意是镜像文件的ESP分区,不是物理硬盘的ESP引导分区。 然后,有云固件微信群群友开始报告,说用得好好的云固件,Windows更新之后,重新启动,然后报错无法启动了,截屏发我一看,显示Windows引导程序的BCD文件丢失。 好嘛,云固件启动Windows镜像的BCD文件是云固件自动生成的,怎么可能丢失,让群友录像整个启动过程,竟然云固件启动界面都没有了,直接启动Windows,然后报错。 通过分析启动过程,可以发现云固件独占模式的计算机本来就应该只有云固件一个启动项,但是现在凭空多出来了Windows的引导启动项,并且还调整启动顺序,让Windows启动项排在第一位。 这是怎么回事呢? 这里面包含了两个关键点,第一,凭空多出来的Windows引导程序,第二,自动修改了启动顺序,这两个点缺一不可,只有这两个点都出现了,云固件独占模式下的第一顺序才会被改变。 咱们接下来分析,Windows引导程序怎么来的? 聪明的网友,一定就猜出来了,肯定是Windows更新自动安装的。没错,必须是Windows自动更新带来的。可是,Windows更新,为什么外置模式、移动模式和混合模式不产生这种问题呢?外置模式和移动模式,云固件主程序是安装在外置存储设备上,内置硬盘应该包含Windows引导程序,所以Windows自动更新发现存在Windows引导程序,因此不会重新写入引导文件。混合模式,本身就是Windows引导程序和云固件主程序混用,而且云固件主程序还是单独添加的启动项,没有抢夺Windows的第一引导项,Windows自动更新也就不会再写入Windows引导文件。 通过这个分析,可以看到外置模式、移动模式和混合模式没有威胁到Windows的第一启动顺序项的地位。 但是,独占模式不一样了。桌面操作系统第一占有率的市场霸主,一看,TMD这台计算机竟然没有老子的引导项,这岂能忍受?哗哗哗的,不由分辨就给你把Windows引导程序写入内置硬盘的ESP分区了。当然,云固件的引导程序本身提供了/EFI/BOOT文件夹,三哥再过分,也不能覆盖/EFI/BOOT文件夹下云固件提供的引导文件。但是,为什么Windows却成了第一顺序引导呢? 这得说一下第二点,启动顺序的调整。 持续担当操作系统第一占有率的市场霸主,几十年下来,小弟无数。市场也默认计算机必须要安装Windows了。于是,各种主板厂商也是默认安装Windows是必须的。装机市场也是竞争激烈,而且电脑装系统还有各种不规范操作,为了降低售后服务成本,主板厂商甚至在BIOS里面做了调整,自动设置Windows为第一优先启动项。如果这台计算机没有安装windows,那么显然不能把Windows设置为第一启动项。那主板是如何判断的呢?就是通过检测ESP分区下是否有windows的引导程序文件bootmgfw.efi这个文件来实现的。 好巧不巧,上面第一点,霸权的三哥通过Windows自动更新强制给你写入了bootmgfw.efi,然后俯首甘为孺子牛的主板厂商就检测到了bootmgfw.efi,直接把Windows提升为第一启动顺序,管什么用户配置的云固件引导项,老子不认识你,不鸟你。 于是,Windows就成了这台计算机的第一引导项。 说到这里,大家明白整个过程了吧。话说,三哥和主板小弟把这启动的活整好了,也就没事了。可惜,偏偏三哥又掉链子了。Windows的引导程序文件都添加了,但是引导程序需要的配置文件BCD文件却没有添加。好端端凭空造了一辆法拉利,上路却发现没加油,让人笑掉大牙。至于为什么没有BCD文件,这里只能猜测了。云固件启动Windows后,Windows是运行在虚拟磁盘里面的,也就是不存在BCD配置文件需要的物理分区。于是,Windows自动更新程序发现无法创建成功BCD配置文件,估计多次尝试后,也无法成功,然后自动放弃创建了,留下了缺斤少两的Windows引导程序。 计算机重启的时候,阴差阳错的启动了缺少BCD配置文件的Windows引导程序,然后报错卡死在缺少BCD配置文件的Windows启动黑屏上了。 这计算机操作系统的大哥,遇到了初出茅庐的云固件,不给个下马威就不是大哥了,结果就坑惨了云固件用户了。 现在您明白了整个事情的来龙去脉,知道怎么解决这个问题了吗? 首先调整BIOS启动顺序,选择云固件启动项优先,就可以正常进入云固件了。其次,删除三哥创建的无效Windows引导程序文件。这样,就恢复如初了。 这时候,聪明的你就会问,Windows下次更新还会不会再出现这个问题呢?答案是,还会。那怎么办?有没有一劳永逸的解决方法?有的,咱们后面继续讲这个问题,挑战霸权主义!
品牌机,自带正版Windows,用了云固件,如何激活 美好的周末,又生生被干无语了。有云固件用户,周六一早就私信问我,Windows怎么激活? 因为我一般都是晚上干活,所以睡觉一般都是凌晨了。 看到微信单聊,迷迷糊糊看了一眼,不是云固件本身问题,所以就继续睡了。 等睡醒,一看,“老人家”不乐意了,说我不搭理人家,爱理不理。 我就想,激活,这种事情,能轻易开口回答嘛,好歹我也是靠知识产权获益的。 这种事情大家都懂的。 激活问题,唯一能回答的就是“品牌机,原装系统是正版激活,现在安装了云固件镜像,怎么还原激活”? 目前购买的家用品牌机,通常包含Windows家庭版或者家庭单语言(中文版)的OEM激活,这种激活是通过在BIOS里面内嵌了一个数据字段来实现。 也就是说,你重新安装系统,格式化硬盘,不会删除这个标记数据。即使是升级BIOS,厂商的升级包也会保留这个数据。因此,只要安装对应版本的Windows 10/11,就可以实现联网自动激活,无须人工干预。如上图,安装云固件镜像后,Windows 10家庭版就自动激活了,激活方式是数字许可证。 版本安装错误的话,数字许可证无法对应,就不能激活了。 建议大家购买和使用正版软件,保护知识产权!
自制个带网络功能的Windows PE云固件镜像 最近云固件新增关注比较多,新手也比较多,提出来的要求也比较奇葩,不回答糟心,回答了堵心,太难了。。。前面有文章讲解过了云固件整合包里面微PE的新式镜像打包方法《云固件整合包里面微PE的wim文件是怎么启动的?》。 有“爱好者”提出了需求,微PE没有网络功能,能不能换成带网络功能的PE。 我说有很多PE,参考微PE原来的ISO镜像方法就可以了。 “爱好者”又说了,ISO不能放ESP分区,无法启动。 确实,有很多机器不支持。那就参考微PE整合包做一个就行,参考上面的文章就行。 “爱好者”又说,不会做。 我说没时间做这个,自己动动手就行,我忙着调试专业版的bug呢。 “爱好者”又说,服务态度太差。 。。。。。。 好吧,我没招了,那就做一个,能不能看懂就别再来烦我了。 随便找了个带网络功能的PE,是ISO文件,很多年前用过,犄角旮旯里翻出来的。 新建一个“MyPE”文件夹,当作工作文件夹。 将整合包微PE里面的menu.config文件复制过来。 改改图标和名字,得到这样的内容。我这里复制了一个新的图标文件。原来bootmgfw.efi文件有个命名错误,现在改正过来。(bootmgrfw.efi => bootmgfw.efi)用解压软件打开ISO文件,将里面boot文件夹下的boot.wim、boot.sdi、BCD三个文件复制到MyPE文件夹根目录下。现在得到这样的目录结构。文件搜集完毕,最后修改一下BCD文件,就大功告成了。 用Bootice工具打开MyPE文件夹下的BCD文件。按照图片红框中修改文件夹为MyPE即可,两处都要修改,改完保存即可。 至此,WIM格式的PE镜像就制作完成了。 添加到vd.config配置文件,测试验证。 启动云固件,可以看到新增的My PE镜像。启动后,就可以进入PE,看到有网络功能了。
云固件镜像启动的Windows 10无法安装vmware workstation虚拟机? 用云固件启动的Windows 10,包括Windows 11,不能安装vmware workstation虚拟机软件?确实会遇到这样的情况。 云固件新版24978开始,更改了Windows引导的内置辅助镜像,同时也更新了其中的BCD文件设置,增加了“hypervisorlaunchtype”为“auto”设置。 默认情况下,通常会自适应开启或者关闭。但是,在某些特定主机或者主板上,这个设置有出现默认开启的情况。 于是,vmware workstation虚拟机就无法安装了。 但是,云固件镜像启动的Windows 10/11,并不存在BCD文件,或者准确的说,不存在单独在外的BCD文件。因为这个BCD文件只是启动镜像的时候,在内存里出现一下后就消失了。 那针对这个问题如何解决呢? 云固件默认的启动辅助文件可以修改,但是这样就会影响全部的镜像启动。 于是,可以启动针对单个镜像启动的helper指令来调整这个镜像启动的BCD设置。 修改过的helper辅助启动镜像,已经保存在云固件演练场里面,大家可以直接使用。 路径在“WinHelper”下“VM.7z”文件,解压后得到VM.HPR文件。 将这个文件复制到需要安装vmware的镜像文件夹下,和vhdx文件同一级目录。修改menu.config配置文件,增加helper一行,如下图所示,其他内容保持原来设置不变即可,注意不是全部复制上面例子里面的设置。 重新启动计算机,选择这个镜像启动,再继续安装vmware workstation就没有问题了。
云固件新版本r1.6.24989 最近新增关注云固件的同学比较多,一些老机器还在使用MBR分区表,老版本的云固件是不支持MBR分区表磁盘存储镜像的,24989开始已经支持了。其实24989版本早就发布了,就在24988发布之后,由于云固件的正式版是历经一段时间测试后才会转的,因此就没想在一个正式版之后立即发布一个替代的正式版,所以24989发布到了测试版文件夹中。 实际上,24989版本也已经达到正式版的稳定性,目前销售的云固件快优,包括增强版和入门版,都是使用24989的整合包。 24989和24988两个版本,最大区别就是,24989版本已经支持MBR分区表硬盘,云固件镜像可以存储在MBR分区表硬盘分区里面,包括MBR的扩展分区,Windows镜像和Linux镜像都可以启动的。 这里稍微解释一下为什么原来不支持MBR分区表硬盘。 云固件主程序是UEFI程序,UEFI环境要求使用GPT分区表,而且云固件主程序要求安装到ESP分区中,这个ESP分区在MBR分区表硬盘上是不存在。既然不存在,那么就无须支持古老的MBR分区表了。 另外,镜像存储在MBR分区表硬盘分区内,硬盘分区的标记方法与GPT分区表硬盘分区完全不同,Windows引导的BCD文件书写格式也不同,所以需要重新“hack”,Linux镜像内传递的硬盘分区信息也需要重新实现。 基于以上原因,之前的云固件主程序就没支持MBR分区表。 现在,这个限制已经不存在了,还存在MBR分区表硬盘的爱好者可以更新到24989版本,更新方法就是覆盖原来版本即可。如果原先版本是24512或者更早版本,那么需要先删除,再重新复制全部文件到ESP分区。
云固件来贴吧了 贴吧项目启动时我就在百度任职,今天我也来创建自己的第一个贴吧了
1
下一页