It was already the default installer in Ubuntu 18.04. So this is the second LTS release where it is the default, and this thread was created to gather input from users about what features it would need to gain in order to completely obsolete the non-default d-i-based installer. I’m sorry this didn’t come to your attention until after the 20.04 LTS release has happened, but it’s quite difficult to reach all Ubuntu users who might be affected by deprecation of a component. This is effectively why the d-i images have been kept in place as legacy images for 20.04.0 LTS, so that users have a solution for use cases that were not captured for the 20.04 release of the live installer. It is also why the path of these images has been changed, so that users know that there are changes happening and can plan for the future.
Please listen when we say that the Ubuntu mini.iso is useful both for server users and for desktop users.
Many people like the flexibility of the debian installer. And many people are still using computers that run well in BIOS mode (alias CSM alias legacy mode), where systems made with the mini.iso work.
More people than you think want to create a system with a light-weight desktop environment or window manager and install a custom set of application programs. The Ubuntu mini.iso in an excellent tool for this purpose.
So please keep it alive and easily available to end users.
It looks like the solution described does not work on machines with just 2Gb of RAM: the kernel loads and when it tries to download and mount the iso it fails with the initramfs wget: short write: No space left on device error message (after downloading 660Mb)
ramdisk_size=1500000 option in the append section did not change anything
Nope, can’t get these instructions to work in order to netboot Ubuntu 20.04.
First of all, if I use cdimage.ubuntu.com, wget insists on trying to use the IPv6-address, even though I don’t have IPv6, so it fails. If I replace the domain with an IPv4-address, it fails with “Network is unreachable”.
Something about the boot-process is doing something very wrong and it doesn’t help that I don’t have any way of telling it not to use IPv6. The fact that it insists on trying to use IPv6 and doesn’t fall back to trying IPv4 is definitely a bug.
I would like to add my vote for a 20.04 netboot image. I have many recommendations out for new users to use the netboot. I also do not have a need or want the cloud stuff. When I use the live server install I have to take time to remove what I don’t want or need. Same goes for the IOT images.
The mini.iso has been around for years. It’s a well established and small piece of software. I assume it takes only few developer hours to maintain compared to the work related to building and testing a number of full-size ISO’s.
Just looking at the posts in this thread shows that there is a benefit in keeping it (if anyone were in doubt).
One thing the mini.iso - method has over the big live-server iso is that it handles not having any local drives gracefully by letting you quickly and easily connect to and install on an iSCSI-target. The big iso throws a hissy fit, if it doesn’t detect any local drives and refuses to go forward!
You’re highlighting this bug as if it’s a technical limitation that makes mini.iso install process “only usable on an ever-diminishing percentage of older server hardware”. This is very misleading and far from being true. One quick look at the bug reveals that it’s a very simple fix that’s documented right in the bug description - the mini.iso is just missing the EFI boot image, which people have been manually adding to make it work on EFI systems. Several affected users are complaining in the bug comments how this “high” importance bug has been around for years still unfixed, when it has already been fixed in Debian long time ago.
Your own comment on that bug explains why: “The mini iso is an artifact of the debian-installer package build and is not a supported installer”. So although it would be trivial to bring this fix in downstream from Debian, it has intentionally been left broken because it helps drive people away from the debian-installer. Now you still have a valid argument for not fixing it by claiming mini.iso is unsupported ,even though it doesn’t take much and would be very beneficial to the users. However, your decision to not fix the EFI issue does not imply that it couldn’t be just as functional on the modern hardware. It’s capable of supporting a wider range of hardware beyond what live-installer is able to.
I’m still trying to wrap my head around what benefits the live-installer will eventually offer over the traditional d-i based installer that the decision was made to drop support for the latter. It would be good to have some insight into that…
I’ve played enough with the live installer to conclude that … let’s say just that it’s not suitable for my needs, for reasons that others have already explained in this thread, and I don’t understand the reasoning behind deprecating mini iso.
If the decision holds I’m afraid I’ll have to start migrating my servers and those of organizations where it’s up to me away from Ubuntu.
I have tested the netboot of live server and it works well. However I have a problem with autoinstall.
I used datasource nocloud-net (ds=nocloud-net;local-hostname=server01;seedfrom=http://192.168.88.2/). Installer finds the user-data yaml file correctly, but it doesn’t override the hostname from the identity section in the user-data file.
I want to cover the usecase to use the same installer auto configuration for all of my servers, the only difference would be hostname, which would be given as a boot parameter.
How can I pass the hostname to the installer from as boot parameter when in autoinstall mode?
How can I achieve the same effect as by using the boot parameter: netcfg/hostname=server01 when using the d-i installer?
Great question. Probably the easiest (although not exactly clean) thing to do for now would be to use an early-command that reads the hostname off the kernel command line (passed however you want) and stuffs that into the autoinstall config. Something like this (untested!):
- ['python', '-c', *update_hostname]
- &update_hostname |
import shlex, yaml
with open('/proc/cmdline') as fp:
cmdline = shlex.split(fp.read())
hostname = None
for word in cmdline:
hostname = word[len("hostname="):]
if hostname is not None:
with open('/autoinstall.yaml') as fp:
config = yaml.safe_load(fp)
config['identity']['hostname'] = hostname
with open('/autoinstall.yaml', 'w') as fp:
If overriding one particular part of the config via the kernel command line is a common thing, we can certainly make this easier somehow.
The desktop-oriented full ISO-image, at least, fails to install correctly if booted over NFS. The installation just gets stuck towards then end, never finishing. As such, that approach won’t work until/unless someone fixes the installer.