Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#777578: initramfs-tools: update-initramfs fails with btrfs (was: no cryptsetup in initrd when btrfs selected)

130 views
Skip to first unread message

jnqnfe

unread,
Feb 10, 2015, 10:10:04 PM2/10/15
to
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.


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

jnqnfe

unread,
Feb 11, 2015, 12:20:05 PM2/11/15
to

On 11/02/2015 05:05, Ben Hutchings wrote:
> On Wed, 2015-02-11 at 03:04 +0000, jnqnfe wrote:
>> I think that my issues might all stem from initramfs-tools, so
>> reassigning.
> I don't think so - other packages hook into initramfs-tools and are
> quite capable of breaking it.
I see, I wasn't aware of that.

> What are the error messages?
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.

>> 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.
> 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.
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.

Ben Hutchings

unread,
Feb 11, 2015, 1:50:04 PM2/11/15
to
Control: retitle -1 btrfs-tools not always installed with btrfs root
Control: reassign -1 partman-btrfs

On Wed, 2015-02-11 at 17:10 +0000, jnqnfe wrote:
> On 11/02/2015 05:05, Ben Hutchings wrote:
> > On Wed, 2015-02-11 at 03:04 +0000, jnqnfe wrote:
> >> I think that my issues might all stem from initramfs-tools, so
> >> reassigning.
> > I don't think so - other packages hook into initramfs-tools and are
> > quite capable of breaking it.
> I see, I wasn't aware of that.
>
> > What are the error messages?
> 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.
[...]

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

Ben.

--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson
signature.asc

jnqnfe

unread,
Feb 11, 2015, 2:40:03 PM2/11/15
to

On 11/02/2015 18:42, Ben Hutchings wrote:
> 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

jnqnfe

unread,
Feb 12, 2015, 11:40:04 AM2/12/15
to
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.

Nicholas D Steeves

unread,
Aug 15, 2023, 8:50:04 PM8/15/23
to
Hi,

jnqnfe <jnq...@gmail.com> writes:

> On 11/02/2015 18:42, Ben Hutchings wrote:
>> 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

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
signature.asc
0 new messages