Ubuntu Server 22.04 LTSをインストーラに従って通常通りインストールした場合、サーバに接続されているディスク領域を全て使わないでインストールが完了します。
VMを作成して、Ubuntuをインストールして、大量のデータを転送しているときに気が付きました。Proxmoxで128GBを割り当てたはずなのに、60GB超えたぐらいでディ スクがフルになってしまいました。
原因はシンプルで、Ubuntu Installerの指示に従って、特に設定を変えずに順当にインストールした場合、実際に使用できるディスク容量の内、約50%しか割り当てられません。
この問題を解決するには、以下のコマンドを実行します。
$ sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
$ sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv
これによってディスク容量を限界まで割り当てて使えるようになります。
Amazonのブラックフライデーセールで安く売られていた6 TBの外付けHDDを購入したので、それにラズパイをくっつけて簡単お家クラウドを作りました。
この組み合わせの話、擦られすぎて書く意味がよく分かりませんが、こんな事やったよという報告程度に見て頂ければと思います。特別なにか尖ったことをするわけではないので、別にこのサイト以外の内容を見ながら、やっても同じ結果を得られるかと思います。
基盤：Raspberry Pi 3 Model B+（以下、ラズパイ）
ストレージ：32GB SDカード
Team microSDHCカード 32GB UHS-1 U1 Switch動作確認済み 読込み最大100MB/s 日本国内10年保証 SD変換アダプター付属 正規品
ストレージ：外付け6TB HDD
OS：Ubuntu Server 20.04 LTS
（Dockerで動かすのでDebianでもCentOSでも動かせます）
必要なもの：Docker、Docker-compose、やる気、モチベーション
外部からサーバーへアクセスできる環境は整っているという前提で話をしています。例えばポート開放やリバースプロキシ、サーバーのIPアドレスなどは全て設定されているものとみなしています。
ラズパイで動かすので、まずはOSをインストールします。OSさえインストールされればやり方はお好みですが、今回はRaspberry Pi公式が出しているRaspberry Pi Imagerを利用します。
ダウン ロードは下記URLから行えます。
Raspberry Pi OS – Raspberry Pi
下記画像の「Download for Windows」をクリックすることでWindows版をダウンロードできます。macOSやUbuntuをお使いの場合は、下に表示されているリンクをクリックしてください。
インストール後起動すると、下記画像のようなウィンドウが立ち上がります。
ここまで来たら後は簡単です。「CHOOSE OS」でOSを選択してください。今回はUbuntu Serverを選択しますが、もしもこだわりがあれば他のOSを選択してもらっても構いません。ただしその場合、この投稿の手順ではできないかも知れないです。
OS選択後「CHOOSE STORAGE」でPCに刺したマイクロSDカードを選択して「WRITE」でOSを書き込みます。
ここもHDDからブートしたり、ネットワークからごちゃごちゃやったりできたりできなかったりするらしいのですが、今回は面倒なのでやらないというのと、個人的に別用途でも利用するのでSDに書き込んでおきます。
書き込みが終わったら、後はラズパイにマイクロSDカードを挿して、起動させるだけです。
起動後Raspberry Piにモニターとキーボードが接続されている場合は、画面に表示されます。そうでない場合、かつ、Raspberry Pi ImagerのCHOOSE OSでカスタム .imgなどを使用していない限り、初期段階からSSHが有効になっているので、ローカルIPを探し接続してください。
接続後パスワードの設定や必要に応じてユーザーの作成などを行ってください。パスワードの設定は必要ですが、ユーザー作成などの環境面はお好みです。
環境が整ったら、アップデートを行ってください。
Ubuntuの場合、以下の通りです。
$ sudo apt -y update $ sudo apt -y upgrade
時間がかかるのでお茶でも飲みながらゆっくり待ちましょう。
アップデートが完了したらOSの準備が整いました。
初めにDockerインストールしていきます。これは公式ドキュメントに沿ってインストールしていけばいいです。下記は実行するコマンドです。
$ sudo apt install
ca-certificates
curl
gnupg
lsb-release
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
$ echo
"deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu
$(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
$ sudo apt update
$ sudo apt install docker-ce docker-ce-cli containerd.io
Install Docker Engine on Ubuntu
次にDocker Composeをインストールしていきます。こちらについても公式ドキュメントに沿ってインストールしていけばいいです。下記は実行するコマンドです。
$ sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose $ sudo chmod +x /usr/local/bin/docker-compose
インストール完了後、必要に応じてインストールの確認をしてください。
インストールとは言ってもDockerで動かすので、 docker-compose.yml を作成して記述するだけです。
docker-compose.ymlの例は以下の通りです。
version: '3'
services: db: image: mariadb:10.5 command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW restart: always volumes:
redis: image: redis:alpine restart: always
app: image: nextcloud:apache restart: always ports:
cron: image: nextcloud:apache restart: always volumes:
volumes: db: nextcloud:
記述後、ファイルを保存してください。
ディレクトリで以下のコマンドを実行することで、Nextcloudが立ち上がります。
$ sudo docker-compose up -d
起動後、IPやドメインを使ってウェブサイトへアクセスし、指示に従ってインストールしてください。
これで完了です。自分で使いたいように他の設定をいじったりしてください。
結論だけ言います。動作が遅い、たまに完全に固まる。だけど、基本的にほっておけば処理は終わってるので、個人宅のファイルサーバー程度使うのであれば、何ら問題ないです。
快適に複数ユーザーであれこれ色々使いたいのであれば、Raspberry Pi 4を使うか、もっとスペックを持ったPCに入れるのが良い気がしますね。
Twitchで配信をしながら、勉強しつつ１０時間かけてクラスタ構築とクラスタへの移行を行いました。
クラスタを構築したのは良いもののデータベースを実行してるメインサーバが吹き飛んだので、やってからこの記事を書くまで時間が経過しました。
サーバが吹き飛んだことに関するIQ3まとめについては下記の投稿を見てください。
サーバ ーがカーネルパニック起こしたと思ったらハードウェアごと吹き飛んだ件
大きく２つの理由があります。
１つ目は学習目的です。クラスタに関して興味深くQiitaやZennその他様々な記事を目にしていましたが、いままで一度も構築したことがありませんでした。そこでやってみようと考えました。好奇心的なところが強いです。そもそもとして、私が自宅にサーバを持っている理由が学習目的なので、こういう感じで結構色々気軽にやってたりします。
２つ目は複数台管理が面倒くさかったです。クラスタ構築して運用できれば、個別にSSHでいちいちつないで細かく設定する必要がなくなるので、かなり管理の手間が減ると思いました。実際、楽になりました。初期に色々設定するという面ではかなり手間はありますが、そこさえ乗り越えれば楽です。
上記の２つの理由からクラスタ構築を自宅サーバ群で行いました。
サーバ群なんて言っていますが、今回のクラスタ構築では３台のみで考えました。今後追加することも一応考慮しています。
データベースやゲームサーバー、その他諸々一番色々やっているサーバ。スペックもメモリも一番ある。
ストレージは、SSDにOS、HDD２枚にそれぞれバックアップと本番の運用データが乗ってます。
OSはUbuntu Server 20.04、もともとはCentOSで運用していましたがCentOS 8でなくなるということでDebian系に乗り換えました。Ubuntuを選択した理由は、割と安定しながらも、バージョンを比較的新しいのを使ってくれるからです。後は最近のOSSとかがUbuntuで動かすことを想定して作ってることが多かったりするなんて理由もあります。あまり細かいことは考えてません。
Raspberry Pi 3 Model B+です。
どちらもTeam GroupのSDカード32GBを指してあります。
OSはUbuntu Server 20.04です。
基本的にデータを保持せず、サービスをDockerなどで動かしているだけです。このウェブサイトのウェブサーバーもラズパイで動作しています。データはデータベースやNASなどに放り込んであります。
後日、外部HDDをつなげてNAS化する計画がありますが、それはおいおいの話なので、ストレージは無いものとして扱います。
現在はありませんが、今後追加する可能性があるという事を考慮して構築しました。まだ扱いを考えていますが、クラウドのクラスタを自宅サーバのクラスタと混ぜてしまってもいいかなと考えているので、そういった可能性も考慮しつつ作ります。
クラスタ構築で重要なオーケストレーションシステムをどのように選んだのかという話です。
最も有名なオーケストレーションシステムの１つとして、k8s（Kubernetes）があると思います。Googleが設計したやつで、デファクトスタンダードの立ち位置にあるオーケストレーションシステムです。
k8sは技術トレンドですし、扱えたらなんかカッケー！とは思いますが、ここは現実的な事を考えましょう。まずk8sはプロダクション環境で使われることが多く、そこで使うことを想定した作りとなっています。実際Googleさんとか色々な企業は数千ノードをk8sとかで扱っているとか...
しかし私は一般家庭、プロダクション環境ではないのです。もちろん数千ノードなんて扱うことは有りません。現在稼働させてるサーバーをオンプレ・クラウド合わせてもいいとこ１０数個です。まず２０ノードを超えることは有りません。ということはそこまで高性能である必要も無ければ、プロダクション環境に対応できるだけのスケールアウト可能なシステムである必要もありません。
k8sが無いとすると次に挙がってくるオーケストレーションシステムといえば、Docker Swarmです。これはDocker-ce自体に統合されているものなので、追加のインストールなどは必要なく、Docker engineが使えれば利用可能です。
補足ですが、「Docker Swarm 終了」や「Docker Swarm サポート終了」といったサジェストが出てきて、その旨の記述をするブログが散見されますが、終わったのは、Docker-Swarm-Mode-As-A-Serviceです。Docker Swarmが完全に削除されたわけではなく、開発が終了したわけではないです。
これ以外に利用されるオーケストレーションとしてGKEやECS、OpenShift、Rancherなどなど色々ありますが、他のは情報少なかったり、クラウドでやること想定されてたりなので、考えないこととします。後は単純に導入の手間とコストに見合わないです。
少なくとも私が自宅サーバ群でクラスタ構築するにあたり、どちらが良いのか。実際に検証したわけではありませんが、ある記事を見つけたのでそちらの情報を参照します。
[和訳]Docker SwarmとKubernetesの比較 #docker - クリエーションライン株式会社
ここでは技術コンサルタントのJeff NickoloffとDockerが契約して、パフ ォーマンス評価をした結果の和訳が掲載されています。
中身はここでは解説しないので、簡単に呼んで頂くとして、重要な２つのパフォーマンス評価項目とその結果に注目します。
評価項目は「コンテナの起動にかかる時間」と「高負荷状態での応答性」です。後者のような状態になることは想定してないし、プロダクションでもないので最悪time outしてもいいかなぐらいの気持ちではいますが、良いに越したことは有りません。
結果だけ書くと、コンテナの起動にかかる時間はDocker Swarmの方が５倍早く、クラスターの負荷率がほぼ100％であったとき、Kubernetesはクラスターの形成状態が10％～100％に到達するまで、Docker Swarmの98倍の時間がかかっています。
できることの幅は間違いなくk8sの方が良いです。ただしk8sは純粋に複雑なんです。ちょっとしたことをやるためにも色々やる必要があります。大規模なサービスを厳格に動かす場合、おそらくk8sは向いているでしょうが、自宅でちょっとクラスタを動かすぐらいであれば、複雑でパフォーマンスが出ないk8sよりもDocker Swarmの方が良いという結論になりました。
これは私の結論なので、自分で作る場合はぜひ自分で選択してほしいですが、少なくとも少ないサーバー台数で、１人でシンプルに物事を進めたいのであれば、Docker Swarmの方が向いていると思います。
さて一人で管理していくとなると、WebUIがあったほうが楽ですし、やりやすいです。全部CUIでやれという意見も理解はしますが、人間なのでGUIに甘えたいです。
ここに関しては割とすぐに決まりました。というかだいぶ前からクラスタ構築のための構想は頭で練っていて、もともとこれでいいでしょって感じで決めていました。
選ばれたのはPortainerでした。
Container Management | Kubernetes GUI | Docker Swarm GUI | Portainer
Dockerの WebUIで一番有名なのが、Portainerだと思いますね。なぜこれを選んだか話もしたいんですが、いうほど掘れる話題無いです。軽量で簡単に動かせて手間かからないのが、Portainerぐらいで他のWebUI系はパッとしなかった。
まだ結果は出ていません。現状大きな問題はなく順調に動いており、快適といえば快適という感じになっています。その一方、クラスタである必要はないと思うこともあります。今後の課題です。
また、時間が足りなかったりメンテナンスにそこそこな時間を割かなくてはいけないという点から、一部コンテナはStackとしてデプロイできていないです。さらには新たな問題点も見つけているので、今後の課題が積み重なっています。色々勉強しながら、ベストプラクティスを模索していきたいと思います。
今後、ちょこちょことこういう問題あった！解決した！といった系の投稿を小出ししていこうと思います。
大きなアウト プットしようとすると、時間ばかりが経過して何日も投稿しない日が続くのでね...
obs-ndiの.debパッケージをインストール時に、下記のようなエラーが発生する場合があります。
Unable to install obs-ndi:
The following packages have unmet dependencies:
Package created with checkinstall 1.6.2
この問題は、obs-ndiとobs-studioを削除し、PPAバージョンのobs-studioをインストールすることで解消可能です。
PPAバージョンのインストール方法は、OBSProject.comのwikiで解説されています。
Wiki - Install Instructions | OBS
以下は、Ubuntu/Mintへのインストール手順の適当な翻訳です。責任は負いません。
OBS StudioはChrome OS上では完全には動作せず、スクリーンキャプチャやウィンドウキャプチャなどの機能は動作しませんのでご注意ください。
フルスクリーンプロジェクターなど、OBSの特定機能で潜在的なパフォーマンス問題を回避するために、xserver-xorgバージョン1.18.4以降が推奨されます。
FFmpegが必要です。FFmpeg がインストールされていない場合（確信が持てない場合は、おそらく持っていないでしょう）、以下のコマンドで取得できます:
sudo apt install ffmpeg
仮想カメラをサポートするには、v4l2loopback-dkmsをインストールする必要があります。以下のコマンドでインストールできます:
sudo apt install v4l2loopback-dkms
Ubuntuソフトウェアセンターでmultiverseのリポジトリを有効にしたことを確認してください(注意：Ubuntuの新バージョンでは、リポジトリを追加すると自動的にaptアップデートが行われます)。その後、以下のコマンドでOBSをインストールします。
sudo add-apt-repository ppa:obsproject/obs-studio sudo apt update sudo apt install obs-studio
不定期でゲームや雑談などの配信を行っているのですが、近年ゲームの要求スペックが向上し、配信のFPSが安定しない事が増えてきました。これまではチューニングすることで誤魔化していましたが、最近では限界を感じ始めた為、パソコン周りの環境整理を兼ねて、配信環境の大幅な更新を行いました。
新たな配信環境を作るにあたっての一番の目標は、配信の安定化及びゲームの動作安定化です。
これら２つの達成を目標とします。
前述した２つの目標を達成する為に、どうすれば良いのかを考えました。単にGPUを新しいものへと買い替えてCPUを新しくすれば終わる話ですが、それができるほど金銭的余裕はありません。今ある環境で最適かつ最高のものを考える必要があります。
それで導き出された結論は、「1PCから2PCへ環境を変更する」です。
前提知識として1PCと2PCの説明が必要かと思いますので、下記にまとめます。
1PCは１台のパソコンで配信を全て行う事を指します。これは多くの配信者にとってのスタンダードです。１台のパソコンにゲーム、エンコード、配信などの環境をやることができます。
1PCのメリットは、１台のパソコンで全てが完結する為、余計なことを考える必要がなく、１台の強いパソコンがあればいいという点です。
2PCは２台のパソコンで配信を分業して行うことを指します。有名な配信者・ストリーマーはこれでやっていることがあります。１台で配信に写すゲームなどをやりながら、もう１台は配信のエンコードのみを行うというやり方です。
2PCのメリットは、配信を別のPCに任せるので、配信が安定する点です。配信がゲームであれば、ゲームにGPUの処理を全振りできる利点もあります。
2PC構成にするにあたって一番重要な点が、どうやって映像と音声をやり取りするかです。
今回は、Network Device Interface（以下、NDIとします）と呼ばれる技術を選択しました。NDIとは、NewTek社が開発したIPを利用した低遅延かつ高品質な映像伝送技術です。細かい技術的な説明は、難しいので省きます。詳細は自分で調べてください。
今回、NDIを使うにあたって必要なものですが、安定した高速なネットワークさえあれば大丈夫です。NDI自体は、回線が安定していないくても使えなくはないものですが、配信の安定化を目標としているのでネットワークが安定して高速である必要があります。
2PCのスペックもここで記しておきます。
OS - Windows 10
CPU - Ryzen 5 2600X
GPU - Nvidia GeForce GTX 1050 Ti
メモリ - 32GB
OS - Linux Mint
CPU - Intel Core i7-6700HQ @ 2.60GHz
GPU - Intel HD Graphics 530 / Nvidia GeForce GTX 950M
メモリ- 8GB
配信ソフトウェア - OBS Studio
NDIを使うのは良いけど、どうやって使うのさ。っていう問題があるわけですが、簡単に使う方法があります。OBSプラグインの「obs-ndi」を使用します。これはOBSを２つ使い、片方のOBSの映像・音声をもう片方のOBSへNDIを使って送信するものです。
前提としてOBSはインストールされている状態です。されていない場合は、インストールしておいてください。
プラグインをGitHubからダウンロードしてください。
自分と対応するOSのファイルをダウンロードしてインストールしてください。
Windowsの場合は、Windows-Installer.exeを使えば全てやってくれるので、終わります。
私の環境はLinux Mintなので、debをダウンロードします。Debian系の場合、libndiもインストールが必要なので、libndi4_4.5.1-1_amd64.debとobs-ndi_4.9.1-1_amd64.debの２つをインストールします。
obs-ndiの設定は、送信側・受信側の両方で行う必要があります。
obsを起動して、ツール -> NDI Output settings を開く。
Main Outputのチェックマ ークを入れて、Main Output nameを何か設定する。お好きな名前を設定すればいいですが、パソコンを識別できる名前をおすすめします。
シーンにNDI Sourceを追加する。
Source nameで送信側で設定した名前を選択する。
Bandwidthは、Highestを選択してください。回線が細くて安定しない場合は、Lowestを選択してください。音声だけで良ければ、Audio onlyで構いません。
その他は、都度設定を変更してください。
実際に映像を送信してみます。
送信側PCのOBSでキャプチャするウィンドウやゲームなどをシーンに追加してみてください。
送信側PCでOBSにシーンを追加するだけで、受信側PCに映像が届いていることが確認できます。
配信をする場合、受信側PCで配信を開始すれば大丈夫です。
NDIを活用した2PC構成で配信をしてみて、相当快適でした。近年のゲームの要求スペックはすごい勢いで上がっています。少しでも良い画質、良いFPSでプレイするにはGTX 1050Tiは貧弱なので、2PCを選択したのは良かったです。
配信PCは、GeForce GTX 950Mですが、1080p 60fpsで配信が余裕でいけます。相当異常な負荷がかかる状況になったりしなければ、当分はこれで配信楽しくやっていけそうです。
ちなみにNDIですが、結構色々できます。スマホのカメラ映像をNDIで送信してOBSに取り込んだりもできるので、使い方次第ではもっと色々なことができそうです。LANケーブルさえあれば、導入できるのは相当強みですね。
MicrosoftのタブレットPC「Surface 3」で、Windowsを動かすのはもう難しいです。Surface 3はWindows 8だと普通に動くのですが、Windows 10へアップグレードすると動作がもう本当に遅くてストレスだらけです。おまけにストレージ容量が多いわけでもないので、Windowsを動かすだけでもうかつかつ。というわけで、Windows君をSurface 3からクビにしてUbuntu Desktopをインストールします。
※ここで指すSurface 3はnon-Proです。Surface 3 Proではありません。
CPU: Intel® Atom™ Processor x7 Z8700（1.6GHz）メモリ: 4GB HDD: 64GB（128GBモデルも有り）ディスプレイ: 10.8インチワイド フルHD無線LAN: 802.11ac / 802.11 a/b/g/nBluetooth: Bluetooth 4.0※モバイルデータ通信（3G/4G LTE）もありますが、SIMが手元にないので今回は使いません。海外見る限り、動くみたいです。
Ubuntu Desktop 20.04 LTSをインストールします。
Download Ubuntu Desktop | Download | Ubuntu
要件自体は満たしています。モデルが64GBであり、容量が足りないのでデュアルブートにはしません。Windowsは完全に削除します。海外の方々を見る限り、デュアルブートでも問題ないです。128GBでWindowsを削除したくない場合は、デュアルブートでも良いと思います。
インストール方法は色々あると思いますが、USBメモリでインストールメディア作るのが良いと思います。ソフトは色々ありますが、Rufusで良いと思います。
Rufus - 起動可能なUSBドライブを簡単に作成できます
USBのインストールメディアをWindows上でRufusを使用して作る方法は、Ubuntuの公式ページで紹介されています。それに従ってください。英語です。
Create a bootable USB stick on Windows | Ubuntu
ISOは下記のページからダウンロードしてください。
Download Ubuntu Desktop | Download | Ubuntu
Surface 3へUbuntuをインストールする上に、セキュアブートを無効にする必要があります。セキュアブートは信頼されているファームウェアのみでパソコンを起動するというものです。つまりこれ有効だとWindows以外起動しないから、無効にしなくてはいけません。
やり方はMicrosoftの公式ドキュメントに書かれています。このページは日本語があります。BIOS起動して、セキュアブートを無効に設定するだけなので簡単です。
最初に作成したUSBのインストールメディアをSurfaceに挿して、そのUSBから起動する必要があります。BIOSから起動順序を変更することが可能です。やり方は、Microsoftサポートの公式ページに書かれています。日本語です。
USBから起動すると、Ubuntuのインストール画面が出てきます。後は表示される手順に従ってインストールしてください。Windowsを完全に削除する場合は、パーティションを全部削除するだけで良いです。もしもデュアルブートする場合は、Windows側からパーティションを縮小した上で、Windowsのパーティション領域を削除しないでください。パーティションの縮小は、[コントロールパネル]->[システムとセキュリティ]->[管理ツール]->[コンピューターの管理]->[ストレージ]->[ディスクの管理]から行ってください。
これでインストール作業は完了です。OSを利用するにはWi-Fi問題があるので、修正します。困ってない場合は、やらなくても大丈夫です。
なんだかよくわからないですが、Wi-Fiは起動直後は使えるのですが、一定時間するとWi-Fiが使えなくなります。
wifi.powersaveが問題らしいので、 /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf を編集して wifi.powersave の値を2に書き換えます。
ターミナル（端末）から下記のコマンドを実行してvimでファイルを編集してください。
sudo vim /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf
これでWi-Fiは取り敢えず直ります。
先日Raspberry pi（ラズパイ）を購入して、3.5インチディスプレイに接続して操作しようとしたら文字が小さすぎて見づらいという問題に遭遇したので、コンソール上で文字サイズを大きくする方法についてまとめておきます。
想像の数倍、文字が小さくて読めない。 pic.twitter.com/FtvTdwqtHJ — snake (@viasnake) May 1, 2021
ハード: Raspberry pi 3 model B+
OS: Raspberry Pi OS Lite 10 Buster
※Ubuntu 20.04及びDebian 10でも動作します。
本投稿で添付されている画像は全てUbuntu 20.04.2 LTS GNU/Linux 4.4.0-19041-Microsoft x86_64です。
下記のコマンドを実行してTUIを表示します。
$ sudo dpkg-reconfigure console-setup
TUIが表示されると下記のようになります。
最初にコンソールで使うエンコードを選択します。殆どの場合、UTF-8で問題ないです。
次の画面ではサポートさせる文字セットを選択するのですが、一番下の「Guess optimal character set」にしておきます。ここは自分の環境に合わせてください。
ここでコンソールのフォントを選択します。とりあえずここではTerminusを選択します。別に自分で使いやすいのに変更していいと思います。
シンプルさで行くならFixedが一番です。
フォントを選択すると、次にフォントサイズを選択できます。画像はフォントでTerminusを選択した場合です。
3.5インチディスプレイだと16x32が一番見やすかったので、16x32を選択します。
これでフォントサイズが変更されます。
文字サイズ変えたら見えるようになった。 pic.twitter.com/3XLXenAasA — snake (@viasnake) May 1, 2021
Ubuntu Server 20.04 LTS環境下でOSインストール時に作成した一般ユーザを使い、コンソールにログインすると矢印キーが文字化けして、コマンド履歴を遡れない問題に遭遇したので解決策を書き残しておきます。
結論から言っておくと、シェルがshになってるので、bashに変えてあげれば修正されます。
shでも過去のコマンド履歴を表示する方法はありますが、とりあえずここではshをbashに修正することにします。好みがあるならzshとか好きなのに変えてもいいと思います。
下記のコマンドで、有効にできる使用可能なシェル一覧を表示できます。
$ cat /etc/shells
例として、私の環境下でのシェル一覧を下に貼っておきます。環境によって表示が異なる可能性があります。
環境：Ubuntu 20.04.2 LTS (GNU/Linux 4.4.0-19041-Microsoft x86_64)
# /etc/shells: valid login shells
/bin/sh
/bin/bash
/usr/bin/bash
/bin/rbash
/usr/bin/rbash
/bin/dash
/usr/bin/dash
/usr/bin/tmux
/usr/bin/screen
下記のコマンドで各ユーザで使用しているシェルを確認することができます。
$ cat /etc/passwd
補足ですが、使用するシェルは各ユーザごとに定義可能です。
下記に私の環境下での、シェルを全て載せておきます。
各行の一番右側に書いてあるのがshellです。
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-network:x:100:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:101:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
systemd-timesync:x:102:104:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:103:106::/nonexistent:/usr/sbin/nologin
syslog:x:104:110::/home/syslog:/usr/sbin/nologin
_apt:x:105:65534::/nonexistent:/usr/sbin/nologin
tss:x:106:111:TPM software stack,,,:/var/lib/tpm:/bin/false
uuidd:x:107:112::/run/uuidd:/usr/sbin/nologin
tcpdump:x:108:113::/nonexistent:/usr/sbin/nologin
sshd:x:109:65534::/run/sshd:/usr/sbin/nologin
landscape:x:110:115::/var/lib/landscape:/usr/sbin/nologin
pollinate:x:111:1::/var/cache/pollinate:/bin/false
snake:x:1000:1000:,,,:/home/snake:/bin/sh
ユーザ多すぎて探すの多い場合は、grepで絞り込んで上げてください。
$ cat /etc/passwd |grep {ユーザー名}
$ cat /etc/passwd |grep snake
現在ログインしているユーザのシェルを変更する場合、下記のコマンドを実行してください。
$ chsh -s {シェル} {ユーザー名}
$ chsh -s /bin/bash snake
これで変更されます。実行後SSH入り直したりしてください。
変更後、現在のシェルを確認すると/bin/bashに変更されているはずです。
$ cat /etc/passwd |grep {ユーザー名}
Ubuntu Server 20.04 LTSでCronが変な時間に動いておかしいと思ったら、タイムゾーンがUTCになっていたので、タイムゾーンを変更する方法について書いておきます。
現在のタイムゾーンや時間を確認するには下記のコマンドを使用します。
$ timedatectl
コマンドによって表示される情報は下記の通りです。
Local time: Thu 2021-04-15 02:37:15 UTC Universal time: Thu 2021-04-15 02:37:15 UTC RTC time: Thu 2021-04-15 02:37:15 Time zone: Etc/UTC (UTC, +0000) System clock synchronized: yes NTP service: active RTC in local TZ: no
この場合、タイムゾーンはEtc/UTCに設定されている為、Asia/Tokyoに直します。
タイムゾーンを変更するには下記のコマンドを使用します。
sudo timedatectl set-timezone Asia/Tokyo
変更後、再度確認コマンドを使用すると下記のようになります。
Local time: Thu 2021-04-15 11:49:07 JST Universal time: Thu 2021-04-15 02:49:07 UTC RTC time: Thu 2021-04-15 02:49:07 Time zone: Asia/Tokyo (JST, +0900) System clock synchronized: yes NTP service: active RTC in local TZ: no
これで変更完了です。
Ubuntu Server 20.02 LTSのインストール時に最後のインストール画面でインストール状況を表示するログ画面があるのですが、その画面のrunning 'curtin hook'の横でスピナーがずっとぐるぐる回転しています。
所見でインストールした時、全然インストール終わらないなと思いながら、長時間待ってしまったので、書き残しておきます。
この問題はすでにバグとして報告されており、スピナーが回り続けるのみで実際にはインストール作業が終わっています。
インストール作業が完了しているかは「View full log」からログを確認することで分かります。
詳細はsubiquityのBug #1912957「"running 'curtin hook'" spinner keeps spinning forever 」を確認してください。
Bug #1912957 ”“running ‘curtin hook’” spinner keeps spinning for... : Bugs : subiquity
この問題は2021年01月24日に報告され、2021年02月21日に修正がコミットされています。