Netbooting the live server installer

Server
83

Edit 2020-10-14: if there is a simple answer/response to this matter, then why has Ubuntu not yet provided a simpler, official statement (referenced by a direct weblink) to address it? The above thread is quite hard to follow. All we (my team) see thus far is that a properly-working, small-footprint (approx < 100MB) mini.iso installer is not available from Canonical/Ubuntu. (The “legacy” 20.04 mini.iso1 did not work for us, in our first attempt, in our hypervisor=ProxmoxVE environment.) Are we misreading / misunderstanding something?

Original post: 2020-10-13:

My team is trying to understand why mini.iso has effectively “gone away” for Ubuntu 20.04–and we’re late to this discussion. Pls pardon me if we’ve overlooked points below that were already echoed above.

Ubuntu/Canonical personnel seem (?) to have offered no definitive answer that makes sense to us. The need to provide and support an ongoing, working mini.iso seems abundantly clear, from a purely-technical perspective. Given this, our guess is Canonical:

  1. does not want to assume the liability for mini.iso,
  2. wants to sell product or services that are negated by mini.iso, and/or
  3. has some other business-related motivation.

We find a “business” constraint more believe-able; if such a thing exists, we also find it better that Canonical be transparent with this motivation, rather than hiding behind whatever responses are provided above (responses we do not yet understand, and it seems my team is not alone in that confusion).

Conversely: my team finds it hard(er) to believe that Canonical does not understand motivations like these (a small-sized OS install for hypervisor container/kvm templates):

https://www.youtube.com/watch?v=BiIFLFhXByE

If there’s not a business case blocking a working mini.iso, and Canonical somehow does not understand these motivations, then must one wonder about competency issues? (That’s difficult to write, and possibly hear. Given the challenges and confusion, we’re simply being diligent with our analysis, and we’re not trying to be mean.)

Like other users, we may be forced to consider migrating to Debian if Canonical does not long-term solve this matter. Alas, we suspect Canonical has already analyzed this type of scenario and thinks they may “come out ahead” by losing users like us in favor of better supporting some business case. Again: transparency would garner more respect from at least my team, and I’m guessing others as well.

3 Likes
84

You are replying to a thread about netbooting. The mini.iso is not netbooting. Booting from any local image is not netbooting.

The mini.iso has also never been a supported install method. It is a side effect of the d-i build process which is not QAed, has known limitations, and is not promoted for download by the Ubuntu website or the Ubuntu cdimage website. It is frequently used to create unsupported, and unsupportable, installations that are missing key Ubuntu packages.

Regardless of the move away from d-i, there was never any guarantee that we would continue to provide the mini.iso.

Why is “small-footprint” a requirement?

We are not going to provide separate install artifacts to service an abstract preference that smaller images are better. If there are real-world configurations that are irreconcilably incompatible with the larger live server image, then we want to know about that.

Furthermore, we do not recommend the use of installer-based images for virtual machines; we strongly encourage the use of boot-in-place cloud images, which are a more fit-for-purpose technology. Proxmox uses KVM as a backend, so the downloadable image at http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64.img should work, when configured using cloud-init.

1 Like
85

Very helpful, thanks @vorlon. This clears some (most?) of our confusion.

Apologies for invading a netbooting discussion with a (slightly?) off-topic point. (It’s the only place I could quickly find on why mini.iso is not working.)

[disclaimer: the following note is possibly longer/wordier than need be. We prioritized speed-of-reply over conciseness.]

The current cloud-init server (20.04) .img is ~7-times larger than the mini.iso and equates to roughly 450MB of additional space of per-kvm footprint, which can be a big deal in large-scale deployments (and why things like Alpine matter, from what we can tell) that are fully-cloning the images; think qtys=1,000 to 100,000, in each of potential multiple geograhic (datacenter) deployments. But to note: the aforementioned is “dumb” math that does not account for “real” storage/bandwidth use in fully-built kvms, containers. So, we’ll see. And maybe we will not want a kvm-based solution for that and rather strictly container-ish based, which (potentially) dramatically reduces the resource load.

I totally get where Ubuntu is coming from on not wanting to support small-image stuff, that makes a boatload of sense. We would not either, if there’s not a good use-case and sufficient demand that matters to the project and the business.

If and when we want a “stripped down” image for larger-scale deployments, and we want it to be Ubuntu-based, we’ll have to strip it down ourselves (or go with a non-Ubuntu alternative like Alpine, Debian, or something else which will have other issues) if we care about resources in larger-scale deployments (which… maybe we will not after run our prototype testing in each context/application/domain?). Lots of extra work. And no support from Ubuntu.

I suspect Canonical has run the analysis and decided: there isn’t much demand for the above. (eg, again: “when running lots of kvm’s, run containers instead, and then there’s less impact from larger-image size.”)

Separately: maybe there’s another, Ubuntu-based alternative that we do not know that can help us address potential contexts like the above? (We where lots of hats in our realm, and we’re far from OS-deployment experts; we’d love to learn that we’ve overlooked a better solution/approach.)

1 Like
86

If installed footprint is a concern, there are also minimal cloud images available at Ubuntu Minimal 20.04 LTS (Focal Fossa) release [20240221]. The difference between minimal cloud images and server cloud images is that the minimal cloud images lack a lot of what is “comfortable” for users to log into the system at a shell. For deployments at scale, you might find this preferable.

If you were installing before from the mini.iso and ending up with a much smaller installed footprint vs the server image, that also probably means you were not installing the standard tasks… and were probably down one of the “unsupportable” paths I mentioned earlier.

Container-based usage under Proxmox would certainly increase density; and you definitely don’t want to be trying to use an installer-based image for containers…

1 Like
87

If installed footprint is a concern, there are also minimal cloud images available at http://cloud-images.ubuntu.com/minimal/releases/focal/release/ . The difference between minimal cloud images and server cloud images is that the minimal cloud images lack a lot of what is “comfortable” for users to log into the system at a shell. For deployments at scale, you might find this preferable.

minimal/releases/: Super helpful, just what we were seeking, thanks @vorlon. We tried out this minimal image flavor, and it works well.

If you were installing before from the mini.iso and ending up with a much smaller installed footprint vs the server image, that also probably means you were not installing the standard tasks… and were probably down one of the “unsupportable” paths I mentioned earlier.

Makes a lot of sense. Thanks again.

88

Please provide mini.iso for 20.10 (groovy) as it was for 20.04 LTS.
This is a serious bug 1884538.

1 Like
89

Your arguments in that bug for keeping the mini.iso are:

Some users don’t want snaps

Snaps are not an optional part of the Ubuntu experience. An install that is missing snaps that are installed by default is unsupported. Enabling users to install unsupported configurations is not a valid reason to keep this install artifact.

Some users only have CD-ROM drives and the other images don’t fit

DVD technology is 25 years old. Do you really mean to say you are trying to install Ubuntu on a system which only has a CD drive, not a DVD drive; cannot boot from USB; and has a 64-bit CPU supported by the latest release of Ubuntu?

90

Maybe my arguments are ephemeral, but you are breaking user’s habbits by dropping mini.iso.
Forcing usage of Snaps smells like transforming Ubuntu to just another MS Windows 10 for home users, where user’s “rights” are very limited.

As you do not care, I’ll use mini.iso from old supported release and then upgrade it using sudo do-release-upgrade or by changing /etc/apt/sources.list manually from old-supported to new new-version. And run the process of installing tasks or standard Debian meta-packages.

1 Like
91

Do I understand it correctly that there will no longer be hosted vmlinux and initrd images?
If that’s the case, it breaks https://github.com/netbootxyz/netboot.xyz/.

How does one boot the live server installer via iPXE?

3 Likes
92

+1 I have this question as well.

2 Likes
93

I tried following these instructions , but most of the times when I try to perform the netboot, downloading the iso stalls, with repeated lines that look like:

ubuntu-20.04.1-live-server-amd64.iso   75% |*************       | 693M - stalled -

I’ve gotten it to succeed once, but it seems random when it reaches this point, and once it stalls it never seems to recover.

1 Like
94

Furthermore, when it does get past downloading the iso my autoinstall ds=nocloud-net;s=http://<ip-address>/<path> boot options don’t seem to do anything.

95

For the people still struggling with booting via PXE: I managed to get a working PXE setup for Groovy that runs the Subiquity installer with an autoinstall configuration.

I documented my findings in detail at https://askubuntu.com/q/1292032.

My solution can be used both for UEFI and BIOS systems and also mentions how to install a desktop system.

2 Likes
96

I’m sorry to have to say this, but the presence of netboot.tar.gz as well as netboot/ubuntu-installer/${arch}/{linux,initrd.gz} was one of the best things Ubuntu inherited from Debian, and one of the reasons why I encouraged the use and deployed Ubuntu on servers, workstations and VMs all over the globe.

It used to be super simple to bootstrap Ubuntu install, whether it was just a local PXE, workstation brought up from nothingness by simply loading linux & initrd.gz from EFI shell, or automating some very specific cloud image generation.

Good old times; one would simply need to load ~60 megs of stuff over the network or USB drive, perhaps choose an option or two in a super simple text menu that would actually get displayed on any device out there, from simplest serial-over LAN console to the most expensive display on most expensive GPU money can buy, or perhaps leave everything to options pre-configured in a simple text file, and voilà, there is your machine up and running, happily installing stuff while you do spend your time doing something non-trivial and slightly more important then clicking buttons on some GUI, rinse and repeat for each and every machine you may have to set up… And it worked in a same reliable and predictable way for what seems to be decade and a half?

It did not cost Canonical anything to keep this Debian feature. Actually, it seems to me that it must cost quite substantially more, in terms of network bandwidth wasted, to download all these ~900MB-ish bloated ISOs where it could have been just ~60 megs each time there is a new release of Ubuntu, multiplied by all install “locations”.

Oh, yeah, and it will also cost Canonical yet another loyal and influential customer lost, unless this is fixed by 21.10.

2 Likes
97

I agree - this policy is so annoying we’ve recently dropped Ubuntu org-wide - we do a lot of minimal installing on bare metal. In our use-case and it’s just not worth dealing with this sort of thing any more.
We’re far from inexperienced users and sometimes PXE booting is unsuitable, in fact, in our use-case it’s unsuitable about 2/3rds of the time.

I’m not sure of the motives for this - maybe some trendy attempt to rock the boat and lose some more traditional user-base or maybe alienate experienced users and drive inexperienced ones to their cloud products. Reading the blurb on the download pages they seem to want to sell you a managed cloud for thousands of dollars.

2 Likes
98

Ok guys, i’m in.

As i deploy 800 hosts, grouped by 40, i can’t tell to all my hosts to download a 900MB iso.
So i’m trying to nfsroot it.
See cmdline: https://github.com/eoli3n/vagrant-pxe/blob/dev/roles/ubuntu/files/script.ipxe#L4

Problem is that subiquity crash during install because of trying to apt update with cdrom source.
See https://bugs.launchpad.net/subiquity/+bug/1905296

So, ubuntu server iso should handle that case, and
if cmdline contains “netboot” var so, don’t use “cdrom” source.

I just reproduced, installer crashed then i check:
the file /cdrom/dists/focal/main/binary-amd64/Packages doesn’t exist
the file /cdrom/dists/focal/main/binary-amd64/Packages.gz does.

2 Likes
99

fyi, I started a script that can automatically generate a netboot directory from a given ISO - so far it supports amd64 UEFI/legacy arm64 UEFI:
https://github.com/dannf/ubuntu-server-netboot

4 Likes
100
  1. Wanted a quick up-to-date Ubuntu for my VM. Couldn’t find mini.iso. Found this thread.
  2. Decided to take your advice. Downloaded OVA (big) and then fed it to VMware (slow).
  3. Couldn’t log in. Searched and discovered I’d need a bunch of tools.
  4. Went to debian.org, pressed big “download” button on front page (quick, fast) fed it to VMware (quick) answered a few prompts. Was up and running in 10 minutes.

Please consider whether you’re losing something valuable with all the layers upon layers you’re adding.

1 Like
101

So I can’t get it work. I get the Bad mirror archive…

I copied the desktop live DVD to my pxe boot server.

102

Hello,

after years it turns out that it is actually easier to install Debian than Ubuntu. At least if one wants to perform custom install…

I wanted to install minimal Ubuntu 20.10 with openbox for my old laptop. I tried to be ambitious and follow instructions given here. As a plain user without any knowledge about networks, it took me many hours, and I didn’s even manage to start the installer.

Manual is very spare and one has to guess every single step:

  • first dnsmasq failed, I had to enable port 53
  • I had to allow this port in ufw (at least I think I had to)
  • from other site I discovered that correct catalogue for pxe.conf is /etc/dnsmasq.d and not /etc/dnsmasq.conf.d
  • from Debian wiki I’ve learned that I have to disable DHCP on my router
  • then my client got IP from my dnsmasq server, obtained files from tftp, but failed to connect to http://releases.ubuntu.com…
  • I’ve tried to edit /etc/hosts according to https://fedoramagazine.org/dnsmasq-provide-dns-dhcp-services/ , I also added dhcp-option=option:router to my pxe.conf, pointing to my router’s IP

Despite all of this, my client wasn’t able to fetch .iso file, and at least for now, I gave up trying.

From conversation I see, that Ubuntu’s devs idea was to block such tries as mine, to perform minimal installation, and limit users to default system installation. IMO that hasn’t got much in common with open source spirit. I guess I need to wait few months for Debian Bullseye. Ubuntu as an alternative for Debian Testing turned out to be too hard. Strange times…

Sorry for my English

Regards,
Paul

2 Likes