
RFC: Ubuntu 18.04 LTS Minimal Images - pella
http://blog.dustinkirkland.com/2018/02/rfc-ubuntu-1804-lts-minimal-images.html
======
fotcorn
I did a short comparision between this and alpine by installing nginx inside
the image (I used nginx-light inside ubuntu):

    
    
      CONTAINER ID    IMAGE           SIZE
      493450e7bc12    alpine          1.37MB (virtual 5.52MB)
      62b1db90500c    ubuntu:bionic   6MB (virtual 87MB)
    

I deleted the cache files from apt after installing (/var/lib/apt/lists*)

Looks quite nice, but it seems Ubuntu packages are much bigger than Alpine
package, e.g. Postgres is 159 MB in Ubuntu Bionic and only 32 MB in Alpine
(including dependencies). Do the Ubuntu packages have more feature than the
equivalent Alpine packages?

~~~
petre
Alpine is compiled against musl libc, so the binaries are much smaller. Id
addition to tgat, it uses Busybox.

~~~
anarazel
I can't imagine that to be one of the more significant factors in this case.
It's much more likely that the ubuntu version includes a lot more
functionality. Just looking at the configure flags: Alpine: --with-ldap
--with-libedit-preferred --with-libxml--with-openssl --with-perl --with-python
--with-tcl --with-uuid=e2fs Debian: \--with-icu --with-tcl --with-perl --with-
python --with-pam --with-openssl --with-libxml --with-libxslt --enable-nls
--enable-integer-datetimes --enable-thread-safety --enable-tap-tests --enable-
debug --disable-rpath --with-uuid=e2fs --with-gssapi --with-ldap --with-
selinux

Specifically the differences in enabling ICU (portable collations) and nls
(i.e. translations) alone are probably going to be the majority of difference
in installed size.

------
segmondy
Did most of you read the article? I see folks suggesting what can be removed.
They can't do that.

"The Ubuntu Minimal Image is the smallest base upon which a user can apt
install any package in the Ubuntu archive."

~~~
kstenerud
From the article:

"Do you see any other opportunities for savings? Can you help us crop the
Bionic Beaver images any further? Is there something that we've culled, that
you see as problematic? We're interested in your feedback"

~~~
braindongle
"Crop the beaver"? Seriously? It also says "Shave the beaver"! Is it me? Is
this thinly veiled high school innuendo?

~~~
kuschku
Ubuntu uses animal names as codename for releases.

After Artful Aardvark now follows Bionic Beaver.

~~~
isostatic
Breezy Badger being already used (before they moved to incrementinf letter
based system - having done hoary hedgehog and waryy warthog.

It wasn't until the first LTS version, dapper drake, that the letters started
matching the release number. The second LTS, or 8th release overall - Hardy
Heron, in April 2008, was the second "hh" version.

Shockingly we still have 6 hardy heron boxes on our network in far flung
locations.

------
matt_wulfeck
The problem with these 30 MB images:

    
    
        apt update -y
        apt install -y telnet
    

Now you have a 200 MB image.

~~~
gerdesj
I think you miss the point but feel free to provide feedback to the devs: this
is a RFC after all.

I have used the minimals for years now and they really do give you a pretty
decent starter for 10, with a minimum of hassle and a minimum of bloat. Boot
the ISO (PXE, obviously) and off you go.

Even doing the install by hand, you get a _fully_ patched basic server up and
running within 10-20 minutes - the install is all off the current packages.
Add Samba and a few copy n pastes and you have AD joined. A few more copy n
pastes from your docs and you have an app server.

I wrote this lot:
[https://www.mediawiki.org/wiki/Intranet](https://www.mediawiki.org/wiki/Intranet)
which simply assumes Ubuntu mini at the moment. I do have screenshots and
could put together a pretty noddy guide for that bit but I'm not sure its
necessary. Actually now I come to think of it, it probably is. Couple that
with my Ref. build and you have a domain joined, Kerberized etc app server
within about an hour if you do the job by hand and are unfamiliar with the
process. I can do it rather quicker.

Yes, the installer is a 30MB image - good. An installer's size is no
reflection on the installation size.

EDIT: I am from the sysadmin side of things and not dev ops ...

~~~
dsr_
Sysadmin/devops is a nearly meaningless distinction. When a developer needs to
write installation or configuration code, they cross over. When a sysadmin
needs to write code to monitor applications, they cross over. Senior sysadmins
need to write more code, senior developers need to know more about systems and
networks.

Twelve years ago, I hired senior sysadmins. About seven years ago, I hired
senior devops. Same people, same skill sets, same approach.

~~~
gerdesj
"Sysadmin/devops is a nearly meaningless distinction"

It should be as you say but it isn't really. I too hire and fire. To be honest
"dev ops" should not really exist but has become a thing. Many who describe
themselves as such do not bother with the nuts and bolts. To be fair to them,
though, quite a few sysadmins I've known are a bit slack on the networking
side, for example. _sigh_

------
KingEllis
I have feedback on the Ubuntu 18.04 LTS Cloud Image that I am hoping reaches
the right ears.

There is something about the way the disk is partitioned that makes the use of
virt-resize no longer work (as it does for 16.04).

Specifically, I am referring to: [https://cloud-
images.ubuntu.com/bionic/20180124/bionic-serve...](https://cloud-
images.ubuntu.com/bionic/20180124/bionic-server-cloudimg-amd64.img)

The boot partion looks to be sda14 or sda15. But judging from the output of
virt-resize, it appears that although these are sda14/15, they appear in front
of sda1. (When virt-resize is run on sda1, sda14 becomes sda1, sda15 becomes
sda2, and sda1 is now the resized sda3, and grub is confused.

    
    
      $ virt-filesystems --long --parts --blkdevs -h -a bionic-server-cloudimg-amd64.img 
      Name        Type       MBR  Size  Parent
      /dev/sda1   partition  -    2.1G  /dev/sda
      /dev/sda14  partition  -    4.0M  /dev/sda
      /dev/sda15  partition  -    106M  /dev/sda
      /dev/sda    device     -    2.2G  -
    
      $ virt-resize --expand /dev/sda1 bionic-server-cloudimg-amd64.img bionic0.qcow2
    
      $ virt-filesystems --long --parts --blkdevs -h -a bionic0.qcow2
      Name       Type       MBR  Size  Parent
      /dev/sda1  partition  -    4.0M  /dev/sda
      /dev/sda2  partition  -    106M  /dev/sda
      /dev/sda3  partition  -    25G   /dev/sda
      /dev/sda   device     -    25G   -
    

I am hoping this can be addressed before April, as I would prefer not to
maintain my own LTS image (that doesn't have this issue).

~~~
dustinkirkland
Thanks! I'll make sure that gets to the right team!

------
Afforess
My 2 cents, and possibly quite wrong: Is the ncurses packages really necessary
in the minimal ubuntu image? It seems likely that curses based programs should
be likely candidates for exclusion in a minimal image, as they are not usually
meant for automation.

Also, why are there still motd files in /etc/update-motd.d? No sshd but still
a motd? Odd.

~~~
Aloha
ncurses is required, debian-installer (which is used for all the configuration
dialog post install too) require it.

~~~
Daviey
You should be able to use readline rather than ncurses.. Or for dpkg, you
could also use the noninteractive frontend.

------
theandrewbailey
I've been using the MinimalCD images[0] to install Ubuntu for years. (They are
the minimum you need to boot, and they download everything else to install
Ubuntu.) I'm guessing that these aren't what's being talked about.

[0]
[https://help.ubuntu.com/community/Installation/MinimalCD](https://help.ubuntu.com/community/Installation/MinimalCD)

~~~
KayEss
I'd been doing the same thing for a long time (loved how fast it was compared
to the normal installer, especially in a VM), but the last install I did was
with debootstrap straight onto the target disk from another running machine. A
bit of a learning curve the first time, but I think I'll try it again next
time.

------
aplorbust
Not a Linux user but out of curiosity just looked at the "Trusty Tahr" 37MB
amd64 minimal image (mini.iso).

Most recent amd64 minimal image is 58MB ("Artful Aardvark").

Trusty Tahr bzImage compressed kernel is 5.5MB.

The initrd.cpio.gz is 20MB.

The uncompressed initrd is _52MB_.

Assuming most of the initrd size is modules, can the Linux user reduce the
size of the initrd by compiling own kernel and creating own initrd with only
the modules she needs?

~~~
subway
Or just ditch the kernel and initrd entirely. If you're trying to save a few
MB on an Ubuntu image, you're almost certainly working in a container
environment where you don't need a kernel inside the fs.

If you really do need a kernel, and the few extra MB required by modules is a
problem, you should probably be using Buildroot or Yocto for your
bootloader/kernel.

~~~
gerdesj
I don't think everyone is working within a container when they boot a Ubuntu
minimal, unless your containers happen to have a BIOS or similar.

These things are a full OS installer ie put it on a USB key, CDROM, PXE boot
or whatever. These are a minimal installer and not a minimal installation,
although that is a side effect - you don't get much out of the box but you can
add everything later.

You could, for example, do a minimal install and then do "# apt install
libreoffice" and with luck (not too sure) get the whole lot - X etc - to run
it. You might have to add a Window Manager and a few other things.

~~~
subway
I agree -- there are plenty of reasons to use a minimal Ubuntu install. My
point was that if size constraints are so tight that you feel trimming kernel
modules out is a reasonable use of effort, then Ubuntu starts to be a more
awkward fit. If you constantly have to trim away bits left by the package
manager (man pages, examples, extra kernel modules), your time is probably
better spent with a distro that allows you to avoid ever laying those into the
rootfs to begin with.

Also worth noting:these images _are_ full minimal root filesystems.
"installer" images refer to the images containing software --the debian/ubuntu
installer for bootstrapping a root filesystem onto a mounted volume. The
minimal images from thearticle do not contain this installer, and are
stanalone root filesystems.

~~~
secabeen
Yeah. To be more clear, you can install a "minimal" system of Ubuntu on bare
metal by just installing the "required" packages only, although I think the
default if you don't select any tasks in the installer is to install
"required" \+ "standard", which is a small amount more than just "required".
Either way, it doesn't include much. I have to install openssh-server on my
"nothing-but-standard" systems, before chef comes in and drags along another
1000 packages.

The installs the OP is talking about are images that don't even have a kernel,
and don't use the traditional installer.

------
LinuxBender
Somewhat off topic: Is there an effort similar to this for CentOS 7? The
centos minimal image is still rather large and I have to do some really ugly
things to prune it down. Even then I can not get it down anywhere close to 80
MB. That would be amazing.

~~~
anonacct37
It's been my experience that people are less open to hacking CentOS/RedHat.
It's pretty much you get what you get and changing anything makes it
unsupported which defeats the purpose of using an enterprise distribution.
That's not my opinion, it's what seems to be the community's opinion when you
bring up things like using non-stock kernels.

~~~
mastax
Seems like it would make sense to have a CentOS version of RHEL Atomic
Host/Fedora Atomic though? (I know nothing about CentOS)

~~~
emmelaich
[https://wiki.centos.org/SpecialInterestGroup/Atomic/Download](https://wiki.centos.org/SpecialInterestGroup/Atomic/Download)

------
butz
Would be nice if desktop Ubuntu images became smaller as well. I have a few
1GB USB drives just waiting for it.

~~~
dustinkirkland
Stay tuned :-) That's my next post...

------
verst
This could be smaller by removing compilers and build headers. If I'm not
mistaken I see GCC is currently part of this.

I would prefer to manually install build-essentials when needed (I can then
get rid of them after compiling via multistage builds).

Alpine Linux specifically makes you manually install compilers and necessary
headers via

    
    
      apk add --update build-base
    

EDIT: Make is not being installed by default. But I would like to manually
install GCC as needed (for a truly minimal image).

EDIT2: I stand corrected. Looks like GCC isn't installed by default (which is
exactly what we want for minimal images). Awesome.

~~~
roller
The gcc-7-base package (assuming that's what you're looking at) looks like
it's just an empty directory to put various gcc things and some basic docs.

[https://packages.debian.org/sid/gcc-7-base](https://packages.debian.org/sid/gcc-7-base)

[https://packages.debian.org/sid/amd64/gcc-7-base/filelist](https://packages.debian.org/sid/amd64/gcc-7-base/filelist)

~~~
verst
Thanks! I was looking at [1] and wasn't sure if those were binaries.

That's perfect then. Install GCC, compilers, build headers etc via `sudo apt-
get install build-essential` when necessary. So this should be the same
general approach as on Alpine.

[1]:
[https://pastebin.ubuntu.com/26506363/](https://pastebin.ubuntu.com/26506363/)

~~~
geofft
libgcc_s.so.1 is a collection of utility routines used by all sorts of
programs. The entry named "gcc" is a directory (that contains only empty
directories?). /usr/share/gcc-7/python/libstdcxx/ is from the libstdc++6
package (looks like gdb pretty-printers for C++ standard library types).

------
peterwwillis
I used to build embedded Linux distros for a hobby. The best, least
aggravating way to have minimal platforms is to build them from scratch. Not
only are they 10-50x smaller, you have more visibility over what's installed,
and it's easier to tailor to your use case.

~~~
revelation
Something like OpenWRT or buildroot can fit into 8 MiB easy. These people have
an actual reason to make small "containers" because flash is a big part of the
BoM cost and adds up when you are shipping many thousands.

------
mwj
If this is for deployment, why not just use debian slim?

~~~
make3
I suspect, though I could be wrong, that the reason would be that some
packages support Ubuntu specifically and not Debian, because of a larger
consumer user base. An important example of this is the Nvidia CUDA toolkit,
which supports Ubuntu and not Debian.

------
hodl
How big is templeos LTS minimal IMG?

~~~
hodl
16mb

------
pikchurn
Posting here rather than the blog because I don't have a google account:

What about adding sshd to the minimal install? If the purpose of this is
minimal installs of containers and cloud servers and such, that seems like
quite an omission.

~~~
acomar
This is supposed to run inside of a container. Why would you want sshd inside
of a container?

~~~
pikchurn
I use containers as lightweight VMs in many places. Generally I see this as a
way to get a minimal install that other tools can then configure
appropriately, with up to date packages fetched from upstream mirrors
directly, instead of installed from CD and then upgraded.

I currently use packer.io to script the creation of a bunch of server images,
and for ubuntu I've missed the "minimal install CD" that other distros have.
Instead packer has to download a 800MB CD image, in order to install only a
few hundred megabytes of uncompressed packages in a bare-bones install, which
is then provisioned using some orchestration tool that at its heart uses ssh
to login to the virtual machine.

Not having SSH means you need to add in some sort of serial-attach step to
manually install sshd, or hook into the install scripts to download sshd as
part of the install or whatever. Either way that's additional custom work that
is probably common to a great many use cases.

~~~
verst
So why not build your own version with a SSH daemon if you really need it? I
don't think most people need the SSH daemon in their container image.

Your Dockerfile could be something like this:

    
    
      FROM ubuntu:bionic
      RUN sudo apt-get install openssh-server -y && sudo service ssh restart
    
    

These are definitely not the complete steps for setting up SSHd but you get
the idea.

------
tomc1985
Wonderful, I've always hated how much crap a default Ubuntu install comes
with. 10% idle CPU usage just after OS install? Ewww.

~~~
Lev1a
How many DECADES old is your hardware that an idling just-set-up Ubuntu uses
10% CPU?

------
revelation
What is the obsession with smaller images? If you are running out of disk
space before CPU, RAM, IOPS, network, well there is a cheap fix for that.

~~~
geofft
Containerization - taking a deployment that previously was made of lots of
apps running on one OS on one physical machine (or a relatively generous
fraction of one, as a VM), and turning it into lots of apps each running on
their OS on top of the same amount of machine. Containerization significantly
increases disk usage for each container and probably increases RAM use a
little bit, but to first order does not affect CPU or IOPS or network.

~~~
revelation
I understand it is about containers. But no disk space of the world is worth
your container app crashing because someone wanted to save a few megabytes by
ditching glibc or otherwise just pushing more work into each and every
individual container. It's Java Enterprise all over, who cares it's always
allocating tens of GiB of RAM, you have to get to the point of buying a lot of
it before it makes an hour of an engineers time worthwhile.

