Netbooting the live server installer

Is there a trick to making PXE boot with the liveCD work when served from http(s) server? It doesn’t appear the build of wget used doesn’t support https…

Hi, welcome to the forum. https support was added to focal after release so it won’t work with the release ISO but should work with those from http://cdimage.ubuntu.com/ubuntu-server/focal/daily-live/current/. I admit I haven’t tried it though, so please let us know if it doesn’t work!

Do you know if pxe booting works with the autoinstall option? I keep getting brought back to the menu selection.

Also where is cloud-init pulling the user-data and meta-data files from? Is there a default somewhere that I missed?

thanks.

If you are installing onto a UEFI machine, you may be running into an issue where curtin changes the boot order during the install so that PXE is first

The user-data and meta-data file location is specified in the command line to the kernel.

I created a full PXE example at https://askubuntu.com/questions/1235723/automated-20-04-server-installation-using-pxe-and-live-server-image

I found the issue, it was a typo in my pxeconfig/default file. But thank you for the link it really helped yesterday.

We used Cobbler in the past, but we had a lot of issues with it because it makes a lot of assumptions about the structure of installers / images and is thus hard to adapt to new distributions.

For this reason, we developed our own replacement called “Vinegar” that you can find at https://github.com/KIT-IBPT/vinegar/ (just in case you are interested in alternatives to Cobbler).

Hello @mwhudson I just wanted to mention that the download link listed here in this guide no longer works. I believe that the correct new location is http://cdimage.ubuntu.com/ubuntu-server/focal/daily-live/current/focal-live-server-amd64.iso (using Focal in the URL instead of just daily-live) - can the guide please be updated?

1 Like

Ah good point, I’ve updated the URL to the release URL for 20.04.1.

Point one: It is a very bad move to kill the netinstall right before a final Release - a RC is a Release Candidate! Or does this means nothing anymore - so no testing should be done befor the final release? So the complete beta/rc cycle can be scrubbed all together. I assume that this was a move to break any resistance, because you knew very well that this is a very wide-used approach

Point two: The subiquity installer is, sorry, plain bullshit. I tried it several times - it always refused my partition scheme, and it is very ugly to use on TUIs. I used the mini.iso even on local installs to avoid the shitty so called “modern” installers - because d-i yust works flawlessly, in opposite of the half-backed ubuntu-created ones.

Point three: A 800 MB download only to get to the installer - loading the whole iso in a ramdisk?! Are you kidding me?

Point four: The netinstall can indeed be used with UEFI fine - with the described fix, or over netboot

Point five: Not only netinstall gets borked, but also debmirror. 20.04 can’t be mirrored fo a complete local install as on https://bugs.launchpad.net/ubuntu/+source/debmirror/+bug/1821251 . A system which I can’t install 100% without internet (incl. additional software from the repo) is utterly useless for me.

Point six: When get ubuntu healed from its “DIH” syndrom? I see absolutly zero advantage over the d-i installer. Only things which are caused from willful killing the d-i. The completely loughy point is that the “new shiny installer” can’t even do zfs (which can only be done by ubiquity). So there is not even code sharing between uniquity and subiquity!

If there is no classical netinstall when I do my next linux install class I’m forced to switch over to debian. Sorry, but I don’t have any other solution for me.

2 Likes

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

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

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

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

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.

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

1 Like

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?

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

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

+1 I have this question as well.

2 Likes

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