The mini.iso is a locally booted iso image. If you were using this before, I don’t see any reason why you would change to use a netboot setup instead of locally booting the current server iso. This thread is about how to netboot with the new installer, it is not saying that you have to netboot with the new installer.
I see. I couldn’t find the link to the new mini.iso file in the repository and read all that discussion about the lack of a mini.iso in this release. Could you provide the link?
I didn’t mention a new mini.iso file, I suggested using the current server iso (https://releases.ubuntu.com/focal/ubuntu-20.04-live-server-amd64.iso). The mini.iso has never been a supported method of installing Ubuntu.
We do still provide a mini.iso image for 20.04 at http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/legacy-images/netboot/mini.iso but expect to drop this in the 20.10 cycle.
Thank you for the link.
I really liked being able to select for my installation Just enough OS (JeOS) at the start of the old d-i based method. I don’t want all these “standard” base items from Ubuntu; I want a partitioned disk, default networking working, sudo capable user, and SSH server. Everything else I want to be able to add. This makes a much better foundation for making all those streaming/containerized/golden/cloud images that are touted. The alternative is taking the base installation and working too hard to rip out extra.
It can’t be much burden to maintain a choice that does less.
I have a need within my organization to make Ubuntu 20.04 work within our existing environment (a Cobbler server running on Redhat). I cannot do this without a netboot image-the mininmal image won’t boot on raw hardware into an efi environment.
I’m a huge supporter of Ubuntu normally, but I find myself very disappointed when Canonical makes these kinds of decisions that remove features that were provided previously…
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.
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
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.
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. https://help.ubuntu.com/community/LiveCDCustomization
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?
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).