UPDATE: Okay, there is a Encrypt the LVM group with LUKS option in the Ubuntu 20 installer.
But we used to be able to do LUKS encryption with LVM using the Ubuntu Server 18.04 Alternative Installer.
Guess it is not possible now?
cmgui
i also came here due to packer issuesā¦
i wanted to use packer to automate the creation of ubuntu vmware templates for customers, the installation was meant to install as little as possible , provision the configuration and create the template.
now i see that not only packer cannot use it, but the installer doesnāt allow me to specify only the packages i need , which makes it unusable for me
thanks, it seems youāre the only that worked so far at least for inputting the command, cause other configs, tried inputting them after ā
can those be used for on-prem locations? as thought they were regular ubuntuās? (the comment about certified for cloud environments puts me off)
Yes, they can be used on-prem (or non-public clouds or VMWare/VSphere setups) or locally. Theyāre published in cloud-images because the Public Cloud team produces the images. Theyāre based on the server image, and include small changes. You can review the manifests to see any additional items from the base server image.
is the āurl to see data fromā act like an auotmated installer? (can it be used with on prem http too?)
iām also using packer, and i can tell you my use case.
we provide our customers ova installed with our application server,
till now we are using vmware studio to automate ova creation.
weāre trying to get away from it, and packer is perfect for this, it allows us to create a machine from scratch and provision it with various packages and configurations in reproducible way previously with d-i i was able to specify swap partitions, as well as what other packages i want to install, i didnāt even need an http server, cause i could provide the preseed file via floppy
@mwhudson
Dear Mark,
Sorry for the RANT. But the direction you have taken the installer in as absolutely abysmal. I have been battling with subiquity since the release of 18.04 ! often saved by the now deprecated debian installer which you have so kindly dropped support for.
I have spent around 4 hours today tying to install ubuntu 20.04. Multiple crashes on UEFI & Legacy boot modes. Multiple expletives have been bellowing out my mouth during the install process.
Partitioning disk is completely broken unless I select the defaults for the disk and LVM and even that crashes sometimes.
I now have no other option than to use your āLIVEā installer that just sends my blood pressure through the roof.
I donāt understand why you think its ok to release bug ridden software and make it the ONLY way to install Ubuntu, just like when it was decided to make netplan the default way of configuring the network and it wasnāt even ready for production ( I tried installing openstack using netplan and openVswitch but that wasnāt happening ifup down had to be re-installed at the time ).
Iām all for progress and iām all for improving the state of the installer and network configuration. But why, oh, why do people think its appropriate to remove the tried and tested methods for installing this software and configuring its network.
If you had developed the software AND made sure it was thoroughly QAāed, Then dropped the old methodsā¦that would have been fine.
But youāre doing this on purpose so that I loose hours out of my day battling with your design decisions and bugs, in software that isnāt even ready nor should be released until proper QA has been done.
why canāt you verify that the software your creating meets the requirements required by the community and mirrors the functionality thatās has came before it.
Iām at my wits end. And really donāt want to use Ubuntu anymore but iām forced to. I donāt like that fact that the response that iāll likely get back from this is. GET ON WITH IT. or FILE A BUG REPORT.
I want a STABLE way to install ubuntuā¦ thats all i want.
Anyway all that has been said will probably fall on deaf ears. but its good to get all that off my chest.
I will now go cry in the corner of my server room.
Kind regards
K
FYI: At the moment you can still get debian-installer based install media at:
http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/legacy-images/
It has been QAed extensively. It still has bugs, but the old installer also had bugs. It seems that you are experiencing bugs that are not addressed by the QA that weāve done. But without providing us any details about the problem youāre encountering, the bug will only be fixed once someone else encounters it and does provide us with that information.
You mention battling with subiquity since 18.04. Well, 18.04 was released two years ago. If you have been encountering bugs for two years, but are not submitting bugs to the developers, Iām sorry, but thereās not much else that can be done.
We have continued to provide the old installer for 20.04, precisely because we know there may be use cases that subiquity cannot currently address. But the only way those will be addressed in the future is if we get feedback from users explaining what use cases it is not currently meeting.
1 Like
I too am one of the people who are unhappy with the fact that a new installer was sprung on us. We run an ubuntu mirror to help with our automated non-interactive installs, and the first I heard of a new installer was when mirroring of the just-released 20.04 failed (http:// archive[.]ubuntu[.]com/ubuntu/dists/focal/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/ is not there, but was renamed to ā¦/legacy-images/ā¦)
I admit there are some bugs in the d-i installer (in particular, it doesnāt mount the efivarfs when installing the boot loader, causing it to fail - this may be the bug that @ sergiuhlihor in item 59 ran into).
But the reference documentation at https: //ubuntu[.]com/server/docs/install/autoinstall-reference seems rather lacking some features of the old installer. For instance, weāre using
d-i base-installer/kernel/image select {% if item == "xenial" %}linux-image-generic-hwe-16.04{% else %}linux-image-generic{% endif %}
to select which kernel to install, depending on the version, but didnāt seem to find an equivalent in the new installer. Neither did I find an equivalent for d-i pkgsel/language-packs or pkgsel/update-policy or clock-setup/utc or clock-setup/ntp-server or time/zone.
So I hope that at least those features are added before the next LTS released, and of course the efivarfs bug I linked above.
When I dug into the new installer, I found that it will install the kernel image based on the contents of /run/kernel-meta-package
https://github.com/CanonicalLtd/subiquity/blob/main/subiquity/models/subiquity.py#L327
I found scripts/init-bottom/live-server in the initrd image is hardcoded to write linux-generic to this file. I was able to use the user-data autoinstall file to overwrite /run/kernel-meta-package with my desired kernel image. It would certainly be nice to not have to use this kludge, but it does work pretty simply
#cloud-config
autoinstall:
...
write_files:
# override the kernel package
- path: /run/kernel-meta-package
content: |
linux-virtual
owner: root:root
permissions: "0644"
My impression for the missing configuration options, e.g. timezone, is that cloud-init is expected to configure these.
1 Like
Yes, as youāve found, it is effectively possible to configure anything at all through subiquity auto-install using some combination of files and scripts.
Your particular choice of kernel here is concerning, however - the linux-virtual kernel is only intended for use in VMs, where we would normally expect to use a boot-in-place cloud image instead of the server installer. Are you using linux-virtual on a physical server, or using the server installer in a VM? In either case, we would be interested to know why.
That config was only from a proof-of-concept as I was playing with the new installer, but I did use it in a VM. Iāve noticed the official opinion appears to be that the pre-made images should be used when deploying VMs. I still like to make my own images.
I disagree with the idea that it is āeffectively possible to configure anythingā. One thing I would find very convenient and make that statement more true is a hook between generating the curtin configuration and running curtin. In the case of the kernel image, I was able to modify the curtin config with the file kludge. Most other options have no such work around.
Youāre right that thereās no easy way to configure this right now, although it is possible to hack around it as other posts describe. This is the first request Iāve had for this feature btw ā itās surely possible and not very hard to add less klunky support for this. Can someone file a bug with some details?
Most of these things can be configured via cloud-init, for example you can configure the timezone with something like:
autoinstall:
userdata:
timezone: Europe/London
Iām not quite sure what the hook would look like (a shell script that gets passed the location of the config to rewrite?) but this seems reasonable. File a bug for this too?
I hit this page looking for more information about the new way for automating Ubuntu installations. I found that information somewhere else, but I thought it might help others (or even my future self), if I add that information to this thread.
I found a great working example of using autoinstall/cloud-init in this GitHub repo: https://github.com/lavabit/robox
It uses Packer to generate Vagrant boxes for multiple OSās and multiple providers. It has been using autoinstall since Ubuntu 20.10. Hope this helps!