Description of problem: when creating custom partitioning scheme with encrypted partitions on ia64 the install completes but the target system will not boot. Version-Release number of selected component (if applicable): anaconda-11.1.2.132-1 How reproducible: Always Steps to Reproduce: 1. Boot into the installer 2. On partitioning screen select "Create custom partitions" 3. I have 2 disks, the layout is as follow: /dev/sda1 /boot/efi vfat 100MB /dev/sda2 / ext3 all remaining space encrypted /dev/sdb1 /home ext3 all remaining space encrypted 4. Enter pass phrase and continue with install Actual results: System is not able to boot Expected results: System boots Additional info: When selecting "Remove all partitions and create default layout" & encrypted the system boots successfully.
Created attachment 318066 [details] anaconda.log from the system (rescue mode)
What happens when you try to boot the system? In what way does it fail? Any messages?
(In reply to comment #2) > What happens when you try to boot the system? In what way does it fail? Any > messages? The systems tries to boot the default target (Red Hat Enterprise Linux Server) but fails to find config file for elilo. Message is: Loading.: Red Hat Enterprise Linux Server Starting: Red Hat Enterprise Linux Server no config file found in EFI\redhat\ forcing interactive mode due to config file error(s) ELILO boot:
Installing with the disk layout in comment #0 (and then rescue mode) shows: -rwxr-xr-x 1 root root 358948 Aug 8 2007 elilo.efi -rwxr-xr-x 1 root root 5567390 Oct 1 07:32 initrd-2.6.18-116.el5.img -rwxr-xr-x 1 root root 110 Oct 1 07:32 sha256-2.6.18-116.el5 -rwxr-xr-x 1 root root 3697336 Sep 18 22:38 vmlinuz-2.6.18-116.el5 while installing with default layout+encryption shows: -rwxr-xr-x 1 root root 163 1 окт 7,57 elilo.conf -rwxr-xr-x 1 root root 358948 8 авг 2007 elilo.efi -rwxr-xr-x 1 root root 6627714 1 окт 7,56 initrd-2.6.18-116.el5.img -rwxr-xr-x 1 root root 110 1 окт 7,56 sha256-2.6.18-116.el5 -rwxr-xr-x 1 root root 3697336 18 сеп 22,38 vmlinuz-2.6.18-116.el5 under /boot/efi/efi/redhat Dave, what is generating elilo.conf ?
Bootloader configuration is generated by booty.
We were able to reproduce on similar hardware in Westford. The problem is most likely occurring in booty. pjones will start to debug in the morning, with me joining him shortly afterward if needed.
When the logical volume for / is encrypted (but not the underlying PV) also missing is sha256-2.6.18-116.el5 sh-3.2# ls -l total 10436 -rwxr-xr-x 1 root root 358948 Aug 8 2007 elilo.efi -rwxr-xr-x 1 root root 6625765 Oct 2 08:12 initrd-2.6.18-117.el5.img -rwxr-xr-x 1 root root 3697215 Sep 30 02:39 vmlinuz-2.6.18-117.el5
A healthy install has in anaconda.log: 12:55:20 INFO : moving (1) to step firstboot 12:55:20 INFO : moving (1) to step instbootloader 12:55:20 INFO : moving (1) to step writeksconfig 12:55:20 INFO : Writing autokickstart file while a broken one has: 05:21:16 INFO : moving (1) to step firstboot 05:21:16 INFO : moving (1) to step instbootloader 05:21:16 ERROR : unable to find default image, bailing 05:21:16 INFO : moving (1) to step writexconfig
The problem was brought on by an oversight when backporting the change from rawhide to use LUKS UUIDs in mapping names. In RHEL5, unlike F10, bootloader configuration occurs before the LUKS devices are created. This means there is no UUID at the time we do bootloader configuration, leaving only the underlying device for use in generating mapping names. Later, we fail to associate the device used for bootloader configuration with the newly formatted LUKS device since they do not match ('luks-sda2' != 'luks-$UUID'). We have implemented a little fixup in anaconda's bootloader code which seems to remedy the issue.
Please attach /tmp/anaconda.log.
Created attachment 320872 [details] /var/log/anaconda.log from the system in comment #13
anaconda.log is attached in previous comment. More info from rescue mode: sh-3.2# cat etc/fstab /dev/mapper/luks-468062e4-2b9e-497c-b2c7-b46ae51701a3 / ext3 defaults 1 1 /dev/cciss/c0d0p3 /boot/efi vfat defaults 0 0 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 sh-3.2# cat etc/crypttab luks-468062e4-2b9e-497c-b2c7-b46ae51701a3 UUID=468062e4-2b9e-497c-b2c7-b46ae51701a3 none sh-3.2# ls -l boot/efi/efi/redhat/ total 8174 -rwxr-xr-x 1 root root 358948 Aug 8 2007 elilo.efi -rwxr-xr-x 1 root root 4307756 Oct 20 15:02 initrd-2.6.18-118.el5.img -rwxr-xr-x 1 root root 3698733 Oct 4 04:35 vmlinuz-2.6.18-118.el5 elilo.conf is missing as in comment #5
The second problem was a result of the fact that the CCISS device names contain a directory component (eg: cciss/c0d0p4). To generate the initial LUKS mapping name, we use the basename ("c0d0p4") since the mapping name cannot contain the "/" character. However, we still use the full device name as a key in partitions.encryptedDevices. So our new fixup code that came because of this bug checks if we have an entry in encryptedDevices whose key is "c0d0p4", but such an entry is not found because the key is "cciss/c0d0p4". So we will add another hack to the hack in bootloader.py to check the basename if the initial lookup fails.
Fix for bootloader installation problem in anaconda-11.1.2.145-1.
To be clear, there is still a kernel oops that is occurring during boot. This is almost certainly a separate matter, falling under the domain of the kernel.
kernel issues filed as bug #467839
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0164.html