Raspberry Piは、NOOBSによるインストールやOSイメージをダウンロード、ddや適切なコピーツールを使い、バージョンによって可能なmicroSDカードやUSBメモリなどに書き込めば、何事もなく起動します。
ただ、一度書き込んだラズパイ用ブートデバイスから他のデバイスにコピーしようと思った場合、コピー先デバイスにパーティションを切ってフォーマットし、rsyncを使ったりすると起動しなくて一瞬、あたふたすることも。
[random crng init done.]なんてメッセージが出て、そこでいつまで経っても止まっている場合は、ブートデバイスが不明である(指定されているデバイスが異なる)ことが原因と考えて良いでしょう。
自身は、まさにrsyncした時にこれに遭遇。
原因は、cmdline.txtやコピー先の/etc/fstabのPARTUUIDやUUIDが実際と異なることでした。
異なるデバイス・メディアに中身だけコピーした為、一意な識別子であるUUIDも異なるのは当然ですよね。
尚、デフォルトでUSBブートできるRaspberry Pi 3 Model B+では、/boot/cmdline.txtに[/dev/mmcblk0pX]や[/dev/sdaX]ではなく、PARTUUIDで指定されていました。
編集用にしているパソコンでblkid /dev/sdbXして得たPARTUUIDやUUIDで、それぞれマウント後、/boot/cmdline.txtや/etc/fstabに反映すべく、修正すれば、OK。
swap領域作ってswap onしたのに/etc/fstabに書いてなかったりすると、一瞬、[a start job is running for dev-desk-by...]というメッセージが表示され、1分30秒カウントし始めたと思いきや、スキップして起動したりします。
ブート時に[a start job is running for ...]と表示され、1分30秒きっちり待たされる場合は、まさにUUIDが異なっているので修正します。
ちなみに、この時は、がんばって起動してくれるはずなので起動後に修正可能です。
自身が今回rsyncすることにしたのは、サイズの異なるパーティション間でコピーすべく、ddのコマンドラインオプションbs、countの指定を間違えたようで2回ほどセクタが干渉しているとかで失敗したからです。
そうだとするとGPartedなどパーティショニングソフト上でエラーが表示されるはずで、この場合は、他の手段含め、やり直すしかなさそうです。
e2fsckとresize2fsを使って修復する方法もあります。
が、自身のエラーの場合?e2fsckに[-p]や[-y]オプションを使って自動修復しようとしたところ、実行直後に以下のようなエラーが...。
「ちょっと困ったエラーがあるから手動で調整しなよ、ここでAbort(停止)する?(y)」
また、全てyesとする先のコマンドオプションを使っても、いきなりここで終わってしまうので意味がない...。
それならばと、手動にしたら、Enter押しまくっても、いつまでも終わらない地獄にハマり...。
というわけで他の手段としてrsyncを選んだ次第。
結果的にイメージをダウンロードしてddしてから、追加で環境構築した方が早かったかもしれません。
他の原因は、想定するのも不毛なのでやめておきます。