常連

apt-getコマンドについて質問です。

apt-get remove [パッケージ名]　：　パッケージを削除
apt-get purge [パッケージ名] :設定ファイルを含めパッケージを削除

ここまではわかりました。
ここで、

apt-get --purge remove　というのを見かけました。
これは、なんですか？
Q1. --purge の --はどういう意味でしょうか？
Q2. purgeとremoveを同時に使わなくてもpurgeだけで住む気がするのですがなぜどちらも使っているのでしょうか？

ご回答よろしくお願いします。

apt-get のpurgeとremoveについて

### windows10からLinuxへSSH接続してscpでファイルコピーがしたいのですが…

現在、Windows10からDebianで駆動しているタブレット端末にTera TermでSSH接続しています。
Linuxでタブレット端末のセットアップが簡単にできるようにシェルスクリプトを組んでいます。
Linuxの中の操作は、なんとか出来て次に、素材の配置をどうしようかと考えています。
ゴールはバッチファイルを叩いたらすぐセットアップができるようにスクリプトを組むことです。
### 悩んでいる問題

```
Windows10 PC からの操作で、GIF、HTMLなどの素材を適切な場所に配置したいと思い、
SCP ******
というコマンドを使用すればなんとかなる、ということまで辿りつきました。

この場合ですが、ニュアンス的に
１）Linux側からWinに入り、データを引っ張る
２）Windows側でバッチファイルを作成しデータを送信する
のうち、２）が近道では、と考えています。

コピー元：win     c:¥sample¥
コピー先:Linux   /usr/test/
```
接続先：Debianタブレット
IP Address：198.168.11.5
ユーザー：User
Password：Hogehoge
SUのPW：SUbuzz
```
この場合、Windows側のスクリプトがいいのか、Linux側のスクリプトがいいのか、
そのどちらかの場合どんな方法があるのかご教授願えますか？

ちなみに
scp c:¥sample¥test.txt /usr/test/test.txt
は失敗しました。
よろしくお願いします。
```

windows10からLinuxへSSH接続してscpでファイルコピーがしたいができません

### 前提・実現したいこと
Dockerのバージョンを18.x（正確なバージョンは失念）系から19.03.13へアップグレードしたところ、
コンテナから外部向けに通信できなくなりました。
この状況を解消したいです。


### 状態
#### pingの状況
以下の通り、ホスト名・IPアドレスのどちらの指定でもpingで疎通できない状態です。
```
$ docker run -it --rm debian ping -c 1 google.com
ping: google.com: Temporary failure in name resolution

$ docker run -it --rm debian ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
```

なお、ホストOS上ではどちらも疎通できている旨確認済みです。


#### ネットワーク周りの設定
##### ip link
```
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether f6:08:0d:fa:10:b4 brd ff:ff:ff:ff:ff:ff
3: sit0: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default
    link/sit 0.0.0.0 brd 0.0.0.0
4: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether 34:c3:d2:93:cd:23 brd ff:ff:ff:ff:ff:ff
5: p2p0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether 36:c3:d2:93:cd:23 brd ff:ff:ff:ff:ff:ff
6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
    link/ether 02:42:5b:4a:1b:70 brd ff:ff:ff:ff:ff:ff
```

##### iptables -L
```
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER-USER  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER (1 references)
target     prot opt source               destination

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere
RETURN     all  --  anywhere             anywhere

Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere
RETURN     all  --  anywhere             anywhere

Chain DOCKER-USER (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere
```

##### iptables -L -t nat
```
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DOCKER     all  --  anywhere             anywhere             ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DOCKER     all  --  anywhere            !loopback/8           ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  172.17.0.0/16        anywhere

Chain DOCKER (2 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere
```

##### sysctl net.ipv4.ip_forward（2020/10/28 19:42追記）
```
net.ipv4.ip_forward = 1
```
##### firewalld について（2020/10/28 19:42追記）
firewalldは未使用です。

##### docker network inspect bridge（2020/11/05 21:16追記）
```
[
    {
        "Name": "bridge",
        "Id": "168c88ff61f7714631933374a51b27a0a17315613034eb352cfb4ae6b6565904",
        "Created": "2020-11-05T21:11:47.467361496+09:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]
```
##### docker network ls（2020/11/05 21:16追記）
```
NETWORK ID          NAME                DRIVER              SCOPE
168c88ff61f7        bridge              bridge              local
dbd4737f60a2        host                host                local
8f72254d2392        none                null                local
```

##### docker run -it --rm debian ip a（2020/11/05 22:11追記）
```
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: sit0: <NOARP> mtu 1480 qdisc noop state DOWN group default
    link/sit 0.0.0.0 brd 0.0.0.0
9: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever
```


### 試したこと
#### ホストOSの再起動
```
reboot
```
#### Dockerサービスの再起動
```
service docker restart
```
#### Dockerサービスを停止した上でDokcerのブリッジ関連の設定を削除し、Dockerサービスを改めて起動
```
service docker stop
iptables -t nat -F
ifconfig docker0 down
brctl delbr docker0
service docker start
```


### 補足情報（FW/ツールのバージョンなど）
#### 稼働環境
アーキテクチャ：ARM v8（Pine64）
ホストOS：ARMBIAN 5.60 stable Debian GNU/Linux 9 (stretch)
インストールしたDockerのパッケージ名：Docker-ce
インストールに使ったsources.listの内容：
```
deb [arch=arm64] https://download.docker.com/linux/debian     stretch stable
```
※今回のDockerのアップグレード時に、jessieからstretch に変更
　（OS自体はDockerアップグレード前からstretchを使っており、今回の事象発生前後で変更なし）

Dockerのコンテナから外部へ通信できない

下記の、/etc/init.d/vsftpdをstartしたところ、プロセスは起動するのですが、pidファイル(/var/run/vsftpd/vsftpd.pid)が作成されません。
他のデーモンは/var/run配下にpidファイルが作成されるのですが、何故かvftpだけ、pidファイルが作成されません。

原因について、ご教授をお願い申し上げます。

```
#!/bin/sh

### BEGIN INIT INFO
# Provides:             vsftpd
# Required-Start:       $remote_fs $syslog 
# Required-Stop:        $remote_fs $syslog
# Default-Start:        2 3 4 5
# Default-Stop:         0 1 6
# Short-Description:    Very secure FTP server
### END INIT INFO

set -e

DAEMON="/usr/sbin/vsftpd"
NAME="vsftpd"
PATH="/sbin:/bin:/usr/sbin:/usr/bin"
LOGFILE="/var/log/vsftpd.log"
CHROOT="/var/run/vsftpd/empty"

test -x "${DAEMON}" || exit 0

if [ ! -e "${LOGFILE}" ]
then
        touch "${LOGFILE}"
        chmod 640 "${LOGFILE}"
        chown root:adm "${LOGFILE}"
fi

if [ ! -d "${CHROOT}" ]
then
        mkdir -p "${CHROOT}"
fi

Check_standalone_mode ()
{
        # Return 1 if vsftpd.conf doesn't have listen=yes or listen_ipv6=yes
        # (mandatory for standalone operation).

        CONFFILE="/etc/vsftpd.conf"

        if [ -e "${CONFFILE}" ] && ! egrep -iq "^ *listen(_ipv6)? *= *yes" "${CONFFILE}"
        then
                echo "${CONFFILE}: listen disabled - service will not start"
                return 1
        fi
}

case "${1}" in
        start)
                Check_standalone_mode || exit 0
                echo -n "Starting FTP server: "

                start-stop-daemon --start --background -m --oknodo --pidfile /var/run/vsftpd/vsftpd.pid --exec ${DAEMON}

                echo "${NAME}."
                ;;

        stop)
                echo -n "Stopping FTP server: "

                start-stop-daemon --stop --pidfile /var/run/vsftpd/vsftpd.pid --oknodo --exec ${DAEMON}
                rm -f /var/run/vsftpd/vsftpd.pid

                echo "${NAME}."

                ;;

        restart)
                echo -n "Stopping FTP server: "

                start-stop-daemon --stop --pidfile /var/run/vsftpd/vsftpd.pid --oknodo --exec ${DAEMON}
                rm -f /var/run/vsftpd/vsftpd.pid

                echo "${NAME}."
                Check_standalone_mode || exit 0
                echo -n "Starting FTP server: "

                start-stop-daemon --start --background -m --pidfile /var/run/vsftpd/vsftpd.pid --exec ${DAEMON}

                echo "${NAME}."
                ;;

        reload|force-reload)
                echo "Reloading FTP server configuration: "

                start-stop-daemon --stop --pidfile /var/run/vsftpd/vsftpd.pid --signal 1 --exec $DAEMON

                echo "${NAME}."
                ;;

        status)
                PID="$(cat /var/run/vsftpd/vsftpd.pid 2>/dev/null)" || true

                if [ ! -f /var/run/vsftpd/vsftpd.pid ] || [ -z "${PID}" ]
                then
                        echo "${NAME} is not running"
                        exit 3
                fi

                if ps "${PID}" >/dev/null 2>&1
                then
                        echo "${NAME} is running"
                        exit 0
                else
                        echo "${NAME} is not running"
                        exit 1
                fi
                ;;

        *)
                echo "Usage: /etc/init.d/${NAME} {start|stop|restart|reload|status}"
                exit 1
                ;;
esac

exit 0
```

---

# 環境

* vsftpd  : 3.0.2-17
* OS : Debian 8.11

/var/run/にpidファイルが作成されない

emergency mode となり起動できないです。
root account is locked となっているため、
セットアップ（OSの再インストール）からやり直すしかないでしょうか。
![エラー画像](e646d8e76a7a2f734d63799fca097b7a.jpeg)

/etc/fstab の末尾に下記を記述し、
```txt
UUID="HOGE-HOGE"     /mnt/hdd1      exfat-fuse      async,auto,dev,exec,gid=33,rw,uid=33,umask=007    0       0

```
sudo reboot では特に異常なかったと思ったのですが、
sudo poweroff して、配線作業後改めて起動するとこうなっていました。

exfat-fuse exfat-utils をインストールし、
exfatでフォーマットした外付け3TBのHDDをマウントすることに成功し、
再起動もマウントできていた様子なので、こうなった原因が不明です。

こうなったのは2回目でセットアップをやり直すのは大変なので、
fstabの記述ミス等でセットアップするしかない状況になることを避けたいのですが、
rootアカウントがロック状態でなければ、セットアップを避けることはできるのでしょうか。

emergency mode となり起動できない

### 実現したいこと
UEFI > Storage > SATA/NVMe Operation => AHCIモード
で、ソフトウェアRAID1構成のdebian12をインストールしたHDD2本をUEFIに認識させる


### 発生している問題・分からないこと
・UEFI > Storage > SATA/NVMe Operation でAHCIモードに変更
└この時点では新品のHDD4TBは両方とも認識されていました。
・debian12をソフトウェアRAID1でインストール
・再起動
└再起動時も問題なくOSが立ち上がりました。
・電源OFF
★電源ON

★部分でUEFIがHDDを認識してくれなくなりました。
ただ、
①UEFI > storage > STA/NVMe operation を「Raid On」モードにする
②UEFIの再起動を何度か試す（これは電源OFFではなく「EXIT」からのUEFI再表示
どちらかの方法でHDDを認識させることができます。「RaidOn」は継続しますが、①の方は電源OFFにするとHDDを認識しない状態に戻ってしまいます。

UEFIにHDDを認識させるにはどうしたらよろしいでしょうか？
何卒よろしくお願いいたします。


### エラーメッセージ
```error
BIOSがHDDを認識しないという現象のため、エラーメッセージはありません
```
### マシンスペック
マシン：optiplex Tower Plus 7020
HDD：WD GOLD 4TB * 2
電源：最大260W
マザーボード：Dell Inc. 0Y7V6M
CPU：intel core i7-14700
BIOS：DELL BIOS 1.9.0

### 該当のソースコード

```HDDのパーティション情報
GPT fdisk (gdisk) version 1.0.9

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

HDDはGPTでフォーマットしています。
```

```HDDのパーティション構成
NAME                              MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
/dev/sda                            8:0    0  3.6T  0 disk
|-/dev/sda1                         8:1    0  953M  0 part  /boot/efi
`-/dev/sda2                         8:2    0  3.6T  0 part
  `-/dev/md0                        9:0    0  3.6T  0 raid1
    |-/dev/mapper/vg-root 253:0    0  3.6T  0 lvm   /
    `-/dev/mapper/vg-swap 253:1    0 14.9G  0 lvm   [SWAP]
/dev/sdb                            8:16   0  3.6T  0 disk
|-/dev/sdb1                         8:17   0  953M  0 part  /boot/efi_sub
`-/dev/sdb2                         8:18   0  3.6T  0 part
  `-/dev/md0                        9:0    0  3.6T  0 raid1
    |-/dev/mapper/vg-root 253:0    0  3.6T  0 lvm   /
    `-/dev/mapper/vg-swap 253:1    0 14.9G  0 lvm   [SWAP]


各HDDにEFIパーティション(sda1、sda1)を作成、grubをインストールしています。
残りの領域(sda2、sdb2)でRAID1(md0)を作成、md0にボリュームグループを作成し、論理ボリュームでroot(ext4)とswap領域を分けています。

```

### 試したこと・調べたこと
- [x] teratailやGoogle等で検索した
- [ ] ソースコードを自分なりに変更した
- [ ] 知人に聞いた
- [x] その他

##### 上記の詳細・結果
・BIOSアップデート
→1.9.0の最新にアップデートしましたが変わりませんでした

・GPTで再フォーマット
→一度認識しなくなったHDDは何度フォーマットしても初回に認識しなくなります。

・wipefs -a
→GPTフォーマット後、メタデータが残っているのが問題かと思いこちらのコマンドを試しましたが改善しませんでした。

・shred -n 1
→一度全てを０で埋めると直るかと思いましたが変わりませんでした。

・windowsにつなげてのclean all
→I/Oデバイスエラーが表示されclean allができません。ただ、debianでは問題なく操作できるためHDDが破損していることは考えづらいです。

・SATAケーブルの入れ替え
→SATAの接続を入れ替えたりもしましたが効果はありませんでした。

・500GBのHDDでインストールしてみる
→500GBのHDD2本ではこの現象が起こりませんでした。

・別の古いPCにつなぐ
→古いPC（2013年購入）のUEFIモードではAHCIモードでもHDDを認識してくれました。


### 補足
「Raid On」モードでは安定するのですが、ソフトウェアRAIDを組んでいるため、UEFI上で「Raid On」にした場合に競合しないかが不安です。そのため、なんとかAHCIモードで運用したいと考えています。
また、debian12はRAID1構成で問題なく動いており、mdadmでRAID管理もできます。UEFIが初期起動時にHDDを認識してくれないことだけが問題です。


debian12(ソフトウェアRAID1)をインストールした4TBHDD×2本が起動時にUEFI(AHCIモード)に認識されない

### 前提・実現したいこと
[PACEMAKER > RPi設定 > デスクトップ起動時にターミナルを表示する > .config/autostart/[任意の名前].desktopを用意する](https://qiita.com/7of9/items/6aa0ea8b3a4fc802ca61)
や
[Raspberry Pi 起動時に ターミナルを開いて Python スクリプトを自動実行させる](http://mogen-hogen.blogspot.com/2017/01/raspberry-pi-python.html)
を参考にして

Raspberry Piの起動時にターミナルが立ち上がり、「Hello world」と表示される機能を実装しようと思いましたが上手くいきません。

私が書いたコード自体に問題があるのでしょうか？
それともどこかの設定を変更するべきなのでしょうか？
![イメージ説明](2ef861c209e61436d6ff4b2610eff6ce.png)


### 発生している問題
そもそもターミナルが立ち上がらないうえに、「Hello world」と表示されない。


### 現状のソースコード
/home/pi/.config/autostart/hogehoge.desktopに

```hogehoge
[Desktop Entry]
Exec=lxterminal -e "echo Hello world"
Type=Application
Name=Terminal autostart
Terminal=true
```
と打ち込んでいます

### 試したこと

ターミナル自体に問題があるのかなと思い、
/home/pi/.config/autostart/hogehoge.desktopに

```hogehoge
[Desktop Entry]
Exec=lxterminal
Type=Application
Name=Terminal autostart
Terminal=true
```
と打ち込みました。結果はターミナルは立ち上がったので、ターミナル自体に問題はないと思います。
![イメージ説明](7bf72b2a5eae0e0d0e75efeef51283fb.png)
　
　
　
また、[Raspberry Pi 起動時に ターミナルを開いて Python スクリプトを自動実行させる](http://mogen-hogen.blogspot.com/2017/01/raspberry-pi-python.html)を参考にして
/home/pi/.config/autostart/hogehoge.desktopに

```hogehoge
[Desktop Entry]
Name=hogehoge
Exec=lxterminal -e "echo Hello world"
Type=Application
```
と打ち込んでも、同様にターミナルが立ち上がらないうえに、「Hello world」と表示されませんでした。


### 補足情報
**使用機器：**
Raspberry Pi 4 Computer Model B

**OS情報：**
Distributor ID:　Raspbian
Description:　Raspbian GNU/Linux 10 (buster)
Release:　10
Codename:　buster

**ターミナル:**
LXTerminal

### 参考にした文献
[PACEMAKER > RPi設定 > デスクトップ起動時にターミナルを表示する > .config/autostart/[任意の名前].desktopを用意する](https://qiita.com/7of9/items/6aa0ea8b3a4fc802ca61)

[Raspberry Pi 起動時に ターミナルを開いて Python スクリプトを自動実行させる](http://mogen-hogen.blogspot.com/2017/01/raspberry-pi-python.html)

Raspberry Piの起動時にターミナルが立ち上がり、「Hello world」と表示される機能を実装しようと思いましたが上手くいきません.

### 前提・実現したいこと

Raspberry Piのアップデートをするために
sudo apt-get update
を行った。
そこで以下のようなエラーが発生しました。
### 発生している問題・エラーメッセージ

```
エラー:1 http://raspbian.raspberrypi.org/raspbian buster InRelease
  'raspbian.raspberrypi.org' が一時的に解決できません
エラー:2 http://archive.raspberrypi.org/debian buster InRelease
  'archive.raspberrypi.org' が一時的に解決できません
パッケージリストを読み込んでいます... 完了
W: http://raspbian.raspberrypi.org/raspbian/dists/buster/InRelease の取得に失敗しました  'raspbian.raspberrypi.org' が一時的に解決できません
W: http://archive.raspberrypi.org/debian/dists/buster/InRelease の取得に失敗しました  'archive.raspberrypi.org' が一時的に解決できません
W: いくつかのインデックスファイルのダウンロードに失敗しました。これらは無視されるか、古いものが代わりに使われます。

```
このサイト[Debian 10 Buster testing をリリース後に apt update するとエラーになる](https://matoken.org/blog/2019/07/11/apt-update-after-releasing-debian-10-buster-testing-results-in-an-error/)
を参考に、
sudo apt --allow-releaseinfo-change update
を行ったが、同様な結果が得られた。

Debianのバージョンは10.1です。
### 該当のソースコード

```ここに言語名を入力
pi@raspberrypi:~ $ sudo apt --allow-releaseinfo-change update
エラー:1 http://raspbian.raspberrypi.org/raspbian buster InRelease
  'raspbian.raspberrypi.org' が一時的に解決できません
エラー:2 http://archive.raspberrypi.org/debian buster InRelease
  'archive.raspberrypi.org' が一時的に解決できません
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています       
状態情報を読み取っています... 完了
パッケージはすべて最新です。
W: http://raspbian.raspberrypi.org/raspbian/dists/buster/InRelease の取得に失敗しました  'raspbian.raspberrypi.org' が一時的に解決できません
W: http://archive.raspberrypi.org/debian/dists/buster/InRelease の取得に失敗しました  'archive.raspberrypi.org' が一時的に解決できません
W: いくつかのインデックスファイルのダウンロードに失敗しました。これらは無視されるか、古いものが代わりに使われます。
```
この問題の解決方法がわかりません。どなたかご教授よろしくお願いします。