Re: LMDE Live-Process/Installer
On 09/15/2010 05:30 PM, Ikey Doherty wrote:
> Hi there,
> 1) Build Time
> Initially we start with an expert Debian Testing install (weekly builds)
> to an extra partition, once installed we make absolutely no customisations.
> Using rsync from another instalation we clone the entire install into
> a working directory, ensuring not to copy /home /dev etc.
> All of our work is done inside of a chroot environment, making sure
> to keep the future medium as clean as possible. Once we're ready to
> make the system "live" we install the live-initramfs,live-config etc.
> packages from the live project.
this sounds like an awfull lot of work. have you read about live-build
already? it's a bunch of shell scripts that operate on a configuration
directory (which holds all sorts of information, such as what
distribution to bootstrap, what packages to install, etc.).
the benefit of using it is to have a totally automated and unattended
process, as well as reproducible builds.
if you're interested in knowing more about that, i'm happy to give you a
hands-on introduction through IRC.
> However we ran into a fair amount of
> bugs to begin with, such as no creation of the live user. We worked
> against the bugs by editing /etc/passwd to omit the password, generate
> the user ourself and edited /etc/live.conf to match. Other errors were
> encountered such as /etc/hosts, so a lot of the "automatic" stuff was
> done manually. Other files such as /etc/gdm3/daemon.conf also had to
> be manually modified to allow automatic login with gdm3
those were all bugs that we had with live-initramfs during the phase
where ftp-master did not process our uploads to the NEW queue for
several months, so that the fixed live-boot+live-config did not make it
to the archive. i'm sorry to hear that you were hit by those.
we do however have a repository on live.debian.net/debian that contains
the git snapshots of live-* packages to allow us testing our own stuff,
as well as circumwenting ftp-master in the cases where we're grounded by
the new queue.
> We switched the initrd to use LZMA, and opted out of the default ISO
> layout required by the live scripts, instead emulating the same layout
> used by standard Mint ISO's (/casper as opposed to /live). This gave
> us two things, compatability with mintConstructor and compatability with
> unetbootin. Obviously our isolinux.cfg was modified to support live-media-path
> being altered. After that we spun the ISO as normal with mkisofs on a iso9660
i'd very much like to see if you switch to using live-boot and
live-config instead of casper, not just because it's faster and better
extensible, but because i believe the support situation is better
regarding fixing bugs. also, in the middle to long run, ubuntu will
switch to using live-* instead of casper and liverootfs.
did you patch or modify casper in any way, or did you basically go with
a stock version from ubuntu? if the latter, changing to live-* is done
in a matter of minutes.
i don't know about unetbootin (never used it; what are the problems when
using live-* with it anyway?), but mintConstructor should be easily be
patchable for looking in /casper and /live.
> 2) Run Time
> A lot of boot-time configurations are handled for us by the live-config
> packages (and co.) provided by Debian Live, as I've previously stated there
> were some bugs we had to initially protect ourselves against. As for the whole
> "automatic" process of generating an autologon, we done a lot of that ourselves
> by preconfiguring our files.
i think all bugs you're refering to should be fixed. for any
changes/extensions etc, i'd be happy to integrate all of them into
note that we're supporting explicitly distribution specific changes, so
that all config scripts can rely in the source tree, but at build time,
the package only installs those scripts that are usefull for that
specific target distribution, e.g. if the package is build on squeeze,
we dropp lenny legacy scripts and ubuntu only scripts. so adding mint
specifica is welcome :)
> 3) Install Time
> Our live-installer takes much the same approach as most modern installers.
the name is a bit unfortunate. did you know that 'live-installer' in
debian is taken by the .udeb that allows debian-installer to install a
live system to the target, instead of bootstrapping one from .debs.
> We had considered porting Ubiquity for the purpose, but that proved nigh-on
> impossible, so we took the from-scratch approach. The installer is completely
> implemented in pure Python (2.6) with minimal dependancies, making it suitable
> for use in other distributions. Our eventual goal is a live-installer generic
> and configurable enough not to be tied to one specific distribution.
ubiquity is the wrong way to go, i fully agree. however, no offence, i
think writing a new one instead is too.
imho the right way to do it, and that is what we're persueing since
quite some time, is to use debian-installer directly for this.
that way, we don't have to support anything ourself. if you install a
regular debian, or a debian from a livecd, just looks and behaves the
same and is working on all architectures with all strange features and
during last debconf, we made a small wrapper ready so that d-i can be
called from the desktop, presenting its gtk frontend as a 'normal'
application. this, together with some preseeding, is imho the best and
most reliable way to install a live system.
(note: currently d-i is a bit broken due to other issues before the
release, they should be fixed in some time.. otherwise i would have
shown you screenshots or a demo image to have a look at).
> 4) Obtaining LMDE and live-installer
> If you wish to test LMDE, the latest ISO available for download is at:
> If you wish to test/fork/otherwise use the latest live-installer:
i'm downloading it right now and having a look at it. will probably come
back with some more things :)
> If anyone has any more questions regarding the live-installer or the process used
> in creating the live-medium (I can port my documentation) then I'd be happy to oblige.
> I know that Clement Lefebvre and myself are very grateful for the work that the Debian
> Live project has done, and for the Debian base itself.
Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist