encrypt hook fails to find the root partition

Xi0N · 2014-10-30 07:37:57

I have arch installed on a 64Gb usb stick in order to have a live system I can take anywhere.
I already asked about this some time ago and couln't find a solution, but I might have new ideas now and I'´d like anyone to give their opinion
The stick ha three partitions.
1Gb ext4 Boot
17Gb dm-crypt Root Formatted with ext4 once it's unlocked
40Gb dm-crypt Home Formatted with ext4 once it's unlocked
The partition scheme is MBR in order to keep compatibility with older systems and the system itself is 32 bit for the same purpose.

Syslinux is the chosen loader and I had to predict that, because I'd boot the system on different machines, the partition number would vary depending on the disks on the system, so I went with UIID for the boot parameters on syslinux.cfg
I also reference all the partitions by UUID for the same reasons: Under /etc/crypttab and /etc/fstab

Now, the problem I'm facing is that sometimes, upon booting, the system finds the Root dm-crypt partition and sometimes it doesn't.
Seems pretty much random to me.
I'd get a message like "Waiting 10 seconds for the disk xxxxxxxxx....", then, it times out and I'd get thrown to a root shell.
Rebooting sometimes fixes it, sometimes does not, so I'd keep rebooting until it succeeds.
I tried with every possible combination for booting: by uuid, by id,.... I can't do it by label because dm-crypt partitions don't have label, so I tried redoing everything and setting GPT (GUID partitions) and referencing by label, with the same problem.

Now, I'm out of options and the next step would be try to put the encrypted partitions into LVM, see if this fixes the issue.

What do you people think the problem would be? Will setting LVM fix the issue?

BTW: The usb stick is not a cheap chinese device: It's a kingston datatraveller one, so the device quality theory should be off the table... I think.
I have had this kind of setup for several years now: The only difference is that i have been upgrading the capacity with new devices. From 16 Gb to 32 and now 64. This is the first time I'm facing this problem, and I learned to cope with it for months now, but it really annoys me.

Thanks.

Moviuro · 2014-11-01 21:37:53

Hi,

Some thoughts:

wrong order in the hooks in mkinitcpio.conf

In the syslinux line:

cryptdevice=UUID=<uuid>:<somename> root=UUID=<uuid of the ext4 part>

USB3 port incompatibility?

Good luck

Xi0N · 2014-11-01 22:14:45

I tried with lvm and nothing. The first partition would be a standard ext4 boot partition and the rest of the disk, lvm2 with root and home partitions.
I still get the same issues. Sometimes it works, sometimes it doesn't (also changed to gpt, by the way)
I'm starting to think the device being usb3 could have something to do.
About the hooks, this is what I have: base udev keyboard modconf block lvm2 encrypt filesystems fsck

Moviuro · 2014-11-01 22:19:55

I know nothing about LVM, so can't help you with that, sorry.
Also, the hooks seem to be correct, though you might want to give a try to:

HOOKS="systemd udev autodetect modconf block sd-vconsole keyboard sd-encrypt filesystems btrfs"

And of course adapt it to your case. Save your old initramfs beforehand. You might need to write things in the crypttab if it isn't already the case.

MickeyRat · 2014-11-02 12:32:42

It's not quite the same thing you are going for but, I have a netbook set up with syslinux and an encrypted partition with LVM patitions inside it. Never had a problem with the booting part.

Here are my hooks and the syslinux menu entry. Hope this helps.

HOOKS="base udev autodetect modconf block encrypt lvm2 filesystems keyboard fsck"

LABEL arch
    MENU LABEL Arch Linux
    LINUX ../vmlinuz-linux
    APPEND cryptdevice=/dev/sda3:mydisk root=/dev/mapper/mydisk-rootvol rw
    INITRD ../intel-ucode.img,../initramfs-linux.img

I'm no expert. I've only done this once and that time it worked fine but, as others have said order is important in the hooks and appends. Also for a flash drive I'm not sure you'd want the ../intel-ucode.img in the syslinux append. That's pretty hardware specific.

Last edited by MickeyRat (2014-11-02 12:35:43)

ANOKNUSA · 2014-11-02 13:25:01

If you're using LVM then the typical advice about using UUIDs just gets confusing (the physical partition, logical volume and LUKS container all have their own UUIDs), and really can just be ignored. Since VG and LV labels are unique, there's no chnace of them being overridden. Use the label-based path of your logical volumes instead:

 cryptdevice=/dev/<volume group name>/<logical volume name>:<device mapper name>:<options>

So if you've got a volume group named Arch, and you've labeled your logical volumes "root" and "home," you'd get:

cryptdevice=/dev/Arch/root:root

This would mount the logical volume "root" in the volume group "Arch" to /dev/mapper/root. You'd then just need to ensure your /etc/fstab file matched those mount points.

Xi0N · 2014-11-04 10:07:15

Nope, I tried all your options, guys: Specially, shifting the hooks order as MuckeyRat suggested, but I still have the same problem. ANOKNUSA: I'll try your suggestion when I find a couple free minutes.
Thanks

Xi0N · 2014-11-04 15:02:46

I tried what ANOKNUSA said with the same result.
The weird thing is that afterwards i get thrown to a simple terminal and if I
ls /dev/
I can see the device perfectly. Meaning, the device is there but the encrypt hook does not see it for some reason. OR, the device is generated after I'm thrown to the terminal, but before i get to perform the "ls" command.... This is driving me nuts.
I need more ideas, please.
Thanks to all of you for try helping You're the best.

EDIT: rootwait seems to not be working, or it does not seem to work. Here the syslinux entry:

LABEL arch
    MENU LABEL Arch Linux Test
    LINUX ../vmlinuz-linux
    APPEND cryptdevice=/dev/traveller64/lvolroot:root root=/dev/mapper/root rw rootwait
    INITRD ../initramfs-linux.img

Last edited by Xi0N (2014-11-04 16:26:50)

Arch Linux

#1 2014-10-30 07:37:57

encrypt hook fails to find the root partition

#2 2014-11-01 21:37:53

Re: encrypt hook fails to find the root partition

#3 2014-11-01 22:14:45

Re: encrypt hook fails to find the root partition

#4 2014-11-01 22:19:55

Re: encrypt hook fails to find the root partition

#5 2014-11-02 12:32:42

Re: encrypt hook fails to find the root partition

#6 2014-11-02 13:25:01

Re: encrypt hook fails to find the root partition

#7 2014-11-04 10:07:15

Re: encrypt hook fails to find the root partition

#8 2014-11-04 15:02:46

Re: encrypt hook fails to find the root partition

Board footer