Netbooting the live server installer

Server
1

Netbooting the live server installer

The process for network booting the live server installer – at least
on systems that support PXE network boot – goes like this:

  1. The to-be-installed machine boots, and is directed to network boot.
  2. The DHCP/bootp server tells the machine where to get pxelinux.0.
  3. The machine’s firmware downloads pxelinux.0 over tftp and executes it.
  4. pxelinux.0 downloads configuration, also over tftp, telling it
    where to download the kernel, ramdisk and kernel command line to
    use.
  5. 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.
  6. 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.

  1. Install dnsmasq with “sudo apt install dnsmasq”

  2. Put something like this in /etc/dnsmasq.conf.d/pxe.conf:

    interface=<your interface>,lo
bind-interfaces
dhcp-range=<your interface>,192.168.0.100,192.168.0.200
dhcp-boot=pxelinux.0
enable-tftp
tftp-root=/srv/tftp

(This assumes several things about your network; read man dnsmasq
or the default /etc/dnsmasq.conf for lots more options).

  1. restart dnsmasq with sudo systemctl restart dnsmasq.service.

Serving PXELINUX and its configuration

  1. Download pxelinux.0 and put it into place:

    # wget http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/legacy-images/netboot/pxelinux.0
# mkdir -p /srv/tftp
# mv pxelinux.0 /srv/tftp/

  2. Download the latest live server ISO for the release you want to install:

    # wget http://releases.ubuntu.com/focal/ubuntu-20.04.1-live-server-amd64.iso

  3. Mount it.

    # mount ubuntu-20.04.1-live-server-amd64.iso /mnt

  4. Copy the kernel and initrd from it to were the dnsmasq serves tftp from:

     # cp /mnt/casper/{vmlinuz,initrd} /srv/tftp/

  5. Make sure to have installed package syslinux-common and then:

     # cp /usr/lib/syslinux/modules/bios/ldlinux.c32 /srv/tftp/

  6. Create /srv/tftp/pxelinux.cfg/default containing:

    DEFAULT install
LABEL install
  KERNEL vmlinuz
  INITRD initrd
  APPEND root=/dev/ram0 ramdisk_size=1500000 ip=dhcp url=http://releases.ubuntu.com/focal/ubuntu-20.04.1-live-server-amd64.iso

    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).

This configuration is obviously very simple. PXELINUX has many, many
options, and you can consult its documentation at
https://wiki.syslinux.org/wiki/index.php?title=PXELINUX for more.

8 Likes
2

Work perfectly also with UEFI PXE boot! :slight_smile:

menuentry 'Ubuntu 20.04 Liveserver' --id ubuntu-server_1804 {
  linuxefi /ubuntu_2004_amd64_netinstall/vmlinuz ethdevice-timeout=30 ip=dhcp url=http://ubuntudev.tux.lan/ubuntu-20.04-live-server-amd64.iso boot=casper ide=nodma debian-installer/language=de console-setup/layoutcode?=de
  initrdefi /ubuntu_2004_amd64_netinstall/initrd
}
3

@mwhudson

What is going on here? Where is the netboot image ? Server image is 800 MB where netboot image is 70 MB. Did you mix things up.? Please fix the issue.

http://cdimage.ubuntu.com/netboot/focal/ does not point to the netboot image.

6 Likes
4

Hello, can you offer a netboot.iso ?

4 Likes
5

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.

2 Likes
6

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.

7

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?

7 Likes
9

Again, a major change in a LTS release…

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.

Thanks!

8 Likes
10

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.

1 Like
11

Most people I know who are familiar with VMs, have used mini.iso for years and years…

There is no point in a full desktop install in a VM - just enough to get the job done.

4 Likes
12

mini iso for 20.04 now deprecated?

13

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

14

Thanks for the link to the focal mini.iso. It’s well hidden while it was easy to found on previous ubuntu release.

1 Like
15

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)!

4 Likes
16

I note also that the information here seems to conflict the documentation here:

Note that it refers to three installation types (and the corresponding memory requirements):

Server (Standard), 512 megabytes
live server, 1 gigabyte
Server (Minimal), 384 megabytes

But the instructions which follow are only in relation to live server. How does one perform the other two types of installation?

2 Likes
17

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.

1 Like
18

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?

6 Likes
19

I always used d-i to install my HTPC system

2 Likes
20

Please keep the mini.iso in a well maintained state and at a visible path without ‘archive’ and ‘legacy’ in the URL.

It serves a lot of purposes both for desktop and server users.

6 Likes
21

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

netinstall has:
GRUB_CMDLINE_LINUX_DEFAULT = "splash quiet"

system with normal iso:
GRUB_CMDLINE_LINUX_DEFAULT = "maybe-ubiquity"

After changing and rebuilding the grub config next boot normally loads login prompts.

2 Likes