Bug#767589: systemd: cryptdisks other than root/swap fail cryptsetup

2014-12-18 Thread Simon McVittie
Control: reassign 767589 cryptsetup
Control: forcemerge 767832 767589

On 18/12/14 00:48, Arnaud Installe wrote:
> On Thu, 27 Nov 2014 10:53:35 +
> Simon McVittie  wrote:
>> I think this may be the same thing as
>> 
...
>> It would be great if you could try rebuilding the initramfs after
>> installing a version of cryptsetup with the patch
...
> I installed that, and my problem was solved.

Merging the bugs.

Thanks,
S


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#767589: systemd: cryptdisks other than root/swap fail cryptsetup

2014-12-17 Thread Arnaud Installe
On Thu, 27 Nov 2014 10:53:35 +
Simon McVittie  wrote:

> On Sat, 01 Nov 2014 at 11:50:40 +0100, Arnaud Installe wrote:
> > After successfully unlocking and mounting root and swap devices,
> > the system hangs a while, then drops to a rescue shell,
> > with /usr, /var and /home not unlocked by cryptsetup. After
> > manually running cryptsetup for the underlying devices, and exiting
> > the rescue shell, boot proceeds normally.
> 
> I think this may be the same thing as
> . Am I right in saying that your
> system looks like this?
> 
> /dev/sda (or whatever)
>   \- /dev/sda1 (or whatever): /boot
>   \- /dev/sda2 (or whatever): LVM PV for VG "boulez"
>  \- boulez/root LV: encrypted, boulez-_root__crypt
> \- / (rootfs)
>  \- boulez/swap LV: encrypted, boulez-_swap__crypt
> \- swap
>  \- boulez/home LV: encrypted, boulez-_home__crypt
> \- /home
>  \- boulez/usr LV: encrypted, boulez-_usr__crypt
> \- /usr
>  \- boulez/var LV: encrypted, boulez-_var__crypt
> \- /var

Yes, that's about it.

[...]

> It would be great if you could try rebuilding the initramfs after
> installing a version of cryptsetup with the patch from
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767832#22
> applied. I believe that should fix your situation too, but
> so far I have only tested LUKS on partitions, not LUKS on LVM.

I'm sorry for the late reply. I wanted to try out your suggestion
today, only to find that a new version of cryptsetup including your
patch had made it to unstable.

I installed that, and my problem was solved. Thank you very much, and
again, sorry for the late reply!

Arnaud

-- 
Arnaud Installe   +32 477 304199
ESAT - STADIUS, KULeuven iMinds Medical Information Technologies


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#767589: systemd: cryptdisks other than root/swap fail cryptsetup

2014-11-27 Thread Simon McVittie
On Sat, 01 Nov 2014 at 11:50:40 +0100, Arnaud Installe wrote:
> After successfully unlocking and mounting root and swap devices, the system
> hangs a while, then drops to a rescue shell, with /usr, /var and /home not
> unlocked by cryptsetup. After manually running cryptsetup for the underlying
> devices, and exiting the rescue shell, boot proceeds normally.

I think this may be the same thing as .
Am I right in saying that your system looks like this?

/dev/sda (or whatever)
  \- /dev/sda1 (or whatever): /boot
  \- /dev/sda2 (or whatever): LVM PV for VG "boulez"
 \- boulez/root LV: encrypted, boulez-_root__crypt
\- / (rootfs)
 \- boulez/swap LV: encrypted, boulez-_swap__crypt
\- swap
 \- boulez/home LV: encrypted, boulez-_home__crypt
\- /home
 \- boulez/usr LV: encrypted, boulez-_usr__crypt
\- /usr
 \- boulez/var LV: encrypted, boulez-_var__crypt
\- /var

With initramfs-tools < 0.117, the intended result for a system like this
is that the initramfs decrypts the root filesystem and swap, mounts
the root filesystem, and hands over to the "real system" (systemd as pid 1).
The "real system" is meant to decrypt and mount /home, /usr and /var.

With initramfs-tools >= 0.117, the intended result for a system like this
is that the initramfs also decrypts and mounts /usr. However, cryptsetup
does not currently decrypt /usr.

It should be unnecessary to decrypt /home or /var in the initramfs
in either case.

It would be great if you could try rebuilding the initramfs after
installing a version of cryptsetup with the patch from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767832#22
applied. I believe that should fix your situation too, but
so far I have only tested LUKS on partitions, not LUKS on LVM.

S


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#767589: systemd: cryptdisks other than root/swap fail cryptsetup

2014-11-04 Thread Arnaud Installe
On Tue, 04 Nov 2014 13:52:16 +0100
Michael Biebl  wrote:

> Therefore re-assigning to initramfs-tools.
> Please followup on the bug report and include the version of
> initramfs-tools you have installed. As well as the version of
> cryptsetup.

initramfs-tools 0.118
cryptsetup  2:1.6.6-3

Thanks,

Arnaud

-- 
Arnaud Installe   +32 477 304199
ESAT - STADIUS, KULeuven iMinds Medical Information Technologies


pgpeqAYJoWqrz.pgp
Description: OpenPGP digital signature


Bug#767589: systemd: cryptdisks other than root/swap fail cryptsetup

2014-11-04 Thread Michael Biebl
Control: reassign -1 initramfs-tools

Am 04.11.2014 um 13:37 schrieb Arnaud Installe:
> On Tue, 04 Nov 2014 13:20:05 +0100
> Michael Biebl  wrote:
> 
>> Am 04.11.2014 um 11:46 schrieb Arnaud Installe:
>> cue shell is booted off an initrd image which doesn't have
>>> enough of systemd / journalctl available (libraries missing etc.).
>>> So I ran the commands you mention after I manually ran cryptsetup
>>> for boulez-_home_, boulez-_usr_, and boulez-_var_, exited the
>>> rescue shell, and waited for the system to finish booting. I hope
>>> that the logs will help finding the problem. Thanks for looking
>>> into it!
>>>
>>
>> Ok, that log is then not really helpful. What confuses me though, is
>> that you said you have no journalctl available in the rescue shell?
>>
>> Are you by chance dropped into the rescue shell from the initramfs and
>> not the systemd rescue shell?
> 
> Yes. The shell prompt says "(initramfs) ".
> 
> Does that mean that this bug should have been assigned to
> initramfs-tools instead of systemd?

Yes.

>> Can you make a screenshot of the rescue shell prompt?
> 
> If you're looking for more than just the rescue shell prompt, I'll make
> a screenshot tonight, and add it to the bug report. Otherwise, I'll
> just add the information from this e-mail.
> 

No, this information is sufficient, so a screenshot is not necessary.
Since this is indeed an issue in initramfs-tools, which is started
*before* systemd, systemd is not involved here.

Therefore re-assigning to initramfs-tools.
Please followup on the bug report and include the version of
initramfs-tools you have installed. As well as the version of cryptsetup.


thanks,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#767589: systemd: cryptdisks other than root/swap fail cryptsetup

2014-11-04 Thread Michael Biebl
Am 04.11.2014 um 11:46 schrieb Arnaud Installe:
cue shell is booted off an initrd image which doesn't have
> enough of systemd / journalctl available (libraries missing etc.). So I
> ran the commands you mention after I manually ran cryptsetup for
> boulez-_home_, boulez-_usr_, and boulez-_var_, exited the rescue shell,
> and waited for the system to finish booting. I hope that the logs will
> help finding the problem. Thanks for looking into it!
> 

Ok, that log is then not really helpful. What confuses me though, is
that you said you have no journalctl available in the rescue shell?

Are you by chance dropped into the rescue shell from the initramfs and
not the systemd rescue shell?
Can you make a screenshot of the rescue shell prompt?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#767589: systemd: cryptdisks other than root/swap fail cryptsetup

2014-11-03 Thread Michael Biebl
Control: tags -1 moreinfo

Am 01.11.2014 um 11:50 schrieb Arnaud Installe:
> Package: systemd
> Version: 215-5+b1
> Severity: critical
> Tags: d-i
> Justification: breaks the whole system
> 
> After successfully unlocking and mounting root and swap devices, the system
> hangs a while, then drops to a rescue shell, with /usr, /var and /home not
> unlocked by cryptsetup. After manually running cryptsetup for the underlying
> devices, and exiting the rescue shell, boot proceeds normally.

Do you get any password prompts for the other partitions?
Did you maybe miss them because they were overwritten by other output?

> Contents of /etc/crypttab:
> 
> boulez-_home__crypt UUID=70967099-611f-4082-aad4-3d3e9966fad6 none luks
> boulez-_root__crypt UUID=b8806964-812e-4239-8914-60b1c33c0491 none luks
> boulez-_swap__crypt UUID=42dfca9b-0815-402e-a605-1dbfb39b42c3 none luks,swap
> boulez-_usr__crypt UUID=386fb30f-389d-4feb-9c59-352628c0de6b none luks
> boulez-_var__crypt UUID=97d4e051-a1b8-4ecc-9dd3-5a69eeed4686 none luks
> 
> (Previously boulez-_usr__crypt, boulez-_var__crypt and boulez-_home_, _crypt 
> used
> "/etc/secretkey" instead of "none", so no passphrase needed to be asked for
> them. I believe this used to work for a while after I migrated from sysv to
> systemd. But it has stopped working since around August I believe. I tried
> using "none" instead of "/etc/secretkey" to verify if that would solve the 
> boot
> problem, but it didn't.)
> 
> Not sure if this problem would also occur if /usr resided in the root 
> partition
> instead of being a separate partition.
> 

Please boot with systemd.log_level=debug on the kernel command line
When you're dropped into the rescue shell, please save the output of
"journalctl -alb" and "systemd-analyze dump" and attach it to the bug
report.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature