Ubuntu User Blog

記事の更新日：2026/07/15 1.概要 miniPC(BMAX)のWindows11の再導入を実施して、ハマってしまいました。SSDを交換した場合、Windows11のデジタルライセンス認証を再認証する必要があると知りませんでした。miniPCはWindows11プリインストールですが、ライセンスはWindows10であったことも問題を複雑にしました。また、Window11へ移行できないWindows10のPCではWindows11のインストールUSBを作成できないことも今回わかりました。 とても難しかったと私が感じた点は、以下の通りです。 (1) 最新版のWindows11(24H2)をminiPCで作成。インストールが0x8007025dで停止 (2) Windows11の要求仕様を満たすPCでないとインストールUSBを作成できない (3) Windows11(24H2)のUSBから導入でデジタル認証は消えて、PCの既定値に戻る (4) Windows10導入、Windows11アップグレードの手順となってしまう (5) Windows11(24H2)で再導入するとデジタル認証が有効になる 2.詳細 (a) はじまり miniPCのWindows11はWSLなどを導入して色々変更を加えたので、初期化しようと考えました。初期化するならば最新のWindows11のインストールUSBを作成してから作業をするほうが良いと考えて、新しいインストールUSBを作成。以前のWindows11のインストールUSBを初期化して利用しました。 Windows11のインストールを開始するとインストール処理が、0x8007025dで停止 。ネットで調べるとインストールUSBが正しくないとのこと。 WindowsのインストールUSBの作成は何度も経験があり、間違えることはなく、USBが壊れてしまったと思いました。代替のWindowsのインストールUSBを急いで作成することを最初に考えて、旧型Windows10のPCを引き出して作業を始めました。 (b) 旧型Windows10でWindows11のインストールUSB作成 Windows10でWindows11のインストールUSBを以前作成していたので問題が発生するなど思っていません。しかし、 Windows10でWindows11のイ...

記事の更新： 2026/09/06 1.概要 Google Driveをubuntu環境で利用する方式を調べました。gdriveが標準と知って調べて動作確認をしたのですが、思った通りに動作しません。同時の環境問題かもしれませんが、gdriveへのチャレンジを途中で打切って、google-drive-ocamlfuseに変えました。こちらはGoogle Driveをmountして利用することができます。 まず、gdriveでチャレンジしたことを記載し、google-drive-ocamlfuseに変更した結果を記載します。また、この過程で他の手段も色々調べているので追加情報として記載します。 私の評価は以下の通りです。 (1) gdriveはGoogle標準ですが、使い勝手が良くない (2) google-drive-ocumlfuseはmount利用できるが、速度や接続切断時の課題がある (3) rcloneはmount操作よりも、コピー操作が使いやすく、推奨する (4) LAN環境のgioは非常に良いが、クラウド上のファイルアクセスをしたことがない 2.詳細 (1) gdrive 参考資料に従って、GdriveのVersion2を導入しました。 環境はUEFI CSM環境のubuntu-20.04.6です。 (a) gdrive_2.1.1_linux_amd64.tar.gz $ ./gdrive bash: ./gdrive: そのようなファイルやディレクトリはありません 動作しません。 (b) gdrive_2.1.1_linux_386.tar.gz $ ./gdrive No valid arguments given, use 'gdrive help' to see available commands こちらは動作します。 (c) gdrive_linux-x64.tar.gz Gdrive Version-3 (gdrive_linux-x64.tar.gz)を試しました $ ./gdrive Usage: gdrive <COMMAND> Commands:   about        Print information about gdrive   account...

記事の更新日：2026/09/30　評価を加筆 1.概要 運用しているシステムがエラーで停止した。普通はエラー発生時のテキストデータを表示しているので、原因の特定は比較的簡単にできます。しかし、見えない文字が存在してエラーになる場合もあります。そんな場合に対処する方法がHEX表示です。 システムを運用していると想定していないデータが入力されてエラーが発生することがあります。テキスト形式のデータは目視確認することができるので、入力データはテキスト形式を多用します。しかし、テキストデータを目視しても見えない文字の影響でエラーとなる場合があります。改行コードがその例です。 目視できない文字を確認するためにはHEX表示を利用します。viやviewを利用して、HEX dump表示や修正を実施できます。viでHEX修正を実施することは滅多にありませんが、viewで内容を読みたいときはあります。操作方法は同じなのでviewを利用して表示する方法を記述します。 私の評価は以下の通りです。 (1) データ処理でエラーが発生した場合、入力データの確認が必要です (2) 入力データはテキストデータであっても、可読できない文字が存在する場合があります (3) そんな時にHEX表示を利用します (4) viを利用するとHEX表示で修正をすることができます 2.詳細 試験用のテキストファイルを作成して、viewで表示後、HEX表示モードへ変更します。更に、HEX表示モードを解除して元の表示に戻します。 (1) テスト用のファイルを作成します $ echo "0123456789" > test.txt viewで参照します。 $ view test.txt [表示内容] 0123456789 (2) HEXモードに変更します ESC :%!xxd W10: 警告: 読込専用ファイルを変更します とメッセージが表示され、HEX表示に変わります。 [表示内容] 00000000: 3031 3233 3435 3637 3839 0a              0123456789. (3) HEXモードを解除します ESC :%!xxd -r 表示が戻ります。 [表示内容] 0123456789 3.所見 データの確認には...

記事の更新日：2026/09/30　評価を加筆、新しい手法を追加 1.概要 この記事は2023年の記事です。しかし、この記事は、私のシェル・プログラムのスタイルを変えた大切な記事だと思っています。もう一度、読み直し、リライトして備忘録に残すことにしました。 シェル・プログラミングに慣れてくるとVAR=$(pwd)などのように、コマンド実行結果をシェル変数に入れて処理の効率化をします。シェル・プログラミングは即時処理を実行できるので早く結果を出すには最速の方法だと思っています。 しかし、 $(...) の実行結果がNULLになってしまいシェル変数の値をifで参照するとエラーとなります。シェル変数に入っている文字数を調べることが簡単にできることがわかり、シェル変数の値がNULLの対処方法をシェル変数に設定された文字数確認で実施できます。 以前はシェル変数に固定文字を付加して、結果が固定文字と同じであると、シェル変数の値はNULLだと判断する処理をしていました。シェル変数に設定された文字数確認のほうがスマートな気がします。 ネットで調べると新しいNullの調べ方が記載されていました。-z "$VAL"という手法がありました。その内容を追加記述します。 私の評価は以下の通りです。 (1) shellコードの読みやすさは、${#VAL}が優れています (2) abc${VAL} != abcの比較も機能的に問題ありません (3) shellコードは個人ユースの場合、他の方が見ることはありません (4) 仕事でshellコードを書く場合は、${#VAL}を使うほうが良いと考えます (5) -z "$VAL"は、更に新しい手法のようです。こちらも優れています 2.詳細 (1) abc${VAL} != abc を利用する手法 シェル・プログラミングを実施すると、VAL=$(...........)にて処理結果をシェル変数に入れます。しかし、シェル変数（ここでは${VAL}）に値が設定できずにNULLとなると、 それ以降に記述するif文でエラーになります。 /dev/sddが存在しない環境で下記シェルを実行します。 VAL=$(lsblk | grep sdd) if  [ ${VAL} = 1 ]; then     echo "...