:: Re: [DNG] Unofficial Devuan live im…
Top Page
Delete this message
Reply to this message
Author: KatolaZ
Date:  
To: Steve Litt
CC: dng
Subject: Re: [DNG] Unofficial Devuan live images
On Fri, May 13, 2016 at 02:06:27PM -0400, Steve Litt wrote:
> On Fri, 13 May 2016 06:59:37 +0100
> KatolaZ <katolaz@???> wrote:
>
> > please try the iso linked from http://devuan.kalos.mine.nu
>
> ====================================================
> However, due to the size of the ramdisk used at boot time, 256 MB of
> RAM are currently necessary to boot.
> ====================================================
>
> That's messed up. Your subdistro runs in 37MB of RAM, but the initramfs
> requires 256MB. I'd suggest adding another initramfs that assumes a
> no-encryption, no-lvm ext4 root partition, and does nothing but get
> that root partition mounted.
>
> I bet you can put it on even more of a diet if you use busybox to do
> most of the work.
>


Steve, I cannot (and I don't want to) make any assumption on behalf of
potential users of a minimal live system :) The initramfs contains all
the modules shipped with the standard Devuan kernel, that's why it is
so fat. In fact, "du -ch /lib/modules/`uname -r`/kernel" says that
those sum up to 159 MB, which account for most of the space required
by the initramfs.

Now, it is obviously possible to strip it down to the bare minimum,
removing most of those modules, but then the corresponding live
images, which should run, by definition, on a relatively wide number
of machines, with heterogeneous hw configurations, will be mostly
useless.

Imagine a case in which you, the user, would like to boot from a live
image, e.g. for rescue purposes, only to find out that your live CD
does not recognise your disk controller, or your graphic adapter, or
your ethernet card. Well, that image might be perfectly slim, and
optimal, and everyting, but completely useless if it cannot help you
performing the rescue task...

I am interested in finding possible solutions to this problem, but I
am unable to find one that makes more sense than the current one.

One possibility is to create your own image containing only the
modules needed by your machine, but this is not a solution which works
for everybody. I could have done that, and in that case those images
would have run only on relatively recent lenovo laptops. Period. You,
and most of the others, would have complained that I had to consider a
wider number of hw configurations. Specifically, each person would
have complained about the fact that *his* or *her* own hardware was
not supported...

Another possibility is to decide which sets of modules can be removed,
but then you will still have unhappy users, namely those who possess
hardware for which we don't provide a kernel module.

Compiling everything into a static kernel is not a viable option
either, IMHO.

I am open to comments and suggestions on this matter, but please do
not forget that a live image does not know in advance where it will be
run, or for which reason.

HND

KatolaZ

--
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]