Lot of rancor in this thread, which seems to have devolved into a bunch of rock-throwing and me-too posts. Freezing the thread briefly to get discussion back on track.
Advice to new folks:
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.
Bug #1429030 “netboot mini.iso doesn't support UEFI boot” : Bugs : debian-installer package : Ubuntu shows that the mini.iso does not work on any system running in UEFI mode instead of in BIOS mode. That means it is only usable on an ever-diminishing percentage of older server hardware.
I understand that you find the mini.iso better suited to your needs. But I don’t think it helps for you to assert that it meets the needs of “most of [Ubuntu’s] users”.
It’s been a day for folks to cool down. Reopening…
My solution:
in /etc/default/grub set GRUB_CMDLINE_LINUX_DEFAULT = "**no**splash ...
update-grub
apt -y purge plymouth-theme-ubuntu-text
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 
Right, it also needed root=/dev/ram0, and now right before it installs grub into a freshly installed ubuntu 20.04 it crashes in the curtin which I reported at https://bugs.launchpad.net/curtin/+bug/1876258
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).
Where is the benefit in removing it?
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!):
#cloud-config
autoinstall:
version: 1
early-commands:
- ['python', '-c', *update_hostname]
identity:
hostname: ubuntu-server
password: "$6$exDY1mhS4KUYCE/2$zmn9ToZwTKLhCw.b4/b.ZRTIZM30JZ4QrOQ2aOXJ8yk96xpcCof0kxKwuX1kqLG/ygbJ1f8wxED22bTL4F46P0"
username: ubuntu
bucket:
- &update_hostname |
import shlex, yaml
with open('/proc/cmdline') as fp:
cmdline = shlex.split(fp.read())
hostname = None
for word in cmdline:
if word.startswith("hostname="):
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:
yaml.dump(config, 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.
Instead of downloading the whole ISO to mount it locally, why not allow network mounts via good-old NFS, or even webdav?
I can see a number of advantages in doing so:
Is there a way to provide only filesystem.squashfs and kernel/initrd, and perform a ‘mini.iso-like’ install from a local apt repo?
I am fine with mini.iso being deprecated but it seems wasteful to install a system from a not-neccessarily-up-to-date disk image, then also having to pull updates from the repo seperately.
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.