Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1198214 > unrolled thread

Bug#1071592: fails to enable LVM on crypt during boot, rendering the system unbootable

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1071592: fails to enable LVM on crypt during boot, rendering the system unbootable Luca Boccassi <bluca@debian.org> - 2024-05-22 02:00 +0200
    Bug#1071592: fails to enable LVM on crypt during boot, rendering the system unbootable Evgeni Golov <evgeni@debian.org> - 2024-05-22 20:10 +0200
    Bug#1071592: fails to enable LVM on crypt during boot, rendering the system unbootable Benjamin Lee <ben@b1c1l1.com> - 2024-05-22 07:30 +0200
      Bug#1071592: fails to enable LVM on crypt during boot, rendering the system unbootable Evgeni Golov <evgeni@debian.org> - 2024-05-22 19:20 +0200

#1198214 — Bug#1071592: fails to enable LVM on crypt during boot, rendering the system unbootable

[Multipart message — attachments visible in raw view] — view raw

Control: reassign -1 dracut 060+5-1

On Tue, 21 May 2024 21:47:37 +0200 Evgeni Golov <evgeni@debian.org>
wrote:
> Package: systemd
> Version: 256~rc2-3
> Severity: important
> 
> Ohai,
> 
> I am filing this against systemd, as that's the package that triggers
> the issue when upgraded, but it very well might be in dracut, so
please
> re-assign as you see fit.
> Also filing this "only" as important, as it's breaking a non-default
> setup and I did not verify this on any other system.
> 
> My laptop is running sid with / on LVM on crypt. I am using dracut
for
> initrd generation.
> 
> With the upgrade to systemd 256 (from 255.5) it fails to boot:
> 1. asks for my passphrase
> 2. systemd-cryptsetup@<cryptdevice>.service starts
> 3. dev-mapper-<vg>-<lv>.device runs forever, never reaching
completion
> 
> I can get it to boot by:
> 1. rd.break=pre-mount in the bootloader to interrupt dracut
> 2. lvm lvchange -ae <vg>/<lv> in the dracut shell
> 
> I am aware of #1071278 but I do have dracut 060+5-8 which is supposed
to
> have all the required fixes.
> 
> Downgrading systemd to 255.5-1 and regenerating the initrd fixes the
> boot process.

It's probably the same issue with missing libraries, but I do not use
either dracut nor LVM so I cannot help, reassigning to dracut so that
you might get some help with debugging and finding out what the actual
issue is

-- 
Kind regards,
Luca Boccassi

[toc] | [next] | [standalone]

#1198222

On Wed, May 22, 2024 at 05:58:50PM +0200, Evgeni Golov wrote:
> On Tue, May 21, 2024 at 10:10:02PM -0700, Benjamin Lee wrote:
> > > It's probably the same issue with missing libraries, but I do not use
> > > either dracut nor LVM so I cannot help, reassigning to dracut so that
> > > you might get some help with debugging and finding out what the actual
> > > issue is
> 
> I am rather sure it's not the libraries, as I have dracut -8.
> > 
> > It seems like the issue is that systemd 256 now makes /usr read-only in the
> > initrd environment, but dracut depends on writing to /usr.
> > 
> > One workaround is to set ProtectSystem=no in the initrd, so that /usr is
> > writable again.  I got my system (also LVM on LUKS) booting with a dracut
> > module to write system.conf:
> > 
> > blee@r8 /usr/lib/dracut/modules.d/99local $ cat module-setup.sh
> > #!/bin/bash
> > 
> > # called by dracut
> > install() {
> >     printf "[Manager]\nProtectSystem=no\n" >> "${initdir}/etc/systemd/system.conf"
> > }
> 
> Thanks! That worked, even if it looks like a gross hack. :)
> 
> In the meantime, I have found [1] over at Fedora, which I am going to
> try next (as it is supposed to fix the same thing, but cleaner).

It does fix the issue!

I've opened an MR against the dracut package [2] and uploaded built
packages at [3] if anyone wants to try :)

Thanks for hinting me in the right direction!

Evgeni

[2] https://salsa.debian.org/debian/dracut/-/merge_requests/36
[3] https://people.debian.org/~evgeni/dracut-systemd-ro-usr/

[toc] | [prev] | [next] | [standalone]

#1198258

On Wed, 22 May 2024 00:51:22 +0100 Luca Boccassi <bluca@debian.org> wrote:
> Control: reassign -1 dracut 060+5-1
> 
> On Tue, 21 May 2024 21:47:37 +0200 Evgeni Golov <evgeni@debian.org>
> wrote:
> > Package: systemd
> > Version: 256~rc2-3
> > Severity: important
> > 
> > Ohai,
> > 
> > I am filing this against systemd, as that's the package that triggers
> > the issue when upgraded, but it very well might be in dracut, so
> please
> > re-assign as you see fit.
> > Also filing this "only" as important, as it's breaking a non-default
> > setup and I did not verify this on any other system.
> > 
> > My laptop is running sid with / on LVM on crypt. I am using dracut
> for
> > initrd generation.
> > 
> > With the upgrade to systemd 256 (from 255.5) it fails to boot:
> > 1. asks for my passphrase
> > 2. systemd-cryptsetup@<cryptdevice>.service starts
> > 3. dev-mapper-<vg>-<lv>.device runs forever, never reaching
> completion
> > 
> > I can get it to boot by:
> > 1. rd.break=pre-mount in the bootloader to interrupt dracut
> > 2. lvm lvchange -ae <vg>/<lv> in the dracut shell
> > 
> > I am aware of #1071278 but I do have dracut 060+5-8 which is supposed
> to
> > have all the required fixes.
> > 
> > Downgrading systemd to 255.5-1 and regenerating the initrd fixes the
> > boot process.
> 
> It's probably the same issue with missing libraries, but I do not use
> either dracut nor LVM so I cannot help, reassigning to dracut so that
> you might get some help with debugging and finding out what the actual
> issue is

It seems like the issue is that systemd 256 now makes /usr read-only in the
initrd environment, but dracut depends on writing to /usr.

One workaround is to set ProtectSystem=no in the initrd, so that /usr is
writable again.  I got my system (also LVM on LUKS) booting with a dracut
module to write system.conf:

blee@r8 /usr/lib/dracut/modules.d/99local $ cat module-setup.sh
#!/bin/bash

# called by dracut
install() {
     printf "[Manager]\nProtectSystem=no\n" >> "${initdir}/etc/systemd/system.conf"
}

[toc] | [prev] | [next] | [standalone]

#1198282

On Tue, May 21, 2024 at 10:10:02PM -0700, Benjamin Lee wrote:
> > It's probably the same issue with missing libraries, but I do not use
> > either dracut nor LVM so I cannot help, reassigning to dracut so that
> > you might get some help with debugging and finding out what the actual
> > issue is

I am rather sure it's not the libraries, as I have dracut -8.
> 
> It seems like the issue is that systemd 256 now makes /usr read-only in the
> initrd environment, but dracut depends on writing to /usr.
> 
> One workaround is to set ProtectSystem=no in the initrd, so that /usr is
> writable again.  I got my system (also LVM on LUKS) booting with a dracut
> module to write system.conf:
> 
> blee@r8 /usr/lib/dracut/modules.d/99local $ cat module-setup.sh
> #!/bin/bash
> 
> # called by dracut
> install() {
>     printf "[Manager]\nProtectSystem=no\n" >> "${initdir}/etc/systemd/system.conf"
> }

Thanks! That worked, even if it looks like a gross hack. :)

In the meantime, I have found [1] over at Fedora, which I am going to
try next (as it is supposed to fix the same thing, but cleaner).

Evgeni

[1] https://src.fedoraproject.org/rpms/dracut/blob/rawhide/f/0019-fix-dracut-move-hooks-directory-from-usr-lib-to-var-.patch

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web