I tried multiple times of installation, and now I can understand how to use action-based config and I’m trying various storage layout. I found something weird phenomenon of storage.
Basic environment of my virtual system is like this.
vmgate : running dnsmasq, apache
vmpreseed01 : target vm
Instead of using internal virtual network which doesn’t support dhcp service, I’m using one of vm running dnsmasq and apache to use gateway machine.
Starting installation from vm which had cloned by virt-clone, everything was OK. But installation using virt-install sometimes failed. LVM installation had no problem, but direct layout was matter. Even basic supported layouts failed.
storage:
layout:
name: direct
Finally I figured out the solution. This is how I can install as direct layout successfully.
What you show is odd. Can you please open a bug report against subiquity in Launchpad to take this further?
ubuntu-bug subiquity
should collect all the logs about this. I think we’d want to see the installer logs, because indeed there appear to be inconsistent / unexpected results versus what was requested to be performed.
Same for me. I wonder if is it even possible to make it work with vshpere. With that setup:
VM with two iso files mounted as CD/DVD drive:
install iso and 2. pressed iso (contains meta and data).
In provided docs (https://ubuntu.com/server/docs/install/autoinstall-quickstart) section: Create an ISO to use as a cloud-init data source there is a example with kvm, so second iso file is served like a raw device. Does Ubuntu automatically mount second iso file? I do not think so. In redhat like systems you can set pressed file up with: inst.ks=cdrom:/dev/sr1:/preseed.cfg.
So next question should be how can I specify the way which contains the user-data and meta-data and is not accessible directly. In other words can I tell Ubuntu: mount /dev/sr1 (where second iso is) with some boot param?
You do this by having a vfat or iso9660 filesystem on the iso with the label “cidata” or “CIDATA”, cloud-init looks for this label (by using blkid) and mounts it.
First of all, I must say I’m very happy with the concepts of this new autoinstall method for Ubuntu 20.04. I’ve implemented it here the last weeks and I was able to make most of it work for our use case. (We plan to use it for desktop and server installations.)
However, I still have two feature requests (where the first one is quite important):
Is there a way to avoid users from getting a (root) login when they have physical access to the machine. As I can see, we’d need two things: 1. Never drop to the interactive installer (except for “interactive sections”, show an error message/syslog/… instead; 2. Completely disable console access on TTY2/3/… (e.g. by kernel parameter).
A way to automagically decide if mbr or gpt partitioning should be used (depending on disk size and legacy BIOS vs. EFI). If this is done by the builtin lvm partitioning layout(?), there is an issue with that one: the root partition is to small to even fit our initial package installs (having configuration options there (e.g. initial root part size) would be great). What I’ve done for now is a custom lvm layout with static size (growing with e.g. size: -1 seems not to be working with lvm), and grow it with a latecommand.
And some bugs (I think):
Setting the timezone with autoinstall: { user-data: { timezone: Europe/Zurich } } seems not to be working at all. I’ve also set timezone: Europe/Zurich (top-level) to have correct timestamps in the logs, but this doesn’t seem to work as well.
Also, I’ve noticed that disk encryption with keyfile: ... does not work (it always expects key: ... to be defined).
And a bit a supid question maybe: Is there a way to set the root password during installation? I’ve tried with autoinstall: { identity: { username: root, password: HASH } }, but it’s not working.
I would really appreciate if you could provide me with some ideas, workarounds or tips.
About root’s password. That could be done possibly with changing hash value at late-commands section in /etc/shadow like:
awk -i inplace -F: “BEGIN {OFS=FS;} $1 == “root” {$2=”$6$TQZ0oJ/xl6Gm44rX$iVo/jAUB4fJFviEIIL2lUuCsD/0kMEXNezVmVo2sakjhgjkwhfI7gHW/WGzDPjksadgsjkadfhsadfld5GxVsIuPecUX/"} 1" /target/etc/shadow
Note that destination file is in /target/etc/shadow not in /etc/shadow since afaik ubuntu is being installed to /target/ space. Another caveat is $ letter. It must be with backslash like it is above.
Sed command can be used as well.
But it needs to be tested.
Hi !
I followed autoinstall-quickstart to test the autoinstall. I don’t use kvm but Virtual box with set ubuntu server iso in primary IDE master and the seed.iso in secondary.
Like other person I can’t login using this user-data :
Yes, because that part is buggy. So if want working identity section you must add user-data with the very same settings as well.
Like:
version: 1
identity:
hostname: ubuntu-server
password: “$6$exDY1mhS4KUYCE/2$zmn9ToZwTKLhCw.b4/b.ZRTIZM30JZ4QrOQ2aOXJ8yk96xpcCof0kxKwuX1kqLG/ygbJ1f8wxED22bTL4F46P0”
username: ubuntu
user-data:
users:
- name: ubuntu
password: “$6$exDY1mhS4KUYCE/2$zmn9ToZwTKLhCw.b4/b.ZRTIZM30JZ4QrOQ2aOXJ8yk96xpcCof0kxKwuX1kqLG/ygbJ1f8wxED22bTL4F46P0”
lock_passwd: false
groups: users, adm
First, thank you.
I tried what you suggested, but it’s not working on my side. I see on the documentation that if you use user-data you do not have to add identity part, so I removed it but the user-data seems to be ignored because when I have set the hostname etc. in the user-data part before “- users:”, it was not set. I don’t know if a correlation exists between the two user-data part of my two test (if the user-data of your suggestion is ignored too) but I still can’t connect.
Update:
I add in early-commands this command to update subiquity and get the last version : snap refresh --edge subiquity
and the identity part works perfectly.
Information get at :
I’m trying to use the match functionality in the storage section and it does not seem to work.
My setup is two virtual hard drives of 20 and 40 gigs in a virtualbox test scenario. The final goal is to install a server with different raid types of different sizes. The raid for the system should be the smallest drive in the server available.
I am using a nocloud installation.
But even in the test scenario with a minimal config as:
…
storage:
layout:
name: lvm
match:
size: smallest
#1. Autoinstaller doesn’t seem to create user when loading from floppy
So I’ve been trying to create an autoinstall file to work with Packer and our vSphere environment. Originally, I was using ds=nocloud-net;seedfrom=http://host:port/ to load the user-data file from, however due to our environment and vsphere being unable to connect to my workstation directly, I decided to find an alternative. The only other way I could get Packer to get the user-data into vSphere was by it creating a floppy with a label of CIDATA. Unfortunately, now the installer does not create the user setup in either the identity section OR the user-data section. My current autoinstall file can be found here: https://gist.github.com/bnason/3e268a73adb1d330cb575e7084b19080
#2 Package installation crashes when specifying a version that isn’t the latest.
I’m trying to specify specific versions of packages to install, ie kubectl=1.19.1-00, however if this version isn’t the latest (ie 1.19.2-00 released last night) then the installer crashes.
I’m currently using 20.04.1 I originally was using 20.04 but upgraded and still see the same behavior.
I’m able to run apt-get install kubectl=1.19.1-00 successfully on a system with the Kubernetes repo installed and when apt policy shows 1.19.2-00 as the latest version.
Hmm, annoying to hear. Can you extract the /var/log/cloud-init.log file from the boot of the installed system somehow?
Hm, again can you get the log of the failed installation somehow? ‘packages:\n - foo=bar’ in the install file should just translate to (roughly speaking) ‘chroot /target apt-get install foo=bar’ so something slightly strange must be happening, possibly the apt sources aren’t configured correctly in the target or something.
