Q&A
teratailにおける「Bootstrap」は「CSSフレームワーク」です。OSにおけるブートストラップとは意味が異なるため、タグを編集し直したほうがいいかと思います。
Windows Embbeded Standard 8のイメージファイルを作成して、製品に組み込みを行なっていますが、出荷後、ブードシステムが破損することがままあります。どういうわけか全てのコピーしたものが、時間が経つと破損するようにです。
復旧可能かどうかを調査すると、どうやっても破損が治りません。原因と対策を教えてください。
詳細な話としては、イメージはAcronis True Image（２０１４または２０１６）で作成しています。これをSSDディスクにコピーしています。ボードはBIOSモード（WIndows Boot Manager）でしか起動しませんが、メーカーに診てもらった結果、EFIモードでブートしていると指摘を受けました。しかし、破損しなければ正常にどうしているので、この説明に疑問があり、OSのコマンドでは確かにEFIモードでブートしていましたが、BCDEDITの内容を見ると、直接WindowsのOSが入っているCパーティーションから起動するようになっていたので、この指摘は正しくないと結論しました。
しかし、調査翌日に調査用に利用していたディスクではブートしないなっており、やはりブートシステムが壊れていました。
壊れているのを復旧しようと、USBから起動したWindows PE上からBCDBOOTコマンドを利用してもエラーが発生するばかり、全く治りません。
復旧するにはどうしたら良いのでしょうか？また、どうしてブートシステムが壊れるのでしょうか？
以上、よろしくお願いします。
BIOSでの起動モードはLegacy、UEFIどちらなのでしょう? それに対してデプロイしたイメージはLegacy、UEFIどちらなのでしょう?
起動モードはLegacyです。イメージにもLegacy、UEFIなんてあるのでしょうか？もし、あるのであれば識別方法を教えてください。基本的に、原本のものをそのままコピーするようにしていています。
以下のサイトを参考に確認してみては如何でしょうか。http://www.teradas.net/archives/8968/
参考HPによれば、こまんどではEFI、パーティションはGPTだからEFIでした。EFIで起動しているのは間違いないようです。こうなると、BOOTシステムとハードの違いからは発生しているのは間違いないとしても、大半はなぜ正常に起動するのかわからなくなります。
回答5件
0
いろいろと回答いただきましたが、メーカーの方で解決いただきました。
説明によると、イメージディスクを作製したときと、イメージを焼くときのブートモードが違うと、今回の現象が発生するそうです。
投稿2018/04/02 01:45
総合スコア17
0
遅くなりましたが、ほぼ解決しました。S.M.A.R.T.情報を各ディスクで調査したところ、CRCエラーが異常に大きい値となっているディスクを見つけました。SSDはディスクの内容が壊れることはないと高をくくっていましたが、完全に否定されていました。
物理的に接触状態な変化がCRCエラーを誘発しているのは間違いないようで、今回苦しめられた状態とマッチした回答となりました。
投稿2017/05/29 03:41
総合スコア17
0
いろいろと仮説をいただきましたが、S.M.A.R.T．情報を各個体より検証し直した結果、CRCエラーがたまに大きな値があることから物理的な接触不良からディスク内容が破損していった結果と断定しました。
SSDではさすがにディスクの内容をこわれることはないと先入観を持っておりましたのが、しっかりS.M.A.R.T.情報を調べておけば早く分かった問題でした。
投稿2017/05/29 01:14
総合スコア17
0
ベストアンサー
遅レスですが、似た、というかほぼ同じ現象を知ってます。
結果はSSDの消耗だと思います。SSDのS.M.A.R.T情報を見てみてください。Media Wearout Indicator(消耗指数)やEndurance Indicatorが増えてると思います。
ほとんど使っていないSSDがなぜ消耗しきってしまうのかというと、Acronis製品でイメージファイルを書き込む形でインストールしたからです。SSDはファイルシステム・デバイスドライバから使っていない領域を通知(TRIMコマンド)してもらうことで使用中と未使用中を識別してうまく管理し、メモリセルの消耗を平準化することで長い寿命を実現しています(Wear leveling)。
Acronis True Imageのディスクバックアップは、オリジナルを取り込んだ時に未使用領域の情報を保存しません。Linuxでいえばddコマンド＋圧縮に近いです。この方法でSSDにリカバリするとSSDはほぼ全ての領域を使用中と勘違いし、予備領域も使い始めます。セルの平準化が全体に対してできないので数週間～数ヶ月で消耗しきってしまいます。同じことはLinuxでSSDに向かってddで全体に書き込む(リカバリする)ことでも再現できます。
しかしこの場合でもMedia Wearout Indicatorはなかなか進行しない場合もあるようです(消耗指数は全体の平均から計算されてると思われる)。そしてある日急にお亡くなりになります。
どうすればいいのかというと、リカバリしたあとにファイルシステムの未使用領域すべてが未使用である迄を、つまりTRIMコマンドを発行させればいいのです。アナログな方法では巨大なゴミファイルを作って領域を99%使い尽くし、そしてそれを削除すればOKです。もっとカッコイイ方法やツールもあると思いますので調べてみてください。ちなみにLinuxの場合はfstrim一発です。
なお、一度消耗が一定以上進んだSSDは基本的には復旧はできないと考えてください。
EFIモードでブートしていると指摘を受けました
それではなぜ「時間が経つと」破損するのか説明できません。
とにかくSSDのS.M.A.R.T情報を確認しましょう。もしS.M.A.R.Tについて知らないのなら、今すぐ調べましょう。TRIMについても調べてみてください。もし企業で契約しているのなら、Acronis社に問い合わせて確認するのも手です。
最後に、Windows Embbededの対象の機種にて、ちゃんとTRIMが有効になっているかも確認してください。昨今のPCはAHCIなので問題ありませんが、組み込み向けボードでは何をホストのチップにつかっているやら、分かりませんので。
投稿2017/05/10 22:47
総合スコア1149
0
こまんどではEFI、パーティションはGPTだからEFIでした。
こちら何を言われているか読み解けませんが、「bcdedit」の結果、以下で間違いありませんか?
Windows ブートローダ：～\winload.efi
また、BIOSでは、bootをregacyモードにしているとの理解で宜しいでしょうか?
上記理解で間違いなければ、BootモードはBIOSとイメージでそろえる必要があります。
何故、起動しているか?は不明ですが、OS、およびハードベンダのサポート外となってしまい、今後の運用で障害が発生した場合、サポートの恩恵を受けられなくなる可能性大です。
「Windows Embbeded Standard 8」と制限版のOSを搭載していることから、ハードはシンクライアントなどの読み取り専用領域をもつ特別なハードウェアなのかな?と思ったりもします。
そうであった場合、イメージデプロイにもベンダ推奨の手順があるので、これに従うべきです。
で、疑問に思ったのですが、イメージの取得元端末もデプロイ先の端末も同様の機種なのでしょうか?
UEFI構成でイメージを取得している(これは、OSインストール時にBIOSでbootをUEFIモードにしている必要がある)にも関わらず、戻し先のbootがregacyモードというのに違和感を感じます。
デプロイ先の端末は、BIOSで意図的にbootをRegacyモードにしたということでしょうか?
BOOTシステムとハードの違いからは発生しているのは間違いない
こちらはBIOSにおけるブートの仕組みと、OSが提供しているブートの仕組みの違いから発生しているという理解が正解です。
投稿2017/03/14 04:18
総合スコア4309
＞デプロイ先の端末は、BIOSで意図的にbootをRegacyモードにしたということでしょうか?
ボードはRegacyモードしかないタイプでした。OSのカスタマイズをやっているうちに、なぜかEFIモードに勝手になってしまったといしかいいようがないのですが・・・。
しかし、なぜ壊れるのでしょうか？壊れる原理がわかれば起動している理由もおぼろげながらわかってくるはずです。
WindowsOSはブラックボックスが多く、そこを追うことは不可能に近いと考えています。
そもそも、OSがハードに適した構成になっていないにも関わらず、起動していることがおかしいと捉えるべきです。
そこまでして原因を追いたいのであればOS開発元Microsoftのプロフェッショナルサポートに問い合わせするしかないと思いますが、ベンダサポートと同様に「UEFIが・・・」と回答が返ってくることが目に見えています。
後日談があります。
Regacyで作成したWindowsを、量販のため、イメージを作成して別のPCへコピーします。ところ、せっかくRegacyで作成したものが、Regacyで再現しないで、必ずEFIパーティーションを作成して再現します。イメージのコピー・修復に利用したのはAcronisTrueImageです。
> Regacyで再現しないで、必ずEFIパーティーションを作成して再現します。
こちら、BIOS：Regacyモードにしたうえでイメージを作成していますか?
また、配布先もBIOS：Regacyモードにした上で配布していますか?
上記を全て満たしているのであれば、AcronisTrueImage側で配信に関わるパラメータが関与してる可能性があると思いますが・・・
※TrueImageで配布したことないので推測の域をでませんが
Acronis True Imageに変更するようなパラメータはありませんでした。
結局堂々巡り状態ですね。
あなたの回答
tips
プレビュー
