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.
So after debugging this a whole bunch more it is now working, just not like I expected. It seems the installer doesn’t actually create the user. Instead it creates a cloud-init config to be used at first startup. Is this accurate? I had a late-command in the autoinstall config that was disabling cloud-init which is why the user wasn’t being created.
Maybe this was a bug with the 20.04 iso and it got fixed in 20.04.1 because I can’t seem to reproduce it any more.
My only issue now is I can’t get the installer to NOT create swap. I have the following in my config. Is layout direct conflicting with swap size 0? Is there a way to specify effectively: fill entire disk, don’t use lvm and no swap.
I assume the url kernel param points to the ISO image, but looking at the logs:
2020-09-24 09:28:42,405 - main.py[INFO]: contents of 'http://192.168.57.4/ubuntu_2004/ubuntu-20.04.1-live-server-amd64.iso' did not start with b'#cloud-config'
2020-09-24 09:28:47,201 - main.py[INFO]: contents of 'http://192.168.57.4/ubuntu_2004/ubuntu-20.04.1-live-server-amd64.iso' did not start with b'#cloud-config'
So it looks like it’s looking at the url param for cloud-config?
Anyone got any pointers? Thanks
Does anybody know how can I change default filesystem type? It is possible via system installer guide (supports: xfs, ext4 and brtfs), so I believe that there must be a key for that. All I want is to install ubuntu with lvm (default layout: name: lvm) but with xfs as filesystem type.
Please don’t tell me that I need to do it manually I mean define all the partions like it is mentioned above (look for EFI customization). Docs are silent about changing fs type. All I found so far is doc related to cloud-init here: https://cloudinit.readthedocs.io/en/latest/topics/examples.html.
Possibly, I don’t think anything changed around this but oh well. Get me logs if it starts happening again please!
Ah, looks like the swap key is ignored if you use a layout option. That would be a bug, sorry.
Sign it does look like cloud-init config looks at url= in the kernel command line (I didn’t know this!), but the s= url should still be looked at as well. Can you post any more logs?
Currently the layout options do hardcode ext4 filesystem I’m afraid. This should be easy to fix though, can you file a bug on Launchpad?
You must be using edge? I guess you should stop doing that for the moment, some disruptive changes are landing. It should still be working so I’ll try and fix it, but if you use edge it’s going to break from time to time, realistically.
I plan on going back to stable but it doesn’t work either. Also with the snap package management, I cannot go back to using 20.07.1 like I want. It’s disabled in the stable channel for some reason.
@mwhudson when using another volume to provide the autoinstall config, why am I forced to extract the server iso, write in autoinstall to the kernel command options then repack for a truly hands-off install?
I understand the desire for caution but there ought to be a better solution than this.
