hey, On 08/06/2010 Michael Prokop wrote: > reassign 481104 cryptsetup
i don't agree that this bug belongs to cryptsetup. > * maximilian attems <m...@stro.at> [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 /usr/share/initramfs-tools/conf.d/cryptroot and $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. greetings, jonas
signature.asc
Description: Digital signature
