[Group.of.nepali.translators] [Bug 1762748] Re: Larger than 2 TB disks not possible
This bug is believed to be fixed in cloud-utils in version 0.31. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-utils
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1762748
Title:
Larger than 2 TB disks not possible
Status in cloud-utils:
Fix Released
Status in cloud-utils package in Ubuntu:
Fix Released
Status in cloud-utils source package in Xenial:
Fix Released
Status in cloud-utils source package in Artful:
Fix Released
Status in cloud-utils source package in Bionic:
Fix Released
Bug description:
=== Begin SRU Template ===
[Impact]
Growpart will not grow a partition past the 2TB mark.
The code to do this is present by design for MBR partitioned disks but
was active both for MBR and for GPT.
The primary impact is that guests with very large root disks will
not have their root filesystem grown completely.
[Test Case]
There is a test case in cloud-utils 'test/test-growpart'.
It can be invoked to test this path.
a. Install cloud-guest-utils.
# add -proposed or otherwise add apt to have correct version.
apt-get update
apt-get install cloud-guest-utils
dpkg-query --show cloud-guest-utils
b. get test case
url=https://bazaar.launchpad.net/~cloud-utils-dev/cloud-utils/trunk/download/head:/testgrowpart-20130228125003-ejkrb587l0vw3eep-2/test-growpart
wget "$url" -O test-growpart
chmod 755 test-growpart
c. run test case growing from 1TB disk to 5TB disk.
## Note you do not want to run this on an encrypted disk as it would
## actually take 5TB and would be terribly slow.
$ sudo PT_TYPE=gpt DISK_SIZE_NEW=5T DISK_SIZE_ORIG=1T ./test-growpart
This should result in a 5TB filesystem.
d. make sure MBR doesnt grow past 2TB.
$ sudo PT_TYPE=dos DISK_SIZE_NEW=5T DISK_SIZE_ORIG=1T ./test-growpart
This should show a warning about the disk having unused space,
and should result in a 2TB filesystem.
e. Verify that cloud image correctly resizes.
1. Get a cloud image of correct release with cloud-guest-utils updated
inside it
get-proposed-cloudimg can automate that for you.
https://github.com/cloud-init/ubuntu-sru/blob/master/bin/get-proposed-cloudimg
$ get-proposed-cloudimg --proposed --upgrade=cloud-guest-utils \
xenial xenial-proposed.img
2. create a disk larger than 2TB
qemu-img create -f qcow2 -b xenial-proposed.img large-disk.img 5T
3. boot image with large disk and nocloud seed.
$ cat > my-user-data <<"EOF"
#cloud-config
password: passw0rd
chpasswd: { expire: False }
ssh_pwauth: True
EOF
$ echo "instance-id: $(uuidgen || echo i-abcdefg)" > my-meta-data
$ cloud-localds my-seed.img my-user-data my-meta-data
$ qemu-system-x86_64 -enable-kvm \
-device virtio-net-pci,netdev=net00 -netdev user,id=net00 \
-drive file=large-disk.img,id=disk00,if=none,index=0 \
-device virtio-blk,drive=disk00,serial=large-disk.img \
-drive file=my-seed.img,id=disk01,if=none,index=1 \
-device virtio-blk,drive=disk01,serial=my-seed.img \
-snapshot -m 1G -nographic
Then log in as 'ubuntu' with 'passw0rd'
and run 'df -h /' to verify 5TB root filesystem.
[Regression Potential]
The most likely regression here would be to have mbr attempt to grow
past 2TB and fail. This is called out in test case part 'd' above.
[Other Info]
Upstream merge proposal:
https://code.launchpad.net/~smoser/cloud-utils/trunk.1762748-gpt-big-disks/+merge/343155
Upstream commit:
https://bazaar.launchpad.net/~cloud-utils-dev/cloud-utils/trunk/revision/323
=== End SRU Template ===
Hi,
We run Openstack and need to provide instances that have very large
root disks (> 2 TB) and it looks like cloud-init doesn't want to use
the entire space.
The regular Ubuntu cloud image has MBR and it doesn't see more than 2
TB, but even the GPT version (http://cloud-
images.ubuntu.com/xenial/current/xenial-server-cloudimg-
amd64-uefi1.img) still fails to see more than 2 TB.
root@ubuntu-16:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev121G 0 121G 0% /dev
tmpfs25G 8.6M 25G 1% /run
/dev/vda1 2.0T 857M 2.0T 1% /
tmpfs 121G 0 121G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 121G 0 121G 0% /sys/fs/cgroup
tmpfs25G 0 25G 0% /run/user/1000
root@ubuntu-16:~# parted /dev/vda p
Model: Virtio Block Device (virtblk)
Disk /dev/vda: 5583GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End SizeType File system Flags
1 1049kB 2199GB 2199GB
[Group.of.nepali.translators] [Bug 1762748] Re: Larger than 2 TB disks not possible
This bug was fixed in the package cloud-utils - 0.27-0ubuntu25.1
---
cloud-utils (0.27-0ubuntu25.1) xenial; urgency=medium
* debian/patches/lp-1762748-growpart-grow-past-2TB-disks.patch:
growpart: fix bug that stopped GPT disks from being grown past 2TB.
(LP: #1762748)
-- Scott Moser Thu, 19 Apr 2018 10:56:47 -0400
** Changed in: cloud-utils (Ubuntu Xenial)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1762748
Title:
Larger than 2 TB disks not possible
Status in cloud-utils:
Fix Committed
Status in cloud-utils package in Ubuntu:
Fix Released
Status in cloud-utils source package in Xenial:
Fix Released
Status in cloud-utils source package in Artful:
Fix Released
Status in cloud-utils source package in Bionic:
Fix Released
Bug description:
=== Begin SRU Template ===
[Impact]
Growpart will not grow a partition past the 2TB mark.
The code to do this is present by design for MBR partitioned disks but
was active both for MBR and for GPT.
The primary impact is that guests with very large root disks will
not have their root filesystem grown completely.
[Test Case]
There is a test case in cloud-utils 'test/test-growpart'.
It can be invoked to test this path.
a. Install cloud-guest-utils.
# add -proposed or otherwise add apt to have correct version.
apt-get update
apt-get install cloud-guest-utils
dpkg-query --show cloud-guest-utils
b. get test case
url=https://bazaar.launchpad.net/~cloud-utils-dev/cloud-utils/trunk/download/head:/testgrowpart-20130228125003-ejkrb587l0vw3eep-2/test-growpart
wget "$url" -O test-growpart
chmod 755 test-growpart
c. run test case growing from 1TB disk to 5TB disk.
## Note you do not want to run this on an encrypted disk as it would
## actually take 5TB and would be terribly slow.
$ sudo PT_TYPE=gpt DISK_SIZE_NEW=5T DISK_SIZE_ORIG=1T ./test-growpart
This should result in a 5TB filesystem.
d. make sure MBR doesnt grow past 2TB.
$ sudo PT_TYPE=dos DISK_SIZE_NEW=5T DISK_SIZE_ORIG=1T ./test-growpart
This should show a warning about the disk having unused space,
and should result in a 2TB filesystem.
e. Verify that cloud image correctly resizes.
1. Get a cloud image of correct release with cloud-guest-utils updated
inside it
get-proposed-cloudimg can automate that for you.
https://github.com/cloud-init/ubuntu-sru/blob/master/bin/get-proposed-cloudimg
$ get-proposed-cloudimg --proposed --upgrade=cloud-guest-utils \
xenial xenial-proposed.img
2. create a disk larger than 2TB
qemu-img create -f qcow2 -b xenial-proposed.img large-disk.img 5T
3. boot image with large disk and nocloud seed.
$ cat > my-user-data <<"EOF"
#cloud-config
password: passw0rd
chpasswd: { expire: False }
ssh_pwauth: True
EOF
$ echo "instance-id: $(uuidgen || echo i-abcdefg)" > my-meta-data
$ cloud-localds my-seed.img my-user-data my-meta-data
$ qemu-system-x86_64 -enable-kvm \
-device virtio-net-pci,netdev=net00 -netdev user,id=net00 \
-drive file=large-disk.img,id=disk00,if=none,index=0 \
-device virtio-blk,drive=disk00,serial=large-disk.img \
-drive file=my-seed.img,id=disk01,if=none,index=1 \
-device virtio-blk,drive=disk01,serial=my-seed.img \
-snapshot -m 1G -nographic
Then log in as 'ubuntu' with 'passw0rd'
and run 'df -h /' to verify 5TB root filesystem.
[Regression Potential]
The most likely regression here would be to have mbr attempt to grow
past 2TB and fail. This is called out in test case part 'd' above.
[Other Info]
Upstream merge proposal:
https://code.launchpad.net/~smoser/cloud-utils/trunk.1762748-gpt-big-disks/+merge/343155
Upstream commit:
https://bazaar.launchpad.net/~cloud-utils-dev/cloud-utils/trunk/revision/323
=== End SRU Template ===
Hi,
We run Openstack and need to provide instances that have very large
root disks (> 2 TB) and it looks like cloud-init doesn't want to use
the entire space.
The regular Ubuntu cloud image has MBR and it doesn't see more than 2
TB, but even the GPT version (http://cloud-
images.ubuntu.com/xenial/current/xenial-server-cloudimg-
amd64-uefi1.img) still fails to see more than 2 TB.
root@ubuntu-16:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev121G 0 121G 0% /dev
tmpfs25G 8.6M 25G 1% /run
/dev/vda1 2.0T 857M 2.0T 1% /
tmpfs 121G 0 121G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 121G 0 121G 0% /sys/fs/cgroup
tmpfs25G 0 25G 0% /run/user/1000
root@ubuntu-16:~# parted /dev/vda p
Model: Virtio Block Device (virtblk)
Disk
[Group.of.nepali.translators] [Bug 1762748] Re: Larger than 2 TB disks not possible
This bug was fixed in the package cloud-utils - 0.30-0ubuntu2.1
---
cloud-utils (0.30-0ubuntu2.1) artful; urgency=medium
* debian/patches/lp-1762748-growpart-grow-past-2TB-disks.patch:
growpart: fix bug that stopped GPT disks from being grown past 2TB.
(LP: #1762748)
-- Scott Moser Thu, 19 Apr 2018 10:55:10 -0400
** Changed in: cloud-utils (Ubuntu Artful)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1762748
Title:
Larger than 2 TB disks not possible
Status in cloud-utils:
Fix Committed
Status in cloud-utils package in Ubuntu:
Fix Released
Status in cloud-utils source package in Xenial:
Fix Released
Status in cloud-utils source package in Artful:
Fix Released
Status in cloud-utils source package in Bionic:
Fix Released
Bug description:
=== Begin SRU Template ===
[Impact]
Growpart will not grow a partition past the 2TB mark.
The code to do this is present by design for MBR partitioned disks but
was active both for MBR and for GPT.
The primary impact is that guests with very large root disks will
not have their root filesystem grown completely.
[Test Case]
There is a test case in cloud-utils 'test/test-growpart'.
It can be invoked to test this path.
a. Install cloud-guest-utils.
# add -proposed or otherwise add apt to have correct version.
apt-get update
apt-get install cloud-guest-utils
dpkg-query --show cloud-guest-utils
b. get test case
url=https://bazaar.launchpad.net/~cloud-utils-dev/cloud-utils/trunk/download/head:/testgrowpart-20130228125003-ejkrb587l0vw3eep-2/test-growpart
wget "$url" -O test-growpart
chmod 755 test-growpart
c. run test case growing from 1TB disk to 5TB disk.
## Note you do not want to run this on an encrypted disk as it would
## actually take 5TB and would be terribly slow.
$ sudo PT_TYPE=gpt DISK_SIZE_NEW=5T DISK_SIZE_ORIG=1T ./test-growpart
This should result in a 5TB filesystem.
d. make sure MBR doesnt grow past 2TB.
$ sudo PT_TYPE=dos DISK_SIZE_NEW=5T DISK_SIZE_ORIG=1T ./test-growpart
This should show a warning about the disk having unused space,
and should result in a 2TB filesystem.
e. Verify that cloud image correctly resizes.
1. Get a cloud image of correct release with cloud-guest-utils updated
inside it
get-proposed-cloudimg can automate that for you.
https://github.com/cloud-init/ubuntu-sru/blob/master/bin/get-proposed-cloudimg
$ get-proposed-cloudimg --proposed --upgrade=cloud-guest-utils \
xenial xenial-proposed.img
2. create a disk larger than 2TB
qemu-img create -f qcow2 -b xenial-proposed.img large-disk.img 5T
3. boot image with large disk and nocloud seed.
$ cat > my-user-data <<"EOF"
#cloud-config
password: passw0rd
chpasswd: { expire: False }
ssh_pwauth: True
EOF
$ echo "instance-id: $(uuidgen || echo i-abcdefg)" > my-meta-data
$ cloud-localds my-seed.img my-user-data my-meta-data
$ qemu-system-x86_64 -enable-kvm \
-device virtio-net-pci,netdev=net00 -netdev user,id=net00 \
-drive file=large-disk.img,id=disk00,if=none,index=0 \
-device virtio-blk,drive=disk00,serial=large-disk.img \
-drive file=my-seed.img,id=disk01,if=none,index=1 \
-device virtio-blk,drive=disk01,serial=my-seed.img \
-snapshot -m 1G -nographic
Then log in as 'ubuntu' with 'passw0rd'
and run 'df -h /' to verify 5TB root filesystem.
[Regression Potential]
The most likely regression here would be to have mbr attempt to grow
past 2TB and fail. This is called out in test case part 'd' above.
[Other Info]
Upstream merge proposal:
https://code.launchpad.net/~smoser/cloud-utils/trunk.1762748-gpt-big-disks/+merge/343155
Upstream commit:
https://bazaar.launchpad.net/~cloud-utils-dev/cloud-utils/trunk/revision/323
=== End SRU Template ===
Hi,
We run Openstack and need to provide instances that have very large
root disks (> 2 TB) and it looks like cloud-init doesn't want to use
the entire space.
The regular Ubuntu cloud image has MBR and it doesn't see more than 2
TB, but even the GPT version (http://cloud-
images.ubuntu.com/xenial/current/xenial-server-cloudimg-
amd64-uefi1.img) still fails to see more than 2 TB.
root@ubuntu-16:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev121G 0 121G 0% /dev
tmpfs25G 8.6M 25G 1% /run
/dev/vda1 2.0T 857M 2.0T 1% /
tmpfs 121G 0 121G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 121G 0 121G 0% /sys/fs/cgroup
tmpfs25G 0 25G 0% /run/user/1000
root@ubuntu-16:~# parted /dev/vda p
Model: Virtio Block Device (virtblk)
Disk /
[Group.of.nepali.translators] [Bug 1762748] Re: Larger than 2 TB disks not possible
This bug was fixed in the package cloud-utils - 0.30-0ubuntu4
---
cloud-utils (0.30-0ubuntu4) bionic; urgency=medium
* sync to trunk at 323.
- growpart: fix bug that stopped GPT disks from being grown past 2TB.
(LP: #1762748)
-- Scott Moser Thu, 12 Apr 2018 23:36:41 -0400
** Changed in: cloud-utils (Ubuntu Bionic)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1762748
Title:
Larger than 2 TB disks not possible
Status in cloud-utils:
Fix Committed
Status in cloud-utils package in Ubuntu:
Fix Released
Status in cloud-utils source package in Xenial:
Confirmed
Status in cloud-utils source package in Artful:
Confirmed
Status in cloud-utils source package in Bionic:
Fix Released
Bug description:
Hi,
We run Openstack and need to provide instances that have very large
root disks (> 2 TB) and it looks like cloud-init doesn't want to use
the entire space.
The regular Ubuntu cloud image has MBR and it doesn't see more than 2
TB, but even the GPT version (http://cloud-
images.ubuntu.com/xenial/current/xenial-server-cloudimg-
amd64-uefi1.img) still fails to see more than 2 TB.
root@ubuntu-16:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev121G 0 121G 0% /dev
tmpfs25G 8.6M 25G 1% /run
/dev/vda1 2.0T 857M 2.0T 1% /
tmpfs 121G 0 121G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 121G 0 121G 0% /sys/fs/cgroup
tmpfs25G 0 25G 0% /run/user/1000
root@ubuntu-16:~# parted /dev/vda p
Model: Virtio Block Device (virtblk)
Disk /dev/vda: 5583GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End SizeType File system Flags
1 1049kB 2199GB 2199GB primary ext4 boot
root@ubuntu-16:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda253:00 5.1T 0 disk
└─vda1 253:102T 0 part /
root@ubuntu-16:~# dpkg -l | grep cloud-init
ii cloud-init 17.2-35-gf576b2a2-0ubuntu1~16.04.2
all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.5
all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.5
all write a network interface file in /run for BOOTIF
The cloud-init.log looks like the disk growing and file system resizing went
fine:
018-04-10 14:14:31,332 - stages.py[DEBUG]: Running module growpart () with
frequency always
2018-04-10 14:14:31,332 - handlers.py[DEBUG]: start:
init-network/config-growpart: running config-growpart with frequency always
2018-04-10 14:14:31,332 - helpers.py[DEBUG]: Running config-growpart using
lock ()
2018-04-10 14:14:31,332 - cc_growpart.py[DEBUG]: No 'growpart' entry in cfg.
Using default: {'mode': 'auto', 'ignore_growroot_disabled': False, 'devices':
['/']}
2018-04-10 14:14:31,332 - util.py[DEBUG]: Running command ['growpart',
'--help'] with allowed return codes [0] (shell=False, capture=True)
2018-04-10 14:14:31,352 - util.py[DEBUG]: Reading from /proc/1192/mountinfo
(quiet=False)
2018-04-10 14:14:31,352 - util.py[DEBUG]: Read 2621 bytes from
/proc/1192/mountinfo
2018-04-10 14:14:31,353 - util.py[DEBUG]: Running command
['systemd-detect-virt', '--quiet', '--container'] with allowed return codes [0]
(shell=False, capture=True)
2018-04-10 14:14:31,355 - util.py[DEBUG]: Running command
['running-in-container'] with allowed return codes [0] (shell=False,
capture=True)
2018-04-10 14:14:31,356 - util.py[DEBUG]: Running command
['lxc-is-container'] with allowed return codes [0] (shell=False, capture=True)
2018-04-10 14:14:31,357 - util.py[DEBUG]: Reading from /proc/1/environ
(quiet=False)
2018-04-10 14:14:31,358 - util.py[DEBUG]: Read 153 bytes from /proc/1/environ
2018-04-10 14:14:31,358 - util.py[DEBUG]: Reading from /proc/self/status
(quiet=False)
2018-04-10 14:14:31,358 - util.py[DEBUG]: Read 906 bytes from
/proc/self/status
2018-04-10 14:14:31,358 - util.py[DEBUG]: Reading from
/sys/class/block/vda1/partition (quiet=False)
2018-04-10 14:14:31,358 - util.py[DEBUG]: Read 2 bytes from
/sys/class/block/vda1/partition
2018-04-10 14:14:31,358 - util.py[DEBUG]: Reading from
/sys/devices/pci:00/:00:04.0/virtio1/block/vda/dev (quiet=False)
2018-04-10 14:14:31,359 - util.py[DEBUG]: Read 6 bytes from
/sys/devices/pci:00/:00:04.0/virtio1/block/vda/dev
2018-04-10 14:14:31,359 - util.py[DEBUG]: Running command ['growpart',
'--dry-run', '/dev/vda', '1'] with allowed return codes [0] (shell=False,
capture=True)
2018
[Group.of.nepali.translators] [Bug 1762748] Re: Larger than 2 TB disks not possible
** Also affects: cloud-utils (Ubuntu)
Importance: Undecided
Status: New
** Changed in: cloud-utils (Ubuntu)
Status: New => Confirmed
** Changed in: cloud-utils (Ubuntu)
Importance: Undecided => Medium
** Changed in: cloud-utils
Status: Confirmed => Fix Committed
** Also affects: cloud-utils (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: cloud-utils (Ubuntu Bionic)
Importance: Medium
Status: Confirmed
** Also affects: cloud-utils (Ubuntu Artful)
Importance: Undecided
Status: New
** Changed in: cloud-utils (Ubuntu Xenial)
Status: New => Confirmed
** Changed in: cloud-utils (Ubuntu Artful)
Status: New => Confirmed
** Changed in: cloud-utils (Ubuntu Xenial)
Importance: Undecided => Medium
** Changed in: cloud-utils (Ubuntu Artful)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1762748
Title:
Larger than 2 TB disks not possible
Status in cloud-utils:
Fix Committed
Status in cloud-utils package in Ubuntu:
Confirmed
Status in cloud-utils source package in Xenial:
Confirmed
Status in cloud-utils source package in Artful:
Confirmed
Status in cloud-utils source package in Bionic:
Confirmed
Bug description:
Hi,
We run Openstack and need to provide instances that have very large
root disks (> 2 TB) and it looks like cloud-init doesn't want to use
the entire space.
The regular Ubuntu cloud image has MBR and it doesn't see more than 2
TB, but even the GPT version (http://cloud-
images.ubuntu.com/xenial/current/xenial-server-cloudimg-
amd64-uefi1.img) still fails to see more than 2 TB.
root@ubuntu-16:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev121G 0 121G 0% /dev
tmpfs25G 8.6M 25G 1% /run
/dev/vda1 2.0T 857M 2.0T 1% /
tmpfs 121G 0 121G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 121G 0 121G 0% /sys/fs/cgroup
tmpfs25G 0 25G 0% /run/user/1000
root@ubuntu-16:~# parted /dev/vda p
Model: Virtio Block Device (virtblk)
Disk /dev/vda: 5583GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End SizeType File system Flags
1 1049kB 2199GB 2199GB primary ext4 boot
root@ubuntu-16:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda253:00 5.1T 0 disk
└─vda1 253:102T 0 part /
root@ubuntu-16:~# dpkg -l | grep cloud-init
ii cloud-init 17.2-35-gf576b2a2-0ubuntu1~16.04.2
all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.5
all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.5
all write a network interface file in /run for BOOTIF
The cloud-init.log looks like the disk growing and file system resizing went
fine:
018-04-10 14:14:31,332 - stages.py[DEBUG]: Running module growpart () with
frequency always
2018-04-10 14:14:31,332 - handlers.py[DEBUG]: start:
init-network/config-growpart: running config-growpart with frequency always
2018-04-10 14:14:31,332 - helpers.py[DEBUG]: Running config-growpart using
lock ()
2018-04-10 14:14:31,332 - cc_growpart.py[DEBUG]: No 'growpart' entry in cfg.
Using default: {'mode': 'auto', 'ignore_growroot_disabled': False, 'devices':
['/']}
2018-04-10 14:14:31,332 - util.py[DEBUG]: Running command ['growpart',
'--help'] with allowed return codes [0] (shell=False, capture=True)
2018-04-10 14:14:31,352 - util.py[DEBUG]: Reading from /proc/1192/mountinfo
(quiet=False)
2018-04-10 14:14:31,352 - util.py[DEBUG]: Read 2621 bytes from
/proc/1192/mountinfo
2018-04-10 14:14:31,353 - util.py[DEBUG]: Running command
['systemd-detect-virt', '--quiet', '--container'] with allowed return codes [0]
(shell=False, capture=True)
2018-04-10 14:14:31,355 - util.py[DEBUG]: Running command
['running-in-container'] with allowed return codes [0] (shell=False,
capture=True)
2018-04-10 14:14:31,356 - util.py[DEBUG]: Running command
['lxc-is-container'] with allowed return codes [0] (shell=False, capture=True)
2018-04-10 14:14:31,357 - util.py[DEBUG]: Reading from /proc/1/environ
(quiet=False)
2018-04-10 14:14:31,358 - util.py[DEBUG]: Read 153 bytes from /proc/1/environ
2018-04-10 14:14:31,358 - util.py[DEBUG]: Reading from /proc/self/status
(quiet=False)
2018-04-10 14:14:31,358 - util.py[DEBUG]: Read 906 bytes from
/proc/self/status
2018-04-10 14:14:31,358 - util.py[DEBUG]: Reading from
/sys/class/block/vda1/partition (quiet=False)
2018-04-10 14:14:31,358 - util.py
