Multipass在M1/M3芯片Mac上的文件系统只读问题分析与解决

问题现象

在使用Multipass虚拟化管理工具在Apple Silicon(M1/M3)芯片的Mac电脑上创建Ubuntu虚拟机实例时，用户报告了一个严重问题：虚拟机在重启后会变为只读状态。具体表现为无法创建新文件、无法执行apt更新等写操作，系统日志显示文件系统错误。

根本原因分析

经过技术分析，这个问题主要由以下几个因素导致：

1. 文件系统损坏：系统日志(dmesg)显示EXT4文件系统出现校验错误，特别是system.journal文件损坏，导致系统自动以只读模式重新挂载。

2. 非正常关机：当Mac系统休眠或关机时，如果Multipass实例没有完全挂起或关闭，可能导致磁盘镜像文件损坏。Mac系统有时会强制终止长时间运行的任务，这增加了损坏风险。

3. 磁盘层叠问题：Multipass使用qcow2格式的磁盘镜像，这种格式本身就存在一定的脆弱性，特别是在非正常关机情况下。

技术细节

从日志中可以观察到以下关键错误信息：

• EXT4-fs error (device sda1): ext4_validate_block_bitmap - 块位图校验失败
• Journal file corrupted, rotating - 日志文件损坏
• Detected aborted journal - 日志异常终止
• Remounting filesystem read-only - 系统自动以只读模式重新挂载

这些错误表明文件系统元数据已损坏，Linux内核作为一种保护机制，会自动将文件系统挂载为只读模式以防止进一步损坏。

解决方案

临时解决方案

1. 使用快照功能：Multipass提供了快照功能，可以在实例正常工作时创建快照：

   multipass snapshot create 实例名称 快照名称
   

   出现问题时可以恢复快照：

   multipass snapshot restore 实例名称 快照名称
   

2. 手动修复文件系统：

   • 停止实例
   • 使用qemu-img检查镜像完整性
   • 在主机上运行磁盘修复工具

长期解决方案

1. 规范关机流程：在Mac关机或重启前，先手动停止或暂停Multipass实例：

   multipass stop 实例名称
   

   或

   multipass suspend 实例名称
   

2. 定期维护：

   • 定期检查实例状态
   • 避免创建过长的快照链，这会影响性能
   • 考虑将重要数据存储在挂载的目录中而非实例内部

3. 系统级检查：

   • 检查Mac主机的SSD健康状况
   • 确保有足够的磁盘空间
   • 考虑重置Mac系统或进行磁盘修复

最佳实践建议

1. 快照策略：为重要实例设置定期快照计划，但注意不要创建过多快照链。

2. 监控日志：定期检查实例的系统日志(dmesg)和Multipass日志，及早发现问题。

3. 资源分配：确保为Multipass实例分配足够的资源(特别是磁盘空间)，避免因资源不足导致问题。

4. 备份策略：重要数据应存储在挂载目录或单独备份，因为快照和实例存储在同一个物理磁盘上，不能替代真正的备份。

通过以上措施，用户可以在Apple Silicon芯片的Mac上更稳定地使用Multipass运行Linux虚拟机，避免文件系统损坏导致的数据丢失和服务中断。