20211201のLinuxに関する記事は11件です。

pythonでpgrepして多重起動を防止する(走り書き)

※この記事は個人的なメモです pythonの多重起動を防止するのに,ファイルの存在でチェックしたり(例外で落ちてファイルが残る),ファイルのロックを使ったり(他プログラムからファイル自体を消されたり),専用のライブラリを導入したり(わざわざ?)等いろいろありますが,bashで多重起動をしないようにする方法をそのまま利用してしまえば早いし応用性が高い(perlでも似たようなことができる). コード main_code.py import os def main(): # main codes here. if __name__ == "__main__": pid = os.getpid() scriptname = os.path.basename(__file__) oldest_pid = int(os.popen(f"pgrep -fo {scriptname}").read()) if pid == oldest_pid: main() else: print("other process already running.") 結局やってること bashで言う下記のコードを実行してます. main_code.sh #!/bin/bash main(){ # main codes here. } pid=$$ scriptname=`basename $0` oldest_pid=`pgrep -fo $scriptname` if [ $pid == $oldest_pid ]; then main else echo "other process already running." fi 注意点 スクリプト名が一緒だと別のファイルでも実行制限に引っ掛かります(笑) 参考サイト https://docs.python.org/ja/3/library/os.html https://docs.python.org/ja/3/library/subprocess.html https://www.mk-mode.com/blog/2016/02/21/linux-bash-check-double-start/
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

linux wifiアダプタが見つかりません "ubuntu no wifi adapter found"

表題の不具合は高速スタートアップ無効したところ改善しました。 手順 1. Windowsボタン->設定->システム 2. 電源とスリープ->電源の追加設定(右側にあります) 3. 電源オプションのウィンドウが開くので、そこから"電源の追加設定"を選択 4. "現在利用可能ではない設定を変更します"をクリックしてから"高速スタートアップを有効にする"のチェックを外す 5. 変更の保存をクリックして再起動してみてください 私の環境 富士通ノートPC:Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz 1.80 GHz win10 buntu20.04のデュアルブート linuxの勉強をしようと思い、ノートpcにubuntu20.04をいれたのですが、使い始めてしばらくすると表題の不具合に遭遇しました。 はじめはubuntuでのシステムアップデートなどが原因かなと思ったのですが、どうやらノートpc側の電源設定が良くなかったらしいです。 ubuntu起動->win10起動->ubuntu起動 の用にwindowsのbootを挟むとwifiアダプタを見失うようです ちなみに、linuxmintでも試しましたが同じ不具合が発生しました。 お役に立てたら幸いです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

sarを自分スクリプトにして動かす

元祖の手順書そのままで申し訳ありませんが。。。 1秒ごと かつ 1日(86400秒)で設定 loadget.sh #!/bin/sh /usr/bin/sar -A -o log.txt 1 8640 cronに登録 crontab -e 1 * * * * /root/loadget.sh
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

sarを自分スクリプトにしてcronで動かす

元祖の手順書そのままで申し訳ありませんが。。。 1秒ごと かつ 1日(86400秒)で設定 loadget.sh #!/bin/sh /usr/bin/sar -A -o sar_`date +%Y%m%d`.txt 1 8640 cronに登録 crontab -e 1 * * * * /root/loadget.sh 吐き出したログを確認する。 CPUコアごと版 sar -P ALL -f log.txt cpuマージ版 sar -p -f log.txt ネットワーク sar -n DEV -f log.txt メモリ sar -r -f log.txt 停止方法 ※これしか思いつかなかった。。。 ps -ef | grep sar kill PID
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Linuxの構造を理解すれば、環境PATHの通し方が理解できる

まえがき どのプログラミング言語も、言語の中のライブラリでも、インストールしてから使うまでが実はしんどいということに共感してくれる方も少なくないと信じています。 ターミナルで「jupyter notebook」や「python」コマンドを使うには、環境変数であるPATHにこれらのコマンドを通す必要があります。 しかし、自分はいつもサイトなどで調べて闇雲にコピペして、通れば「っしゃぁ!」って感じで早速コードの学習とかしてきました。 初心者や初学者であればいちいち環境変数の通し方とか学ぶより、実践的なハンズオンをすればいいと思うので、わざわざ知らなくてもいいとは思います。 しかし、何事もちゃんと意味があって動作するのがコンピュータやインターネットであるため、 「どういうことをしているのか?」を知ることは無駄にはならないと思っています。 今回は自分の中である種の原点を探るような感覚だった「PATH」を通す過程の意味するところ、を書いていこうと思います。 ※ちなみに今回はlinuxを対象としているため、windowsなどはその限りではない、ということは御了承下さい。。。 そもそもLinuxのディレクトリ構造を理解しているだろうか? 自分はシステム関係などをまっったく学習せずpythonなどを扱ってきたり、for文・if文などを学習してきた人です。 なので、時たま出てくるディレクトリの「/var/~」やら「/opt/~」などに気にせず、 「そういうディレクトリがこのPCあるんだ〜」程度の認識で進めてました。 (別に悪いとは思いませんが笑) Linuxの学習(LinuCとか)をしていると、実はそれぞれのディレクトリには目的があって構成されていることを知りました。 (仮想環境ではLV(論理ボリューム)などでひとまとめにして自分でパーティションを作成したりはできる) 代表的なものをざっとまず紹介します(後ほど出てくるものも出てこないものもあるので、一旦読み飛ばしてもらってもOKです。) / (root) もっとも最上の階層にあるディレクトリ。 全てのディレクトリはここから始まる。 注意すべきは、rootユーザーと自分のホームディレクトリは違う、という点です。 ちょっと見てみましょう (仮想環境でubuntuを起動しています。windowsユーザーなどはvirtual boxやdockerのコンテナ上でお試しいただければ) 一般ユーザ root ちゃんと違いますね。 もし、例えばrootユーザで自分(画像で言えば「ubuntu」という名前のユーザ)のホームディレクトリを見たい時は以下 cd ~ユーザ名; pwd とかでいけます /bin 一般ユーザ用のコマンドを格納しているディレクトリです。 ずっとbinてなんの略なんかな?って思ってたんですが、binaryの略(っぽい)です。 おそらくちょっと学習してきた方は/binディレクトリは見たことあると思います。 例えばお馴染みmkdirがどこにあるかをwhereisコマンドで見てみると、 ※「whereis コマンド」でコマンド本体のライブラリやソースファイルのパスを参照できるコマンドです。 (/binディレクトリはシステム起動に必要なディレクトリであり、ルートパーティションから分割できないです。) /sbin システム管理者用のコマンドを格納しているディレクトリです。 普段はあまり見かけないかなと思います。 いわゆるshutdown・rebootコマンドなどはここに格納されています。 (/sbinディレクトリはシステム起動に必要なディレクトリであり、ルートパーティションから分割できないです。) /etc 個人的には「エトセトラ」感はないんですが、エトセトラ。 システムの設定ファイルを格納しているディレクトリです。 .confファイルなどが格納されています。 (/etcディレクトリはシステム起動に必要なディレクトリであり、ルートパーティションから分割できないです。) /lib 共有ライブラリを格納しています。 実はpythonとかsystemdとかここにある。 (厳密に言えば、ここのpythonからコマンドの「python」を参照しているわけではない。) (/libディレクトリはシステム起動に必要なディレクトリであり、ルートパーティションから分割できないです。) /dev デバイスファイルを格納しています。 おそらくパーティションの作成とか・外部機器を使う以外に触れることはない。 (/devディレクトリはシステム起動に必要なディレクトリであり、ルートパーティションから分割できないです。) /home 一般ユーザのホームディレクトリ 一つのユーザしかいない場合はユーザ名のディレクトリが一つ存在している。 複数いればその数だけディレクトリが下にある ルートパーティションから分割可能。 /usr システム起動には不要なプログラムなどを格納 さきほどmkdirは/bin/mkdirにあることを確認しましたが、実はおなじみのtouchやgrepコマンドは/binディレクトリではなく、/usr/binディレクトリの方に格納されている。 (わざわざ覚えなくても十分生きていけます。) /binにあるコマンドのように必須でないコマンドをたくさん格納しているため、読み込みが頻繁に発生する。 ルートパーティションから分割可能。 /var variableの略。 ログファイルなどの可変ファイルを格納 ときどき見かけるようなディレクトリのイメージが個人的にある。 ルートパーティションから分割可能。 /opt 追加でインストールしたパッケージを格納 (基本的にインストールしたものが招かれる応接室) たくさんインストールするとここがパンパンになりがち。 ルートパーティションから分割可能。 /boot linuxカーネルなどの起動に必須のファイルを格納 ちなみに自分の/optにはhomebrew とかあったので覗いてみるとDockerfileなどもありました。 ルートパーティションから分割可能。 /tmp 一時ファイルの格納。 ほぼ見ない ルートパーティションから分割可能。 「jupyter lab」コマンドのpathを通す過程をdockerfileでなぞる 以前たしかここでDockerfileでmecabとかsumyのセットアップする、みたいな記事を書いた気がしますが、Dockerfile のように環境構築時にすぐにjupyter labをコマンドとして使うためにはPATHを通す必要があります。 FROM ubuntu:latest RUN apt update && apt install -y \ curl \ file \ git \ libmecab-dev \ make \ mecab \ mecab-ipadic-utf8 \ sudo \ wget \ vim \ xz-utils # install anaconda3 you can change the version if you want to WORKDIR /opt RUN wget https://repo.anaconda.com/archive/Anaconda3-2021.05-Linux-x86_64.sh && \ sh Anaconda3-2021.05-Linux-x86_64.sh -b -p /opt/anaconda3 && \ rm -f Anaconda3-2021.05-Linux-x86_64.sh ENV PATH=/opt/anaconda3/bin:$PATH RUN pip install --upgrade pip && \ pip install mecab-python3 && \ pip install mojimoji && \ pip install unidic-lite WORKDIR / # get the ipadic-neologd RUN git clone --depth 1 https://github.com/neologd/mecab-ipadic-neologd.git && \ echo yes | mecab-ipadic-neologd/bin/install-mecab-ipadic-neologd -n -a CMD ["jupyter", "lab", "--ip=0.0.0.0", "--allow-root", "--LabApp.token=''"] そのときにPATHを通すと言ってもいつもサイトを見ながらしていますが、このディレクトリ構造を理解すれば、(なんとなく)何をしていたのか?を理解できるのかなと思います。 若干ローカル環境とは違いますが、やっていることは同じなので、見ていきます。 該当箇所は以下 WORKDIR /opt RUN wget https://repo.anaconda.com/archive/Anaconda3-2021.05-Linux-x86_64.sh && \ sh Anaconda3-2021.05-Linux-x86_64.sh -b -p /opt/anaconda3 && \ rm -f Anaconda3-2021.05-Linux-x86_64.sh ENV PATH=/opt/anaconda3/bin:$PATH 先程のように一時的なインストールは基本的に/optディレクトリでおこなうため、WORKDIRで場所を移動します。 その次に、wgetでソースを取得し、shコマンドを起動やらなんやらしています。 最後にENVコマンド(exportみたいなやつ)で、起動するために必要なコマンドが格納されている/bin(=/opt/anaconda3/bin)に「jupyter lab」コマンドがあるためこれを環境変数として設定して完了! 終わり サラッとした解説だったかもしれないですが、闇雲にPATHを通していたあの頃と違って、 ちゃんと何をしているからコマンドが使えるのか? を説明してきました。 linuxの学習は(自分は)かなり最初はとっつきにくく、華やかなコーディングや結果もでないのですが、やはりコンピュータを扱う上で大切な概念だと感じてきています。 ま、興味あればぜひ〜 今回参考にさせていただいた記事 ディレクトリ構造 Linuxディレクトリ構造
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Ultra96-V2 の WiFi で超苦労した話(v2021.1編)

はじめに 以前、Ultra96-V2 の WiFi を Xilinx 社の提供する linux-xlnx v2019.1 で動かす方法について Qiita に次のような記事を投稿しました。 『Ultra96-V2 の WiFi で超苦労した話』 @Qiita 上の記事では linux-xlnx v2019.1 (Linux Kernel 5.4 をベース) を対象にしていましたが、linux-xlnx v2021.1 (Linux Kernel 5.10 をベース) では上の記事で紹介した方法では Ultra96-V2 の WiFi を動かすことができませんでした。 この記事では、Ultra96-V2 向け Debian GNU/Linux (v2021.1版) で WiFi を動かすために ATWILC3000 の Linux Driver を組み込む方法を紹介します。 Linux Driver のリポジトリ linux-xlnx v2019.1 では ATWILC3000 の Linux Driver は Avnet が提供しているものを使っていましたが、この Linux Driver は linux-xlnx v2021.1 ではコンパイルできませんでした。そこで linux-xlnx v2021.1 では WiFi Chip の製造元である Microchip 社が提供している Linux Driver を使います。 Microchip 社の提供する Linux Driver は github で公開されています。 https://github.com/linux4sam/linux-at91 上記のリポジトリは Linux Kernel 全体の Fork になっています(かなりデカいので注意)。該当する Linux Driver のソースコードは drivers/net/wireless/microchip/wilc1000 にあります。また、linux-xlnx v2021.1 からは新に mmc のパワー制御のための Linux Driver が必要になります。ATWILC3000 用のパワー制御用 Linux Driver のソースコードは drivers/mmc/core/pwrseq_wilc.c です。 https://github.com/linux4sam/linux-at91/tree/master/drivers/net/wireless/microchip/wilc1000 https://github.com/linux4sam/linux-at91/tree/master/drivers/mmc/core/pwrseq_wilc.c パッチのリポジトリ 上記の Linux Driver を試したところ、私の Ultra96-V2 では動作しませんでした。いろいろ調べた結果、Avnet の提供するパッチをあてる必要があることがわかりました。パッチは次の URL にあります。 https://github.com/Avnet/meta-avnet/blob/2021.1/recipes-modules/wilc/files/0001-ultra96-modifications-15.5.patch Linux Kernel のソースコードに追加する Microchip 社の Linux Driver をダウンロード shell$ git clone --depth 1 https://github.com/linux4sam/linux-at91 Avnet 社の meta-avnet をダウンロード shell$ git clone --depth 1 -b 2021.1 https://github.com/Avnet/meta-avnet linux-xlnx v2021.1 をダウンロード linux-xlnx v2021.1 をダウンロードします。ディレクトリは linux-xlnx-v2021.1-zynqmp-fpga としています。 shell$ git clone --depth 1 -b xilinx-v2021.1 https://github.com/Xilinx/linux-xlnx.git linux-xlnx-v2021.1-zynqmp-fpga shell$ cd linux-xlnx-v2021.1-zynqmp-fpga ATWILC3000 の Linux Driver を linux-xlnx v2021.1 にコピー drivers/net/wireless/microchip/wilc1000/ にあるソースファイルを drivers/staging/wilc3000/ にコピーします。 shell$ mkdir drivers/staging/wilc3000 shell$ cp ../linux-at91/drivers/net/wireless/microchip/wilc1000/* drivers/staging/wilc3000 drivers/staging/Kconfig と drivers/staging/Makefile に wilc3000 を追加します。 linux-xlnx-v2021.1-zynqmp-fpga-wilc3000.diff diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index 9d424b925..2ea288a5e 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -82,6 +82,8 @@ source "drivers/staging/fbtft/Kconfig" source "drivers/staging/fsl-dpaa2/Kconfig" +source "drivers/staging/wilc3000/Kconfig" + source "drivers/staging/most/Kconfig" source "drivers/staging/ks7010/Kconfig" diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index 55a321d29..f0152d834 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -31,6 +31,7 @@ obj-$(CONFIG_UNISYSSPAR) += unisys/ obj-$(CONFIG_XILINX_APF) += apf/ obj-$(CONFIG_FB_TFT) += fbtft/ obj-$(CONFIG_FSL_DPAA2) += fsl-dpaa2/ +obj-$(CONFIG_WILC) += wilc3000/ obj-$(CONFIG_MOST) += most/ obj-$(CONFIG_KS7010) += ks7010/ obj-$(CONFIG_GREYBUS) += greybus/ Avnet のパッチをあてる drivers/staging/wilc3000 に Avnet が提供しているパッチをあてます。 shell$ patch -d drivers/staging/wilc3000 < ../meta-avnet/recipes-modules/wilc/files/0001-ultra96-modifications-15.5.patch patching file Kconfig patching file Makefile patching file cfg80211.c patching file debugfs.h patching file netdev.c patching file netdev.h patching file power.c patching file sdio.c patching file wlan.c patching file wlan.h patching file wlan_cfg.c ATWILC3000 パワー制御用の Linux Driver を linux-xlnx v2021.1 にコピー pwrseq_wilc.c を drivers/mmc/core/ にコピーします。 shell$ cp ../linux-at91/drivers/mmc/core/pwrseq_wilc.c drivers/mmc/core/ drivers/mmc/core/Kconfig と drivers/mmc/core/Makefile に pwrseq_wilc を追加します。 linux-xlnx-v2021.1-zynqmp-fpga-pwrseq-wilc.diff diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig index c12fe13e4..b65ff34fe 100644 --- a/drivers/mmc/core/Kconfig +++ b/drivers/mmc/core/Kconfig @@ -34,6 +34,16 @@ config PWRSEQ_SIMPLE This driver can also be built as a module. If so, the module will be called pwrseq_simple. +config PWRSEQ_WILC + tristate "HW reset support for Microchip WILC BT + WiFi devices" + depends on OF + help + This selects hardware reset support for Microchip WILC BT + WiFi + devices. By default this option is set to n. + + This driver can also be built as a module. If so, the module + will be called pwrseq_wilc. + config MMC_BLOCK tristate "MMC block device driver" depends on BLOCK diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile index 95ffe008e..058ac3fa9 100644 --- a/drivers/mmc/core/Makefile +++ b/drivers/mmc/core/Makefile @@ -13,6 +13,7 @@ mmc_core-$(CONFIG_OF) += pwrseq.o obj-$(CONFIG_PWRSEQ_SIMPLE) += pwrseq_simple.o obj-$(CONFIG_PWRSEQ_SD8787) += pwrseq_sd8787.o obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o +obj-$(CONFIG_PWRSEQ_WILC) += pwrseq_wilc.o mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o obj-$(CONFIG_MMC_BLOCK) += mmc_block.o mmc_block-objs := block.o queue.o Linux Kernel のイメージに組み込む Ultra96-V2 では ATWILC3000 は ZynqMP の sdio1 に接続しています。ATWILC3000 を SDIO から制御するためのデバイスドライバは CONFIG_WILC_SDIO です。arch/arm64/configs/xilinx_zynqmp_defconfig に CONFIG_WILC_SDIO=y を追加します。ここではモジュールではなく Linux Kernel Image に組み込んでしまうために =m でなく =y を指定しています。 同様に ATWILC3000 のパワー制御用ドライバを組み込むために CONFIG_PWRSEQ_WILC=y を arch/arm64/configs/xilinx_zynqmp_defconfig に追加します。 diff --git a/arch/arm64/configs/xilinx_zynqmp_defconfig b/arch/arm64/configs/xilinx_zynqmp_defconfig index cd6b1a7d7..a6cdc6600 100644 --- a/arch/arm64/configs/xilinx_zynqmp_defconfig +++ b/arch/arm64/configs/xilinx_zynqmp_defconfig @@ -180,6 +180,8 @@ CONFIG_USB_USBNET=y CONFIG_WL18XX=y CONFIG_WLCORE_SPI=y CONFIG_WLCORE_SDIO=y +CONFIG_WILC_SDIO=y +CONFIG_PWRSEQ_WILC=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y CONFIG_KEYBOARD_GPIO_POLLED=y Device Tree に組み込む Ultra96-V2 では ATWILC3000 は ZynqMP の sdio1 に接続しています。したがって Device Tree の sdio1 のデバイスドライバである sdhci1 に ATWILC3000 のデバイスドライバをノードとして追加します。下記の例では wlcore というシンボルでノードを追加しています。 arch/arm64/boot/dts/xilinx/avnet-ultra96v2-rev1.dts &sdhci1 { status = "okay"; bus-width = <0x4>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sdhci1_default>; xlnx,mio-bank = <0>; non-removable; disable-wp; // cap-power-off-card; /* This is not compatible with the WILC3000 and means the WILC will always be powered on */ non-removeable; mmc-pwrseq = <&sdio_pwrseq>; vqmmc-supply = <&wmmcsdio_fixed>; #address-cells = <1>; #size-cells = <0>; wlcore: wilc_sdio@0 { compatible = "microchip,wilc3000", "microchip,wilc3000"; status = "okay"; reg = <0>; bus-width = <4>; }; }; wlcore の compatible プロパティには "microchip,wilc3000", "microchip,wilc3000" を指定します。 mmc のパワー制御用のドライバは mmc-pwrseq プロパティで指定します。Ultra96-V2 では <&sdio_pwrseq> を指定します。 <&sdio_pwrseq> はデバイスツリーのトップレベルに次のように記述します。 arch/arm64/boot/dts/xilinx/avnet-ultra96v2-rev1.dts / { : (中略) : sdio_pwrseq: sdio-pwrseq { compatible = "mmc-pwrseq-wilc"; reset-gpios = <&gpio 7 GPIO_ACTIVE_HIGH>; powerdown-gpios = <&gpio 8 GPIO_ACTIVE_HIGH>; status = "okay"; }; }; sdio_pwrseq の compatible プロパティには "mmc-pwrseq-wilc" を指定します。 reset-gpiosプロパティには <&gpio 7 GPIO_ACTIVE_HIGH> を指定します。Ultra96-V2 では ATWILC3000 の RESETN ピンは ZynqMP の MIO7 に接続されています。RESETN の最後の N は Negative(Low Active) を意味するのですが、ここでは GPIO_ACTIVE_HIGH を指定しなければなりません。紛らわしいので注意してください。 powerdown-gpios プロパティには <&gpio 8 GPIO_ACTIVE_HIGH> を指定します。Ultra96-V2 では ATWILC3000 の CHIP_EN ピンは ZynqMP の MIO8 に接続されています。CHIP_EN ピンは High にすることで動作を開始し、Low にすることでパワーダウンします。そういう意味では powerdown-gpios に GPIO_ACTIVE_HIGH を指定するのは少し違和感があるのですが、Linux Driver がそうなっているので仕方がありません。 Firmware を Root File System にインストールしておく ATWILC3000 の Linux Driver は、起動時に firmware を ATWILC3000 にロードします。firmware は以下の URL にあります。 https://github.com/linux4wilc/firmware この firmware は /lib/firmware/mchp になければなりません。Root File System を作る時にインストールしておくか、後で追加してください。ネットワークが使えないと後から追加するのにも不便なので、あらかじめインストールしておいたほうが良いでしょう。 debian10-rootfs# mkdir /lib/firmware/mchp debian10-rootfs# git clone git://github.com/linux4wilc/firmware linux4wilc-firmware debian10-rootfs# cp linux4wilc-firmware/*.bin /lib/firmware/mchp debian10-rootfs# rm -rf linux4wilc-firmware 苦労した点 当初は、Avnet 社のパッチを知らずに Microchip 社の提供する Linux Driver のみで動かそうとして全然動かずに難儀しました。もうあきらめて Ultra96-V2 は古いカーネルで動かしていました。そしたら ある方(この方は Yocto でシステムを構築したらしい)から meta-avnet を使って構築した Linux 5.10 では Ultra96-V2 の WiFi が動いているとのメールをいただきました。さっそく調べたところ、meta-avnet ではパッチをあてていることがわかり、このパッチをあてれば Ultra96-V2 の WiFi が動きました。 メールで教えてくださった方、パッチを提供してくれた Avnet 社、もちろん Linux Driver を提供している Microchip 社にも感謝します。 参考 https://github.com/linux4sam/linux-at91 https://github.com/Avnet/meta-avnet/ https://github.com/linux4wilc/firmware 『Ultra96-V2 の WiFi で超苦労した話』 @Qiita 『UltraZed/Ultra96/Ultra96-V2/KV260 向け Debian GNU/Linux (v2021.1版) ブートイメージの提供』@Qiita
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

RedhatOS設計 fdisk→pv→vg→lvまで

※参考古賀先生のcentos8 CentOS8 実践ガイド [システム管理編] なんのためにfdiskを実施するのか。 理由:OSが認識できるパーティションを作成するため。 パーティションを作成後に、LVM(Logical Volume Manager)管理する。 手順 0.ゲストOSを停止する。 0-1。ゲストOSにディスクを追加する または 0-1 ゲストOSの既存ディスクサイズを増やす。 今回は、既存ディスクサイズ変更で実施しました。 1.fdiskでデバイスの情報を取得する。 fdisk -l デバイス名(/dev/sdaX) ディスクが30GB→50GBに増えていることを確認。 fdisk -l /dev/sda Disk /dev/sda: 53.7 GB, 53687091200 bytes, 104857600 sectors Units = sectors of 1 * 512 = 512 bytes 2.fdiskを行う。今回追加されるのは「/dev/sda3」 n add a new partition p print the partition table t change a partition's system id w write table to disk and exit fdisk /dev/sda Welcome to fdisk (util-linux 2.23.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. コマンド (m でヘルプ): n Partition type: p primary (2 primary, 0 extended, 2 free) e extended Select (default p): p パーティション番号 (3,4, default 3): 最初 sector (62914560-104857599, 初期値 62914560): 初期値 62914560 を使います Last sector, +sectors or +size{K,M,G} (62914560-104857599, 初期値 104857599): 初期値 104857599 を使います Partition 3 of type Linux and of size 20 GiB is set コマンド (m でヘルプ): p Disk /dev/sda: 53.7 GB, 53687091200 bytes, 104857600 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト Disk label type: dos ディスク識別子: 0x000ae6d1 デバイス ブート 始点 終点 ブロック Id システム /dev/sda1 * 2048 2099199 1048576 83 Linux /dev/sda2 2099200 62914559 30407680 8e Linux LVM /dev/sda3 62914560 104857599 20971520 83 Linux コマンド (m でヘルプ): t パーティション番号 (1-3, default 3): Hex code (type L to list all codes): 8e Changed type of partition 'Linux' to 'Linux LVM' コマンド (m でヘルプ): p Disk /dev/sda: 53.7 GB, 53687091200 bytes, 104857600 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト Disk label type: dos ディスク識別子: 0x000ae6d1 デバイス ブート 始点 終点 ブロック Id システム /dev/sda1 * 2048 2099199 1048576 83 Linux /dev/sda2 2099200 62914559 30407680 8e Linux LVM /dev/sda3 62914560 104857599 20971520 8e Linux LVM コマンド (m でヘルプ): w パーティションテーブルは変更されました! ioctl() を呼び出してパーティションテーブルを再読込みします。 WARNING: Re-reading the partition table failed with error 16: デバイスもしくはリソースがビジー状態です. The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) ディスクを同期しています。 3.fdiskの設定確認を行う。 fdisk -l Disk /dev/sda: 53.7 GB, 53687091200 bytes, 104857600 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト Disk label type: dos ディスク識別子: 0x000ae6d1 デバイス ブート 始点 終点 ブロック Id システム /dev/sda1 * 2048 2099199 1048576 83 Linux /dev/sda2 2099200 62914559 30407680 8e Linux LVM /dev/sda3 62914560 104857599 20971520 8e Linux LVM Disk /dev/mapper/vg001-system: 27.9 GB, 27908898816 bytes, 54509568 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト Disk /dev/mapper/vg001-swap: 3221 MB, 3221225472 bytes, 6291456 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト 4.現在の物理ボリューム情報を取得する。 pvdisplay pvdisplay --- Physical volume --- PV Name /dev/sda2 VG Name vg001 PV Size <29.00 GiB / not usable 3.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 7423 Free PE 1 Allocated PE 7422 PV UUID qQ1CeJ-9ulz-VqO8-qSno-lXsf-ig4b-Ilkf7o 5.物理ボリュームに先ほど追加したデバイスを追加する。 ※createっていうけど、デバイスを登録するイメージに近い。 ※以下のコマンド失敗。。。。 ※OS再起動が必要でした。。。。 ※fdiskからは見えるがLVM側からは認識できない。 pvcreate /dev/sda3 Physical volume "/dev/sda3" successfully created. 6.物理ボリューム一覧を表示する ※追加されたこと確認 [root@redhat ~]# pvdisplay --- Physical volume --- PV Name /dev/sda2 VG Name vg001 PV Size <29.00 GiB / not usable 3.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 7423 Free PE 1 Allocated PE 7422 PV UUID qQ1CeJ-9ulz-VqO8-qSno-lXsf-ig4b-Ilkf7o "/dev/sda3" is a new physical volume of "20.00 GiB" --- NEW Physical volume --- PV Name /dev/sda3 VG Name PV Size 20.00 GiB Allocatable NO PE Size 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID W2MHA4-Ndpf-thlp-xWh9-B5li-563U-4kBzrm 7.今回は、既存のvgにディスクを追加する。 vgdisplay --- Volume group --- VG Name vg001 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size <29.00 GiB PE Size 4.00 MiB Total PE 7423 Alloc PE / Size 7422 / 28.99 GiB Free PE / Size 1 / 4.00 MiB VG UUID parUDn-nSC2-cUs7-dgaj-I2oA-pYAW-30Y4Vg 既存のボリュームグループがvg001なのでそれに先ほどpvcrateしたデバイス「/dev/sda3」を追加する。 vgextend vg001 /dev/sda3 Volume group "vg001" successfully extended lvdisplayで ※LV NAME変な名前にしてすいません。 lvdisplay --- Logical volume --- LV Path /dev/vg001/system LV Name system VG Name vg001 LV UUID Hvjad0-ZyxR-zPB9-HAvL-jcFQ-Sx6E-B5Bo9T LV Write Access read/write LV Creation host, time localhost, 2021-11-30 01:41:10 +0900 LV Status available # open 1 LV Size 25.99 GiB Current LE 6654 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 8192 Block device 253:0 --- Logical volume --- LV Path /dev/vg001/swap LV Name swap VG Name vg001 LV UUID mGV0k1-NvUF-Y5nH-rDV2-ocpC-0BN6-03UToQ LV Write Access read/write LV Creation host, time localhost, 2021-11-30 01:41:11 +0900 LV Status available # open 2 LV Size 3.00 GiB Current LE 768 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 8192 Block device 253:1 最後に lvextend lvextend -l +100%FREE /dev/vg001/system Size of logical volume vg001/system changed from 25.99 GiB (6654 extents) to 45.99 GiB (11774 extents). Logical volume vg001/system successfully resized. vgdisplayで Free PE / Size 0 / 0になったこと vgdisplay --- Volume group --- VG Name vg001 System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 5 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 2 Act PV 2 VG Size 48.99 GiB PE Size 4.00 MiB Total PE 12542 Alloc PE / Size 12542 / 48.99 GiB Free PE / Size 0 / 0 VG UUID parUDn-nSC2-cUs7-dgaj-I2oA-pYAW-30Y4Vg lvdisplayでサイズが増えたことを確認する。 LV Size 45.99 GiB lvdisplay --- Logical volume --- LV Path /dev/vg001/system LV Name system VG Name vg001 LV UUID Hvjad0-ZyxR-zPB9-HAvL-jcFQ-Sx6E-B5Bo9T LV Write Access read/write LV Creation host, time localhost, 2021-11-30 01:41:10 +0900 LV Status available # open 1 LV Size 45.99 GiB Current LE 11774 Segments 3 Allocation inherit Read ahead sectors auto - currently set to 8192 Block device 253:0 今回はファイルシステムがxfsなので xfs_growfsコマンドを実行 xfs_growfs /dev/vg001/system meta-data=/dev/mapper/vg001-system isize=512 agcount=4, agsize=1703424 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0 spinodes=0 data = bsize=4096 blocks=6813696, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal bsize=4096 blocks=3327, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 data blocks changed from 6813696 to 12056576 #拡張前 df -h /dev/mapper/vg001-system 26G 3.8G 23G 15% / #拡張後 df -h /dev/mapper/vg001-system 46G 3.8G 43G 9% / 増えていることを確認
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

RedhatOS設計 ログイン設計②

パスワード文字数制限 いつか書きます。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ワンライナー1 コメント行と空行を消す

CentOS8の本から コメント行とから行を外す。 パターン① cat .bash_profile | grep -v ^# | grep -v ^$ パターン② grep -Ev "^#|^$" .bash_profile
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Ubuntuでマイクのノイズを軽減する時にハマったこと

背景 最近開発をUbuntu20.04でやっていて、ZoomやTeamsのようなビデオ通話も今後使いたく、マイクを繋いでみました。 (ミニタワーの自作デスクトップでフロントのマイク3極+イヤホン3極に4極変換プラグをかましてEarPodsを接続) サンワサプライ ヘッドセット用変換アダプタケーブル(4極メス->3極オスx2) 黒 KM-A24-005 Teamsのテスト通話をやってみたところ、ノイズが酷く、比較のため手持ちのMacBook Proでテスト通話をやってみるとノイズはありませんでした。 調べたこと 調べたところ、Mac等では音声入力に対しノイズ軽減をしているとのことで、LinuxではPulseAudioのエコーキャンセルモジュールを使うと良いようでした。 使用しているUbuntu20.04もデフォルトでPulseAudioは入っており、設定ファイルにひと手間加えることでノイズ軽減ができるようでした。 ハマったこと ネットの情報を頼りに/etc/pulse/default.paにload-module module-echo-cancelを追記して、とやったところ、確かにオーディオ設定で(echo cancelled ...の選択肢が出てくるのですが、これが音が出ません。 よく見るとUSB3.0 capture Analog Input (echo cancelled ...となっており、現状ノイズはあるが音が出ているBuilt-in Audioではないようです。これの正体に気づくまでに時間がかかりました。 見落としていたこと 気づけばしょうもない話なのですが、実はこれ数ヶ月前にPCにUSBで差し込んでいたHDMIキャプチャーボードのようでした。(忘れてました...←) Chilison HDMI キャプチャーボード どうやらアナログのinputよりこちらが優先されてエコーキャンセルが適用されていたようで、それでマイクからのinputに適用されていなかったようです。 解決した方法 How To Enable Echo / Noise Cancellation Of Microphone Input On Your Linux Desktop (PulseAudio) こちらの記事の「How to choose the microphone in setups with multiple microphones, to use with the PulseAudio module-echo-cancel」の章に求めていた答えがありました。 どうやらinputするデバイスが複数ある場合、エコーキャンセルにどれを適用するか指定ができるようです。 詳細はリンク先を見て頂ければと思いますが、こちらの方法で繋いでいるマイクの方が適用になるようにしたところ、無事Built-in Audio Analog Stereo (echo cancelled ...が表示され、Teamsのテスト通話でノイズキャンセルされたマイク入力の確認ができました 余談 ここまでやってみてですが、ノイズは消えたものの音がこもってるような感じもするので、音質自体はデバイスの問題もあるかもしれないです。(PC側や4極変換プラグ等) また、あまり自分のようなケースの人はいないと思うので、今回情報が出てこず手こずりました もし似た境遇で困っている人がいたらヒントになると良いなと思います。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

自作Cコンパイラ、自作viクローン、自作Pythonクローン(未完成)がiSHで動きました。

どうやら、iSHにはinstall先にファイルがあるとファイルが壊れるみたいで7時間くらいハマって ようやくデバッグしました。単にコンパイル時にsudo make uninstallするだけですが 僕の7時間返せ。でも、iPhone実機で自作エディッタが動いた時は感涙しました。 androidのtermuxでも同じように全環境が動きます。 どうでもいいんですけどね。まあ、面白いんでやってます。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む