I’m not especially familiar with UEFI netboot, but it should be possible to boot the live server installer this way. Have you tried that?
It’s definitely something we need to document properly.
Yes, Cobbler won’t properly import the Ubuntu Live image (it has to import the .iso image). My guess is that it’s expecting to serve up files where the Ubuntu Live image wants to hand out a url…I’ve got a separate question open to the cobbler user forum over this, but in the past, the answer with Ubuntu has always been “don’t use the live CD!”
Ah, I’ve no experience with cobbler unfortunately.
Providing the mini.iso for so long automatically implies that it was supported. As you can see in this thread that it was a very popular method (I myself am affected as I have been using it since 2010). Lets face it, the removal of it affects a lot of users and its overall a bad idea and Canonical needs to listen more to the communities requests. I am switching to debian for now.
1 Like
Hi All,
I follwoed the OP and manged to PXE boot the liveCD, this is installing onto a Virtual Machine, but during the installer i get an error
'2020-06-26 12:09:31,765 ERROR root:39 finish: subiquity/InstallProgress/curtin_install: FAIL: Command '['systemd-cat', '--level-prefix=false', '--identifier=curtin_log.16470', '/snap/subiquity/1772/usr/bin/python3', '-m', 'curtin', '--showtrace', '-c', '/var/log/installer/subiquity-curtin-install.conf', 'install']' returned non-zero exit status 3.
2020-06-26 12:09:31,765 ERROR subiquitycore.controller.installprogress:134 curtin_error
Traceback (most recent call last):
File "/snap/subiquity/1772/lib/python3.6/site-packages/subiquity/controllers/installprogress.py", line 307, in install
await self.curtin_install(context)
File "/snap/subiquity/1772/lib/python3.6/site-packages/subiquity/controllers/installprogress.py", line 91, in decorated
await meth(self, subcontext, *args)
File "/snap/subiquity/1772/lib/python3.6/site-packages/subiquity/controllers/installprogress.py", line 287, in curtin_install
self.logged_command(curtin_cmd), check=True)
File "/snap/subiquity/1772/lib/python3.6/site-packages/subiquitycore/utils.py", line 85, in arun_command
raise subprocess.CalledProcessError(proc.returncode, cmd)
subprocess.CalledProcessError: Command '['systemd-cat', '--level-prefix=false', '--identifier=curtin_log.16470', '/snap/subiquity/1772/usr/bin/python3', '-m', 'curtin', '--showtrace', '-c', '/var/log/installer/subiquity-curtin-install.conf', 'install']' returned non-zero exit status 3.
2020-06-26 12:09:31,766 INFO subiquity.core:438 saving crash report 'install failed crashed with CalledProcessError' to /var/crash/1593173371.766197443.install_fail.crash
has anyone got this or have any suggestions
Hi,
I have several question
-
The mini.iso doesn’t work for focal at the moment since there is a kernel update in the repo and the mini.iso didn’t get updated. Please provide an update for the iso.
-
Why would it be dropped? We just want to build our custom iso for our remix, desktop amd64 image, on top of netboot install. That’s what is recommended in the wiki. We don’t want server iso since it is over 800 MB and netboot iso is just 70MB. It doesn’t make sense to use server.iso for desktop remix in the first place. So my question is
Does Ubuntu discourages people building custom remix iso on top of Ubuntu ? If so why ? -
My second question brings the third point. AFAIK mini.iso is created simply executing a script, getting kernel, generating inirtd, compressing file system and all that. Is it possible to generate the iso on my local system ? Actually I don’t even need the iso, only tar.gz so that I can boot directly boot it from hard-disk.
I found several old guide based on debian but not a single one on Ubuntu. Can you provide a small guide for Ubuntu?
If it is feasible may be community can take it over and continue providing mini.iso.
Thanks.
2 Likes
Where in the Ubuntu wiki do you find this recommendation?
It certainly doesn’t, but neither does the mini.iso, so I’d like to know where this is written and fix it since that is not a method that I’m aware has ever been endorsed by the Ubuntu development team.
We do not discourage this, but there are other methods for doing this customization. LiveCDCustomization - Community Help Wiki
It is built as part of the debian-installer package build. The debian-installer package is not going to be supported by the Ubuntu archive in groovy and forward.
The error you posted tells us no more than that the install failed unfortunately. Can you post more of the output?
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:
- does not want to assume the liability for
mini.iso, - wants to sell product or services that are negated by
mini.iso, and/or - 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