Bug 1282785 - Encrypted disk doesn't unlock with latest kernel, grub.cfg missing initrd16 configuration
Encrypted disk doesn't unlock with latest kernel, grub.cfg missing initrd16 c...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: grubby (Show other bugs)
24
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-17 07:13 EST by Alexander Todorov
Modified: 2017-08-08 08:25 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-08 08:25:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/grubby (1.41 KB, text/plain)
2015-11-19 02:34 EST, Alexander Todorov
no flags Details
dnf.log (1.45 MB, text/plain)
2015-11-19 02:38 EST, Alexander Todorov
no flags Details
journalctl (6.22 MB, text/plain)
2015-11-19 02:42 EST, Alexander Todorov
no flags Details

  None (edit)
Description Alexander Todorov 2015-11-17 07:13:42 EST
Description of problem:

I have a Rawhide system with encrypted disk which doesn't unlock if the latest kernel is used but boots fine otherwise. 


Version-Release number of selected component (if applicable):
kernel-4.4.0-0.rc0.git9.1.fc24.x86_64

How reproducible:
Always (?)

Steps to Reproduce:
1. I have sda2 and sda3 encrypted (for LVM and swap), password contains only ASCII characters. 
2. While booting with kernel-4.4.0-0.rc0.git9.1.fc24.x86_64 I'm asked for the password but the disk isn't unlocked.
3.

Actual results:
System fails to boot

Expected results:
System boots fine

Additional info:
With kernel-4.4.0-0.rc0.git6.1.fc24.x86_64 I'm presented with a text prompt to enter the disk password. Disk is unlocked and system boots fine.

With kernel-4.4.0-0.rc0.git9.1.fc24.x86_64 I'm presented with a graphical prompt to enter the password (!!! this is difference in behavior) and the disk isn't unlocked. 

My grub.cfg is:

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
set pager=1

if [ -s $prefix/grubenv ]; then
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="${saved_entry}"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}

function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

terminal_output console
if [ x$feature_timeout_style = xy ] ; then
  set timeout_style=menu
  set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
  set timeout=5
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/01_users ###
if [ -f ${prefix}/user.cfg ]; then
  source ${prefix}/user.cfg
  if [ -n ${GRUB2_PASSWORD} ]; then
    set superusers="root"
    export superusers
    password_pbkdf2 root ${GRUB2_PASSWORD}
  fi
fi
### END /etc/grub.d/01_users ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Fedora (4.4.0-0.rc0.git9.1.fc24.x86_64) 24 (Rawhide)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.4.0-0.rc0.git6.1.fc24.x86_64-advanced-7739d499-b6bd-4762-af08-98f72050772f' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  71a5ee26-2142-4f6a-8d73-9b3529a8debe
	else
	  search --no-floppy --fs-uuid --set=root 71a5ee26-2142-4f6a-8d73-9b3529a8debe
	fi
	linux16 /vmlinuz-4.4.0-0.rc0.git9.1.fc24.x86_64 root=/dev/mapper/vg_redbull_mini-root ro rd.luks.uuid=luks-f3f6cea1-baba-4aaf-bca8-33a0ec540369 rd.lvm.lv=vg_redbull_mini/root rd.luks.uuid=luks-71c91dd0-5def-47ff-9b54-b2a16fa9ef0c rhgb quiet LANG=en_US.UTF-8
menuentry 'Fedora (4.4.0-0.rc0.git6.1.fc24.x86_64) 24 (Rawhide)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.4.0-0.rc0.git6.1.fc24.x86_64-advanced-7739d499-b6bd-4762-af08-98f72050772f' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  71a5ee26-2142-4f6a-8d73-9b3529a8debe
	else
	  search --no-floppy --fs-uuid --set=root 71a5ee26-2142-4f6a-8d73-9b3529a8debe
	fi
	linux16 /vmlinuz-4.4.0-0.rc0.git6.1.fc24.x86_64 root=/dev/mapper/vg_redbull_mini-root ro rd.luks.uuid=luks-f3f6cea1-baba-4aaf-bca8-33a0ec540369 rd.lvm.lv=vg_redbull_mini/root rd.luks.uuid=luks-71c91dd0-5def-47ff-9b54-b2a16fa9ef0c rhgb quiet LANG=en_US.UTF-8
	initrd16 /initramfs-4.4.0-0.rc0.git6.1.fc24.x86_64.img
}
menuentry 'Fedora (0-rescue-a4a79b0f8d6844fb86de973b8c20a143) 24 (Rawhide)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-0-rescue-a4a79b0f8d6844fb86de973b8c20a143-advanced-7739d499-b6bd-4762-af08-98f72050772f' {
	load_video
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  71a5ee26-2142-4f6a-8d73-9b3529a8debe
	else
	  search --no-floppy --fs-uuid --set=root 71a5ee26-2142-4f6a-8d73-9b3529a8debe
	fi
	linux16 /vmlinuz-0-rescue-a4a79b0f8d6844fb86de973b8c20a143 root=/dev/mapper/vg_redbull_mini-root ro rd.luks.uuid=luks-f3f6cea1-baba-4aaf-bca8-33a0ec540369 rd.lvm.lv=vg_redbull_mini/root rd.luks.uuid=luks-71c91dd0-5def-47ff-9b54-b2a16fa9ef0c rhgb quiet
	initrd16 /initramfs-0-rescue-a4a79b0f8d6844fb86de973b8c20a143.img
}

### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###

### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/20_ppc_terminfo ###
### END /etc/grub.d/20_ppc_terminfo ###

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f  ${config_directory}/custom.cfg ]; then
  source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###



The latest kernel is missing the initrd16 line but the initrd.img appears to be there.

I've recently (yesterday) updated the system but I have no idea how I ended up with this configuration.
Comment 1 Josh Boyer 2015-11-17 09:09:56 EST
You need to add the equivalent initrd16 line.  Otherwise the initramfs is not loaded at all and the tools to help unlock the disks are not present.
Comment 2 Alexander Todorov 2015-11-18 03:05:08 EST
(In reply to Josh Boyer from comment #1)
> You need to add the equivalent initrd16 line.  Otherwise the initramfs is
> not loaded at all and the tools to help unlock the disks are not present.

I know that, the question is why wasn't this line automatically added in grub.cfg at the time I was upgrading my system. Something broke but I'm not quite sure how to reproduce or go hunt for it.
Comment 3 Josh Boyer 2015-11-18 08:36:21 EST
It's a problem in grubby.  There are many instances of something like this happening.  I'll shift the bug over there as it is not a kernel problem.
Comment 4 Brian Lane 2015-11-18 15:46:40 EST
Please attach your /var/log/grubby file, and anything else relevant from the time of the upgrade (eg. check the journal for errors).
Comment 5 Alexander Todorov 2015-11-19 02:34 EST
Created attachment 1096516 [details]
/var/log/grubby
Comment 6 Alexander Todorov 2015-11-19 02:38 EST
Created attachment 1096517 [details]
dnf.log

Look for events on Nov 16 around 09:00 AM
Comment 7 Alexander Todorov 2015-11-19 02:42 EST
Created attachment 1096518 [details]
journalctl
Comment 8 Jan Kurik 2016-02-24 10:46:34 EST
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Comment 9 Fedora End Of Life 2017-07-25 15:30:49 EDT
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 10 Fedora End Of Life 2017-08-08 08:25:27 EDT
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.