I have not tried Ethernet since it does not come with the Laptop I have ASUS ZenBook UX550VE-DB71T, it does come with a Intel Corporation Wireless 8265.
I guess the next step would be to add a USB to LAN device and see if that works. So I am guessing Wifi usually not a standard way of setting up server and more desktop. So the packages are not included?
I tried a ‘normal’ live server install on my laptop and it detected the ethernet NIC, but not my WiFi card. So I think the server ISO does not include the required firmware packages.
It’s definitely possible to set up a graphical desktop with the autoinstall process as I showed above, but I have not been able to get it to work via WiFi only yet.
Yes that is also my problem with the live server install. I thought of updating the ISO by adding the wpa_supplicant package using Cubic but I was not successful and it does not seem like the proper way given that it’s an old package.
It seems logical that the desktop version would use the same autoinstall feature.
Thanks for the confirmation that it only works with an Ethernet NIC.
I am working on setting up a wifi only enabled automated install from a usb stick with the user-data and meta-data provided by the NoCloud datasource to cloud-init. I’ve observed a few issues. First lesson, if you modify any of the information in /etc/os-release or /etc/lsb-release, then you may possibly break cloud-init when it checks for devices with the cidata label. It’s best to take a look at those files in a non modified running system and make sure if you do modify them, they don’t have any unquoted funny white spaces. Second lesson, cloud-init doesn’t do nearly enough path sanitation. If you give the kernel seedfrom a value that doesn’t end with a os.sep value, then cloud-init just blindly will join this with the filenames, resulting in a failure. Why cloud-init decided to go with a seedfrom value of a directory for NoCloud, I have no clue? Who cares about verbosity on something that no-one other than us poor lonely sys admins will read anyway? Thirdly, I couldn’t get cloud-init to detect a separately mounted vfat volume with the cidata label. I had to resort to methods similar to the script from covertsh and others that puts the user-data and meta-data in a modified unsquashed filesystem. Unfortunately, even when I did that, and cloud-init seemingly loaded my datasource (as evidenced by logging the mydata variable from the _get_data func in /lib/python3/dist-packages/cloudinit/sources/ DataSourceNoCloud.py) when subiquity starts to run, for some unknown reason, the seedfrom value which was only moments earlier recognized, is rejected, and the installer craps out and puts me back in the live installer. I have no hypothesis as of now why that happens. Why and exactly when cloud-init needs to modify files in /var/lib/cloudinit and in /run/cloudinit is beyond me. But, presumably, knowing when these paths are written to would go a long way in easing my pain.
As a side note, I ran the live server installer and manually added the ubuntu-desktop package with --no-install-recommends, and I get what I want, just without wifi. Of course, adding the wpa_supplicant package and its dependents missing from the live server iso works fine, that is, I get internet connectivity but only through this extra unfortunate manual step.
What you might ask do I want to achieve? Well, what I want to achieve for my small office is a lan accessible service that provides custom isos for download. Employees can simply write to usb and plug in to get their base system. No, I don’t want netboot, because I actually do want these usb sticks, not provisioning directly to the eventual host machine.
This looks like a pretty handy script. One thing you can do instead is to mount the iso, create an overlay over it and then pack the overlay which will be quicker and use less disk, but will make the script require root. You can also make it more robust using xorriso to extract the arguments needed to recreate the ISO, as done here: https://github.com/CanonicalLtd/subiquity/blob/main/scripts/inject-subiquity-snap.sh#L194
The desktop installer is currently still d-i based. I think it’s possible to install it automatically somehow but I certainly don’t know how.
This is pragmatically the case yes. It would be possible of course to add the needed packages to the ISO and change the installer to enable the wifi bits and so on but very far from trivial.
@mwhudson I am trying to test a candidate change to adduser for Private home directories for Ubuntu 21.04 onwards? using the hirsute daily image and autoinstall. I had hoped to use a config like the following to add the PPA with the candidate build during the install but it doesn’t seem to work.
autoinstall:
version: 1
identity:
hostname: ubuntu-server
password: "$6$exDY1mhS4KUYCE/2$zmn9ToZwTKLhCw.b4/b.ZRTIZM30JZ4QrOQ2aOXJ8yk96xpcCof0kxKwuX1kqLG/ygbJ1f8wxED22bTL4F46P0"
username: ubuntu
apt:
sources:
adduser-private-homedirs-ppa:
source: ppa:alexmurray/adduser-private-homedirs
Whilst I can see the PPA is enabled in the apt sources in the installed system, the version of adduser is still the one from the hirsute archive and not the newer one from my PPA. So if I log into the installed system and run and apt upgrade I then have the newer version but I want to try and test that the private home dirs part works when this newer version of adduser is used as part of the installer. Am I doing something wrong?
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?