User talk:Sakaki/Sakaki's EFI Install Guide/Configuring and Building the Kernel
From Gentoo Wiki
Jump to:navigation
Jump to:search
Note
This is a Talk page - please see the documentation about using talk pages. Add newer comments below older ones, sign comments using four tildes (
This is a Talk page - please see the documentation about using talk pages. Add newer comments below older ones, sign comments using four tildes (
~~~~), and indent successive comments with colons (:).
Add new sections at the bottom of the page, under a heading (== ==). Please remember to mark sections as "open for discussion" using {{talk|open}}, so they will show up in the list of open discussions.K2t0f12d
Buildkernel fails to identify disks by uuid if they are configured without partitions, eg. Solid State Disks.
This is because buildkernel looks for uuids from /dev/disk/by-partuuid rather than /dev/disk/by-uuid, presumably to prevent users with traditional disks from shooting at their feet. K2t0f12d (talk) 01:36, 1 October 2014 (UTC)
Worse yet, changing $PARTUUIDDEVDIR to /dev/disk/by-uuid instead also fails, because vfat disks have uppercase characters in their uuid and we are arbitrarily downcasing user definintions read from the config! K2t0f12d (talk) 02:36, 1 October 2014 (UTC)
- Hi K2t0f12d - as you point out, buildkernel is targeted specifically at the case of partitioned GPT drives (whether SSD or not) - as will be the case for the EFI dual-boot scenario (on standard Ultrabooks etc.), where the user has followed the boot USB key prep instructions in the earlier chapter (or where overwriting a standard Win 8 system, with a GPT drive containing the EFI system partition and a LUKS / LVM partition).
- Could you please let me know the full details of the use case you would like to facilitate, and I'll see what can be done? Many thanks, sakaki (sakaki) Wed 1 Oct 10:01:08 UTC 2014
- Hi Sakaki, same isuse here, let me explain:
- Linux livecd 3.14.14-gentoo #1 SMP Thu Oct 23 06:24:17 UTC 2014 x86_64 Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz GenuineIntel GNU/Linux
- when ending up at the point to run buildkernel with EFIPARTUUID="7ecaf269-b104-4817-9342-d2f1840d0d85" and CRYPTPARTUUID="cb74f32d-01" I got:
- (chroot) livecd / # buildkernel --ask --verbose
- * Secure-bootable EFI kernel build script
- * buildkernel: Error: Partition with UUID 'cb74f32d-01' does not exist - exiting
- This is because the CRYPTPARTUUID ist't listed anywhere beneath /dev/disk, especially not in /dev/disk/by-partuuid
- instead, I have the following (sda=HDD, sdc=USB with EFIPART):
- (chroot:2) livecd / # blkid /dev/sda1 /dev/sdc1
- /dev/sda1: UUID="5172cadb-d229-47ba-95bc-fbb6ebf3f9d9" TYPE="crypto_LUKS" PARTUUID="cb74f32d-01"
- /dev/sdc1: UUID="7987-E0A0" TYPE="vfat" PARTLABEL="primary" PARTUUID="7ecaf269-b104-4817-9342-d2f1840d0d85"
- (chroot:2) livecd / # ls -l /dev/disk/by-partuuid/
- lrwxrwxrwx 1 root root 10 29. Okt 12:57 7ecaf269-b104-4817-9342-d2f1840d0d85 -> ../../sdc1
- (chroot:2) livecd / # cryptsetup isLuks /dev/disk/by-uuid/5172cadb-d229-47ba-95bc-fbb6ebf3f9d9; echo $?
- 0
- (chroot:2) livecd / # cryptsetup isLuks /dev/sda1 ; echo $?
- 0
- For some reason the PARTUUID="cb74f32d-01" disappeared from the /dev/disk/by-partuuid or was never there. Charly531 (talk) 14:13, 29 October 2014 (UTC)
- Hi Charly531 - sorry to hear you are having problems with this. Could you please post the output of blkid /dev/sda and blkid /dev/sdc as well please? Thx sakaki (sakaki) Wed 29 Oct 14:45:06 UTC 2014
- (chroot:2) livecd / # blkid /dev/sda /dev/sdc
- /dev/sda: PTUUID="cb74f32d" PTTYPE="dos"
- /dev/sdc: PTUUID="ce6c1c27-7946-4000-8cf9-6011f7ccd69d" PTTYPE="gpt"
- oh, well I guess partition type "DOS" is the problem, I need to review the process from the beginning...
- Charly531 (talk) 15:46, 29 October 2014 (UTC)
- Hi Charly531 - sorry to hear you are having problems with this. Could you please post the output of blkid /dev/sda and blkid /dev/sdc as well please? Thx sakaki (sakaki) Wed 29 Oct 14:45:06 UTC 2014
- Ok, thanks for that. I think I understand the problem now (and perhaps this is what K2t0f12d was referring to as well). Essentially, the tutorial assumes that your crypt partition lives on a GPT-partitioned disk, which it will if you have placed it on space freed up from Windows 8 (since the disk must be GPT to boot under UEFI in the first place). Ditto for your EFI boot key (which it looks like you have set up fine incidentially, based on the above). However, if you are adapting the tutorial to a single-OS (or multi-hard-drive) boot, and put the crypt partition on a drive that is MBR-partitioned, then no /dev/disk/by-partuuid/ entries are created for it (since the partition identifier is not of the appropriate format). Instead, such MBR partitions should show up in /dev/disk/by-uuid/ (which I think is what K2t0f12d was alluding to).
- Would you mind just checking if your /dev/sda1's UUID (i.e., 5172cadb-d229-47ba-95bc-fbb6ebf3f9d9) shows up if you ls -l /dev/disk/by-uuid ?
- If this is the case, I will look to see if buildkernel can easily be adapted to check for crypto partitions on MBR drives too, via the /dev/disk/by-uuid/ route.
- In the meantime, you may be able to use gdisk to convert your MBR /dev/sda to GPT (see this Arch Linux wiki item), but please read the warnings there before proceeding.
- Thank you for taking the time to provide details about this issue btw, it's only through detailed bug reports like yours that I can get a chance to improve the tools. Best, sakaki (sakaki) Wed 29 Oct 17:21:13 UTC 2014
- Sakaki, great, indeed it was not a Win8 but WIN7 instead, and I missed to change the MBR HDD to GPT.
- the /dev/disk/by-uuid is nicely like following, and above, the "cryptsetup isLuks" suceeded:
- lrwxrwxrwx 1 root root 10 28. Okt 16:37 2014-10-23-06-34-14-36 -> ../../sdb1
- lrwxrwxrwx 1 root root 10 28. Okt 18:19 5172cadb-d229-47ba-95bc-fbb6ebf3f9d9 -> ../../sda1
- lrwxrwxrwx 1 root root 10 28. Okt 18:33 5241ac69-de63-4a9a-94e9-6bbddd329579 -> ../../dm-1
- lrwxrwxrwx 1 root root 10 28. Okt 18:34 72293b43-7084-44e4-ba08-74c764a36c22 -> ../../dm-3
- lrwxrwxrwx 1 root root 10 29. Okt 12:57 7987-E0A0 -> ../../sdc1
- lrwxrwxrwx 1 root root 10 28. Okt 18:33 92f9c5fb-9a0c-4a1b-9b08-984ba46fab5e -> ../../dm-2
- FYI, I've patched buildkernel now, so that you can directly specify the LUKS path in /etc/buildkernel.conf. The version of buildkernel you need is >= 1.0.8. To upgrade, either run genup as root (if you have installed that utility from sakaki-tools), or if not, then issue
- # layman --sync=sakaki-tools
- followed by
- # emerge --update --ask --verbose sys-kernel/buildkernel
- Once you have the new version, you can then simply add a line defining CRYPTPATHMAP into /etc/buildkernel.conf, after which, you should be able to run buildkernel! For example, in the case you gave above Charly531, you would need to add the following line to buildkernel.conf:
- CRYPTPATHMAP="/dev/disk/by-uuid/5172cadb-d229-47ba-95bc-fbb6ebf3f9d9"
- If you set CRYPTPATHMAP in this way, CRYPTPARTUUID is ignored. For more details, see the buildkernel.conf manpage. BTW, users who have GPT-based LUKS systems need do nothing, their existing /etc/buildkernel.conf file will still work fine with the new version of buildkernel.
- Hope that helps! sakaki (sakaki) Sat 1 Nov 15:10:35 UTC 2014
- Just came here to say I had the same issue but without the MBR problem. Using CRYPTPATHMAP seems to have sorted it! For yuor info I've included blkid and lsblk output below. Thanks for the amazing guide!
- livecd ~ # lsblk
- NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
- sda 8:0 0 3.7T 0 disk
- sdb 8:16 0 931.5G 0 disk
- |-sdb1 8:17 0 350M 0 part
- |-sdb2 8:18 0 204.8G 0 part
- `-sdb3 8:19 0 726.4G 0 part
- `-gentoo 253:0 0 726.4G 0 crypt
- |-vg1-swap 253:1 0 40G 0 lvm [SWAP]
- |-vg1-root 253:2 0 100G 0 lvm /mnt/gentoo
- `-vg1-home 253:3 0 557.1G 0 lvm /mnt/gentoo/home
- sdc 8:32 0 14.9G 0 disk
- `-sdc1 8:33 0 204M 0 part /mnt/cdrom
- sdd 8:48 1 1.9G 0 disk
- `-sdd1 8:49 1 1.9G 0 part
- loop0 7:0 0 175.2M 1 loop /mnt/livecd
- livecd ~ # blkid
- /dev/sdd1: UUID="D3ED-4CD0" TYPE="vfat" PARTLABEL="primary" PARTUUID="9545168a-a4b4-470e-b2a9-::::::: 6e1371baf6e8"
- /dev/sdb3: UUID="27bca5b7-b4a6-4cd9-9b40-3106b375da02" TYPE="crypto_LUKS" PARTUUID="f5c05fc6-03"
- /dev/loop0: TYPE="squashfs"
- /dev/sdb1: LABEL="System Reserved" UUID="A60030B900309273" TYPE="ntfs" PARTUUID="f5c05fc6-01"
- /dev/sdb2: UUID="E03C3D763C3D48B4" TYPE="ntfs" PARTUUID="f5c05fc6-02"
- /dev/sdc1: UUID="2014-11-13-06-39-58-57" LABEL="Gentoo Linux amd64 20141113" TYPE="iso9660" PTUUID="3086abc2" PTTYPE="dos" PARTUUID="3086abc2-01"
- /dev/mapper/gentoo: UUID="behR36-Jj7a-mnZ8-m0Y1-9UEb-5sce-yitzQP" TYPE="LVM2_member"
- /dev/mapper/vg1-swap: LABEL="swap" UUID="08af2cdd-dacb-4927-9163-24857cad38bb" TYPE="swap"
- /dev/mapper/vg1-root: LABEL="root" UUID="f215f08c-c89b-4e07-8bbd-15016c4940d5" TYPE="ext4"
- /dev/mapper/vg1-home: LABEL="home" UUID="8ad9890b-55f2-44ae-bc2b-dd40737fcaa1" TYPE="ext4"
- /dev/sda: PTUUID="d20d20be-4426-4b86-9b2f-6838ab395222" PTTYPE="gpt"