On 08/06/2010 Michael Prokop wrote:
> reassign 481104 cryptsetup
i don't agree that this bug belongs to cryptsetup.
> * maximilian attems <email@example.com> [Don Jul 10, 2008 at 11:57:52 +0200]:
> > On Wed, Jul 09, 2008 at 09:51:22PM +0300, Giorgos D. Pallas wrote:
> > > Not to my surprise, you were right :-)
> > > I just deleted the /etc/initramfs-tools/conf.d/cryptroot file, and run
> > > again update-initramfs -u. Laptop boots fine. Btw, I already had
> > > /etc/crypttab correctly configured, so it seems that the cryptroot file
> > > was redundant.
> > > So, probably the bug has to be closed since it was a consequence of a
> > > wrong practice, if I got it right.
> > no you found an interesting conrner case, wont invest too much time
> > now before release on it, but that needs to be rethought afterwards.
> > keeping open and thanks to David for the bug chase!!
> > thanks for the report!
> I'm reassigning this bugreport to cryptsetup, as initramfs-tools
> doesn't provide any crypt* stuff any longer. AFAICS this issue is
> resolved, though it would be great if cryptsetup packagers could
> take a closer look at it before closing it.
mh, strange. it seems like mkinitramfs pastes the output of
/conf/conf.d/cryptroot (in initramfs) to either of
$CONFDIR/conf.d/cryptroot if they exist. even touching them as empty
files leads to the described issue.
i didn't identify the relevant code yet, sh -x mkinitramfs didn't give
any further information.
i suggest to close the bugreport anyway, as shipping mkinitramfs
cryptroot configuration in $CONFDIR/conf.d/cryptroot was not supported
in the first place.
to my knowledge the cryptroot-hook script is not the problem here. the
problematic code should be in mkinitramfs itself.