Re: APEX, NSLU2, skip stuff

[Martin Michlmayr <tbm@cyrius.com>]

* Marc Singer <elf@buici.com> [2006-08-13 15:27]:
> Then the absence of apex-setenv *is* a show stopper for release

Well, yes and no.  It would certainly be nice to have but there are
work-arounds, so it's not necessarily a show stopper for the release.
The big question is what you understand under release anyway.  There's
still some time until the release of the next verions of Debian, but I
was mostly talking about an initial release of APEX to the Debian, and
for that's it's certainly not a show stopper.  Basically, I just want
an initial, working copy of APEX in Debian so I can prepare the build
environment, and then you can always upload another version of APEX
with apex-setenv before we move this into production use.

> I am also curious about the user's options for recovery.  If he
> wants to change the boot device or if he loses access to his system
> and has to reflash *something* to recover, what would that look
> like?  Should he reflash the installer?  Are there some recovery
> tools available there?

A bit of historical overview:

Initially (as of beta2), I provided 2 images: one to start the
debian-installer, and one which allows you to boot from /dev/sda1
(hard-coded).

As of beta3, (thanks to Joey) you boot into debian-installer and it
will generate a proper initramfs which hard-codes your boot device and
then writes it to flash.

So at the moment, recovery can either be: boot into debian-installer
and then mount your disk and fix it, or take the image I provided as
of beta2 that'll boot from sda.  The latter option might go away, but
given that we now have a script which generates and flashes an
initramfs, you can simply boot into debian-installer, chroot to your
disk and then run that script.

In the long-term, Rod suggested to keep a copy of both the initramfs
to boot from disk and debian-installer in flash.  The user could then
interrupt APEX and tell it to load ramdisk2 instead of ramdisk (or
'rescue' or whatever).  This is definitely post-etch though since the
current initramfs is huge (it contains glibc/busybox - work is
underway to get rid of this though).
-- 
Martin Michlmayr
http://www.cyrius.com/