-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
systemd udev doesn't wait for HDDs, system can't boot (not even recovery) #20
Comments
That should not happen, as sd-zfs goes https://github.com/dasJ/sd-zfs/blob/master/src/zfs-generator.c#L173 You can check the dependency tree by putting systemd-analyze to your initrd and generating a depenency graph. |
Any thoughts on how to get that to work and get data out of it? zfs pool never imports or mounts, no login access is available. I don't see a way to run this against a non-running systemd setup. |
Have you tried both emergency and recovery target and did you prepend rd. to the kernel option?
…On 23 Feb 2017, 02:37, at 02:37, alaricljs ***@***.***> wrote:
Any thoughts on how to get that to work and get data out of it? zfs
pool never imports or mounts, no login access is available. I don't
see a way to run this against a non-running systemd setup.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#20 (comment)
|
I appear to be having the same issue only it's also not waiting for cryptsetup.target. |
Do you use hibernation? You may have the same problem I had: systemd/systemd#4577 |
No I don't use hibernation at the moment; I only have one SSD and I didn't want to partition it. My swap sits in a VDEV and won't work with hibernation as far as I know. |
I just tried again on a fresh install and Where: /sysroot
What: zfs:rpool/root
Docs: ...
Process: 116 ExecMount=/usr/bin/mount zfs:rpool/root /sysroot -o rw ... |
How did you configure LUKS? |
I encrypted the drive with the following: cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 /dev/sda2 Then I modified
The zpool bootfs is configured: zpool get bootfs
NAME PROPERTY VALUE SOURCE
rpool bootfs rpool/root local |
Correct ..... almost. You need to add Now create a
Also, you can add Then, rebuild your initcpio. Hope this helps. |
Btw, my full
I don't really need |
Sorry I had forgotten
The only difference I see is |
Do you have a proper crypttab.initramfs? |
I tried adding your Also, why is it |
Because the crypttab.initramfs is put into your initramfs, while crypttab isn't. |
I'm sorry, do you mean for the ZFS partition? I do not have the ZFS partition UUID under a
I could try
|
I had the same problem. For the record, ZFS on LUKS encrypted full disk encryption, boot is encrypted on a separate drive and no keyfiles, manual entry of passwords until I get things debugged correctly. |
@schlesiger Sorry, I was mistaken. Have you tried the hint of @dschaper ? |
I'm seeing the same behaviour — sd-zfs tries to import the pool before sd-encrypt has decrypted it — with this hook order:
I'll try different device specifications (currently @maksim-pinguin For what it's worth, you can create an unlocked root account in your initramfs (which is created separately from your regular root account) to at least get an emergency shell: https://bbs.archlinux.org/viewtopic.php?pid=1927757#p1927757 |
I have the same error as @maksim-pinguin on my setup. |
I managed to get it running with the old syntax for the kernel parameter regarding the zfs partition. Check this thread: |
With systemd udev, sd-zfs fails to find my boot devices and attempts to go into rescue mode and fails there with an inability to mount /sysroot and systemd whining about not being able to do something with the password file. With udev and zfs hooks udev spins for a while waiting on my storage and then everything comes up clean. With systemd and sd-zfs the udev startup appears to get paralleled with other items and this breaks the process. The boot devices are SSDs, however primary storage is all HDDs set to not spin up unless told to. Unfortunately I don't have the resources to determine if this will happen without sd-zfs.
Do you know of some way to force systemd to wait on udev before proceeding? The initramfs is a very truncated version and I don't know where to start looking.
The text was updated successfully, but these errors were encountered: