Re: dpkg divert in preinst scripts
On 13/04/10 11:35 PM, Neil Williams wrote:
> On Tue, 13 Apr 2010 22:54:49 +1000
> Brendan Simon <Brendan@BrendanSimon.com> wrote:
>
>
>>> It all depends on how many packages are involved and whether you need
>>> to allow for future upgrades. If yes, use Grip and try to work around
>>> the issues of a first-boot configuration step. If no, set the
>>> configuration manually and consider something like Baked. (Basically,
>>> that means telling me you'd like Baked to be available. I can get it
>>> into the next release of emdebian-grip.)
>>>
>>>
>> I am not familiar with Baked, but it sounds like it is worth having :)
>>
> Baked has existed as an idea for, oh about an hour now. (!) See my
> other email and the thread that followed.
>
Oh, so it's mature then ;-)
If it is so new, does that make it 'half-baked' ?? ... lol
>>> I'm expecting that networking devices like that will (generally) fit
>>> the criteria for Baked - i.e. that once produced, the device itself
>>> will not need or expect to install new updates via dpkg or apt and will
>>> therefore not want maintainer scripts installed.
>>>
>>>
>> Yes. Updates are handled by installing an entire new filesystem image,
>> and the device boots to the new filesystem. Most products that are
>> mission critical will have the ability to revert back to the previous
>> version if booting of the new filesystem fails, or the user decides the
>> new version is unsuitable (e.g. incompatibilities or interoperability
>> issues, etc).
>>
> Where is the previous version kept? On device? As long as there's
> enough room you can do that with Baked - it would be a question of how
> you put the Baked rootfs onto the device.
>
>
Yes, the previous version would be on the device. It needs to be in
case the update fails and an automatic fallback is required. Think of
remotely updating a router that is located in the middle of nowhere
(where maintenance personal visit infrequently).
There are a few ways of doing this. Each FS could live in it's own
partition, or images can be stored on a common partition and loaded
somehow (e.g. loop device). Kernel images may or may not live in the
fs, depending on the bootloader capabilities of the embedded system.
The kernel may or may not need to use initramfs.
As far as configuration is concerned. Most user settable values are
stored in a common location (e.g. an eeprom, or a dedicated partition,
etc). These values are used by the running linux system (which ever it
is). An example would be hostname, IP address, etc.
Cheers,
Brendan.
Reply to: