Right, I'm in agreement with comment 12, I don't know that this is
actionable from the Subiquity perspective.
For golden image deployment, we do generally recommend starting from a
preinstalled image, which I think is going to behave closer to what you
expect.
Subiquity builds a cloud-config,
The problem that was initially reported was resolved in this bug report.
Cloud-init was behaving as expected so setting to invalid.
** Changed in: cloud-init (Ubuntu)
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Dear Chad. That you very much for those very detailed comment about
subiquity artifacts.
I did
root@ubuntutemplate:~# cloud-init clean --logs
root@ubuntutemplate:~# sudo rm -f /etc/netplan/00-installer-config.yaml
/etc/cloud/cloud.cfg.d/curtin-preserve-sources.cfg
Marking subiquity project for reference tracking and information as we
better define what supported use-cases cloud-init/subiquity we need to
cover in the future. It may very will be a WON'T FIX from suquitity
point of view at the moment as this bug doesn't yet represent an
actionable feature
TLDR: generally for individuals looking to create custom Ubuntu Server
golden images, we suggest they start from a stock Ubuntu Server cloud
image instead[1] of the subiquity-based Ubuntu Server Live installer
images[2].
[1] Ubuntu Server cloud images for
I certainly did not put one of those in there. But Subiquity did:
root@ubuntutemplate:~# cat
/etc/cloud/cloud.cfg.d/subiquity-disable-cloudinit-networking.cfg
network: {config: disabled}
I may not have noticed a warning of the installer regarding this, but in
case it did not warn about it, IMO
Sorry, I should have been more clear in my comment.
In your bug report, you mentioned:
root@ubuntutemplate:~# cat /mnt/tmp/meta-data
instance-id: 61a74c24a0b88039cc7ee3e0560d6ffe0a91f956
root@ubuntutemplate:~# cat /mnt/tmp/user-data
#cloud-config
hostname: ubuntutemplate
manage_etc_hosts: true
Hmmm, Launchpad does not seem to like me to add the log files from
cloned VM "ubuntu01". Well, I confirmed that the provided log matches
what I see on the original "ubuntutemplate" VM so I bet this will do.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I can confirm the log lines you posted with exactly the same time stamp
on the affected VM.
One thing to note: There was already an initial cloud init setup
straight after the installation. I changed cloud-init.cfg and logging to
my needs afterwards. As far as I can remember also the initial
I used "ubuntu-bug cloud-init" to report the bug. I do not see how the
logs it send should be incorrect. I did not disable network
configuration. I disable a lot of things I do not need, but initial
network configuration is mostly what I use cloud-init for. I made sure
the cloud init configuration
Looking at the cloud-init.log, it appears that network is intentionally
disabled.
2022-01-17 15:13:47,267 - stages.py[DEBUG]: network config disabled by
system_cfg
2022-01-17 15:13:47,267 - stages.py[INFO]: network config is disabled by
system_cfg
which means network is disabled via the "cloud
I believe the ISO to have the correct name as well:
root@ubuntutemplate:~# file -sk /dev/sr0
/dev/sr0: ISO 9660 CD-ROM filesystem data 'cidata'\012- (Lepton 3.x), scale
0-0, spot sensor temperature 0.00, unit celsius, color scheme 0,
calibration: offset 0.00, slope 0.00\012-
One more comment. I switched to
GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 biosdevname=0"
as well, in order to make sure cloud-init finds the network interface
after it did not work with "ens18".
However on the other Ubuntu LTS 20.04 VM I did not so this and cloud-
init generates a config with
Ah, and of course in order to send the additional data for this bug
report, I manually fixed up the network configuration.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1958377
Title:
cloud-init
14 matches
Mail list logo
