私のChromebookを最新の開発版（Version 59.0.3071.25 dev）に更新した後、通常のログインプロンプトで始まりますが、パスワードと2番目の要素（Yubikey）を入力するとすぐに、「私のChromebookの古いパスワード」の入力を求められます。 2012年以降にGoogleパスワードを変更したことはありません。https://myaccount.google.com/security）これは私がこのChromebookにログインするために使用する唯一のパスワードのようです。パスワードマネージャを使用していない他のすべてのパスワードを試してみましたが、実際のGoogleパスワードも何十回も試してみました。
Google Chromebook Pixel (2015)興味深いことに、Googleセキュリティは私がログインしていると思うようです（編集：私はChromebook PixelではなくHP Chromebook 13 G1を使用しています）。https://myaccount.google.com/device-activity、Pixelが昨夜最後に使用されたと言われています。これは私が通常のアカウントで最後にログインしようとしたときでした。確認のために今日再試行することができますが、私のアカウントを持っている人ではなく、私がしたことはほぼ確実です。 。
関連する可能性があるその他の情報：私は開発者モードにあり、私のchrootにアクセスでき、私のGoogleアカウントにアクセスできます（ゲストモードで）。
私はこれがChromeOS側のバグだと思いますが、ホームディレクトリを手動でマウントする方法がある場合は、すべてのデータを外部ドライブに保存して消去し、自分のアカウントに再び正常にアクセスできます。
ベストアンサー1
申し訳ありません。完全な解決策はありません。解決策の提案とナビゲーション中に見つけたものはいくつかあります。
見つかったファイルをマウントする方法を探していますが、他encrypted.blockにも詳細はありません。エラーレポート。暗号化されたストレージに関する詳細はありません。ディスクフォーマットでも、以前にも同様の質問があったようです。Chrubuntuで暗号化されたChromeOSパーティションのマウント。ステートフルパーティションをインストールした後、このファイルを実行しましたが、fileGaliumOSインストールでのみそのファイルが表示されました。ステートフルパーティションの暗号化されたストレージは、以前に見たことのない特定の方法で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特殊ビルド、障害なしで実行されていることを確認してから、ステートフルパーティション（通常は最大のパーティション）をこのテスト設定のステートフルパーティションにコピーします。理論的にはファイルを復元する必要がありますが、ここでどのようなエラーが発生するのかわかりません。