[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Lower memory install tip (example from yesterday's meeting)

Lower memory install tip (example from yesterday's meeting)

Got an installation that's a bit intensive on memory, struggling with /
not quite making it through the installation on account of that?
But ... the distribution/installation itself is (semi-?)reasonable as
far as (virtual) memory goes ... at least once it's been installed?
Installing from ISO image on USB flash?
But the flash is fair bit bigger than the size of the ISO image itself?
Well, try adding, early in the installation process, some swap on that
USB flash!

E.g. Kubuntu (or Ubuntu) 16.04.3 LTS amd64 - struggles (at best!) to
install from the (standard) Live DVD on a system with "only" 1 GiB of
RAM(!).  But it does run (semi-?)reasonably once installed (and with
swap also configured and available).

So ... when installing, quite early in the procedure - before kicking
off the install proper (before clicking or double clicking the desktop
icon to kick off the install) ...
open up root session on text virtual console, e.g.:
login (e.g. kubuntu)
become root (superuser, UID 0), e.g. via sudo.

examine and determine the disk/flash devices, e.g.:
# blkid /dev/sd?
/dev/sdb: UUID="2017-08-01-12-29-51-00" LABEL="Kubuntu 16.04.3 LTS amd64" TYPE="iso9660" PTUUID="626b608f" PTTYPE="dos"

Note the device that has the ISO image - /dev/sdb in our example.

Make note of the size of the ISO image - you'll need that information:
$ ls -on kubuntu-16.04.3-desktop-amd64.iso
-r--r--r-- 1 0 1599602688 Aug  1 12:29 kubuntu-16.04.3-desktop-amd64.iso
$ curl -I -s http://cdimage.ubuntu.com/kubuntu/releases/16.04.3/release/kubuntu-16.04.3-desktop-amd64.iso
HTTP/1.1 200 OK
Date: Mon, 27 Nov 2017 14:43:55 GMT
Server: Apache/2.4.18 (Ubuntu)
Last-Modified: Tue, 01 Aug 2017 12:29:59 GMT
ETag: "5f580000-555b04e41cadd"
Accept-Ranges: bytes
Content-Length: 1599602688
Content-Type: application/x-iso9660-image

Either way, we note the size (in bytes): 1599602688 - be sure you're
checking the ISO that precisely matches what's on the flash.

Now create a loopback device that starts on that USB flash immediately
after the ISO image, and also (optionally) set a size(limit) for it:
# losetup --show -f -o 1599602688 --sizelimit 1073741824
And note the loop device it shows as output (if for any reason you
don't see that, use:
# losetup -l -a
to determine the created loopback device (it should have the correct
offset that we set, and sizelimit if we set that, and correct underlying
Note that we gave an offset (-o option) precisely matching the size of
our ISO image.
In our example, we set a sizelimit of 1 GiB (expr can come in
handy, e.g.:
$ expr 1024 \* 1024 \* 1024
This was chosen as it matched our physical RAM (ample for swap), and was
less than the remaining space on the USB flash (didn't need it all).  If
the remaining space on the USB flash is less than the size of physical
RAM, one may want to omit the --sizelimit option and option argument.

And what if you're not sure of the size of the USB flash device?
$ cat /sys/block/sdb/size
(or whatever your USB flash device is - sdb in our example)
that output gives you the size in 512 byte blocks

Now format that USB flash space for use as swap, and activate it:
# mkswap /dev/loop1
# swapon /dev/loop1

That's it.  One can verify the swap is active with, e.g.:
swapon -s
Then just proceed with the installation as normal (e.g.
<Control>-<Alt>-<F7> to return to the ewey GUI console and then click
or double-click the install icon to kick off the install proper).

In example case done yesterday, swap usage went to over 600 MiB before
the installation (successfully) completed.  So having the added (virtual)
memory (swap) was important ... the installation attempts otherwise
slowed to absurdly unresponive/slow/locked.  Use of free early on
provided essential clue that we were relatively starved for (virtual)
memory - hence decision was made to (temporarily) add swap while

Or, of course :-), one can use an installer/(distribution) that doesn't
suck so bloody much RAM, e.g. the Debian installer, found of course on
the Debian distribution and used by default there, and also ... well,
the various *buntu flavors used to put out an "alternate" installer
CD/DVD image - which used the Debian installer, with a few *buntu
flavored tweaks such as color scheme ... looks like they're no longer
doing those in general, however their "server" install images still use
the Debian installer.
*buntu's current recommended minimum RAM: 2 GiB
Install Type    RAM (minimum)   RAM (recommended)
No desktop      128 MiB         512 MiB
With Desktop    256 MiB         1 GiB

You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug+unsubscribe@googlegroups.com.
To post to this group, send email to berkeleylug@googlegroups.com.
Visit this group at https://groups.google.com/group/berkeleylug.
For more options, visit https://groups.google.com/d/optout.