[solved] kernel 2.6.27 - open LUKS encrypted root partition fails

Hi,
after updating to kernel 2.6.27 the passphrase for my LUKS encrypted root partition does not work anymore.
I get this error messages:
Enter LUKS passphrase:
device-mapper: table: 254:0 crypt: Error allocating crypto tfm
device-mapper: ioctl: error adding target to table
device-mapper: ioctl: device doesn't appear to be in the dev hash table.
Command failed: No key available with this passphrase.
Enter LUKS passphrase:
With a old (2.6.25) vanilla kernel it works.
any ideas?
EDIT
Solved.
The Problem was that I had this line in my mkinitcpio.conf to get rid of the padlock-error-message at boot.
#CRYPTO_MODULES="aes_i586 aes_generic sha256_generic"
With kernel 2.6.27 there are new / more modules needed to open the LUKS encryptet root partition.
So I removed the line from mkinitcpio.conf and deletet the padlock modules in /lib/modules/2.6.27-ARCH before regenarating the initrd image.
Thanks to GerBra for the tip.
Last edited by SiD (2008-10-22 11:41:56)

I'm not shure, but think ... yes.

Similar Messages

[solved] Encrypted root partition decrypts, not recognised on boot

Hello everyone
As per the wiki entry on system encryption with LUKS, I have an unencrypted boot partition (sda1) and a second encrypted partition (sda2) containing everything else, including root. This is on an eeepc 901 (I'm posting here, though, as I understand this as a mounting issue rather than laptop/netbook specific).
I have just done a full system upgrade, including moving to kernel 2.6.34-ARCH. Now, although I am prompted for the passphrase, which is accepted. I subsequently see the following:
::Checking Filesystems [BUSY] fsck.ext2: No such file or directory while trying to open /dev/mapper/root
/dev/mapper/root:
The superblock could not be read or does not describe a correct ext2 filesystem.
If the device is valid and it really does contain an ext2 filesystem (and not swap or
ufs or something else), then the superblock is corrupt, and you might try running
e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Runnig ecfsck -b 8193 /dev/mapper/root simply results in that error message being repeated. Googling and searching the forum only really found this thread to be anything similar. As per the suggestions there, the encrypted partition is last in /etc/fstab and the <options> value is populated:
/dev/sda1 /boot ext2 defaults 0 1
/dev/sdb1 /mnt/sdb1 vfat rw #This is an sdhc card permanently inserted
/dev/mapper/root / ext2 defaults 0 1
/etc/crypttab is entirely commented out, as it advises the root partition needs to be defined in the initramfs.
I can decrypt and open the partition using systemrescuecd, and fsck confirms the partition is clean. Equally, I can access the decrypted partition from the maintenance shell I get dumped into.
I'd be very grateful for any suggestions.
Last edited by Sagittar (2010-07-17 03:40:49)

Thanks for responding. I can confirm /dev/sda2 is ext2: after mounting both partitions with the -r flag, df -T reports ext2 file systems. (The theory is that ext2 helps prolong the life of the SSD in the eee pc. Not that that's entirely relevant here.)
I can't see a way of booting off sysresccd with root=/dev/sda2 without decrypting /dev/sda2 first. I am able to do that from Grub. Is there something I'm missing?
However, when I pay more attention to what happens on sysresccd when I decrypt the partition, I get the following:
% cryptsetup luksOpen /dev/sda2 root
Enter passphrase for /dev/sda2:
device-mapper: remove ioctl failed: Device or resource busy
Key slot 0 unlocked.
So, although I can then mount /dev/sda2 (or, to be precise, /dev/mapper/root) as normal, my guess is that the third line is a big clue as to why my normal boot process fails. I am pursuing that now.

SOLVED: kernel loads, but doesn't have a root file system

Hi,
The system is an Asus X202E. It does UEFI and has a GPT partition system. I've gotten through that part. And it is clear to me that the kernel loads.
It's the next step that's giving me grief. I've tried this with two bootloaders: gummiboot and rEFInd.
With gummiboot, the kernel panics because it can't mount the root file system. With rEFInd, it gets to the intial ramdisk and then drops me to a shell, apparently because the root file system is set to null, and it obviously can't mount that as "real root".
Here is what I posted on the Arch mailing list, documenting that I have indeed specified the correct root (I'm copying this from the email, eliding the unfortunate line wraps):
bridge-live# cat /boot/loader/entries/arch.conf
Title Arch Linux
linux /vmlinuz-linux
initrc /initramfs-linux.img
options root=PARTUUID=d5bb2ad1-9e7d-4c75-b9b6-04865dd77782
bridge-live# ls -l /dev/disk/by-partuuid
total 0
lrwxrwxrwx 1 root root 10 Apr 15 19:26 0ab4d458-cd09-4bfb-a447-5f5fa66332e2 -> ../../sda6
lrwxrwxrwx 1 root root 10 Apr 15 19:26 3e12caeb-1424-451c-898e-a4ff05eab48d -> ../../sda7
lrwxrwxrwx 1 root root 10 Apr 15 19:26 432a977b-f26d-4e75-b9ee-bf610ee6f4a4 -> ../../sda3
lrwxrwxrwx 1 root root 10 Apr 15 19:26 95a1d2c2-393a-4150-bbd2-d8e7179e7f8a -> ../../sda2
lrwxrwxrwx 1 root root 10 Apr 15 19:26 a4b797d9-0868-4bd1-a92d-f244639039f5 -> ../../sda4
lrwxrwxrwx 1 root root 10 Apr 15 19:26 d5bb2ad1-9e7d-4c75-b9b6-04865dd77782 -> ../../sda8
lrwxrwxrwx 1 root root 10 Apr 15 19:26 ed04135b-bd79-4c7c-b3b5-b0f9c2fe6826 -> ../../sda1
lrwxrwxrwx 1 root root 10 Apr 15 19:26 f64f82a7-8f2b-4748-88b1-7b0c61e71c70 -> ../../sda5
The root partition is supposed to be /dev/sda8, that is:
lrwxrwxrwx 1 root root 10 Apr 15 19:26 d5bb2ad1-9e7d-4c75-b9b6-04865dd77782 -> ../../sda8
So the correct PARTUUID followed by the one I have specified in
arch.conf is:
d5bb2ad1-9e7d-4c75-b9b6-04865dd77782
d5bb2ad1-9e7d-4c75-b9b6-04865dd77782
I'm guessing that this is really the same problem with both gummiboot and with rEFInd, but don't really know. It's clear to me that the initrd is not being correctly constructed. So I removed /etc/mkinitcpio.conf and did, as per the Arch wiki,
pacman -Syyu mkinitcpio linux udev
No joy.
I don't even know which way to go at this point. If I even knew how to tell it where the real disk is in the initial ram disk shell, that would help. Better of course, would be actually solving the problem.
Thanks!
Last edited by n4rky (2013-04-17 21:41:36)

I have made extremely limited progress on this issue.
My previous attempt to specify the root partition in mkinitcpio.conf was insufficient. Furthermore, this is no place--despite the documentation--for the orthodoxy about using UUIDs rather than the straight /dev/sdx. In my case:
root=/dev/sda8
and run
mkinitcpio -p linux
It still drops me into the shell at boot. I can do
mount /dev/sda8 /new_root/
and exit the shell. It still won't believe it has the root device and drops me back in. I just exit.
At this point, for a very brief moment, things look promising. It appears to be starting normally. Then, gdm.service, NetworkManager.service, and dbus.service all fail to start. There may be others but the screen goes by too quickly. At this point, it hangs trying to initialize the pacman keyring and all I can do is CTRL-ALT-DEL.
It occurred to me that this might extend to the rEFInd configuration and so I modified it to also use /dev/sda8 rather than the UUID, but this made no difference. Trying to boot via gummiboot still yields the previously specified kernel panic.

Luks encrypted root on sd card - problem with hooks

Hi,
I was trying to set up my arch system on an SD card on EeePC. I was using arch like that for about 4 months already, before my card crapped out, so now I have to reinstall it on a new card.
This time I thought I make an effort and use encrypted root, just like it is in the wiki.
I followed it exactly, and everything went fine - except when I actually tried to boot the system, it didn't work. Apparently the "encrypt" hook is being executed earlier than my /dev/sdb2 is recognized by the system.
However, when I use the arch-install cd to boot it ("arch root=/dev/sdb2") it correctly asks for my password and everything is fine, I'm in my newly installed system!
So, is this difference because the arch-install uses a different order of hooks? Or because it has to wait for the cdrom to settle, the /dev/sdb2 is not too late anymore?
I guess one solution would be is adding a "sleep 5" or something to the "encrypt" hook at installation. Where does the arch install find that version of "encrypt" that mkinitcpio uses during the install?
Or - is there any better solution? Like rearranging the order of hooks?
Thanks!

It doesn't seem to help - i think the "rootdelay=" kernel parameter only appears to have a difference at a different stage (and I think the [usb] hook has that already)
The problem is, that the udev hook (or the hardware recognition in [autodetect]?) doesn't finish before the [encrypt] hook runs.
I can see, that the hook [encrypt] passes, and a few lines afterwards "waiting for devices to settle", then the /dev/sdb is recognized....
Using the install CD - all hardware section finishes way before [arch_encrypt]...

LVM + LUKS + TRIM @ root partition

Hi.
I'm installing a fresh arch linux PC right now with LVM + LUKS and TRIM because i have one SSD , and UEFI mobo.
SSD has a physical partition for the /boot and the rest one used with LVM where a virtual group created called "lvmRootPool" which contains two logical volumes ("lvmRootPool-root" and "lvmRootPool-swap")
The lvmRootPool-swap was kept for swap and
the lvmRootPool-root for /.
Here comes the question. I want to enable TRIM for that disk (i know the security risk) and following this guide i have to add a specific line with discard keyword in /mnt/etc/crypttab (i'm before chroot). But when i open the /mnt/etc/crypttab it has a note saying
Do not list your root partition here, it must be set up beforehand by the initramfs (/etc/mkinitcpio.conf)
So what i supposed to do ? Should i add that line at crypttab file or not ?
lvmRootPool-root /dev/sda2 none luks,discard
Also , is it possible to use TRIM for swap ? I think that isn't but maybe something have been changed that i don't know.
Thank you.
Last edited by netpumber (2015-05-24 18:06:40)

maybe your missing pieces are: https://wiki.archlinux.org/index.php/So … IM_for_LVM and https://wiki.archlinux.org/index.php/Dm … encryption
In a nutshell:
For encryption you need to change the kernel parameter in your bootloader, add encryption and resume hook to mkinitcpio.conf. If the hooks are at the right spots, it just works for swap as well.
For LVM passthru there is a setting described in the link above
You still need the discard flags in your fstab.

Trouble with luks non root partition

hello,
today i struggled with creating an encryptet archlinux installation.
what i want is to encrypt my root and all other partitions with luks.
basically i used the guide on the archwiki ( https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS ),
but iam always failing at the same point.
my setup is a bit more complex, but to describe my problem i want to use a simple testcase
/dev/sda with 2 partitions
/dev/sda1 as /boot
/dev/sda2 as crypto_LUKS
/dev/sdb with 1 partition
/dev/sdb1 as crypto_LUKS
/dev/sda2 should be / and /dev/sdb1 f.eks. /home
iam using passphrases for both partitions.
i edited the HOOKS line in mkinitcpio.conf and added "encrypt" before "filesystems",
and i also edited the crypttab to somethink like this:
sdb1_crypt /dev/sdb1 none luks
my fstab entry for /home looks like
/dev/mapper/sdb1_crypt /home ext4 rw,relatime,data=ordered 0 1
so far so good, when iam booting iam prompted for passphrases 2 times. first time to encrypt and mount the root-partition, which works fine.
second time for the /home partition, but then the boot process stucks and systemd times out
[ OK ] Found device /dev/mapper/sdb1_crypt
[ OK ] Started Cryptography Setup for sdb1_crypt
[ OK ] Reached target Encryptet Volumes
[ TIME ] Timed out waiting for device dev-mapper/sdb1_crypt
[ DEPEND ] Dependency failed for /home
[ DEPEND ] Dependency failed for Local File Systems
iam thrown to emergency shell then.
/dev/mapper/sdb1_crypt exists, but when iam trying to mount it with
mount /dev/mapper/sdb1_crypt /mnt
it says
mount: special device /dev/mapper/sdb1_crypt does not exist
cryptsetyp says , that /dev/mapper/sdb1_crypt is inactive.
anyway i can luksOpen it manually with
cryptsetup luksOpen /dev/sdb1 foo
enter passphrase again and now iam able to mount /dev/mapper/foo
what am i missing in my here?
thanks for helping !
ineb

I just worte this. It dose not cover the LVM part. However, you do not need to do anything for that.
Just add this between "keymap encrypt" and "filesystems" in the HOOKS= array
lvm2
Also, becuase you have more then mone parition that is encrypted and needs to be decrypted at boot, you may need to have this the the /etc/default/grub instead of what what I put in the post I linked to.
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root cryptdevice=/dev/sdb1:home"
The `grub-mkconfig -o /boot/grub/grub.cfg` command WILL find all your LVM2 lv's with no problem and configure grub.cfg correctly. You just need to edit /etc/default/grub and use that command to rebuild the grub.cfg
Other then that this post should solve your problems.
https://bbs.archlinux.org/viewtopic.php … 2#p1209702
Last edited by hunterthomson (2012-12-25 02:40:23)

Issues with installing and booting encrypted root partition.

Hello all,
I am trying to install ArchLinux using the guide here:
http://wiki.archlinux.org/index.php/LUKS_Encrypted_Root
It all works fine until the very end when it comes to booting the system, The thing is that my method varies slightly from what is in the file.
I am having my /boot on my usb drive, I also have my keys on my usb drive albeit on a different partition.
I put into the menu.lst file:
root (hd1,0)
kernel /vmlinuz26 root=/dev/sda1 root ro cryptkey=/dev/sdb3:vfat:/sda1.key
initrd /kernel26.img
Everytime I try to boot I get the following error:
Booting 'Arch Linux'
root (hd1,0)
kernel /vmlinuz26 root=/dev/sda1 root ro cryptkey=/dev/sdb3:vfat:/sda1.key
Error 17: Cannot mount selected partition
Press any key to continue
I really hope someone here can help me.
Thanks allot
Last edited by constant (2009-03-16 15:28:26)

OK thanks allot, Your correct my /boot is on /dev/sdb1. Through trial and error I found root(hd0,0) worked for me although I now get another error where it is just not booting, http://wiki.archlinux.org/index.php/Ins … _a_USB_key for those who have this issue in the future...
As forum etiquette goes, Would it be considered bad here if I continued to discuss new issues in this thread or should I create a new one? I am not a leach nor am I the sort to do no research, It is just that some of this is a bit out of my area and often the errors to me seem rather non-descriptive, I do try my best to research for myself however as proven above I do miss things!
Thanks allot zyghom, I really appreciate the help.
Last edited by constant (2009-03-16 17:02:28)

Luks encrypted key file as key for luks partition (two-factor auth)

I'm trying to implement "two-factor" authentication (possession of a keyfile and knowledge of a passphrase required) using dm-crypt in order to open an encrypted root filesystem. In the past I used gpg and later openssl to decrypt a keyfile using a passphrase, which then was used by cryptsetup using --key-file to decrypt the actual data device. I'd like to ditch gpg/openssl and use only cryptsetup.
So the idea is to create a luksFormatted key file (loop device) which, when opened using a passphrase, will be used as the key (using --key-file) to open a luksFormatted hard drive partition.
To illustrate:
# create and luksFormat the key container file
dd if=/dev/urandom of=key_container bs=1M count=4
cryptsetup luksFormat key_container
# open the container and create a random "key" by directly writing pseudo random data to it
cryptsetup luksOpen key_container key_device
dd if=/dev/urandom of=/dev/mapper/key_device
# luksFormat the data device using the random data from the luks key device
cryptsetup -d /dev/mapper/key luksFormat /dev/sda1
# later, to open /dev/sda1
cryptsetup -d /dev/mapper/key_device luksOpen /dev/sda1 encryptedfs
My questions:
1. Is this a valid approach or am I making a mistake/do you see a problem somewhere?
2. How much data from the loop device will cryptsetup use as key to format/open the data device? Everything? Is there a limit?
3. Is there a difference between doing a
cat /dev/mapper/key | cryptsetup -d -
and
cryptsetup -d /dev/mapper/key?
3. Assuming that the answer to 1 is "no mistake/problem" and 2 is "everything there is" or even "the first x bytes", is it possible that the actual contents of the loop device may change in the future because of different loop device implementations or somethings else I didn't think of? I'd like to avoid bad surprises in the future..
4. What would you recommend as size for the key container file, knowing that the luks header requires some space too?
Any feedback appreciated.
Cheers,
fabriceb

I do the same ( https://wiki.gentoo.org/wiki/Custom_Ini … ed_Keyfile ).
--key-file=- should be equivalent, but it's meant for grabbing a key from gpg output or whatever; since you can specify it directly here, no need to involve anything else like cat etc.
without --key-file=- it would stop reading at newlines or something. this behaviour is quite dangerous as it may cause people who believe they're using a long random key, to use only a very short (or even empty) key instead. one way to avoid such ambiguousness is to make sure there are no newline bytes in your keyfile, so it would use the whole thing in either interpretation.
as for the key length, a key is essentially a passphrase. So it does not have to be very long at all; 8 truly random bytes would require up to 256^8 tries to break after all and with LUKS, each try takes ~1 second per physical CPU... but the smallest unit that LUKS allows is 512 bytes (1 sector) so you could just as well use the whole thing. If you use 4096 bytes, you're confusing bytes with bits somewhere... and as for bits, even 128bit AES is still considered secure...
You could save some bytes in the initrd.gz if you initialize the container file with zeroes instead of random, so it can be compressed. The key will still be random as the random cipher key will turn the zeroes to something else after all...

[SOLVED] Running Systemd service on login (encrypted home partition)

Hi,
I have a dm-crypt/LUKS encrypted home partition that's mounted via PAM on login. I'm trying to use a systemd service (profile-sync-daemon), but the service tries to start and access the home partition before the partition is mounted. The service does seem to start successfully, but it doesn't gain access to necessary files on the home partition and malfunctions later on. Is there a sane hack to somehow delay the start of the service until the relevant partition gets mounted (basically after login)? Manually starting the service after login works just as intended in this case - I'm just looking for a way to automate this process.
I have an idea of starting the service via Openbox autostart, but I've currently failed in my attempts.
Last edited by ggg377 (2015-05-28 18:31:10)

Things got quite complicated and hacky as I researched this so I went out of the box a bit (or took the easy way out, whichever you prefer) and reinstalled Arch with a full disk encryption. All is fine now and I also expect to see less problems overall in the future. If anyone wants to continue researching this it would probably be a good idea to start a new thread.

How to shrink an LUKS encrypted partition?

Alright, so I have this external hard drive with 1TB. I created 1 partition on it which spans the whole drive. Then I luks-encrypted this partition and put an ext4 filesystem on it. Now I need to make a second partition on it (~8GB). So how would I accomplish this without data loss?
I googled, but only found information about lvm-setups. In this case I don't use lvm.
Should I first resize the partition using fdisk and then somehow tell luks that the partition got smaller and last but not least resize the ext4 fs inside?
Could somebody help me out?
Edit: Alright so this is definitely the wrong way. I think first resizing the ext4 partition, then the partitiontable and then the luks should do the trick. Will try out and then report back.
Edit2: Alright this worked without problems.
Last edited by Watermel0n (2010-07-02 10:21:15)

I'd like to resize 2 LUKS partitions, so I'm wondering what did you do after resizing ext4 filesystem. I think you used resize2fs for the first step, but I don't know how you resized the physical partition without deleting/recreating it.

Kernel updates kill my luks encrypted system

All right, this is weird. I have a 64bit system with encrypted root, home and swap partitions. To setup I followed the wiki here:
https://wiki.archlinux.org/index.php/LUKS
My swap is encrypted like described here:
https://wiki.archlinux.org/index.php/LU … sk_support
Since the updates to kernel 3.1 each new kernel update kills my system. Pacman says while upgrading
[2011-11-08 08:21] >>> Updating module dependencies. Please wait ...
[2011-11-08 08:21] >>> Generating initial ramdisk, using mkinitcpio. Please wait...
[2011-11-08 08:21] ==> Building image from preset: 'default'
[2011-11-08 08:21] -> -k /boot/vmlinuz-linux_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img_64
[2011-11-08 08:21] ==> Starting build: 3.1.0-3-ARCH
[2011-11-08 08:21] -> Parsing hook: [base]
[2011-11-08 08:21] -> Parsing hook: [udev]
[2011-11-08 08:21] -> Parsing hook: [autodetect]
[2011-11-08 08:21] -> Parsing hook: [pata]
[2011-11-08 08:21] -> Parsing hook: [scsi]
[2011-11-08 08:21] -> Parsing hook: [sata]
[2011-11-08 08:21] -> Parsing hook: [usbinput]
[2011-11-08 08:21] -> Parsing hook: [keymap]
[2011-11-08 08:21] -> Parsing hook: [usb]
[2011-11-08 08:21] -> Parsing hook: [encrypt]
[2011-11-08 08:21] -> Parsing hook: [openswap]
[2011-11-08 08:21] -> Parsing hook: [resume]
[2011-11-08 08:21] -> Parsing hook: [filesystems]
[2011-11-08 08:21] ==> Creating gzip initcpio image: /boot/initramfs-linux.img_64
[2011-11-08 08:21] ==> Image generation successful
[2011-11-08 08:21] ==> Building image from preset: 'fallback'
[2011-11-08 08:21] -> -k /boot/vmlinuz-linux_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img_64 -S autodetect
[2011-11-08 08:21] ==> Starting build: 3.1.0-3-ARCH
[2011-11-08 08:21] -> Parsing hook: [base]
[2011-11-08 08:21] -> Parsing hook: [udev]
[2011-11-08 08:21] -> Parsing hook: [pata]
[2011-11-08 08:21] -> Parsing hook: [scsi]
[2011-11-08 08:21] -> Parsing hook: [sata]
[2011-11-08 08:21] -> Parsing hook: [usbinput]
[2011-11-08 08:21] -> Parsing hook: [keymap]
[2011-11-08 08:21] -> Parsing hook: [usb]
[2011-11-08 08:21] -> Parsing hook: [encrypt]
[2011-11-08 08:21] -> Parsing hook: [openswap]
[2011-11-08 08:21] -> Parsing hook: [resume]
[2011-11-08 08:21] -> Parsing hook: [filesystems]
[2011-11-08 08:21] ==> Creating gzip initcpio image: /boot/initramfs-linux-fallback.img_64
[2011-11-08 08:21] ==> Image generation successful
So the generation of the initramfs seems to be ok.
But when I reboot this box, I get:
running hook [openswap]
device /dev/sda4 doesn't exist or access denied
running hook [resume]
waiting 10 seconds for device /dev/mapper/swapDevice
waiting 10 seconds for device /dev/mapper/root
root device /dev/mapper/root doesn't exist. Attempting to create it.
ERROR: unable to determine major/minor number of root device /dev/mapper/root
/dev/sda4 is my swap partition. Then I get dropped to a recovery shell which I can't use because my (usb) keyboard is not working.
Now the funny part. I start the box from a install cd and chroot into the existing installation. I do a
mkinitcpio -p linux
The initramfs is regenerated and it works again! What the hell is pacman doing other than regenerate the initramfs with my presets?
Harvey
Last edited by Harey (2011-11-12 16:10:48)

New kernel 3.1.1 did it again. My system hangs in initramfs after the reboot. Same as before: a simple rebuild without any changes fixed the boot process. This time I was able to backup the 'bad' initramfs before chrooting in and rebuilding.
it is very funny to see the content of the 'bad' initramfs image - it is nearly empty!
==> Image: /boot/initramfs-linux.img_64.bak
==> Kernel: unknown
==> Compressed with: gzip
-> Compression ratio: .452
-> Estimated decompression time: 0.036s
==> Included binaries:
/sbin/dmsetup
/sbin/cryptsetup
/sbin/udevadm
/sbin/blkid
/sbin/modprobe
/bin/busybox
==> Hook run order:
udev
keymap
encrypt
openswap
resume
The rebuilt image looks like this:
==> Image: /boot/initramfs-linux.img_64
==> Kernel: 3.1.1-1-ARCH
==> Compressed with: gzip
-> Compression ratio: .593
-> Estimated decompression time: 0.047s
==> Included modules:
aes_generic fcrypt hid-roccat-kone rmd160
aesni-intel ff-memless hid-roccat-koneplus rmd256
aes-x86_64 gcm hid-roccat-kovaplus rmd320
af_alg gf128mul hid-roccat-pyra salsa20_generic
ahci ghash-clmulni-intel hid-samsung salsa20-x86_64
algif_hash ghash-generic hid-sjoy scsi_mod
algif_skcipher hid hid-sony sd_mod
ansi_cprng hid-a4tech hid-speedlink seed
anubis hid-apple hid-sunplus seqiv
arc4 hid-axff hid-tmff serpent
async_memcpy hid-belkin hid-topseed sha1_generic
async_pq hid-cherry hid-twinhan sha256_generic
async_raid6_recov hid-chicony hid-uclogic sha512_generic
async_tx hid-cypress hid-wacom snd
async_xor hid-dr hid-waltop snd-rawmidi
ata_piix hid-elecom hid-wiimote snd-seq-device
authenc hid-emsff hid-zpff soundcore
authencesn hid-ezkey hid-zydacron sr_mod
blowfish hid-gaff hifn_795x syscopyarea
camellia hid-gyration hmac sysfillrect
cast5 hid-holtekff jbd2 sysimgblt
cast6 hid-kensington khazad tcrypt
cbc hid-keytouch lcd tea
ccm hid-kye libahci tgr192
cdrom hid-lcpower libata twofish_common
crc16 hid-logitech lrw twofish_generic
crc32c hid-magicmouse lzo twofish-x86_64
crc32c-intel hid-microsoft mbcache uhci-hcd
cryptd hid-monterey md4 usbcore
crypto_null hid-multitouch md5 usbhid
ctr hid-ntrig michael_mic usb-storage
cts hid-ortek padlock-aes vmac
deflate hid-petalynx padlock-sha wp512
des_generic hid-picolcd pata_acpi xcbc
dm-crypt hid-pl pata_jmicron xor
dm-mod hid-prodikeys pcbc xts
ecb hid-quanta pcrypt zlib
ehci-hcd hid-roccat raid6_pq zlib_deflate
ext4 hid-roccat-arvo raid6test
fb_sys_fops hid-roccat-common rmd128
==> Included binaries:
/bin/busybox
/sbin/udevadm
/sbin/dmsetup
/sbin/blkid
/sbin/cryptsetup
/sbin/modprobe
==> Hook run order:
udev
keymap
encrypt
openswap
resume
For some reason the initramfs built by pacman is missing all modules. To say it again, nothing changed, simple rebuilt by mkinitcpio -p linux!
This seems to be a bad bug...
Harvey
Last edited by Harey (2011-11-12 16:07:09)

[SOLVED] Installation with LUKS encryption--ok to grub, then black s..

Installation with LUKS encryption--ok to grub, then black screen
I'm trying to install ArchLinux onto an existing Luks encrypted HDD, formerly dual boot with Fedora 17.
First,I left the Windows partition unchanged and erased the root partition. Then I booted to the ArchLinux, mounted and decrypted the LVM encrypted volume group partitions and followed along with the Beginner's Guide Installation Instructions. This progressed without a hitch; near as I can tell. I can boot to grub select kernel interface, but no further.
So I forgot something...the encrypted volume. I found the archLinux page dm-crypt with LUKS and tried my best to follow along encouraged by the first line, "The installation of a LUKS-encrypted system is largely the same as installing an unencrypted system."
And that's where I stand. I edited the grub.cfg to boot to run level 3, but the kernel doesn't seem to load at all and never starts to give me the chance to enter the password. So now I'm not sure if its the LUKS encryption after all. (maybe its my _next_ problem)
Any ideas?
Last edited by xtian (2013-09-17 22:03:48)

Sure, here's the layout,
# lsblk -fa
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 vfat xxxx-xxxx
├─sda2 ext4 xxxxxxxxxxxxxxxxxxxxx /boot
└─sda3 crypto_L xxxxxxxxxxxxxxxxxxxx
└─luks-93xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (dm-0) LVM2_mem xxxxxxxxxxxxxxxxxxxxxxx
├─cryptVG-root (dm-1) ext4 xxxxxxxxxxxxxxxxxxxxxxxxxxxx /
├─cryptVG-swap (dm-2) swap xxxxxxxxxxxxxxxxxxxxxxxxxxxx [SWAP]
├─cryptVG-home (dm-3) ext4 home xxxxxxxxxxxxxxxxxxxxxxxxxxxx /home
└─cryptVG-local (dm-4) ext4 local xxxxxxxxxxxxxxxxxxxxxxxxxxxx /usr/local
I left sda1 alone. Reinstalled on sda2 (/boot) and sda3 (cryptVG-root). I also remade swap. I didn't see an opportunity to set /usr/local, so I may simply free up this space after copying the data. But for home I set up a sub directory for the new install and left the old user in place (something I've been wanting to accomplish for some time as anaconda is not so nice to old user files).

[SOLVED] Booting a luks encrypted system directly from UEFI firmware

I've been struggling somewhat with my first UEFI machine (a Toshiba laptop).
The wiki got me to a basic four-partition install okay, and then after a small amount of pain I managed to get a build booted okay from gummiboot and with with root, swap and home luks-encrypted.
What I'm trying to do now is boot directly from the UEFI using an appropriate firmware entry, ie with something like what's described in the EFISTUB Wiki page:
# efibootmgr -d /dev/sdX -p Y -c -L "Arch Linux" -l /vmlinuz-linux -u "root=/dev/sda2 rw initrd=/initramfs-linux.img"
...but I've been unable to achieve this with luks-encrypted partitions. Has anyone here had any success? Is there a "-u" parameter in the above command that will achieve this? I've certainly not found anything online explaining how this can be done, so maybe I'm being unrealistic and expecting too much.
Last edited by bananabrain (2015-06-18 14:45:56)

Head_on_a_Stick wrote:
Try this (untested -- I don't use encryption):
# efibootmgr -d /dev/sdX -p Y -c -L "Arch Linux" -l /vmlinuz-linux -u "cryptdevice=UUID=<UUID>:<mapped-name> root=UUID=<luks-UUID> rw initrd=/initramfs-linux.img"
You're a star - that works perfectly.
I wondered about lifting that syntax from "$esp/loader/entries/arch-encrypted.conf" in my last instalation but stupidly thought it was gummiboot-specific.
I'm as surprised that I couldn't find your solution on the web as I am that so few people seem interested in using UEFI firmware in this way. It seems like PC hardware has at last "grown up", with a versatile firmware that must have been a long time in collaborative development - something akin to Sun's OpenBoot - but the community's response has been to create another raft of boot loaders to sit on top of it. Maybe I'm missing something.
Thanks very much for your help.

[SOLVED] Kernel will not boot. No early hooks, nothing...

I am having some serious trouble getting my machine to boot. It never even gets to ":: running early hooks (udev)."
I normally shut it down every night, but I recently kept in on for a few days straight. I was having some trouble with a USB flash drive being read-only in Windows 8 in VirtualBox. I shut down Windows 8 and then arch wouldn't even read the flash drive. I'm pretty sure that pacman updated the kernel since I last shut down the machine, so I decided to restart just for good measure. I never got back in...
I am UEFI booting, running LVM on top of LUKS on top of two Samsung 830 256GB SSDs in mdadm raid 0. I have encrypted root and no swap. I have /boot mounted on a 512MB FAT32 partition and use a straight efibootmgr entry to start the system. It has worked fine until today.
My mkinitcpio.conf has
# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are run. Advanced users may wish to specify all system modules in this array.
MODULES="ahci dm_mod dm_crypt aes_x86_64 raid0"
# BINARIES
# This setting includes any additional binaries a given user may wish into the CPIO image. This is run last, so it may be used to override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=""
# FILES
# This setting is similar to BINARIES above, however, files are added as-is and are not parsed in any way. This is useful for config files.
# Some users may wish to include modprobe.conf for custom module options like so:
# FILES="/etc/modprobe.d/modprobe.conf"
FILES=""
# HOOKS
# This is the most important setting in this file. The HOOKS control the modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the order in which HOOKS are added. Run 'mkinitcpio -H <hook name>' for help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
## This setup specifies all modules in the MODULES setting above.
## No raid, lvm2, or encrypted root is needed.
# HOOKS="base"
## This setup will autodetect all modules for your system and should
## work as a sane default
# HOOKS="base udev autodetect pata scsi sata filesystems"
## NOTE: If you have /usr on a separate partition, you MUST include the
# usr, fsck and shutdown hooks.
## ORIGINAL ##HOOKS="base udev autodetect pata scsi sata filesystems usbinput fsck"
HOOKS="base udev autodetect sata mdadm usbinput keymap encrypt lvm2 filesystems fsck shutdown"
# COMPRESSION
# Use this to compress the initramfs image. By default, gzip compression
# is used. Use 'cat' to create an uncompressed image.
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=""
My kernel parameters are
cryptdevice=/dev/md1:RootVault root=/dev/RootArray/VolRoot ro rootfstype=ext4 init=/bin/systemd add_efi_memmap initrd=initramfs-linux.img
I can boot fine from the Arch install media via UEFI at which point I can luksOpen, activate the lvm volumes, mount everything, and chroot in like normal. I have:
rebuilt the initramfs
reinstalled linux, mkinitcpio, and udev
erased and recreated the efibootmgr entry
tried to boot straight from the UEFI shell
slimmed down to minimal hooks in mkinitcpio
tried nomodeset and mem=4G kernel parameters
tried booting the kernel with debugging enabled at various levels
I get nothing at all every time. I boot up to a black screen with a static white cursor in the top left.
I am happy to offer any more necessary information and I would be extremely grateful for any suggestions. Thanks.
Last edited by matthew02 (2012-11-02 15:14:46)

lesto wrote:
same problem here with a stock kernel. solver rolling back to 3.6.3-1 by livecd.
seems a problem with AMD cpu. solution here https://bbs.archlinux.org/viewtopic.php?id=151686
I had just rolled back my kernel and was about to comment here that it worked when I saw your post. I had actually skimmed that other post, but since mem=4G didn't work for me, I didn't figure it applied. I suppose I should have read it more thoroughly. Thanks for the help everyone!

[SOLVED] Encrypted root, /boot on USB, cryptkey issue

Well to the topic. Followed this guide.
Usb flash drive with GRUB and a keyfile on it. Encrypted root.
grub.cfg
linux /vmlinuz-linux root=UUID=<uuid> ro cryptdevice=/dev/disk/by-id/<id>:luks cryptkey=/dev/disk/by-uuid/<uuid>:ext2:/key ipv6.disable=1 quiet
echo 'Loading initial ramdisk ...'
initrd /initramfs-linux.img
mkinitcpio.conf
MODULES="ata_generic ata_piix nls_cp437 ext2 i915"
HOOKS="base udev autodetect modconf block encrypt filesystems keyboard fsck consolefont"
Result: "Meh can't read a keyfile. Please input a passphrase om nom nom."
Tried:
1. Quadruple-checked UUID's, used /dev/sdX instead of them.
2. Using different modules, like nls_utf8, removing ata_* stuff.
3. Playing with <path> and <keyfile> strings, slashes, e t c.
4. A barrel roll.
Is it actually possible to make that filesystem key reading work? If not, how can I get physical offset of keyfile in a filesystem?
UPDATE:
Trouble in device detection speed. Any other usb media get's recognized instantly, while the one I booted from is slow like hell.
Last edited by wfoojjaec (2013-08-14 14:37:11)

Marked as solved.
It seems that origin of a bug was somewhere in a kernel. After a recent update, done today of a 'linux' package a /boot usb device is properly recognized after about 5 seconds passed from poweron (instead of a full initialization at ~270 sec and hanging udev before).
A hack with fstab & noauto is not required now. <_<

[solved] kernel 2.6.27 - open LUKS encrypted root partition fails

Similar Messages

Maybe you are looking for