[SOLVED] Arch Linux on encrypted luks partition on USB key

The Infinity · 2014-08-08 19:28:05

Hi

I've installed Arch Linux on a USB key following this Wiki page: https://wiki.archlinux.org/index.php/In … _a_USB_key
I also used dm-crypt as described in this Wiki page: https://wiki.archlinux.de/title/Festpla … iante_1.29

I installed Arch Linux on the USB key using VirtualBox.
To do that, I created a "rawvmdk":

vboxmanage internalcommands createrawvmdk -filename ./usb.vmdk -rawdisk /dev/sdd

Everything works fine when I'm trying to start the system within VirtualBox.
Syslinux loads Arch using the following kernel command:

APPEND cryptdevice=UUID=6aa73872-3755-4bdf-bee3-d1cd7a3fe0bf:main root=/dev/mapper/main-root rw

/etc/mkinitcpio.conf holds the following "HOOKS" configuration:

HOOKS="base udev autodetect modconf block keyboard keymap encrypt lvm2 filesystems fsch resume"

As already mentioned the configuration works within VirtualBox. When I'm trying to boot from the USB key on my real computer, I'm getting an error. Syslinux works fine and loads Linux, but Linux is complaining. Here's the log:

.....
:: running hoock [encrypt]
Waiting 10 seconds for device /dev/disk/by-uuid/6aa73872-3755-4bdf-bee3-d1cd7a3fe0bf ...
ERROR: device '/dev/mapper/main-root' not found. Skipping fschk.
ERROR: Unable to find root device '/dev/mapper/main-root'.
You are being dropped to a recovery shell
.....

I'm not getting prompted for the passphrase since the cryptdevice can not be found. But why? It can be found when I'm booting within VirtualBox. What might be different? I successfully installed other Linux distributions (but without encryption and using GRUB as bootloader) previously within VirtualBox and was able to boot from the USB key on a real machine afterwards.

Some additional information that might help:
Here's the "lsblk -f output" for the stick:

sdd                                                           
├─sdd1 ext4     usbboot  bb45e84e-842e-4209-8c44-1af3c7933389 
└─sdd2 crypto_L          6aa73872-3755-4bdf-bee3-d1cd7a3fe0bf

When I'm running "lsblk" or "blkid" from the recovery shell after the failure, I'm getting no output. "ls /dev/sd*" returns nothing as well. The directory /dev/disk does not even exists in the recovery shell. (I'm not sure if this is normal or not.)

Thanks for helping.

Last edited by The Infinity (2014-08-14 20:26:06)

alphaniner · 2014-08-08 19:51:27

Tried booting from the fallback image?

The Infinity · 2014-08-08 19:56:43

No, I'm going to try.

EDIT: I've tried it and it worked. All devices are recognized as expected and all partitions can be decrypted and mounted as configured in /etc/fstab. The normal image still does not work.

The task is not to figure out the difference between the two images and which of these could cause the problem.

Last edited by The Infinity (2014-08-08 20:11:33)

alphaniner · 2014-08-08 20:29:53

The normal image shouldn't work, as the 'autodetect' hook would have tailored it to the VBox virtual hardware. That's the whole point of autodetect. Just boot using the fallback image then regenerate.

The Infinity · 2014-08-08 21:26:18

Thanks for your help.
I've booted the fallback image and regenerated. The normal image works now too. But of course not when booting again within VirtualBox.

Should I remove the "autodetect" option from the normal image to allow booting independent from the hardware configuration? The Wiki page mentioned above says nothing about the usage of "autodetect".

But now I've discovered another problem:
Starting the X via startx does not work (it does within VirtualBox). I'm just getting a message like "Waiting the xserver to begin accept connections ...". I'm now going to figure out what the reason for this could be.

Last edited by The Infinity (2014-08-08 21:26:38)

alphaniner · 2014-08-08 21:55:13

Should I remove the "autodetect" option from the normal image to allow booting independent from the hardware configuration?

That's what the fallback image is: the normal image built without the 'autodetect' hook. If you manually remove 'autodetect' you'd wind up with two identical images. If don't want a hardware dependent image then you'll need to modify the preset file (in /etc/mkinitcpio.d/ ) as well as mkinitcpio.conf .

The Infinity · 2014-08-08 22:15:00

What do I need to modify? Currently only an empty string is assigned to the "default_options". Should I simply remove the fallback image to be created since having two identical images is needless?

To the X problem:
I don't have a /etc/xorg.conf which contains hardware specific configuration. Do you have an idea where I possibly have a X related configuration which is hardware depended?

Last edited by The Infinity (2014-08-08 22:49:17)

The Infinity · 2014-08-10 21:09:41

I have checked the X log file at /var/log/Xorg.0.log for useful information but there are no log entries for my attempts to start the X server on my real machine. It looks like I have never tried to start X. Is there maybe another place to look for information helping to figure out what's going on?

I have also the recommended video drivers installed: xf86-video-vesa mesa xf86-video-ati xf86-video-intel xf86-video-nouveau xf86-video-nv (https://wiki.archlinux.org/index.php/In … patibility)

When trying to shutdown the system when it is not running in VirtualBox I'm getting stuck at

kvm: exiting hardware virtualization

Last edited by The Infinity (2014-08-14 18:13:55)

The Infinity · 2014-08-14 18:35:16

I still haven't solved the problem:

When starting the system on a machine with NVIDIA GTX 560Ti graphics card:
- X doesn't start using startx or xinit and there are no log entries in /var/log/Xorg.*.log (as I haven't tried to start X).
- I'm getting the message "Waiting for X server to begin accepting connections .. .. .. ..".
- I already tried to uninstall xf86-video-nouveau and nouveau-dri with no effect.
- Additionally: The "default terminals tty1/2/3/..." (which I'm using to start X) from have a poor resolution (I think 640x480 pixel).

When starting the system on a virtual machine or a machine with an ATI Radeon (mobile) graphics card:
- X starts and runs without any trouble the XFCE desktop environment.
- Additionally: The default terminals have a proper resolution (I think the maximal resolution of the display).

alphaniner · 2014-08-14 19:03:48

You've figured out the original problem, IMO you should start a new thread with these X issues. You'd probably get more hits that way.

The poor tty resolution is to be expected if the closed-source nvidia drivers are installed, because they don't support KMS. What happens if you uninstall nvidia and use nouveau? Also have you looked in /etc/X11 ?

The Infinity · 2014-08-14 20:21:28

You've figured out the original problem, IMO you should start a new thread with these X issues.

You're right. I'll create a new thread. And thanks for your help solving the original problem.

Arch Linux

#1 2014-08-08 19:28:05

[SOLVED] Arch Linux on encrypted luks partition on USB key

#2 2014-08-08 19:51:27

Re: [SOLVED] Arch Linux on encrypted luks partition on USB key

#3 2014-08-08 19:56:43

Re: [SOLVED] Arch Linux on encrypted luks partition on USB key

#4 2014-08-08 20:29:53

Re: [SOLVED] Arch Linux on encrypted luks partition on USB key

#5 2014-08-08 21:26:18

Re: [SOLVED] Arch Linux on encrypted luks partition on USB key

#6 2014-08-08 21:55:13

Re: [SOLVED] Arch Linux on encrypted luks partition on USB key

#7 2014-08-08 22:15:00

Re: [SOLVED] Arch Linux on encrypted luks partition on USB key

#8 2014-08-10 21:09:41

Re: [SOLVED] Arch Linux on encrypted luks partition on USB key

#9 2014-08-14 18:35:16

Re: [SOLVED] Arch Linux on encrypted luks partition on USB key

#10 2014-08-14 19:03:48

Re: [SOLVED] Arch Linux on encrypted luks partition on USB key

#11 2014-08-14 20:21:28

Re: [SOLVED] Arch Linux on encrypted luks partition on USB key

Board footer