hello! On Thu, Mar 25, 2010 at 07:18:46PM +0100, deb...@x.ray.net 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. :)
taking patches ;) latest git is on http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary > > 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 > KEYMAP=y > 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/scripts/..., > /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 :) thanks. > >> 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 > convenience... acked-by me :) > regards, > > Chris > 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 @@ > # > > #DROPBEAR=y > + > +# > +# UMASK: [ 4-DIGIT OCTAL UMASK ] > +# > +# umask to use when creating an initramfs > +# > + > +UMASK=0077 > + -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org