![快速启动 Chromium-only Linux](https://linux22.com/image/214604/%E5%BF%AB%E9%80%9F%E5%90%AF%E5%8A%A8%20Chromium-only%20Linux.png)
我有一个控制器,它通过 HTTP 作为单页应用程序 (SPA) 提供 GUI/Cockpit 视图。
我的项目现在是拥有一台驾驶舱计算机来显示这个“网站”(SPA),仅此而已。
我需要一个启动速度超快的 Linux,理想情况下是 10-15 秒,进入 Chromium。
...因为没有人愿意等半分钟才能看到发动机数据(如现代汽车中的 HUD 显示屏)。
这个 Linux 系统上除了
- 带有 Intel 驱动程序的 Xorg
- 铬
在 Intel Atom x5-Z8350 x64 上运行。 EFI 需要 1 秒。
我已经尝试过裸露的 Debian,但我只能将其缩短到 24 秒(开机到页面加载)
有人能指出我正确的方向吗?是否有一个发行版完全适合我的用例?我不知道这样的东西的搜索词。
Systemd-analyze plot
:
我制作了启动过程的视频。当测试站点显示黄色的“two.js”文本时,系统就会启动。
答案1
根据查看生成的 SVG,优化 systemd 系统上的启动过程通常效果很好systemd-analyze
;你甚至不需要root权限,IIRC:
systemd-analyze plot > boot.svg
firefox boot.svg
现在,如果您认为您确实已禁用甚至屏蔽了所有不需要的 systemd 单元,并且没有什么可做的,例如延迟安装网络文件系统或硬编码 IPv4 地址,而不是等待 DHCP,另一件需要时间的事情是存储启动。例如,根据我的经验,Ext4 在启动时检查其日志的时间往往比 XFS 长一些,但我认为这在 eMMC 上不会很明显。可能产生更大影响的是使用压缩的根文件系统:加载整个操作系统,甚至更糟糕的是从未压缩的 eMMC 中的 chromium 可能比解压它需要更长的时间;我敢打赌瓶颈是存储带宽,而不是 CPU 能力。 Btrfs和ZFS支持压缩;我认为对于 eMMC 设备,将 /(或 /usr,也许还有 /var)驻留在带有 zstd 压缩的 F2FS 上(需要 Linux >= 5.7;否则使用默认的 LZO)将是一个明智的选择;它针对该用例进行了大量优化。
例如,我在所有系统上使用 LVM(原则上不适用。我只是不想再次处理“哦,如果我可以跨磁盘扩展此文件系统”或“没有安全的方法来执行此操作”)在线备份”,而且由于糟糕的经历,我不信任 btrfs,可悲的是);必须扫描所有存储设备中的物理卷。您可以使用和部分中的指令/etc/lvm/lvm.conf
来限制扫描;请参阅您的.filter
global_filter
devices
/etc/lvm/lvm.conf
如果这一切都没有帮助,并且您的 debian 只依赖于让您的系统等待的服务,处于关键路径中,如 所示systemd-analyze critical-chain
,那么,好吧,也许 debian 对您来说真的太多了! (有可能的是:您可以再减少几个百分点,但在所有可避免的阻碍因素之后,具有相同功能的系统不会神奇地以三倍的速度启动)。
但如果您想尝试:汽车信息娱乐系统的几乎标准方法是制作您自己的开放式嵌入式发行版! OpenEmbedded 附带了一个默认的 x86 示例,该示例与您所做的没有太大不同。我敢打赌,某个地方有人已经编写了一些有关如何构建信息亭系统的文档;)
(除了它的根源之外,我对 buildroot 没有任何经验,这些仍然让我不太喜欢它;))