Hi Ludo',
On 4/7/24 19:43, Ludovic Courtès wrote:
Oops, sorry for not noticing it earlier! (That was a hard-to-debug one
so kudos for the work you and others put in it.)
I pushed these two commits to address the problem:
49f82fca41 mapped-devices: luks: Specify modules needed at the top-le
guix pull + reconfigure worked for me as well.
Thank you verry much.
Hi,
aurtzy skribis:
> On 4/7/24 19:43, Ludovic Courtès wrote:
>> Oops, sorry for not noticing it earlier! (That was a hard-to-debug one
>> so kudos for the work you and others put in it.)
>>
>> I pushed these two commits to address the problem:
>>
>>49f82fca41 mapped-devices: luks: Specify
Hi aurtzy,
aurtzy skribis:
> This bug has also been reported here: https://issues.guix.gnu.org/70051
>
> I sent a patch that a few others have confirmed fixes the issue:
> https://issues.guix.gnu.org/70051#5
Oops, sorry for not noticing it earlier! (That was a hard-to-debug one
so kudos for th
I can't roll back to the earlier commit mentioned by Remco because other
things/channels depend on me being roughly up-to-date on the main guix channel.
However, I can confirm the issue, as changing my configuration *not* to mount
an encrypted /home resolves the boot issue.
I note two things:
I can confirm aurtzy's patch works (just tested on top of
7af70efd7633b0d70091762cf43ce01a86176e8e)
2024/04/02, Benjamin Slade:
> I can't roll back to the earlier commit mentioned by Remco because
> other things/channels depend on me being roughly up-to-date on the
> main guix channel.
Reverting the commit on a local checkout of guix worked for me but isn't
workable of course. I tested the pat
2024/04/02, aurtzy:
> Can anyone confirm this patch works for them too?
Yes, it does.
Cheers,
Remco
It seems like `use-modules' never actually worked due to the way it is eval'd
by the Shepherd, and was only apparent after a change that prevented other
module imports from leaking into the namespace. This is fixed by using direct
references instead.
* gnu/system/mapped-devices.scm (open-luks-dev
yep I got the same issue too. but, in my case, I have an encrypted root
with three other encrypted partitions, none of them my home. initrd
decryption succeeds, but shepherd device-mapper services fail as usual
Hi,
Confirmed on a couple of my installs. I too have an unencrypted root
and encrypted home filesystems. The passphrase prompt never appears and
the system seems to be waiting for something or is halted.
I've git bisected it down to:
commit 6f9d844d2ece7b369d17bbe678978462425f869c (HEAD)
A
And I also forgot to mention *sigh* that I am not the only one affected
by this problem. See :
https://lists.gnu.org/archive/html/help-guix/2024-03/msg00152.html
… And I forgot to mention that, when the boot hangs, shepherd still responds to
ctrl-alt-del by closing some services and then the system hangs with hardware
button shutdown as last resort.
Hello,
Up to guix 9b84b36, my system was properly booting with a LUKS2 partition
mounted on /home. Starting with guix d5f857a (22 mar 2024), the boot hangs on
the same system using the same configuration.scm file. The only way out I found
when it hangs is hardware shutdown. There are no avaible co
14 matches
Mail list logo
