[Solved] ... not > a LUKS volume and the crypto= not specified.

KairiTech · 2014-01-09 18:22:25

[Synopsis] Add a custom hook like the one shown lower down in this post for a three second pause before the encrypt hook. It's a dirty ugly hack. It's not r.i..g...h....t......! and shouldn't be allowed. I'm hoping it's really my hardware beginning to fail.

On my LVM2 on LUKS encrypted SSD RAID0 install most times the boot fails with the error message below:

... not > a LUKS volume and the crypto= parameter was not specified.

But if I re-boot a few times in succession (usually three or four times) the boot eventually succeeds. Don't recall this ever happening on a similar HDD install.

It is my understanding that this message comes from the encrypt hook so I can only assume that the real issue is that I'm not being prompted for the passphrase.

Is this really a timing issue? How do I insure that the passphrase prompt always appears as required to decrypt the RAID0 array?

Edit: Here's something similar.

Last edited by KairiTech (2014-01-18 19:57:17)

jasonwryan · 2014-01-09 19:11:31

Not an Installation issue, moving to Sysadmin...

guidop · 2014-01-11 04:45:43

Out of curiosity, I took a quick look at /usr/lib/initcpio/hooks/encrypt, which is the init script where it looks like you are failing a test of the "resolved" parameter, starting on line 63.

So your problem is not quite identical to mine.

It may be in both case that the hard drive(s) is(are) not ready when polled.

I am taking a wild guess here, but you may have success editing the /etc/default/grub file and adding rootdelay=60 to the list of arguments assigned to the variable GRUB_CMDLINE_LINUX_DEFAULT, i.e:

GRUB_CMDLINE_LINUX_DEFAULT="quiet rootdelay=60"

This may be a simpler way to resolve my blkid issue, too. I haven't had time to test it yet, though.

KairiTech · 2014-01-11 14:54:24

I don't use a bootloaded. Booting directly from the UEFI STUB kernel.

One thing I did notice that makes me suspect that you are on to something is that on occasion when I boot from my USB install media the drives are rearranged. sd{a,b,c} are for my 'production' RAID0 array and sdd is where I install to test things.

I've seen sdd turn up as sdc and sdc as sdd so of course my test install fails until I reboot to fix the drive ordering. I'll have take a closer look before I reboot when my 'production' boot fails.

guidop · 2014-01-13 02:13:01

Would you do me a favor and try creating and using the blkid_wait script I described in the other post?

I would add the blkid_wait to your hooks variable just before encrypt (maybe also before lvm2), then rerun mkinitcpio

If both the lvm2 and btrfs_advanced scripts need udev (or maybe systemd in your case) to finish setting up hard drive drivers, waiting for blkid to return a valid answer may also help fix your issue.

Can you also post your /etc/mkinitcpio.conf HOOKS variable?

KairiTech · 2014-01-17 20:37:12

I apologise for the late reply. I was working on a re-write of my install strategy.

With your hook I get the message below before the passphrase prompt and so far it hasn't failed to prompt me for the passphrase. So it seems it is a timing issue. Heavens forbid I hope one of my SSDs is starting to fail and it's not systemd booting too fast for SSDs. I've since lowered the time-out to 5 seconds and it still seems to work.

:: blkid_wait [FAIL]: blkid did not return /dev/mapper/vg64SSDx3 status within 60 seconds

Here's my HOOKS=:

HOOKS="base hushkernel consolefont udev autodetect block mdadm_udev keyboard keymap blkid_wait encrypt lvm2 filesystems           shutdown"

And since I know you are going to ask here's my hushkernel hook:

/usr/lib/initcpio/hooks/hushkernel

#!/usr/bin/ash

# https://bbs.archlinux.org/viewtopic.php?pid=1312342#p1312342

run_hook() {

   # http://unix.stackexchange.com/questions/44999/how-can-i-hide-messages-of-udev/45525#45525

   # The four values in printk denote: console_loglevel, default_message_loglevel, minimum_console_loglevel and default_console_loglevel respectively.

   # These values influence printk() behavior when printing or logging error messages. See 'man 2 syslog' for more info on the different loglevels.

   # • console_loglevel: messages with a higher priority than this will be printed to the console
   # • default_message_level: messages without an explicit priority will be printed with this priority
   # • minimum_console_loglevel: minimum (highest) value to which console_loglevel can be set
   # • default_console_loglevel: default value for console_loglevel

   #define  KERN_EMERG    "<0>"  /* system is unusable               */
   #define  KERN_ALERT    "<1>"  /* action must be taken immediately */
   #define  KERN_CRIT     "<2>"  /* critical conditions              */
   #define  KERN_ERR      "<3>"  /* error conditions                 */
   #define  KERN_WARNING  "<4>"  /* warning conditions               */
   #define  KERN_NOTICE   "<5>"  /* normal but significant condition */
   #define  KERN_INFO     "<6>"  /* informational                    */
   #define  KERN_DEBUG    "<7>"  /* debug-level messages             */

   echo "3 3 3 3" > /proc/sys/kernel/printk

}

/usr/lib/initcpio/install/hushkernel

#!/bin/ash

build() {
   add_runscript
}

help() {
   cat <<HELPEOF

This hook will suppress kernel messages during the boot LUKS password prompt

HELPEOF
}

Last edited by KairiTech (2014-01-18 03:13:47)

clfarron4 · 2014-01-18 15:30:27

#!/bin/ash

should be

#!/bin/bash

in both files.

KairiTech · 2014-01-18 19:49:55

clfarron4 wrote:

#!/bin/ash
should be
#!/bin/bash
in both files.

Really? All of the hooks that come with Arch say:

#!/usr/bin/ash

KairiTech · 2014-01-18 20:02:44

I added a custom hook for a 3 second pause before the encrypt hook:

/usr/lib/initcpio/hoo/kencrypt_wait

#!/usr/bin/ash

run_hook() {

   let wait=3
   let    i=0
   echo -en "encrypt hook wait: "
   while [[ ${i} -lt ${wait} ]]
      do
         echo -en "$((${wait}-${i}))."
         sleep 1
         i=$((${i}+1))
   done
   echo "0.....Okay! Let's go!"

}

/usr/lib/initcpio/install/encrypt_wait

#!/bin/ash

build() {
   add_runscript
}

help() {
   cat <<HELPEOF

This hook is a dirty hack to add a pause before the encrypt hook

HELPEOF
}

clfarron4 · 2014-01-18 21:57:55

KairiTech wrote:

clfarron4 wrote:
#!/bin/ash
should be
#!/bin/bash
in both files.
Really? All of the hooks that come with Arch say:
#!/usr/bin/ash

Well, I've never seen an executable at /usr/bin/ash or /bin/ash for what look like bash scripts.

progandy · 2014-01-18 22:34:52

clfarron4 wrote:

Well, I've never seen an executable at /usr/bin/ash or /bin/ash for what look like bash scripts.

The boot image uses busybox with ash (a simple bourn shell variant, Almquist-Shell) to ensure a small memory footprint. Only the real system has glibc, bash, coreutils, ...

Arch Linux

#1 2014-01-09 18:22:25

[Solved] ... not > a LUKS volume and the crypto= not specified.

#2 2014-01-09 19:11:31

Re: [Solved] ... not > a LUKS volume and the crypto= not specified.

#3 2014-01-11 04:45:43

Re: [Solved] ... not > a LUKS volume and the crypto= not specified.

#4 2014-01-11 14:54:24

Re: [Solved] ... not > a LUKS volume and the crypto= not specified.

#5 2014-01-13 02:13:01

Re: [Solved] ... not > a LUKS volume and the crypto= not specified.

#6 2014-01-17 20:37:12

Re: [Solved] ... not > a LUKS volume and the crypto= not specified.

#7 2014-01-18 15:30:27

Re: [Solved] ... not > a LUKS volume and the crypto= not specified.

#8 2014-01-18 19:49:55

Re: [Solved] ... not > a LUKS volume and the crypto= not specified.

#9 2014-01-18 20:02:44

Re: [Solved] ... not > a LUKS volume and the crypto= not specified.

#10 2014-01-18 21:57:55

Re: [Solved] ... not > a LUKS volume and the crypto= not specified.

#11 2014-01-18 22:34:52

Re: [Solved] ... not > a LUKS volume and the crypto= not specified.

Board footer