Squeeze Ubuntu down to a minimum???

GoogleGroups
1

Due to my last question I am now curious how much space is really required to run Ubuntu. The reason for asking is that I doubt, that I need most of the packages cause I wanna play around with WebServer, MailServer, FTP, etc. (I know ‘performance’, but that’s another issue I wanna skip for the very moment).I think, that as soon as I install packages like PHP, postfix, exim, etc. they will consume anyway a lot of space and I don’t wanna bloat the system with things I get for less amount of space (e.g. LXDE instead of GNOME). After reading Geralds response I get the idea, that reducing the size is possible, e.g. Amstrong uses around 1.2 GB, while Ubuntu-armhf+LXDE uses approx 0.9GB. I am aware that I might compare apples and oranges, nevertheless I am curious about it. AND I’m aware that below a certain point its ridiculous to discuss about (e.g. I don’t mind, if its 60MB or 54MB, although 10% difference). I think in chunks of 50MB which are worth discussing (MY point of view).

So my curiosity is what is a good starting point? Do I need cross compiling on a VirtualBox and then transfer it to the SD-card? Is it the best to start with omap-image-builder or sufficient to just start with the kernel-builder? Are they downloaded on the BBB or on a VirtualBox-image (running Ubuntu)? How can I flash them to the eMMC finally (when I installed my packages I wanted to have)? I follow mainly the BeagleBoardUbuntu but there it mentions as well the Raring 13.04 armhf and I have no real clue what’s the difference to the armhf-site for the end-result. ALSO what to do with things, I think they might be beneficial for everybody (e.g. following the NTP-settings I’m curious if I can configure ntpdate.service automatically so I don’t need to adjust it every time (resp. whom to suggest it?)).

Well anyway, I guess I’m mixing too many things up in different ways. But I try to get a foothold in the beginning and would highly appreciate some more insights. There are many loose ends I’m trying to bind together…

leo

2

I went the same way a couple of months ago. First I downloaded the image of Ubuntu ARM Core (the least possible image of ubuntu I guess) and then started to struggle with absent packages by searching and installing them. Eventually I realized that the best way was to install an image from Robert Nelson at eewiki

3

Forgot to mention that the final image is about 600M

4

Thx for the response. At least that’s a clear statement out of your experience.

Maxim Podbereznyy lisarden@gmail.com schrieb:

5

There are 2 issues with space.

One: How big is your kernel file. As this is the guy that gets loaded into memory when the system boots, getting stuff out of it gives you a big performance boost. To cut down on space there, when you compile a kernel try change the compile options from * to M for everything you can. M means it is stored in a module on the disk drive instead of in the kernel image file - so stuff that is not loaded will not bloat size. There are a number of things that should not be moved even though they can be - for example you don’t want to move your serial drivers to a Module because then you won’t be able to get debug info out of the serial port while the system loads[correction: you will, but it will be much further along in the boot process after the module is loaded from the file system].

Two: Hard disk space. If your planning on installing a basic LAMP system, I find it’s not really worth the effort to remove stuff because much of what you remove will end up being re installed as dependencies for Apache, MySQL, or PHP. One of the reasons I prefer Ubuntu to most other platforms for servers is that it comes with: 1) more recent versions of PHP and other packages and 2) many of the dependencies that I end up having to hunt/track down on debian, centos, etc are included in Ubuntu.

Note: this is purely from a server perspective. It does not apply for the UI. I try to avoid installing any UI and do things from the command line.

6

Two: Hard disk space. If your planning on installing a basic LAMP system, I find it’s not really worth the effort to remove stuff because much of what you remove will end up being re installed as dependencies for Apache, MySQL, or PHP. One of the reasons I prefer Ubuntu to most other platforms for servers is that it comes with: 1) more recent versions of PHP and other packages and 2) many of the dependencies that I end up having to hunt/track down on debian, centos, etc are included in Ubuntu.

Hm’, I’m little bit surprised to see that in the given distro of Robert an already running Apache. The surprise is cause I’m finally not sure, if I really wanna use Apache resp. MySQL due to performance considerations (e.g. LiteSpeed, lighttpd).

Note: this is purely from a server perspective. It does not apply for the UI. I try to avoid installing any UI and do things from the command line.

Well, that’s as well an approach :slight_smile:

7

funny to see other persons ask same question as myself. Anyway thx for the responses.

I reviewed the installation scripts from Robert and disabled some of the modules I’m currently not using (e.g. WLAN-modules). So, the current size is about 462MB (without enabling X nor LXDE). I guess that’s really a matter ‘What you want? AND what are your requirements?’ For the very moment I’m happy with that size of image, cause I guess this will expand in near future quickly…

The responses I got here were fine in sense of rethinking my approach. Thx.

8

My perspective is that I have to start somewhere, and anything other than Apache + MySQL + PHP 5 under mod-php is a chore. It’s not a bad chore, but I have found that there are little nits and changes for every single alternative configuration where small changes between versions can end up with some headaches of figuring out what to do.

On a server for a client my preference is for Apache with mod_rewrite + MariaDB + PHP 5 under fastcgi. For all it’s faults, open source PHP apps tend to assume a functional mod_rewrite system to provide Search Engine Friendly links - while this CAN be translated to a different configuration on other servers - my goal with freelance consulting projects is to walk away when their down secure in the knowledge that I have not made myself a dependency if the client ever decides to upgrade something.

On a server where I am going to be supporting it long term, I tend towards nginx + MariaDB + PHP 5 under fastcgi.

For an embedded system, I am considering that long term I may switch to either:
PHP5 with EMBEDDED mysql using the built in HTTP server. This wraps everything into one single installation package. The downside here is that MySQL is only accessible via PHP, there is no seperate mysql server which can accept connections. Another downside is that the built in HTTP server in PHP is designed for testing, so it doesn’t deal well with high volume traffic. However since I would not dream of running a high traffic website on a BeagleBone Black - it doesn’t really matter that it doesn’t do high volume.

Alternatively, uWSGI might be fun to use here. https://github.com/unbit/uwsgi-docs It has a plugin for PHP5 and standardizes everything to use the WSGI interface. What’s more, it has support for using .htaccess files built for Apache’s mod_rewrite - so it means easy SEF friendly links.

9

My perspective is that I have to start somewhere, and anything other than Apache + MySQL + PHP 5 under mod-php is a chore. It’s not a bad chore, but I have found that there are little nits and changes for every single alternative configuration where small changes between versions can end up with some headaches of figuring out what to do.

On a server for a client my preference is for Apache with mod_rewrite + MariaDB + PHP 5 under fastcgi. For all it’s faults, open source PHP apps tend to assume a functional mod_rewrite system to provide Search Engine Friendly links - while this CAN be translated to a different configuration on other servers - my goal with freelance consulting projects is to walk away when their down secure in the knowledge that I have not made myself a dependency if the client ever decides to upgrade something.

On a server where I am going to be supporting it long term, I tend towards nginx + MariaDB + PHP 5 under fastcgi.

On the BBB this currently no real alternative, namely MariaDB is not available under armhf. I checked the sources and the prerequisits are quite high:

Even on a fast connection, expect to need 1-2 GByte of RAM and possibly several CPU hours for the checkout.

So, MariaDBs somehow a No-Go.

For an embedded system, I am considering that long term I may switch to either:
PHP5 with EMBEDDED mysql using the built in HTTP server. This wraps everything into one single installation package. The downside here is that MySQL is only accessible via PHP, there is no seperate mysql server which can accept connections. Another downside is that the built in HTTP server in PHP is designed for testing, so it doesn’t deal well with high volume traffic. However since I would not dream of running a high traffic website on a BeagleBone Black - it doesn’t really matter that it doesn’t do high volume.

The embedded mysql gives me little headache, cause I though you need to configure MySQL anyway who access from which client. Or do you mean with EMBEDDED MySQL already an sql-server only accessible through localhost? Or the php_mysql?

Well, the performance I see anyway as a different issue due to the design architecture of the BBB.

Alternatively, uWSGI might be fun to use here. https://github.com/unbit/uwsgi-docs It has a plugin for PHP5 and standardizes everything to use the WSGI interface. What’s more, it has support for using .htaccess files built for Apache’s mod_rewrite - so it means easy SEF friendly links.

From your response I realize my approach to have some little Web-Server (+ some extra stuff) shifts more to some standard-components. AND I guess the space provided (2GB eMMC) seems sufficient for a nice start… With your last hint reg. uWSGI I think my learning curve is quite steep to have finally a Web-Server/Mail-Server running the way I would like to have… Anyway thx for the hints resp. your perspective.