Hi,
Colin Watson (2015-07-16):
> On Thu, Jul 16, 2015 at 10:05:48AM -0400, Martin Michlmayr wrote:
> > On a related note, flash-kernel waits for user input when the UUID of
> > root is not found, which makes sense in an installed system, but not
> > in d-i -- for the user, d-i will just hang with no obvious error. Is
> > there a good way to solve this? In particular, is there a way for a
> > postinst in /target to detect that it's run from within d-i? KiBi
> > doesn't know a way. I guess a debconf prompt is the way to go?
>
> I think trying to add debconf prompting to an initramfs hook would
> probably be unwise. flash-kernel already seems to check for
> DEBIAN_FRONTEND=noninteractive, so you could just set that in
> flash-kernel-installer.postinst when calling flash-kernel.
I'm not aware of other use cases right now, but maybe we could or should
standardize on an environment variable we would set in { all | most |
a particular set of } calls to let scripts know they're being executed
within an installer context?
Right now, provided /proc is mounted within /target, looking at /proc/1
might help one figure out that one /might/ might running within d-i; or
looking for main-menu in ps; both approaches look very fragile.
If adding support for a variable looks like a good idea, how should we
name it?
Using sources.debian.net, looking for DEBIAN_INSTALLER returns 3 hits:
- obs-build
- live-build
- libdebian-installer
live-build actually uses longer variable names, so not an issue:
| LB_DEBIAN_INSTALLER
| LB_MIRROR_DEBIAN_INSTALLER
| LB_PARENT_DEBIAN_INSTALLER
| LB_PARENT_MIRROR_DEBIAN_INSTALLER
obs-build uses the same variables.
libdebian-installer uses DEBIAN_INSTALLER__* for define/#include guards,
plus a LIBDEBIAN_INSTALLER_MAP_REAL #define.
So DEBIAN_INSTALLER shouldn't be an issue. Maybe something more specific
would make it easier to check for later…
Thoughts?
Mraw,
KiBi.
signature.asc
Description: Digital signature
