Re: dpkg divert in preinst scripts
On 13/04/10 8:59 PM, Neil Williams wrote:
>> Couldn't the 'first boot' be mocked on the host system somehow ?? I'm
>> _not_ talking about processor/system emulation (e.g. qemu).
>>
> If you're dealing with a very fixed package set then maybe you can
> (hence Baked) but Grip involves using packages that are
> binary-compatible with Debian and that is hard to anticipate. (Moving
> target etc.)
>
> 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 :)
>>> Yes, pre-seeding is the answer. Create the configuration outside -
>>> using a native chroot that can be automatically configured as close as
>>> possible to the desired config and then tweaked to resolve corner cases
>>> - and then just dump that config onto the foreign filesystem.
>>>
>>>
>> Phew.
>> Does this also solve the 'first boot' issue above ??
>>
> Emdebian Baked will, yes.
>
> We need a "at-first-boot-run-this" script for Grip - it's been an idea
> for a long time but nobody has written one yet.
>
> Having packages believe they are configured is simply telling dpkg to
> set the status files that way. Multistrap can do that (or it can if
> no maintainer scripts exist in the packages.)
>
I am not familiar with Baked, so will do some research :)
>> For a networking device, things like a shell interpreter, an snmp agent,
>> an ssh server, a web server, etc.
>>
>> e.g. A 'fat' networking device may have: libc6, bash, coreutils,
>> net-snmp, openssh-server, openssl, apache.
>>
>> e.g. A 'thin' networking device may have: uclibc, busybox, net-snmp,
>> dropbear, appweb.
>>
> OK.
>
> 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).
Cheers, Brendan.
Reply to: