きり丸の技術日記

技術検証したり、資格等をここに残していきます。

WSLの時刻がズレたのでWindowsの時刻に修正する(sudo hwclock -s)

WSLの時刻がズレたことによるエラーが発生したので、時刻修正をした時のメモ。

環境

  • Ubuntu
    • 22.04.2 LTS
  • GNU/Linux 5.15.133.1-microsoft-standard-WSL2 x86_64

前提条件

  • なし

コマンド

次のコマンドをWSL上で実行することで、Windowsの時刻と一致できます。

sudo hwclock --hctosys
または
sudo hwclock -s

説明

WSLからWindowsのハードウェアクロック側にアクセスするので、sudo hwclockが必要です。

そのオプションとしてソフトウェアクロックをハードウェアクロックの値で更新するHardware Clock to System Timeの省略であるhctosysを一緒に実行します。それでも長いオプションなので-sという短縮形が用意されています。

ChatGPTによる説明

この記事を作るにあたって、不明瞭だった単語をChatGPTに確認しています。

ハードウェアクロックとソフトウェアクロック

ハードウェアクロック(RTC、Real-Time Clock)

ハードウェアクロックは、マザーボード上に存在し、電源が切られたときでもバッテリーにより動作を続けるクロックです。通常、コンピュータの電源が切られている間も正確な時間を保つために使用されます。ハードウェアクロックは通常、UTC時間を保持し、システムが起動するときまたはシャットダウンするときに時間情報をシステムクロックと同期します。

システムクロック(Software Clock、 Kernel Clock、またはOS Clock)

システムクロックは、OSのカーネルが管理するクロックです。コンピュータの電源が入っている間は、OSがこのクロックを使用して時間を追跡します。システムクロックは高精度であり、OSのスケジューリングやタスクのタイミングなどに使用されます。しかし、コンピュータの電源が切られるとリセットされるため、再起動後の時間情報はハードウェアクロックから取得されます。 実際に時間を要求するとき(例えば、dateコマンドを実行するなど)は、通常はシステムクロックの時間が参照されます。そしてその時間は通常、起動時にハードウェアクロックから取得した時間に基づいています。

一般的に言って、ハードウェアクロックはコンピュータがオフになっているときの時間を保持する責任があり、システムクロックはオンになっているときの時間を正確に追跡します。

ソースコード

なし

自動実行する場合

cronで自動で修正する記事が既にあったので次のリンクの記事を参考にしてください。まだ手元で実施していないので、この記事との差分があったら改めて書きます。

終わりに

仕事を始めた朝には発生しないのに、昼休憩後には頻発するエラーだったので原因に心当たりをつけるまで時間がかかりました。知らなかったのですが、WSLの時刻って結構ズレるんですね。

まだまだWSL初心者なのでもっと勉強したいです。

WSLの一般ユーザのパスワードをリセットしたい

sudoコマンドを実行したいが、パスワードを忘れたのでWSLのパスワードをリセットするときのメモ。

環境

  • Ubuntu
    • 22.04.2 LTS
  • GNU/Linux 5.15.133.1-microsoft-standard-WSL2 x86_64

前提条件

  • 変更対象の一般ユーザー名が分かっていること

コマンド

# root ユーザでログインする
wsl -u root

# kirimaruユーザのパスワード変更
passwd kirimaru

ソースコード

なし

終わりに

WSL上ではなく、Windows上で構築することに慣れてしまっているので忘れてました。

小ネタですが、残しておきます。

WindowsのGit操作で発生したFilename too longを解決する(git config --global core.longpaths true)

Macを使用している他人がコミットしたファイルをpullしようとしたらFilename too longが出力されてpullできませんでした。その解決方法を残します。

環境

  • Windows
    • 11
  • GitBash
    • 4.4.23(1)-release

ゴール

次の操作時にエラーが発生しない。

$ git reset --hard origin/develop

error: unable to create file xxx/yyy/zzz[ファイルパス] :Filename too long

解決方法

Gitのcore.longpathstrueに設定する。

git config --global core.longpaths true

備考

ChatGPTにこのエラーを直接貼り付けたら、次のメッセージが返ってきました。ある程度はあっていると思うのですが、こちらにしたがっても解決はできませんでした。レジストリ修正したのに…。

この問題は Windows のファイルシステム (FAT32 と NTFS) の制限から来るもので、ディレクトリの深さやファイル名の長さが一定の限度を超えると発生します。Windows でのパスの最大長は 260 文字と設定されています。
次のいずれかに該当する解決策を試してみてください:
- フィル名を短くする: 長いパスやファイル名を短くすることで問題を解決できます。ただし、これはファイル構造を変えることを意味するため、他の開発者との協調作業に影響を及ぼす可能性があります。

長いパス名のサポートを有効にする: Windows 10 version 1607 以降では、レジストリ エディタを通じてまたはローカル グループ ポリシー エディタを通じて長いパス名をサポートする機能が追加されています。ただし、この機能を有効にしても古いアプリケーションは最大 260 文字の制限を守る可能性があるのでご注意ください。
以下に、Windowsで長いパス名を扱う機能を有効にする手順を記載します。ただし、この操作はシステム全体に影響を与える重要な変更なので、注意深く行ってください。

## ローカル グループ ポリシー エディタを使用する方法:
「gpedit.msc」を実行します。(Windows キー + R を押して、「gpedit.msc」を入力します。)
ローカル グループ ポリシー エディタで、「コンピュータの設定」 -> 「管理用テンプレート」 -> 「システム」 -> 「ファイルシステム」に移動します。
「Enable NTFS long paths」をダブルクリックし、有効にします。
## レジストリ エディタを使用する方法:
「regedit」を実行します。(Windows キー + R を押して、「regedit」を入力します。)
レジストリ エディタで、「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem」に移動します。
「LongPathsEnabled」の値を「1」に設定します。もし「LongPathsEnabled」が存在しない場合は、「新規」 -> 「DWORD 値 (32 ビット) の作成」を選び、「LongPathsEnabled」を作成し、「1」に設定します。
いずれの方法で問題が解消しない場合は、その他の可能性を探るためにさらなる情報が必要です

ソースコード

なし

終わりに

小ネタも小ネタですが、地味に30分くらい格闘してたので残します。