The process for network booting the live server installer – at least
on systems that support PXE network boot – goes like this:
The to-be-installed machine boots, and is directed to network boot.
The DHCP/bootp server tells the machine where to get pxelinux.0.
The machine’s firmware downloads pxelinux.0 over tftp and executes it.
pxelinux.0 downloads configuration, also over tftp, telling it
where to download the kernel, ramdisk and kernel command line to
use.
The ramdisk looks at the kernel command line to see where to download the server ISO from, downloads it and mounts it as a loop device.
From this point on the install follows the same path as if the ISO
was on a local block device.
Configuring DHCP/bootp and tftp
There are several implementations of the DHCP/bootp and tftp protocols
available. This document will briefly describe how to configure
dnsmasq to perform both of these roles.
Install dnsmasq with “sudo apt install dnsmasq”
Put something like this in /etc/dnsmasq.conf.d/pxe.conf:
As you can see, this downloads the ISO from Ubuntu’s servers. You
may well want to host it somewhere on your infrastructure and
change the url to match.
For releases newer than Ubuntu 22.10 you can specify the URL with iso-url= instead of url= which can avoid multiple downloads of the ISO (as cloud-init looks for url= on the kernel command line as well).
Hello. I ended up here for the same reason. I wonder if they have not had time to get to it yet, or, if they do not plan to offer the netboot iso as in the past. Will keep on watching…thanks all for your efforts.
We won’t be making a netboot ISO. We will be publishing the kernel and initrd so you don’t have to fish them out of the ISO, but the installer requires a more full featured rootfs than d-i worked with. It might be possible to mount that rootfs over iscsi or something, perhaps.
The mini.iso allowed users to netboot low-memory systems lacking cd-rom over the network and install a minimal server with ease.
The minimum system requirement for mini.iso d-i install was ~64 Mb RAM if I remember correctly.
The current live-installer downloads the entire ISO file and loads it in memory.
Have you decided to just take away this functionality from the existing server users?
If the plan is to discontinue d-i in favor of the live-installer, it would be a reasonable user expectation that equivalent functionality will be offered by the new installer (plus other improvements). Is there a plan to redesign the live installer netboot along the lines of how d-i used to work (before it’s dropped), so that the users are not impacted by this change?
I’m disappointed you dropped the mini.iso with debian installer. It was worked fine until focal RC. Why did you drop it just before final release? I repeat, it was worked fine with RC release!
Your new method force to download 900mb of file just to boot the installer. This is very bad.
I also have issue to use my local mirror with custom apt keys. I just can’t start the install, the installer just crash with cryptic error. The documentation is very basic too.
I hope you change idea and release a new debian-installer compatible with final release.
The mini.iso is output of the debian-installer build and continues to be available at http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/legacy-images/netboot/mini.iso. It has not been dropped, but neither is it an image that we recommend users use for installation. The mini.iso has in fact never been a “supported” install method for Ubuntu, and is not part of the test matrix for Ubuntu releases. And there will not be an equivalent mini.iso image for use with subiquity.
Ubuntu offers boot-in-place cloud images for this use case, which is generally a better experience than having to boot an installer at all. You might want to give them a try. https://ubuntu.com/download/cloud
Ubuntu offers boot-in-place cloud images for this use case, which is generally a better experience than having to boot an installer at all.
And what about the use case for a minimal install on bare metal, or those that want to do their own installations instead of using a pre-installed cloud image? The mini.iso you have linked to pre-dates the 20.04 release date!
The assumption seems to be that everyone either wants (a) a full blown install with Subiquity or (b) to run a pre-installed image in a VM. Not everyone fits into those two categories!
I am rather surprised that what must be a very common use case (minimal server installs) is now dropped (from d-i), unimplemented (subiquity), unsupported (mini.iso), and undocumented (all)!
You are correct that the docs are out of date. We need to finish updating them.
The server guide, prior to Focal was grossly out of date. Some pages had not been touched since Precise. We have hit some of the other pages, but some other pages like the install area are still needing re-writes.
I don’t think the concern he was trying to express is that the documentation is out of date. In fact, the section he quoted was pretty current and up-to-date up until a week ago!
The problem is that the senior management at Canonical seems totally out-of-touch with what your users want and is trying to force something down their throat that just doesn’t fulfill their needs. You seem to believe that a typical server user wants guided disk partitioning during installs and installing to existing disk partitions/volumes is a fringe use-case that can be safely ignored.
The documentation is merely reflective of how well ubuntu server fulfilled wide range of user requirements (even supporting older low-memory systems) by providing several options for the installation. But with this release, you have decided to take away what a significant chunk of your user base has been actively using (both the traditional d-i install and the mini.iso/netboot based minimal server install) and are offering an alternative that just doesn’t fill the huge gap you’ve created. And your solution to fix this problem is to update the documentation to erase any references to d-i!
The live installer has been out there for a couple years and perhaps the lack of complaints made you believe it’s widely accepted. But the fact is that it’s severely limited in functionality compared to d-i and is also horribly broken. It wasn’t quite ready to be the default installer for a major LTE release!
A plenty of server users haven’t looked past mini.iso for years and didn’t even know that live installer existed - so it didn’t matter to them up until now. D-i just worked and allowed most of your users to do what they wanted.
It’s quite obvious that subiquity can’t match the functionality and simplicity of the debian-installer because of the way it’s designed. But on the other hand, the redesign will definitely bring out some benefits over d-i. So why not keep both?
Someone from your staff commented that d-i/mini.iso hasn’t even been officially supported for a long time, so it’s not like it’s being actively developed. If it still works, what’s the point of killing it if there are no alternatives that perform the same function and there’s clearly a demand?
Hi, I found a problem in the new ubuntu 20.04 LTS installer via netinstall.
When installing and selecting only the SSH server, the distribution installs correctly, but after booting from the disk the default terminal is tty7 (thus only the black screen is shown). Switching the ALT + F1 terminal to tty1 solves the problem and shows a normal login prompt.
When installing from a normal ISO image I did not encounter this problem.
It is a bit disturbing because it is not known what happens during startup and whether the server turned on correctly.
The difference I found is in the setting
/etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT