As i understand we are talking about CVE and security issues that needs to be solved not after a release but while we are designing a release engineering lifecycle. How does that effect in real world devices such as embedded devices ?
Could you please give me a spesific security issue example (CVE number like we talk in mailing lists) ?
If this is the right place to talk general risks of the related CVE
This is what I would expect to happen, yes. The installer works by copying a preinstalled filesystem into the new system, it doesn’t run debootstrap like debian-installer (in some variants anyway) does. You can use inject-subiquity-snap.sh to do this I expect – something like:
snap download subiquityinject-subiquity-snap.sh -i -f hirsute-live-server-amd64.iso subiquity_*.snap custom.isodpkg-deb -x /path/to/your/adduser.deb new_filesystem (or maybe some chroot games if you need maintainer scripts to run)There is still no autoinstall with the desktop version, but I have created a new tool that enables you to use the traditional preseed method for Ubuntu 20.04 desktop. Check it out here if you are still looking for a solution: https://github.com/covertsh/ubuntu-preseed-iso-generator
Another question I have after working with this a bit. I can see that the ISO gets downloaded 3 times over the network when doing an automated install. Is there a way I can make it not do that?
I’ve found this to be a very useful page, thank you! I am not terribly familiar with KVM, so I expected the terminal output from the test install to go directly to my terminal.
Instead, I got
Unable to init server: Could not connect: Connection refused
Could not access KVM kernel module: Permission denied
qemu-system-x86_64: failed to initialize KVM: Permission denied
until I added the ‘-nographic’ flag and ran the command with sudo. Even then, I found it unhelpful that the screen was blank for a long period of time until I realized I needed to tell the kernel to use the serial console as well. All of which to say, I might suggest you’re expecting these test commands to be run on a desktop system, or use this slightly altered command for “Run the install”
sudo kvm -nographic -no-reboot -m 1024 \
-drive file=image.img,format=raw,cache=none,if=virtio \
-cdrom ~/Downloads/ubuntu-20.04-live-server-amd64.iso \
-kernel /mnt/casper/vmlinuz \
-initrd /mnt/casper/initrd \
-append 'autoinstall console=ttyS0 ds=nocloud-net;s=http://_gateway:3003/'
Similarly for “boot the installed system”:
sudo kvm -nographic -no-reboot -m 1024 \
-drive file=image.img,format=raw,cache=none,if=virtio
Thanks!
I am convinced that adding some of what is documented at
https://www.molnar-peter.hu/en/ubuntu-jammy-netinstall-pxe.html
to an improved (and less VM targeted) autoinstall manual would be super helpful.
Hi, I want to install the system into BTRFS volumes. How do I script that?
I’ve got an error on network configuration stage with Ubuntu Server 22.04, so the autoinstall stops at the very beginning.
I put my interface names in the config right.
Could you retry or any ideas what may be wrong?
We currently have documented effectively two how-tos: “Providing the autoinstall data over the network” and “Using another volume to provide the autoinstall config”
Further to a discussion on #ubuntu-server just now, it occurs to me that we’re missing a commonly wanted how-to, which is “Make an ISO image that embeds my desired auto-install configuration”. This is needed for simple bare-metal installation automation that works without network infrastructure or the need for a second disk.
I agree with this. I think I’ve hacked things together in the past, but it would be helpful to have an official document to point people to.
This is a recurring question at AskUbuntu, suggesting demand for such a tutorial.
Why does this require the ISO (especially the server ISO) at all? Why not provide a kernel and initrd for people who want to PXE boot?
Odd - releases/lunar/ubuntu-23.04-netboot-amd64.tar.gz is there, but still needs an iso-url appended.
looking for the tutorial for creating an ISO with my auto-install config, is it available somewhere?
This is a perfect tutorial to test the autoinstall on a virtualized environment. When it comes to the actual installation to a physical machine using a non customized ISO, there are some caveats.
autoinstall must be put after vmlinuz but before the triple dashes “---”.ds=nocloud-net must be escaped, i.e. \; instead of ; otherwise the URL part(s=http://_gateway:3003/) won’t be passed as a kernel parameter and will be ignored.It would be nice if this tutorial mentions those differences between the virtual environment with calling vmlinuz and initrd directly and the physical env using GRUB.
Also, if we consider a scenario where somebody tests autoinstall config with the kvm command for a physical machine, it would be nice to use UEFI boot with the kvm command too. If not, the tested config may not be reusable since custom partitioning, etc. may not be applicable each other.
We should give this a bump to 24.04, to deprecate the 22.10 specific instructions and allow us to provide a supportable workflow. Thoughts?
Yes, this is part of the content that was earmarked to be moved to the official Installer documentation, and I think the point @setuid raised is already being addressed as part of the move. As soon as I have the go-ahead, I’ll be sunsetting these pages from the Server Guide and setting up redirects to the newer version of this page in the Installer docs.
Adding my +1 to this as we just had a customer case come in about this too.
There’s some kernel related errors they’re getting trying to follow these instructions for 22.04 or even 23.10.