에 설명된 대로 추가 데이터 디스크를 추가했습니다.Linux VM 문서에 데이터 디스크 연결.
문제의 파티션은 입니다 /dev/sdc1
. 맨 아래에 이 줄을 추가했습니다. 불행하게도 cloud-init의 마법은 나쁜 방식으로 놀라운 일을 해냈고 /etc/fstab의 항목을 이동하여 결국 "숨겨진" 마운트 지점을 갖게 되었습니다.
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#
질문 1: 사용자 정의 지점을 /mnt 외부로 이동해야 합니까?
질문 2: 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을 덮어씁니다. 그러나 재부팅이나 할당 취소/부팅 후에도 유지되도록 다양한 방법으로 마운트 지점을 지정할 수 있습니다. 아래에서 이에 대해 논의하겠습니다.
이제 귀하의 질문에 답해 보겠습니다.
질문 1: 사용자 정의 지점을 /mnt 외부로 이동해야 합니까? 내 생각에 /mnt에 항목을 설치하려면 아마도 그렇게 해야 할 것입니다. 임시 장치에 항목을 설치하고 싶지 않을 것이기 때문입니다. 디스크(당신이 계획한 것이 아니라면).
질문 2: 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