As already described in the users mailing list [1], I have a Debian sid
amd64 install in a VM, using EFI, GPT, btrfs and luks, which after
installation is left broken.

So far, I have identified:
1) that the initrd of this install is lacking at least cryptsetup.
2) that an identical install, with the exception of using ext4 instead
of btrfs, works perfectly fine (at least in terms of booting, I have not
checked issue #3 from the mailing list discussion).
3) that this is reproducible, having recreated the same btrfs install
from scratch, resulting in the same issues.

So it seems that under some scenarios, d-i is not creating a sufficient
initrd.

/conf/initramfs.conf states MODULES=most

All installs so far were done using the standard graphical install mode.

Just FYI, for the installation I am using a sid amd64 based live-cd
image generated with live-build with the latest stable d-i included (I'm
including the proper standard installer, not the "live" installer), and
due to the dev work I've been undertaking on live-build, I am in
possession of a live image with EFI support. Hence I am essentially
simulating use of a Jessie install disc here.

[1] https://lists.debian.org/debian-user/2015/02/msg00323.html

Sorry, when I said that I'm using the latest "stable" version of d-i for
this, I mean I'm using the "current" version under sid as available in the
archives, not the daily build, and not a Wheezy build.

I have tried to do an identical install using (graphical) expert mode
this time, leaving initrd on 'generic'. This results in the same problem:

[    0.000000 ] tsc: Fast TSC calibration failed
Loading, please wait...
Gave up waiting for root device. Common problems:
<blah>
ALERT!  /dev/mapper/sda3_crypt does not exist. Dropping to a shell!
modprobe: module ehci-orion not found in modules.dep
<busybox output>
/bin/sh: can't access tty; job control turned off
(initramfs)

I notice that the initial complaint about ehci-orion not being found
isn't there, but otherwise it's identical.

Again, no cryptsetup installed into initrd.

@maintainer - thoughts?

I just checked issue #3 from the original mailing list post against the
ext4 install.

Performing update-initramfs -u via chroot using the live-cd against the
good install using ext4 results in no errors, unlike the btrfs installs.

I also did a bit of a comparison of initrd content between the ext4 and
btrfs installs, and cryptsetup was the only obvious thing I saw missing.

control: reassign -1 initramfs-tools
control: retitle -1 initramfs-tools: fails to work with btrfs
control: severity -1 grave

I think that my issues might all stem from initramfs-tools, so reassigning.

Firstly, I cannot run update-initramfs within a chroot via a live CD against this btrfs based install because it gets confused about where root is (see original cry for help), and which is at least a bug against initramfs-tools in it's own right anyway.

Secondly, the other issue I believe is due to the initrd created by debian-installer missing at least cryptsetup; I believe debian-installer runs update-initramfs towards the end, so perhaps this is where debian-installer is trying to add things like cryptsetup to initrd, and it is actually silently failing here due to same issue above.

@Maintainer - thoughts? I'd really like to get this solved.

btrfs is still not a recommended filesystem, so downgrading this to
normal.

I don't think so - other packages hook into initramfs-tools and are
quite capable of breaking it.

What are the error messages?

initramfs-tools doesn't make that decision - cryptsetup does.  And if
cryptsetup isn't installed or configured properly, that's the fault of
partman-crypto.

Ben.

I see, I wasn't aware of that.
When executing update-initramfs -u in a chroot via a live CD, I get:

update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64
cryptsetup: WARNING: could not determine root device from /etc/fstab
Warning: /sbin/fsck.btrfs doesn't exist, can't install to initramfs,
ignoring.
<perl locale warnings>

More details of the setup are described in the following mailing list
message (please ignore issue #1), including fstab, crypttab contents and
blkid output:
https://lists.debian.org/debian-user/2015/02/msg00323.html

(please excuse the use of '<etc>' in the UUID's, I couldn't be bothered
to type them all out in full)

The filesystem after installation does contain an install of cryptsetup,
just no copy in initrd. I added 'cryptsetup' into the
/etc/initramfs-tools/modules file before executing update-initramfs -u,
resulting in the above output, and no cryptsetup binary or config files
present in the /boot initrd image.
I'm not going to dispute whether the fault lies with initramfs-tools or
partman-crypto, because I don't have a clue.

All I know at this time is that comparing two VM installs, one using
luks + btrfs and one using luks + ext4, otherwise identical, the btrfs
one lacks cryptsetup in its initrd after installation, causing boot
failure, while the ext4 one is fine, and using a live CD + chroot to try
to fix things via update-initramfs, the tool runs fine on the ext4
install, but fails on the btrfs install. I am guessing that both
problems have a common cause.

Thank you for taking some time to respond to my issue. I appreciate any
help you can offer in resolving it.

Control: retitle -1 btrfs-tools not always installed with btrfs root
Control: reassign -1 partman-btrfs
[...]

So the root (no pun intended) of the problem is that btrfs-tools was not
installed.

Ben.

Ah ha, you're absolutely right, I assumed it was but it is indeed not
installed. Thanks for that.

Yep, now it boots successfully :D

Just ftr, so people don't think I'm a total idiot, I'd read in several
places that there was no fsck for btrfs, so I was deliberately ignoring
the missing btrfs.fsck warning and assuming it had been installed.

Hi,

jnqnfe <jnqnfe@gmail.com> writes:

Are you still able to reproduce the state where Debian is successfully
installed to a btrfs rootfs, but where btrfs-progs is not installed?
From what I can tell, that is the nature of this [by now most likely
historical] bug.

Regards,
Nicholas