Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages initramfs-tools depends on:
ii cpio 2.9-13 GNU cpio -- a program to manage ar
ii findutils 4.4.0-2 utilities for finding files--find,
ii klibc-utils 1.5.9-1 small statically-linked utilities
ii module-init-tools 3.4-1 tools for managing Linux kernel mo
ii udev 0.114-2 /dev/ and hotplug management daemo
Versions of packages initramfs-tools recommends:
ii busybox 1:1.1.3-5 Tiny utilities for small and embed
-- no debconf information
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> On Fri, Jul 04, 2008 at 11:56:59PM +0200, maximilian attems wrote:
>>> Look at that: (updating initrd, duplicates the content of the cryptroot
>>> config file...)
>>
>>
>> right cryptsetup should maybe not write into /etc/i-t/conf.d
>> but in /usr/share/i-t/conf.d but those could also be mounted ro?!?
>>
>> anyway i'd like to hear from cryptsetup maintainers before reassgning.
>
> I'm not sure I understand the question. The cryptsetup initramfs hook
> writes its config file by doing:
>
> echo "$OPTIONS" >> "$DESTDIR/conf/conf.d/cryptroot"
>
> If that is below /etc, that would be due to initramfs-tools, wouldn't
> it?
okay it was quite late yesterday, aboves should be in the initramfs
itself. not sure if that bug report is not completly bogus
it is saying that /etc/initramfs-tools/conf.d/cryptroot is modified
on an update-initramfs -u run. i don't see any hook on my box
that would do that.
--
maks
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Sun, July 6, 2008 17:54, gpall@ccf.auth.gr? wrote:
> maximilian attems wrote:
>> right send output of
>> a) sh -x mkinitramfs -o /tmp/foo
>> b) sh -x update-initramfs -u
>
> Sending requested outputs a) -> out1, b) -> out2
Ok, I see the problem.
During the initramfs build, mkinitramfs will ln -s all config files into
the build dir. Later when the cryptsetup hook is executed it will write
config lines to the cryptroot config file in the build dir (which is
linked to the /etc... file outside the build dir).
I'm not 100% sure how we should solve this (why do you have a cryptroot
file by the way? It's supposed to be a cryptsetup internal config file).
Perhaps the best way to "handle" it would be to detect a symlink'ed config
file in the cryptsetup initramfs hook and to explode...on the other hand,
this is a problem in general since any other hook/script might also want
to write config files from their hook script and the same problem will
happen to them.
An alternative solution would be to move the step where external config
files are copied into the initramfs to a later stage in the mkinitramfs
run and allow mkinitramfs to check if it's about to overwrite already
written config files....maks?
--
David Härdeman
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Sun, July 6, 2008 17:54, gpall@ccf.auth.gr‚ wrote:
maximilian attems wrote:
right send output of
a) sh -x mkinitramfs -o /tmp/foo
b) sh -x update-initramfs -u
Sending requested outputs a) -> out1, b) -> out2
Ok, I see the problem.
During the initramfs build, mkinitramfs will ln -s all config files into
the build dir. Later when the cryptsetup hook is executed it will write
config lines to the cryptroot config file in the build dir (which is
linked to the /etc... file outside the build dir).
I'm not 100% sure how we should solve this (why do you have a cryptroot
file by the way? It's supposed to be a cryptsetup internal config file)
If I understood your question well, my answer is this: I have
/etc/initramfs-tools/conf.d/*cryptroot containing the line:
**target=lukspace,source=/dev/hda3,key=none,lvm=vg-root*
because I have my root partition sitting on LVM, which sits on LUKS. So,
somehow the initrd image must know that it has to find a LUKS partition
and ask me for its passphrase.
I hope I'm not talking nonsense. When I tried to set up encrypted root
partition, I used googling, a bit hacking and imagination. So, there is
the possibility that an easier method eludes me.
On Wed, July 9, 2008 10:51, Giorgos D. Pallas wrote:
> David Härdeman wrote:
>> ... (why do you have a cryptroot file by the way? It's supposed
>> to be a cryptsetup internal config file)
>
> If I understood your question well, my answer is this: I have
> /etc/initramfs-tools/conf.d/*cryptroot containing the line:
> **target=lukspace,source=/dev/hda3,key=none,lvm=vg-root*
> because I have my root partition sitting on LVM, which sits on LUKS. So,
> somehow the initrd image must know that it has to find a LUKS partition
> and ask me for its passphrase.
>
> I hope I'm not talking nonsense. When I tried to set up encrypted root
> partition, I used googling, a bit hacking and imagination. So, there is
> the possibility that an easier method eludes me.
Yes, the "correct" method would be to create a /etc/crypttab file with the
mapping for your root device. See the documentation in
/usr/share/doc/cryptsetup for details on how to do that.
Once a proper crypttab is setup, cryptsetup will automagically generate
initramfs config files for you.
--
David Härdeman
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Wed, Jul 09, 2008 at 09:51:22PM +0300, ?????????????? ???????????? 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.
>
> Thanks for all,
> Giorgos
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!
--
maks
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
* maximilian attems <max@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.
* Jonas Meurer <jonas@freesources.org> [Sat Jun 12, 2010 at 06:36:38PM +0200]:
> On 08/06/2010 Michael Prokop wrote:
[cryptroot in initramfs]
> > 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.
Located the problem now - you're right, it's clearly not a
cryptsetup issue, sorry.
Thanks for spotting and responding, maks and me will investigate.
Bug#481104: /usr/sbin/update-initramfs: update-initramfs edits /etc/initramfs-tools/conf.d/cryptroot
