So I have ran into the 2G limit. I have “REMOTE” machines I would like to install 20.04 on - I cannot add more memory. Its fixed at 2G forever. So the Big quesstion is “how” can I now install 20.04 on a machine with 2G ram ‘today’. I cannot use a mini.iso as it does not have the “autoinstall” install.
I have added the ramdisk_size=1500000 and root=/dev/ram0 but as you all know the issue still is present that the installer dies with out of memory.
Is there a way to TRANSFER on boot a cloud image and “expand” that disk to full size after reboot or something. Really surprised I ran into this wall. I have used CentOS for years - and never any issue like this. I am switching to Ubuntu because of all the CentOS stream stuff.
I just need a method using the new installer to install in 2G ?? How can I accomplish that ?
This thread is linked to by the netboot ISO download page – I only have a CD burner and don’t have spare USB drives. Setting up a PXE server to do something that’s only required a 700MiB CD for the past ten years seems a bit extreme.
Following the netboot here, tries to load the whole image into ram, for an ServerOS that has minimum requirements of 1GB of ram, not being able to install with 2GB of ram, is a bug, a regression, etc.
Certainly, and there are some gaps that have been identified in terms of our coverage of use cases, which is taken into consideration in the future roadmap. Identifying the gaps does, unfortunately, not translate to them being immediately resolved.
If it takes more memory to install than what is listed as the minimum requirements for Ubuntu Server, that is a bug. There are multiple install methods, and netboot has never been the one with the lowest memory footprint.
However, do you really have a physical server with less than 2GB of RAM? Or are you trying to install in a VM? We consistently recommend using boot-in-place cloud images, not server install images, for VMs.
Your coverage is completely wrong. You do not respect user’ habbits and all previous experience.
Please start mini.iso revival process. The 22.04 LTS should have mini.iso file in place! Please choose correct coverage in this aspect as soon as possible.
Ubuntu users have already answered why we/they use mini.iso in the poll created by me (33 voters, 198 answers). Please respect these demands. Do not forget that you create Ubuntu for users!
We use mini.iso for Unity remix and for every other minimal install including mate. Netboot is procuded by package debian-installer. It has build/config directory.
For example, the definition for amd64 images starts with config/amd64.cfg which, besides the current kernel versions, defines the media supported with the line:
MEDIUM_SUPPORTED = cdrom cdrom-xen netboot netboot-xen hd-media
We can simply remove others and keep only netboot. Then it runs make build_netboot to create the image in build/dest/netboot folder.
The issue is it uses udebs from repository and those udebs and the dependencies are removed in groovy and thus the build fails. These udebs are mostly static and pulled from debian. But if we can upload these to a different mirror or change the script it will work. Of course we need to match the kernel as well. The other option is to use local udebs as explained here https://d-i.debian.org/doc/internals/ch04.html
The build/sources.list.udeb contains
deb [trusted=yes] copy:/home/pcuser/debin-installer/debian-installer-20101020ubuntu614/build/ localudebs/
deb http://archive.ubuntu.com/ubuntu focal main/debian-installer
deb http://archive.ubuntu.com/ubuntu focal-security main/debian-installer
deb http://archive.ubuntu.com/ubuntu focal-updates main/debian-installer
deb http://archive.ubuntu.com/ubuntu focal-proposed main/debian-installer
deb http://security.ubuntu.com/ubuntu focal main/debian-installer
deb http://security.ubuntu.com/ubuntu focal-security main/debian-installer
deb http://security.ubuntu.com/ubuntu focal-updates main/debian-installer
deb http://security.ubuntu.com/ubuntu focal-proposed main/debian-installer
deb http://ddebs.ubuntu.com focal main/debian-installer
deb http://ddebs.ubuntu.com focal-updates main/debian-installer
deb http://ddebs.ubuntu.com focal-proposed main/debian-installer
As you can it pulls udebs from focal. May be we can change the script to pull those and use as localudebs. Then we can always upload the generated mini.iso, tar.gz somewhere.
Are you interested to discuss this on Ubuntu forums (we may need some help about changing the script and all)? If so please open a thread an put a link here.
I am currently building netboot on debian testing and I have no problem doing that. For Ubuntu it just needs minor changes.
This must be the worst misfeature ever. On top of that, previously we could just extract the ISO, copy that to a USB drive, and be done with it. Well not anymore! Now it just refuses to work. It will never boot. Just never. The only solution is to use the startup media creator or whatever the feck it’s called.
Well too bad that creates a read-only ISO9660 filesystem, so I have no effin chance to create my custom grub.cfg on the installer media!! What were you thinking? Why is it so darn important to you to make our lives harder? Why did you just HAVE to break this? Why doesn’t Ubuntu boot anymore by just copying the installer files? And for what purpose did you change this, seriously? What did you gain with this? Because we sure as hell didn’t gain anything, but lost quite a lot.
The Ubuntu images that we provide are just that: images. It has always been supported to directly copy the image to your install media (either a CD/DVD or a USB stick) and boot it. This works when you copy to a USB disk - NOT to a partition on the disk. The latter has never been officially supported, though in some configurations it would manage to work.
If there have been regressions in the behavior of copying the installer to a USB disk by any other method, this is not due to the transition to the live installer; it would be due to unrelated changes that have been made in recent cycles to provide the same boot experience for users on both UEFI (nowadays, most common) and BIOS systems. But these behavior changes should only affect BIOS systems anyway, which previously did not use grub at all (so editing grub.cfg would have had no effect).
For EFI systems, this would give you a stub grub.cfg in the EFI System Partition that isn’t normally how we configure the boot, but that you would be able to edit to taste. (The secondary grub.cfg is part of an immutable isofs, yes.)
If you are still experiencing difficulties getting the recent Ubuntu Server to boot in this environment, it’s best that you file a bug report against OpenID transaction in progress.
This new installer has been an unbelievable dumpster fire to convert to from the original installer, It’s taken me 3 days to actually get it to deploy without failing and I’m still struggling to get a 1:1 replication of the previous deployments. This new installer is horrible in comparison.
The hell I have gone through working with it so far aside, during debugging trying to get it working I was trying to find why it was stalling and taking so long to install.
When doing a netboot autoinstall It initially downloads the very large iso specified from the url kernel parameter (ubuntu-20.04.2-live-server-amd64.iso in my case) then continues to boot, loads the installer cd OS then downloads the entire iso again, and then downloads it a 3rd time.
Anyone else actually noticing this?
I tracked it down in the boot process to the cloud-init calls. it’s called during boot twice:
cloud-init init --local
cloud-init init
Each time it runs, it downloads the url specified from the url kernel parameter without validating if its a iso url first.
Having the iso end up downloading 3 times for a total 3.3gb makes netbooting install untenable.
how do you “revive” something that has never been supported ?
if you ever used the mini.iso you did not get an Ubuntu install but a Debian install-configuration on top of Ubuntu packages … it has never been a supported installation method in the last 17 years.
Then how about possibly providing a reduced size network based installer iso at least?
Having the ability to install a “supported” ubuntu configuration in a automated method or manually from nfs/smb file stores or from internet/local repositories is highly advantageous for pxe netbooting.
Can someone double check and confirm the issue I am seeing with the iso being downloaded 3x when doing a netboot autoinstall ?
I do not care about the support.
Please do not break the thing which was working normally for years. By dropping mini.iso you do not respect user habits. Is it ok for you? For whom do you really develop “Enterprise Open Source and Linux | Ubuntu”? Do you then plan to remove tasksel or maybe whole APT in favor of well-designed mature low footprint network-effective embedded-friendly Snap?
again … it was not working normally … mini.iso was waste … a by-product produced by the debian-installer build, it gave you a non-ubuntu installation method for ubuntu …
taking out the creation of mini.iso from the build would have required a huge set of patches which is why it was not removed from the build …
debian-installer has not been a proper, working, supported or tested install method for ubuntu since 12.10/13.04 times at all, it was required to be built for some udebs that Ubiquity (the graphical installer) used, which is why it was not completely removed back then …
if you used mini.iso to install you got some franken-buntu installation with a system configured in ways that might behave completely different from any normal ubuntu install and you seeing bugs nobody else sees …
if the habit is:
to shoot yourself in both feet …
cause countless hours of support in forums, IRC and askubuntu
cause lots of bug reports due to mis-configuration that wastes countless hours of (volunteering) developers
… should we really “respect” that and not instead prevent it ?
if you want to use mini.iso, by all means, install Debian with it, this is what it is designed for, this is what will give you a proper installation that acts as expected and not waste the manpower and support time of their community …
… if you want to rather be constructive, feel free to help improving the supported and tested install methods so it fits your use case …
This is inaccurate; debian-installer had been the sole supported install method for Ubuntu Server up until 18.04. But it was supported as part of the Ubuntu Server ISO and the netboot method. The mini.iso was never supported.
We are using ubuntu pxe to install ubuntu on our workstation, And upon adding ubuntu 21.04 netboot is no longer available on the new version and there is New Ubuntu Server Installer any idea on how to install it?