On Thu, Mar 25, 2010 at 07:18:46PM +0100, email@example.com wrote:
> well actually i checked man initramfs-tools. i think if the
> explanation "/etc/initramfs-tools -> local admin config overriding
> package defaults, /usr/share/initramfs-tools -> package defaults" were
> in this manpage, too, that would have helped against people like me
> not getting it.
latest git is on
> > what you could help at is audit scripts in
> > /usr/share/initramfs-tools/conf.d/
> > and check that they don't set an mkinitramfs variable.
> > then the call in mkinitramfs to source them could be finaly droped.
> hm. i just know about uswsusp dropping a file there, setting
> which is a variable that is used by a hook script on initramfs
> creation - but i'm not sure that it doesn't also make sense during
> initramfs boot... i'll try to investigate and take care of this (as
> long as nobody tells me that i'm totally wrong here
indeed that one should move please file wishlist bug against uswsusp
indicating that this transition is wanted by mkinitramfs.
KEYMAP is a build variable for adding keymaps to initramfs.
don't understand why uswsusp would need that?
for cryptsetup it makes sense, but this seems a bit questionable.
> > concerning templating this is what each perl module likes to reinvent
> > badly, don't think we need that complexity.
> hm. i'm not sure i meant the same thing as you with 'template'.
> what i meant:
> currently when creating an initramfs - let's say under /tmp/foobar/ -
> files like /usr/share/initramfs-tools/scripts/local-top/lvm are copied
> to e.g. /tmp/foobar/scripts/local-top/lvm, and
> /etc/initramfs-tools/modules to e.g. /tmp/foobar/etc/modules and so
> on. i.e. on a mkinitramfs run, what i call 'template' is created from
> various sources (which mkinitramfs has to know about) and the
> 'template' then ends up as e.g. /tmp/foobar/.
> what i meant was: when these files, which are 'collected', already
> reside in /etc/initramfs-tools/template/ (e.g.
> /etc/initramfs-tools/template/modules, and so on), this would be less
> complex and more flexible, in so far as a mkinitramfs run would start
> with something like cp -a /etc/initramfs-tools/template/ /tmp/foobar/
> , the structure i.e. where a file actually ends up in the initramfs
> would be implicitly clear, and changes there (like a new tree
> necessary for and put there by some other package) would not need
> explicit support by or changes to mkinitramfs or a hook script.
this looks like trouble you could get easily file conflicts and stuff.
what be more neat is to have the initramfs of linux-2.6 the modules
build on build time and just concatenated with the staff that is
going on on your box, should reduce build time a lot too.
this something for squeeze +1
> (this is btw not a try to convince you of this idea - it's just to
> make sure you really know what i meant so you can decide on the real
> idea and not on a misunderstanding
> >> and to answer my initial question, i guess using conf.d/ for
> >> modularized configs done by other packages is a good idea.
> > depends what for if it's for bootvariables then it is fine and good.
> > for mkinitramfs i'd be happy to drop.
> > seems good in general, just the packaging change can be dropped.
> ok, i just added the patch without the part moving the config to /etc,
> i.e. the 2nd chunk, just leaving the UMASK config, just for gerrit's
> diff -pruN ../a/dropbear-0.52/debian/initramfs/dropbear-conf ./dropbear-0.52/debian/initramfs/dropbear-conf
> --- ../a/dropbear-0.52/debian/initramfs/dropbear-conf 2010-03-25 11:42:21.000000000 +0100
> +++ ./dropbear-0.52/debian/initramfs/dropbear-conf 2010-03-25 11:48:38.000000000 +0100
> @@ -6,3 +6,12 @@
> +# UMASK: [ 4-DIGIT OCTAL UMASK ]
> +# umask to use when creating an initramfs
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org