我最近从 Ubuntu 18.04 升级到了 Ubuntu 20.04，打算迁移到 Ubuntu 22.04，因为我已经落后了。
我的根文件系统是 BTRFS，分布在三个设备上，其中一些设备已分区。
其中一个这样的“设备”是/dev/sdb10，它包含部分根文件系统。
一开始，我没有遇到任何问题。
然后，dist-upgrade在 18.04 中的某些时候，启动会失败。我将其添加root=/dev/sdb10到内核命令行，然后它开始工作。文件系统本身没有错误，所以像往常一样发生了一些变化。
从那时起，我已经运行并do-release-upgrade成功完成。
重启后系统会(initramfs)报告以下情况：
Alert!! /dev/sdb10 does not exist !!（或类似效果的词语）。
ls /dev/sdb*表明它确实存在。
dmesg表明 BTRFS 扫描确实在启动期间无法找到该分区，但它确实存在。
启动 GParted Live 1.4.0-5 时会出现类似问题：我无法挂载此文件系统，并且 GParted 给出了有关分区的误导性信息。（尽管我可以在缺少设备的情况下以降级方式挂载它，但这没什么用）。
但是，运行btrfs dev scanfinds/dev/sdb10后我可以毫无问题地挂载文件系统。
所以我很困惑。我尝试过寻找强制“扫描”找到此分区的方法，包括添加所有设备，fstab但没有任何效果。
我甚至搞不清楚是什么在进行这种“扫描”。它是 initramfs 的一部分吗？udev？还是某个脚本？我不知道从哪里开始！
Windows 10 的 BTRFS 驱动程序（我用来编写本文的驱动程序）可以毫无问题地找到整个文件系统，并且始终如此。
我尝试向内核命令行添加一些 udev 调试标志，但是对于回滚缓冲区来说，它们太多了，并且都没有保存在任何地方（它没有出现在dmesg）。
帮助！
答案1
深入研究各种脚本后，我终于找到了使系统恢复工作状态的解决方案。
#!/bin/sh
set -e
modprobe btrfs
/bin/btrfs device scan
# Required because `btrfs device scan` doesn't appear
# to scan past 9 partitions!
/bin/btrfs device ready /dev/sdb10
我认为这是一个解决方法，并怀疑有一个错误（或糟糕的设计选择）等待报告。
理想情况下，我会先拉入/usr/share/initramfs-tools/scripts/local-premount，但我不知道如何在不弄乱hooks目录中的脚本的情况下做到这一点。这可能是我将来最终要做的事情。
这也意味着我可以root=/dev/sdb10从内核命令行中删除。
答案2
我遇到了完全相同的问题，并且发现 nvme 编号不稳定（我在 linux 的两个 BTRFS 之间处于 raid 1 中，第三个是 windows）。有时 windows 和镜像 btrfs 会更改系统 nvme 编号...
我试过你的想法，但它对启动恢复也没有帮助。由于不稳定，我添加了 by-uuid，但没有成功