将我的 chromebook 更新到最新的开发版本 ( Version 59.0.3071.25 dev) 后，它会在启动时出现正常的登录提示，但一旦我输入密码和第二个因素 (Yubikey)，它就会要求输入“我的 Chromebook 的旧密码”。自 2012 年以来，我没有更改过我的 Google 密码（在https://myaccount.google.com/security），显然这是我用来登录这台 Chromebook 的唯一密码。我尝试了我使用过的所有其他未使用密码管理器的密码，并且我已经尝试了数十次我的实际 Google 密码，并且即使在打开和关闭大写锁定的情况下也尝试了所有这些密码。
有趣的是，谷歌安全似乎认为我是从Google Chromebook Pixel (2015)（编辑：我不是在 Chromebook Pixel 上，而是在 HP Chromebook 13 G1 上）登录的；当我去https://myaccount.google.com/device-activity，它提到 Pixel 是昨晚最后一次使用，这是我最后一次尝试使用常规帐户登录；我今天可以再次尝试确认，但我几乎可以肯定这是我，而不是拥有我帐户的人。
其他可能相关的信息：我处于开发者模式，我可以访问我的 chroot，我可以访问我的 Google 帐户（从访客模式）。
我怀疑这是 ChromeOS 端的一个错误，但如果有某种方法可以手动挂载我的主目录，我可以将所有数据保存在外部驱动器上并擦除它并再次正常访问我的帐户。
答案1
抱歉，我没有为您提供完整的解决方案，仅在最后提出解决方法的建议以及我在探索时发现的一些内容。
我正在寻找如何挂载encrypted.block我找到的文件，但除此之外我找不到详细信息错误报告。没有关于加密存储的详细信息磁盘格式要么，但看起来之前已经问过一个非常相似的问题在 Chrubuntu 中挂载加密的 ChromeOS 分区。我在安装有状态分区后运行了file该文件，但它只是在我的 GalliumOS 安装上说的。看起来有状态分区上的加密存储只是以一种我以前从未见过的特定方式使用 ecryptfs（尽管我确实将 ecryptfs 用于不仅仅是每个用户加密的主目录）。 TPM 也可能用于解密分区，这是有道理的，但我对此不确定。encrypted.blockdata
以下是使用 ecryptfs_sig 和 ecryptfs_fnek_sig 编辑的挂载的重要部分：
/dev/mmcblk0p1 on /mnt/stateful_partition type ext4 (rw,nosuid,nodev,noexec,relatime,seclabel,commit=600,data=ordered)
/dev/mmcblk0p1 on /home type ext4 (rw,nosuid,nodev,noexec,relatime,seclabel,commit=600,data=ordered)
/dev/mapper/encstateful on /mnt/stateful_partition/encrypted type ext4 (rw,nosuid,nodev,noexec,relatime,seclabel,discard,commit=600,data=ordered)
/dev/mapper/encstateful on /var type ext4 (rw,nosuid,nodev,noexec,relatime,seclabel,discard,commit=600,data=ordered)
/dev/mapper/encstateful on /home/chronos type ext4 (rw,nosuid,nodev,noexec,relatime,seclabel,discard,commit=600,data=ordered)
/dev/mmcblk0p1 on /usr/local type ext4 (rw,nodev,relatime,seclabel,commit=600,data=ordered)
/home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/vault on /home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/mount type ecryptfs (rw,nosuid,nodev,noexec,relatime,seclabel,ecryptfs_sig=1234567890abcdef,ecryptfs_fnek_sig=f1234567890abcde,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
/home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/vault on /home/chronos/user type ecryptfs (rw,nosuid,nodev,noexec,relatime,seclabel,ecryptfs_sig=1234567890abcdef,ecryptfs_fnek_sig=f1234567890abcde,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
/home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/vault on /home/user/0b00d80cb6b214a4a8f2d0094a1de796a15a9623 type ecryptfs (rw,nosuid,nodev,noexec,relatime,seclabel,ecryptfs_sig=1234567890abcdef,ecryptfs_fnek_sig=f1234567890abcde,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
/home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/vault on /home/chronos/u-0b00d80cb6b214a4a8f2d0094a1de796a15a9623 type ecryptfs (rw,nosuid,nodev,noexec,relatime,seclabel,ecryptfs_sig=1234567890abcdef,ecryptfs_fnek_sig=f1234567890abcde,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
/home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/vault on /home/root/0b00d80cb6b214a4a8f2d0094a1de796a15a9623 type ecryptfs (rw,nosuid,nodev,noexec,relatime,seclabel,ecryptfs_sig=1234567890abcdef,ecryptfs_fnek_sig=f1234567890abcde,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
这是 lsblk 的输出：
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 7.5G 0 disk
└─sda1 8:1 1 7.5G 0 part /media/removable/SANDISK
loop0 7:0 0 581.6M 0 loop
└─encstateful 253:1 0 581.6M 0 dm /mnt/stateful_partition/encrypted
loop1 7:1 0 402.3M 1 loop /opt/google/containers/android/rootfs/root
loop2 7:2 0 48.8M 1 loop /opt/google/containers/android/rootfs/root/vendor
loop3 7:3 0 4K 1 loop /opt/google/containers/arc-removable-media/mountpoints/container-root
loop4 7:4 0 4K 1 loop /opt/google/containers/arc-sdcard/mountpoints/container-root
loop5 7:5 0 4K 1 loop /opt/google/containers/arc-obb-mounter/mountpoints/container-root
zram0 252:0 0 2.8G 0 disk [SWAP]
mmcblk0rpmb 179:48 0 4M 0 disk
mmcblk0boot0 179:16 0 4M 1 disk
mmcblk0boot1 179:32 0 4M 1 disk
mmcblk0 179:0 0 29.1G 0 disk
├─mmcblk0p1 179:1 0 2G 0 part /mnt/stateful_partition
├─mmcblk0p2 179:2 0 16M 0 part
├─mmcblk0p3 179:3 0 2G 0 part
├─mmcblk0p4 179:4 16M 0 part
├─mmcblk0p5 179:5 2G 0 part
├─mmcblk0p6 179:6 16M 0 part
├─mmcblk0p7 179:7 23G 0 part
├─mmcblk0p8 179:8 16M 0 part /usr/share/oem
├─mmcblk0p9 179:9 512B 0 part
├─mmcblk0p10 179:10 512B 0 part
├─mmcblk0p11 179:11 8M 0 part
└─mmcblk0p12 179:12 16M 0 part
再想一想，您可以尝试以下方法：转储包括分区表在内的整个磁盘（您可以使用实时媒体中的 gnome 磁盘），让另一台计算机和备用磁盘运行ArnoldTheBbat 的 Chromium OS 特殊构建，检查它运行时是否没有缺陷，然后将有状态分区（通常是最大的分区）复制到此测试设置的有状态分区上。理论上这应该可以恢复您的文件，但我不知道您在这里遇到了哪个错误。