I've compiled a custom kernel in order to reduce boot times on my machine. I still have several tests and potential recompiles to run to finish stripping the thing down to absolute minimum, but I'm getting there. Due to outrageous (and healthy) paranoia, I've done my best to secure my computer in addition to making it run fast, and to that end I've encrypted my hard drive.
The problem I've encountered with the custom kernel is that, once compiled and generated into an initial ramdisk, it won't decrypt my HDD. I have the encrypt hook and all other needed options configured in my mkinitcpio.conf, and they work on my default Arch kernel. With my new custom kernel, it will boot the thing but either the encrypt hook isn't running or it's not doing anything when run, and I have no idea why. It will boot, idle for much longer than strictly necessary, and then skip right to the lvm2 and btrfs hooks that succeed it, not prompting for a password as with my default kernel. It's been driving me mad over the course of a week of fiddling, rebooting, testing, and more fiddling. Google has been queried many a time, but to no avail. I'm hoping that you fine folks can come up with a brilliant solution, since all mine have met with failure.
Last edited by ParanoidAndroid (2013-02-01 22:50:53)
I've compiled a custom kernel in order to reduce boot times on my machine.
I doubt this will make much of a difference.
With that out of the way, have you had a look at what is actually being built into the ramdisk?
If I strip down the kernel to the absolute minimum needed to run my system, I can load it just a tad faster. And for me, every millisecond counts.
And no, I have not. This is my first dig-into-the-guts foray into the kernel and related stuff, so I'm not clear on how to do that. Could you, perchance, direct me to a resource or explain how to do so?
Analysis with the command you provided shows that dm-crypt, cryptsetup, the encrypt hook, and all other requisite modules and binaries (so far as I can tell) are compiled into the image. Yet it still won't boot, no matter what I throw at it. I even tried setting up the modules to be hardcoded into the kernel, but nothing seems to be working. Maybe I'm missing a module, or perhaps a binary? I have no way of knowing which ones are missing, because I can't for the life of me figure out which modules/binaries are necessary for the encrypt hook to function properly and which are just extra crap.
here is the entire output of lsinitcpio for my custom image, initramfs-stripped.img:
==> Image: /boot/initramfs-stripped.img ==> Created with mkinitcpio 0.12.0 ==> Kernel: 3.7.5-CUSTOM-ARCH ==> Size: 4.62 MiB ==> Compressed with: gzip -> Uncompressed size: 11.93 MiB (.387 ratio) -> Estimated extraction time: 0.157s ==> Included modules: ahci dm-mod mbcache ahci_platform dm-region-hash pktcdvd arc4 dm-snapshot sata_highbank btrfs [explicit] ecb scsi_mod cbc ehci-hcd sd_mod cdrom ext4 sr_mod crc16 gf128mul usb-common crc32c jbd2 usbcore crc32c-intel jfs [explicit] xts dm-crypt libahci zlib_deflate dm-log libata dm-mirror libcrc32c ==> Included binaries: blkid cp kmod mount btrfs cryptsetup lsblk switch_root btrfsck dmsetup lvm udevadm busybox findmnt lvmetad udevd ==> Early hook run order: udev lvm2 ==> Hook run order: udev encrypt btrfs ==> Cleanup hook run order: shutdown lvm2 udev
I can't detect any discrepancies in this output, but then again I'm far from an expert.
Would the ouput for my primary kernel be helpful, as well?
Looking back, it looks like the custom image has the same binaries as the default one. The only difference between the two is the number of modules included in the image. So it's likely a missing module. Anyone have a clue which one(s) might be the culprit? Looking at the encrypt hook file in /usr/lib/initcpio/hooks, it appears that the only thing it depends on it the cryptsetup binary and possibly the dm-crypt module, both of which I have in the custom image. Going from that, I included the aes module, which had been missing. No luck. I also tried most of the other crypt-prefixed modules... nothing.
I'll try recompiling from scratch using my modified config file and see if that yields any results. In the meantime, I'd still like some input on this. I'm going completely off my nut trying to figure this thing out.
Recompile didn't help. I took the "quiet" option off of the kernel parameters to see if there was any useful or telling output. All I got was a bunch of messages concerning USB buses and such, but nothing that looked like an error. Because the kernel didn't actually save any dmesg logs, I have no way to go back and look at it in detail. Help?
Last edited by ParanoidAndroid (2013-02-01 22:03:55)
I ran further tests, this time using /dev/sda2 instead of a /dev/disk-by-uuid/ entry. Worked flawlessly. It appears that the kernel can't recognize UUIDs, though I'm not sure why or which component of the UUID process (the /dev/disk-by-uuid entry not being created, etc) has failed.
there is a /dev/disk/by-uuid entry, but it looks like it is not being consulted or is not present in early boot.
it was a typo in the UUID... one character off. Marking thread as solved. *facepalm*
Last edited by ParanoidAndroid (2013-02-01 22:50:36)