Live CDに入って、ターミナルをアクティブにしました。次に、gksu nautilusルートディレクトリに一時的にアクセスするために入力しました。Managerウィンドウが開いたら、File Systemをクリックして/etc/default/grubディレクトリに移動しました。次に、Grubファイルをダブルクリックして、TIMEOUTとに変更を加えましたTIMEOUT_QUIET。
変更を加えた後、ファイルを保存しました。その後、ターミナルモードに戻り、次のように入力しました。
gksu update-grub
私が得たエラーメッセージは：
/のデバイスが見つかりません（/ devがマウントされていますか？）
この時点で何をすべきかわかりません。update-grub変更を更新するにはどうすればよいですか？よろしくお願いします。私はこの環境をまったく知らないので、あなたの反応を非常に詳細かつ具体的にしてください。
回答:
gedit admin:///etc/default/grub gedit。sudo update-grubで、更新が完了するまで待ちます。gksu gedit /etc/default/grubGRUB_HIDDEN_TIMEOUT=0
#には、この行の先頭に追加すると、結果は#GRUB_HIDDEN_TIMEOUT=0sudo update-grubます。ブート時にgrubメニューを表示することだけが必要な場合は、ファイルへの以前の変更を元に戻す必要があります。
Live CDは書き込み可能なファイルシステムをマウントしないため、このメッセージが表示されます。これは、Ubuntuを試用したり、破損したシステムを救出したりするためにのみ使用することを目的としています。の実行はsudo update-grub、インストールされているUbuntuでのみ機能します。Ubuntuでは、基盤となるGRUBファイルへの書き込みアクセス権があります（Live CDではアクセスできません）。
/etc/default/grub、その後にupdate-grub。
インストールされたUbuntu DistroのライブCDからupdate-grubを実行できます（これは[debianベース？]のLinuxディストリビューションでも動作すると仮定しています。ドライブのクローンを作成し、すでに新しいドライブをコンピュータにインストールしている場合は、それらをまったく気にしません。ある意味でupdate-grubステップはそのサブセットであり、アプローチは同じなのでまた、この方法は、クローン作成のコンテキストでの検索を通じて発見されました。クローン作成していない場合は、必要なものをそこから取り出すことができ、プロセスが簡素化されます。
ここでこれを修飾する必要があります。重要なのは、クローン作成のためであり、update-grubを行うためだけではありません。これはBIOSシステムでのみ行っています。UEFIシステムでは試していません。UEFIシステムでは、ブートロードのためにFATパーティションが必要です。このパーティションがコピーコピー手順中に乗って来るかどうかはテストしていません。ライブセッション中にネイティブのgrub環境を合成する必要な[バインド-]マウントに影響を与えると思います...
これについては、http：//frugaltech.happystoic.com/ssdlinuxのページで詳しく説明しています。私はこの方法を何度も使用しましたが、これを使用して広告を無限にハードドライブに交換できます。物理的なハードドライブを交換することは、このように非常に簡単になります。
以下は、あなたがそこにあるものの役に立つ言い換えかもしれません：
Ctrl+ Alt+ TBashターミナルの場合sudo -s、ライブセッション中にスーパーユーザーシェル（）を入力します。
フルインストールドライブパーティション（永続的なLinuxファイルシステムのルートディレクトリである[または今後なる]パーティション）をマウントします。
2a。ハードドライブに完全インストールが既に存在する場合は、（2）にスキップします。クローンを作成する場合：[新規インストールを行っていないという仮定に基づいて、この場合はすべて完全に自動化されているため]このパーティションに完全インストールが存在しない場合は、単純に
rsync -a /existing/linux/filesystem/live-mount-point/ /new/linux/filesystem/live-mount-point/
[これらのマウントポイントは、純粋にライブセッション環境に関するものです。Ubuntuでは、一般に「/ media / ubuntu / ???」の形式です]新しいドライブ[パーティション]に配置します。
2b。他のオペレーティングシステムのフルインストールは、ここで同じ方法で処理できます。私は通常、Windowsベースのリソースを使用してWindowsパーティションを新しいドライブに一括コピーしますが、rsyncも使用し、Win XPで機能しました（ntfsなどの正しいパーティションフォーマットのサポートがあると仮定します;ライブセッションメディアには通常、代替形式のサポートが含まれます）。/ターゲットの名前を完全に指定する場合は、スペルに注意し、ソースディレクトリの末尾を使用してください 。
ライブバインドマウント/dev、/procと/sysあなたにそれぞれのディレクトリへのディレクトリを使用すると、使用しようとしているパーティションをインストールし、完全な永久[マウント]。上記のリンクで詳しく説明されているスクリプトは、「for」ステートメントでこれを非常にエレガントに実現します。また、指定されたスクリプトは、それ自体がスクリプトとして実行される必要はありません。これは、bashプロンプトから行ごとに入力できます。
chroot永続的なフルインストールパーティションに。（3）および（4）を実行すると、システムは「最終ファイルシステム」に「仮想的に常駐」し、GRUBは均一に機能します。これらの手順がなければ、grubはシステムが単にライブセッションであると想定します。その場合の具体的な処理方法はわかりませんが、このスレッドで前述したように、望ましい結果ではありません。
/dev/sdX永久インストール（または、マルチドライブ[マルチブート]システムの場合はGRUBをホストするドライブ）に対応する（マウントポイントではなく、ドライブ）でgrub-installを実行します。ここでの柔軟性は、ヴィンテージとBIOSに依存する場合があります。私が知る限り、「grub-install」を実行する必要がない場合は何も有害ではないため、このライブセッションメソッドを使用している場合は常に実行します。
update-grubを実行すると、実行中のシステムが将来の永続パーティションにネストされているように動作し、利用可能なすべてのカーネルと起動可能なOSを検出します。
ハードドライブを物理的に変更していない場合は、（5）に進んでください。それ以外の場合は、/new/linux/filesystem/live-mount-point/etc/fstabファイルを編集または検証して 、[新しい]環境に適したファイルシステム構造を確保します。このレベルにいる場合blkid 、fstabのUUIDを収集するための使用についてはすでに知っています 。
私見：UUID値のリテラル更新を必要とする程度（例えば、将来のある時点で、/ homeディレクトリなどに追加のHDDをインストールします。これは、最も基本的で堅牢で不変のアプローチです。
chrootを終了し、スーパーシェルを終了し、bashを終了し、シャットダウンして、ライブメディアなしでシステムを起動します。これで、目的の場所にいるはずです。
重要：注：mount およびの 引数は 、ライブセッションに対応するchrootディレクトリ（通常、/mnt/??またはなどのマウントポイント/media/??）です。すべてではありませんが、ほとんどの場合、フルインストールは独自のパーティションに存在するため、ここでは「ディレクトリ」と「マウントポイント」という用語は本質的に同義です。grub-installの引数は、物理ドライブです（通常/dev/sdX、「X」は、システム、sda、sdbなどのドライブに対応する文字であり、セッションに依存するべきではありません）。
これで完了です。この方法を使用して、UbuntuおよびPuppyとともにさまざまな順列でWindows（XPおよび7）を同時にクローンしましたが、失敗していません。使用する予定のGRUBのバージョンを提供している限り、異なるディストリビューションのライブメディアを使用できます（ただし、これには異なるUbuntuフレーバーとMintのみを使用しています）。これを使用して、パーティションを移動したり、ドライブを交換したり、他のOSインストールを結合したり、SSDとの間でクローンを作成したりできます。ただし、同じマシンで作業している場合にのみ話すことができます。別のマシンに必要なドライバーは、以前の完全インストール中にスキップされた可能性があります。私の経験則では、コンピューターのドライブを切り替えるにはこの方法が必要ですが、ドライブのあるコンピューターを切り替えるには完全な[再]インストールが必要です。
おそらく誰かがこれを暴くことができる..？