Skip to content
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

initramfs can't import any LUKS pools at boot on Debian Wheezy #93

Closed
chungy opened this issue Apr 17, 2013 · 3 comments
Closed

initramfs can't import any LUKS pools at boot on Debian Wheezy #93

chungy opened this issue Apr 17, 2013 · 3 comments

Comments

@chungy
Copy link

chungy commented Apr 17, 2013

I've got my laptop running Debian Wheezy and ZFS. At boot time, "zpool import" will not find any pools to import and I need to manually run touch /etc/mtab (creates the file, empty) to make it work.

I tried to add a touch "$DESTDIR/etc/mtab" to /usr/share/initramfs/hooks/zfs without success. I don't know what went wrong and I haven't done a whole lot of investigating into it.

I don't think it's related but for completeness, my disk consists of a LUKS partition and a 100MiB unencrypted ext4 /boot at the end; ZFS lives within the LUKS partition.

@micw
Copy link

micw commented Feb 8, 2014

I had the same problem (indeed there are 2 problems). First, /etc/mtab must be pressent. Second, zfs must be initialized then.

You can fix this by the following initrd script (just run the commands below to create it):

echo "ln -s -f /proc/mounts /etc/mtab" > /etc/initramfs-tools/scripts/init-premount/zfs-fix-mw
echo "zpool status" >> /etc/initramfs-tools/scripts/init-premount/zfs-fix-mw
chmod 700 /etc/initramfs-tools/scripts/init-premount/zfs-fix-mw
update-initramfs -u -k

@FransUrbo
Copy link
Contributor

The current initrd script already creates the mtab file before issuing any zpool command:

        # zpool import refuse to import without a valid mtab
        [ ! -f /proc/mounts ] && mount proc /proc
        [ ! -f /etc/mtab ] && cat /proc/mounts > /etc/mtab

That part originates from Sep 12, 2013 so I'm going to assume that this problem is fixed for Debian GNU/Linux.

Looking through the Ubuntu stable and snapshot tags, this is not fixed in Precise, Quantal, Raring and the Saucy tags. @dajhorn you might want to take a look at merging fixes from snapshot/debian/wheezy/0.6.3-0.9_g540ce4_wheezy

dajhorn pushed a commit that referenced this issue Mar 24, 2016
When various kernel debuging options are enabled this allocation
may be larger than usual as shown by the following warning.  It
is in no way harmful so we suppress the warning.

  SPL: large kmem_alloc(40960, 0x80d0) at
  tsd_hash_table_init:358 (76495/76495)

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #93
@dajhorn
Copy link
Member

dajhorn commented Apr 28, 2016

Other forms of this issue went wontfix after systemd integration, so I will similarly close this ticket as stale because it has the Ubuntu label.

@dajhorn dajhorn closed this as completed Apr 28, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants