投稿

miniPCのBMAXでWindows11のsecure boot設定漏れでトラブル発生

miniPC(BMAX)でWindows 11を再導入する際の注意点 今回のトラブルから得られた、miniPC初期化・再導入時に失敗しないための重要なポイントを整理しました。 1. 発生した問題とエラーの原因 自分で作成した「Windows 11のUSBブートメディア」から新規導入を試みた際、ライセンス認証やセットアップの段階でエラーが発生しました。このトラブルの原因は、以下の仕様ミスマッチによるものです。 インストールメディアの不適合: Windows 11の要求仕様を満たさない環境で作成されたメディアだった可能性 secure boot(セキュアブート)の設定漏れ: BIOS側でセキュアブートが「無効(disable)」のまま新規導入を進めてしまったことによる、BitLocker暗号化の不整合 2. トラブルを未然に防ぐ「失敗しない再導入の3ステップ」 miniPCのクリーンインストールを確実に成功させるためには、以下の手順を順番に確認しながら進める必要があります。 ステップ1:インストールUSBは正規の要件を満たすPCで作成する Microsoftの公式サイトから、必ずWindows 11の動作要件を完全に満たしているPC上でインストールメディア(USB)を再作成します。 ステップ2:導入前にBIOSで「secure boot」を「enable」に設定する OSをインストールする前に必ずBIOS(UEFI)画面を開き、Security項目にある「secure boot」が「enable(有効)」になっていることをmsinfo32等で確認してからインストールを開始します。 ステップ3:BitLockerの「48桁の回復キー」を事前に必ずバックアップする secure bootを設定すると、Windows 11では自動的にドライブが暗号化されます。万が一の障害復旧やWindows Update時のエラーに備え、Microsoftアカウント等に紐付いた「48桁の回復キー」を必ず紙に控えるか、別デバイスに保存してください。 1.概要 始まりは、参考資料の「6月からパソコンが動かなくなる?」です。miniPCのsecure boot設定をmsinfo32で確...

ARM64のLinuxMint/ubuntuをKVMで動作させる方法

1.概要 2024年にubuntu-20.04環境のKVMでubuntu-20.04-arm64を動かしました。今回、LinuxMint環境で動作確認を再度作成したので、記事をリライトします。x86_64環境でarm64を動かすにはqemuのaarch64のエミュレーションを利用します。Virt-Managerでubuntuのarm64の環境にisoからインストールすることは可能ですが、遅くて実用的ではありません。理由はエミュレーションなので命令単位に実行するためです。 今回の試験は、KVM上でLinuxMint/Ubuntuのarm64が動作するのを確認して、arm64のPC購入の検討をする予定でした。従って、インストールすることでなく、動かすことが目標なので作成済み仮想マシンから導入するのが早道と考え直しました。その内容を記述します。 2.詳細 (1) LinuxMint環境 環境はLinuxMint 22.3です (a)KVM環境を構築 $ sudo apt -y install virt-manager qemu-system (b)ubuntu-24.04 server仮想マシンイメージ取得 $ https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-arm64.img Diskサイズを10Gに変更 $ qemu-img resize noble-server-cloudimg-arm64.img 10G (c)仮想マシン設定に必要な情報の作成 user-dataをvimで作成します #cloud-config user: ubuntu password: password chpasswd: { expire: false } ssh_pwauth: true user-data.isoを作成します $ touch meta-data $ genisoimage -output ./user-data.iso -volid cidata -joliet -rock user-data meta-data (d)仮想マシンのインストール $ virt-install \ --connect qemu:///system \ --name ubuntu-arm \ --vcpus...

LinuxMint/ubuntuにWine 11導入を試しました ( LinuxMint 21.3 / 22.3 ubuntu 22.04 / 26.04 Wine 11.0 / 11.6 / 11.8 / 11.13 )

Wine環境でWindowsアプリが動作しない場合の考察と対策 最新のWine 11を利用しても、一部のWindowsアプリケーション(Acrobat Reader等)のインストールや起動が失敗するケースがあります。技術的な背景と、現場で役立つ代替アプローチを整理しました。 1. 起動・インストールが失敗する主な技術的理由 厳格なレジストリ要求: 大手メーカー製のインストーラーは、Windows固有の複雑なレジストリ構成を要求するため、Wineの標準レジストリでは処理が途中で強制終了します。 .NET Frameworkや各種ランタイムの未導入: アプリが依存している特定のランタイムがWine環境側に不足しているケースです。 セキュリティ認証・暗号化: 最新のアプリに組み込まれているデジタル著作権管理(DRM)や通信暗号化機能が、WineのAPI互換性を超えている場合があります。 2. トラブルを解決するための3つのアプローチ Wine上でWindowsアプリを安定して動かす、または目的を達成するためには、以下の対策が有効です。 対策1:winetricks を活用して必要なコンポーネントを補う 今回の日本語化(cjkfonts)と同様に、 winetricks dotnet48 や winetricks vcrun2015 などのコマンドを用いて、アプリが必要とするランタイムを個別にWine環境へ追加導入します。 対策2:単体で動作する「ポータブル版(.exe)」を選ぶ インストーラー形式(.msi や setup.exe)ではなく、フォルダを展開するだけで単体動作するポータブル版(HDBENCHなど)は、レジストリ依存度が極めて低いためWine環境と非常に相性が良く、高確率で動作します。 対策3:Linuxネイティブの代替アプリを検討する Wineに依存せず、Linux標準のリポジトリから導入できる互換アプリ(例:Acrobatの代わりに「Okular」や「Evince」、MS Officeの代わりに「LibreOffice」)を利用する方が、システムの安定性と処理速度の面で圧倒的に有利です。  1.概要 Wine 11.0がリリースされました。...

UbuntuのTerminalで表示される行間を狭くしたい ( ubuntu 22.04 / 24.04 / 26.04 )

1.概要 ubnutu-22.04を試験利用してすぐに気がついたことです。Terminalを開いて、catで/etc/hostsなどを表示すると行間が広く使いにくい。英語環境ではこの問題は発生しません。日本語環境を追加変更すると発生します。この状況はubuntu-24.04やubuntu-26.04でも同じことが起きます。LinuxMintの場合は、LinuxMint 21.3やLinuxMint 22.3の日本語環境で起きません。この内容に関して記述します。 2.詳細 私は、ubuntuとLinuxMintを利用していますが、英語環境でインストールをして、後から日本語を追加導入しています。ubuntu-22.04の試験利用を開始した時に最初に気が付きました。 日本語環境を設定した直後からterminalを利用したときの行間が広くなり表示される行数が減ります 。すぐに、ubuntu-20.04から移行するには難しいと感じました。 私はTerminalを利用してshell programingを行うためにvimで作業をします。terminalは列設定を100、行設定を50にして、50行のコードを参照して作業をしています。しかし、日本語導入後、行間が広がり数行減ってしまいます。参照できる行数範囲が狭くなることが作業効率に影響するとは思っていませんでした。 terminalの行間が広がってしまうことはUbuntuOneへReportでが以前要望を出しました。しかし、有望な返事は来ていません。諦めて英語環境での作業をしていた時に、ネットでこの事象を検索して情報を見つけました。 フォント変更前は、 1画面に最大42行 しか表示されず、スクロールの手間が発生していました。しかし、今回の対策(fonts-takaoの導入)を行った結果、 1画面に50行 が収まるようになり、コードの視認性が大幅に向上しました。体感として約20%表示領域が広がった印象です。 ubuntu-22.04から日本語フォントにNotoフォントを採用しており、以前採用していたTakaoフォントから変更になり、これが要因です。参考資料にはGUIを利用したTakaoフォントの導入手順が記載されていますが、CUIで導入できました。 下記コマンドで導入できます。 $ sudo apt install fonts-ta...

Ubuntu/LinuxMintでHDDの性能評価を簡単に実施できるhdparmを試しました

1.概要 SSDの価格が高騰していますが、DiskをSSDに交換して性能比較をした記事を見直して、備忘録として残すことにしました。 HDDの性能評価を簡単に実施できると知ったので、ちょっと調べてみました。利用するツールはUbuntu/LinuxMintに標準でインストールされているhdparmです。hdparmが標準でインストールされているので追加操作もいらず便利に使えます。 PCはDiskをSSDに交換して利用しています。 SSDに交換することでPCの性能は格段に良くなり、入出力性能がPC性能のボトルネックであることに気が付きます 。SSDの効果が、どの程度のものであるかをhdparmを利用して調べてみました。 2.詳細 hdparamは多数の機能を持っています。コマンドで確認できます。 $ hdparm 今回注目した機能は、read timings です。 -t   Perform device read timing (1) 測定方法(実行例) sudo hdparm -t /dev/sdb1 (2) 測定結果 検証デバイス (対象) 容量 読み込み速度 (MB/秒) 内蔵 HDD (SATA接続) 320GB 81.23 MB/s 外付け HDD (USB3.0接続) 1TB 195.04 MB/s 内蔵 SSD (SATA旧型) 240GB 246.89 MB/s 内蔵 SSD (SATA新型) 250GB 537.85 MB/s ※hdparm -t コマンドを3回実行した平均値を記載しています。 秒あたりの読み込みデータ量を参照すると、readの性能はSSDが非常によく、PC性能を引き出すことがわかります。容量が近いSSDでも性能に差があることもわかります。 測定結果から古い240GBのSSDと最新の250GBのSSDでは 約2倍の速度差(537.85 MB/s) が確認できました。hdparmコマンド...

miniPCのBMAXにUSBからwindows11を再導入して苦労しました

miniPC(BMAX等)のWindows 11クリーンインストールにおける罠と対策まとめ miniPCでOSの初期化や再導入を行う際、デジタルライセンスの仕様やインストールメディア作成時の制約により、深刻なエラーや認証不能トラブルに陥るケースがあります。今回の検証で判明した原因と、確実な解決手順を整理しました。 1. 再導入時に発生する3つのトラブル原因 エラーコード「0x8007025d」の発生: インストールメディア(USB)のデータ破損、またはUSBの規格・相性問題によって、OSファイルの展開処理が途中で強制終了します。 旧型PCでのメディア作成制限: Microsoftの仕様変更により、Windows 11の最小システム要件(TPM 2.0やCPU世代など)を満たさない古いWindows 10のPC上では、公式ツールを使ったWindows 11のインストールUSB作成が進行不可(0%から進まない)になる制限があります。 デジタルライセンスの認証エラー: プリインストールされていたWindows 11のベースが「Windows 10からのアップグレード権」だった場合、最初からWindows 11のクリーンインストールを試みるとデジタルライセンスが正常に引き継がれず、認証拒否(ハードウェア変更と判定)される罠が存在します。 2. トラブルを回避する「完全復旧へのロードマップ」 miniPCの認証トラブルを確実に解決し、最新のWindows 11をクリーンインストールする手順は以下の通りです。 ステップ1:一度「Windows 10」を導入してベース認証を通す 直接Windows 11を入れずに、まずはWindows 10をクリーンインストールします。ネット接続すればマザーボード(BIOS)に埋め込まれた元のデジタルライセンスが自動的にオンライン認証されます。 ステップ2:Windows 11インストールアシスタントでアップグレードする 認証済みのWindows 10環境上で、Microsoft公式の「インストールアシスタント」を実行してWindows 11へアップグレードし、Microsoftアカウントにデジタルライセンスを強固に紐付け直します。 ステップ...

grubでbootできなくなった2048 sector以内のディスク障害

2048セクター以前(MBR・GRUB領域)の解析と対処法 通常のファイルシステムチェック(fsck)やパーティション変更ツール(gparted)では、ディスクの先頭1MB(0〜2047セクター)の物理エラーを検出・修復できないことがあります。技術的な背景と、Linux環境でこの領域を確認するためのコマンドをまとめました。 1. 2048セクター以前に何が書き込まれているか? 従来のMS-DOS(MBR)形式では、先頭セクター以降に以下の重要なデータが配置されます。ここに物理的なバッドセクター(不良領域)が発生すると、OSの起動処理が完全にストップします。 第0セクター(MBR): ブートローダーの第1ステージ(Stage 1)とパーティションテーブル(446+64バイト)が存在します。 第1〜2047セクター(後続領域): GRUBのコアイメージ(Stage 1.5)などが格納される「MBRギャップ」と呼ばれる領域です。近代的なOSではパーティションの開始位置をアライメント調整(最適化)するために、最初のパーティションを2048セクター(1MB目)から開始する仕様になっています。 2. 先頭領域の異常をチェック・操作するLinuxコマンド 通常のツールでエラーが出ない場合、低レイヤのコマンドを用いることで先頭領域のデータ状態を確認、または強制的に書き換えることが可能です。(※実行時は対象ドライブ名に十分注意してください) 状態の確認(ddコマンドによる流し読み): sudo dd if=/dev/sdX of=/dev/null bs=512 count=2048 先頭の2048セクターを読み込み、デバイス(/dev/null)へ破棄するテストです。もしこの段階で「I/O error」が出力されれば、先頭1MB以内に物理的なクラッシュが起きていることが確定します。 MBR・ブート情報の強制初期化: sudo dd if=/dev/zero of=/dev/sdX bs=512 count=2048 先頭2048セクターを全てゼロ(空)で上書きします。パーティションテーブルも含めて完全にクリアされるため、物理エラーではなくデータ破損だった場合は、この処理の後に再セットアップす...