兄弟，别慌！我遇到过几乎一模一样的情况，这大概率不是系统彻底挂了，核心问题是分区UUID变化导致Ubuntu挂载配置失效，咱们一步步来解决：

问题原因拆解 #

你在Windows里把那个372GB的ext4分区格式化成NTFS后，这个分区的唯一识别码（UUID）完全改变了，但Ubuntu的/etc/fstab文件里还保留着原来ext4分区的UUID配置。开机时系统会严格按照fstab里的配置去挂载分区，结果找不到对应UUID的分区，直接触发文件系统检查失败，进入维护模式。至于那个奇怪的内存提示，只是挂载失败引发的系统初始化异常，和你32GB内存毫无关系，不用管它。

补充一句：Windows格式化Linux分区时，偶尔会调整GPT分区表的小属性，但这次的核心矛盾还是UUID不匹配导致的挂载失败。

恢复步骤 #

方法1：直接在维护模式修改配置 #

1. 进入维护模式后，输入你的Ubuntu root用户密码（如果没设置过，就用下面的Live启动方法）。
2. 打开fstab编辑：nano /etc/fstab
3. 在文件里找到对应那个372GB分区的挂载条目（可以通过挂载点或旧UUID识别，比如原来的挂载点是/data之类的），在这一行开头加#把它注释掉。
4. 按Ctrl+O保存，Ctrl+X退出编辑器。
5. 输入systemctl default尝试回到正常启动流程，或者输入reboot重启，应该就能正常进入Ubuntu了。

方法2：用Ubuntu安装盘Live启动修复（如果维护模式进不去） #

1. 插入Ubuntu 22.10安装U盘，选择「试用Ubuntu」进入Live系统。
2. 打开终端，用lsblk命令找到你的Ubuntu系统分区（就是那个244GB的/分区，比如/dev/nvme0n1p5）。
3. 挂载系统分区：sudo mount /dev/xxx /mnt（把xxx换成你的系统分区设备名）
4. 挂载EFI分区（UEFI启动必做）：sudo mount /dev/xxx /mnt/boot/efi（xxx是你的EFI分区，比如/dev/nvme0n1p1）
5. 切换到系统环境：sudo chroot /mnt
6. 接下来和方法1一样，编辑/etc/fstab注释旧分区条目，保存后退出chroot，重启系统即可。

后续：恢复NTFS分区的自动挂载 #

如果之后想把这个NTFS分区挂载到Ubuntu里，按这几步来：

1. 进入Ubuntu后，用blkid命令找到NTFS分区的新UUID（输出里会有UUID="xxxx-xxxx" TYPE="ntfs"的行）。
2. 先创建挂载目录：sudo mkdir /mnt/data
3. 编辑/etc/fstab，添加一行：UUID=xxxx-xxxx /mnt/data ntfs-3g defaults,uid=1000,gid=1000 0 0（把xxxx-xxxx换成实际UUID）
4. 执行sudo mount -a测试挂载是否正常，之后开机就会自动挂载了。

避坑提醒 #

以后跨系统格式化分区时，记得先在Ubuntu里把对应的挂载条目从fstab里注释掉，再去Windows操作。另外，建议关闭Windows的「快速启动」功能，它会把磁盘置于休眠锁定状态，容易导致Linux无法正常访问分区，甚至损坏文件系统。

备注：内容来源于stack exchange，提问作者Mark