Re: apex-nslu2-1.4.14
On Sun, Feb 04, 2007 at 10:28:05PM +0100, Martin Michlmayr wrote:
> * Rod Whitby <rod@whitby.id.au> [2007-02-05 07:34]:
> > >> Assuming this build of apex puts the environment in the same block as
> > >> apex itself, are the debian scripts padding that block with FFs or
> > >> zeros? If the latter, that would explain it.
>
> I just padded it with FFs on my box and I can now successfully change
> the environment. Great work, Marc!
The
# apex-env eraseenv
does the right thing as well.
> BTW, there's nothing like /dev/zero for FFs. The best way I figured
> out to pad the block with FFs is with:
>
> perl -e "print pack('C', 0xff) x $pad"
>
> ($pad indicates the number of bytes of padding that are needed)
>
> > Yes, that's true. How often do you think people will be updating apex
> > without flashing a new image
>
> That's the typical use scenario imho. People will upgrade their
> Debian system, get new kernels, a new APEX and other packages... a new
> initramfs is generated and then written to flash together with the new
> kernel. This is what's happening already. What's still missing is to
> actually update the copy of APEX in flash when the apex-nslu2 package
> is upgraded.
>
> > On the other hand, when flashing a new apex, it might be a good idea to
> > reset apex environment settings (or at least making the user review
> > them) in case there are incompatible changes in the environment format.
>
> I guess if there really was an incompatible changes we could use
> debconf to tell the user and get appropriate new values (unless we can
> figure out it automatically). But usually, we should simply be able to:
>
> - get the values with "apex-env printenv"
> - write a new apex to flash with proper padding
> - set the old values
>
> > I wasn't sure whether we'd come up with a final decision or not - we
> > were waiting for some proof of concept experiments and the Debian
> > input to determine the pros and cons.
>
> OK...
>
> > I'm happy with it going in either spot. I've left room for it after
> > the microcode in the FIS directory area - we would just update
> > slugimage to use that area.
>
> ... I think that the APEX block is the right place for the
> environment. Putting it in the FIS directory is a hack and doesn't
> seem to gain us terribly much. In other words, I'm happy with the
> current implementation. The only thing we need to do in Debian is
> write a script that will actually write APEX to flash and pad it
> properly (and restore user settings). That shouldn't be too hard but
> is material for after etch.
Seems sane.
Reply to: