Azure VM cloud-init が /etc/fstab をオーバーライドします。

Azure VM cloud-init が /etc/fstab をオーバーライドします。

で説明されているように、追加のデータディスクを追加しました。Linux VMドキュメントへのデータディスクの接続

問題のパーティションはです/dev/sdc1。一番下にこの行を追加しました。残念ながら、cloud-initの魔法は悪い方法で驚くべきことをしました。

root@qwerz:/mnt/builds/docker# cat /etc/fstab
# CLOUD_IMG: This file was created/modified by the Cloud Image build process
UUID=cfadafca-7199-49b1-a353-072629b7fcdf       /        ext4   defaults,discard        0 0
LABEL=UEFI      /boot/efi       vfat    defaults,discard        0 0
UUID=0195f789-b5fa-4bea-a91d-dc120bafb23a       /mnt/builds             ext4    defaults,nofail   1   2
#/dev/sdc1      /mnt/builds     ext4    default,nofail  0       0
/dev/disk/cloud/azure_resource-part1    /mnt    auto    defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig       0       2
root@qwerz:/mnt/builds/docker#

Q1:カスタムポイントを/ mntの外に移動する必要がありますか?
Q2:cloud-initタスクは正確に何であり、削除できますか?

root@qwerz:/mnt/builds/docker# dpkg -l |grep cloud-init
ii  cloud-init                          19.1-1-gbaa47854-0ubuntu1~18.04.1           all          Init scripts for cloud instances
ii  cloud-initramfs-copymods            0.40ubuntu1.1                               all          copy initramfs modules into root filesystem for later use
ii  cloud-initramfs-dyn-netconf         0.40ubuntu1.1                               all          write a network interface file in /run for BOOTIF

私が知っているのは、cloud-initはVMが最初に起動したときにのみ実行する必要があります。しかし、私はそれがそれぞれの後に実行されるような気がします。割り当てをキャンセルする特定の仮想マシンの(一部のポイントを節約するため)

cloud-init.logの興味深い部分は次のとおりです。

2019-06-26 06:01:49,392 - util.py[DEBUG]: Reading from /etc/fstab (quiet=False)
2019-06-26 06:01:49,392 - util.py[DEBUG]: Read 451 bytes from /etc/fstab
2019-06-26 06:01:49,392 - cc_mounts.py[DEBUG]: Attempting to determine the real name of ephemeral0
2019-06-26 06:01:49,392 - cc_mounts.py[DEBUG]: Mapped metadata name ephemeral0 to /dev/disk/cloud/azure_resource
2019-06-26 06:01:49,392 - cc_mounts.py[DEBUG]: changed default device ephemeral0 => /dev/disk/cloud/azure_resource-part1
2019-06-26 06:01:49,392 - cc_mounts.py[DEBUG]: Attempting to determine the real name of swap
2019-06-26 06:01:49,392 - cc_mounts.py[DEBUG]: changed default device swap => None
2019-06-26 06:01:49,392 - cc_mounts.py[DEBUG]: Ignoring nonexistent default named mount swap
2019-06-26 06:01:49,392 - cc_mounts.py[DEBUG]: no need to setup swap
2019-06-26 06:01:49,392 - util.py[DEBUG]: Reading from /proc/mounts (quiet=False)
2019-06-26 06:01:49,393 - util.py[DEBUG]: Read 2608 bytes from /proc/mounts
2019-06-26 06:01:49,393 - util.py[DEBUG]: Fetched {'sysfs': {'fstype': 'sysfs', 'mountpoint': '/sys', 'opts': 'rw,nosuid,nodev,noexec,relatime'}, 'proc': {'fstype': 'proc', 'mountpoint': '/proc', 'opts': 'rw,nosuid,nodev,noexec,relatime'}, 'udev': {'fstype': 'devtmpfs', 'mountpoint': '/dev', 'opts': 'rw,nosuid,relatime,size=8187860k,nr_inodes=2046965,mode=755'}, 'devpts': {'fstype': 'devpts', 'mountpoint': '/dev/pts', 'opts': 'rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000'}, 'tmpfs': {'fstype': 'tmpfs', 'mountpoint': '/sys/fs/cgroup', 'opts': 'ro,nosuid,nodev,noexec,mode=755'}, '/dev/sda1': {'fstype': 'ext4', 'mountpoint': '/', 'opts': 'rw,relatime,discard'}, 'securityfs': {'fstype': 'securityfs', 'mountpoint': '/sys/kernel/security', 'opts': 'rw,nosuid,nodev,noexec,relatime'}, 'cgroup': {'fstype': 'cgroup', 'mountpoint': '/sys/fs/cgroup/memory', 'opts': 'rw,nosuid,nodev,noexec,relatime,memory'}, 'pstore': {'fstype': 'pstore', 'mountpoint': '/sys/fs/pstore', 'opts': 'rw,nosuid,nodev,noexec,relatime'}, 'systemd-1': {'fstype': 'autofs', 'mountpoint': '/proc/sys/fs/binfmt_misc', 'opts': 'rw,relatime,fd=32,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=18816'}, 'mqueue': {'fstype': 'mqueue', 'mountpoint': '/dev/mqueue', 'opts': 'rw,relatime'}, 'debugfs': {'fstype': 'debugfs', 'mountpoint': '/sys/kernel/debug', 'opts': 'rw,relatime'}, 'hugetlbfs': {'fstype': 'hugetlbfs', 'mountpoint': '/dev/hugepages', 'opts': 'rw,relatime,pagesize=2M'}, 'fusectl': {'fstype': 'fusectl', 'mountpoint': '/sys/fs/fuse/connections', 'opts': 'rw,relatime'}, 'configfs': {'fstype': 'configfs', 'mountpoint': '/sys/kernel/config', 'opts': 'rw,relatime'}, '/dev/loop0': {'fstype': 'squashfs', 'mountpoint': '/snap/dotnet-sdk/39', 'opts': 'ro,nodev,relatime'}, '/dev/loop1': {'fstype': 'squashfs', 'mountpoint': '/snap/core/7169', 'opts': 'ro,nodev,relatime'}, '/dev/loop2': {'fstype': 'squashfs', 'mountpoint': '/snap/dotnet-sdk/38', 'opts': 'ro,nodev,relatime'}, '/dev/loop3': {'fstype': 'squashfs', 'mountpoint': '/snap/core/6964', 'opts': 'ro,nodev,relatime'}, '/dev/loop4': {'fstype': 'squashfs', 'mountpoint': '/snap/dotnet-sdk/35', 'opts': 'ro,nodev,relatime'}, '/dev/sda15': {'fstype': 'vfat', 'mountpoint': '/boot/efi', 'opts': 'rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro,discard'}} mounts from proc
2019-06-26 06:01:49,393 - util.py[DEBUG]: Writing to /etc/fstab - wb: [644] 451 bytes
2019-06-26 06:01:49,393 - cc_mounts.py[DEBUG]: No changes to /etc/fstab made.
2019-06-26 06:01:49,393 - util.py[DEBUG]: Running command ['mount', '-a'] with allowed return codes [0] (shell=False, capture=True)
2019-06-26 06:01:49,427 - cc_mounts.py[WARNING]: Activate mounts: FAIL:mount -a
2019-06-26 06:01:49,427 - util.py[WARNING]: Activate mounts: FAIL:mount -a
2019-06-26 06:01:49,427 - util.py[DEBUG]: Activate mounts: FAIL:mount -a
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/cloudinit/config/cc_mounts.py", line 495, in handle
    util.subp(cmd)
  File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2069, in subp
    cmd=args)
cloudinit.util.ProcessExecutionError: Unexpected error while running command.
Command: ['mount', '-a']
Exit code: 64
Reason: -
Stdout: 
Stderr: mount: /mnt/builds: mount point does not exist.

マウントポイントは間違いなく存在しますが、/mntにマウントされた以前にマウントされたephemeral0一時記憶ディスクにはありません。

/mntとにかく下に一時ディスクをマウントするのはなぜですか? ?

答え1

遅れたけど助けてくれてよかったです。

Azureでは、Linuxエージェント構成ファイル(waagent.conf)は、通常サポートされているほとんどのLinuxディストリビューションで作業を実行できるマウントポイントを設定します。通常、デフォルトのマウントポイントは「/mnt/resource」です。

ただし、Ubuntu 16.04+では、cloud-initはすべてのリリース/ブートでwaagent.conf ephemeral0マウントポイント設定とfstabを上書きします。ただし、再起動または割り当て解除/起動後も維持されるように、さまざまな方法でマウントポイントを指定できます。以下でこれについて議論します。

今、あなたの質問に答えてみましょう。

Q1:カスタムポイントを/ mntの外に移動する必要がありますか? 私の考えに/ mntにエントリをインストールするには、おそらくそうする必要があります。一時的なデバイスにアイテムをインストールしたくないからです。ディスク(あなたが計画していない場合)。

Q2:cloud-initタスクは正確に何であり、削除できますか? 私はあなたがそれを削除する必要があるとは思わない。代わりに、正しい方法でマウントポイントを再構成してみてください。

どのように貼りますか? Azure 温度をインストールするとします。ディスクは/mnt/resourceにあります。

方法1(クリーンアップ):新しいcloud-init confを作成します。 /etc/cloud/cloud.cfg.d のファイルはマウントポイントを定義します。

    cat >> /etc/cloud/cloud.cfg.d/91-azure_datasource.cfg <<EOF
mounts:
- [ ephemeral0, /mnt/resource ]
EOF

方法2(ダーティ):一時的にcloud-initマウントオプションを削除します。ディスクfstabエントリは次のとおりです。

/dev/disk/cloud/azure_resource-part1    /mnt    auto    defaults,nofail       0       2

方法3(不快):cc_mounts.pyでマウントポイントの行を見つけ、パス:/usr/lib/python3/dist-packages/cloudinit/config/cc_mounts.pyコードのマウントポイントを変更します。この行は次のようになります。

defmnts = [["ephemeral0", "/mnt", "auto", defvals[3], "0", "2"],
           ["swap", "none", "swap", "sw", "0", "0"]]

一度試して、どのように進行しているかを確認してください。

答え2

私が見つけた簡単な回避策は、ファイルを編集した後にcloud-initが上書きできないように/etc/fstab設定することです。chattr +i /etc/fstab

関連情報