Grub2 menu doesn't autogenerate properly for signed kernels

[Bartłomiej Żogała]

Installing signed kernel(in my case linux-signed-image-3.13.0-58-generic) resulted in unbootable system. This is not due to secure boot, but due to error mounting encrypted file system. Reason for that is lack of initfamfs modules - initrd is not appended to grub menu entry.
Previous working kernel entry with initrd:
menuentry 'Linux Mint 17 Cinnamon 64-bit, 3.13.0-55-generic (/dev/sda2)' --class ubuntu --class gnu-linux --class gnu --class os {
 recordfail
 gfxmode $linux_gfx_mode
 insmod gzio
 insmod part_gpt
 insmod ext2
 set root='hd0,gpt2'
 if [ x$feature_platform_search_hint = xy ]; then
   search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 e98af929-c299-4a87-9076-7b1ec50e396d
 else
   search --no-floppy --fs-uuid --set=root e98af929-c299-4a87-9076-7b1ec50e396d
 fi
 linux /vmlinuz-3.13.0-55-generic root=/dev/mapper/mint--vg-root ro crashkernel=384M-2G:64M,2G-:128M iommu=pt radeon.dpm=1 ivrs_ioapic[3]=00:14.0 ivrs_ioapic[4]=00:00.1 ivrs_hpet[0]=00:14.0 amd_iommu_debug crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M
 initrd /initrd.img-3.13.0-55-generic
}

Unbootable menu entry without initrd :
enuentry 'Linux Mint 17 Cinnamon 64-bit, 3.13.0-58-generic.efi.signed (/dev/sda2)' --class ubuntu --class gnu-linux --class gnu --class os {
 recordfail
 gfxmode $linux_gfx_mode
 insmod gzio
 insmod part_gpt
 insmod ext2
 set root='hd0,gpt2'
 if [ x$feature_platform_search_hint = xy ]; then
   search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 e98af929-c299-4a87-9076-7b1ec50e396d
 else
   search --no-floppy --fs-uuid --set=root e98af929-c299-4a87-9076-7b1ec50e396d
 fi
 linux /vmlinuz-3.13.0-58-generic.efi.signed root=/dev/mapper/mint--vg-root ro crashkernel=384M-2G:64M,2G-:128M iommu=pt radeon.dpm=1 ivrs_ioapic[3]=00:14.0 ivrs_ioapic[4]=00:00.1 ivrs_hpet[0]=00:14.0 amd_iommu_debug crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M
}

Expected behaviour is initrd line for every kernel - including signed ones.

[Ben Howard (darkmuggle-deactivatedaccount)]

Hi Anoop,

In doing our GAP analysis, we found that the Ubuntu images _almost_ just
work.

Issues:
1. The meta-data source for OPC is not fully EC2 compliant when it comes
to SSH keys. If you could add "0=opc" (or something like it) as a leaf
at http://169.254.169.254/latest/meta-data/public-keys, (i.e
http://169.254.169.254/latest/meta-data/public-keys/0=ocp), then
Cloud-init will just work.

2. The meta-data version that Cloud-init uses by default is
"2009-04-04". For compatibility's sake, if you were able to add this a
meta-data version, then Cloud-init would be 99% capable sans the first
issue.

Canonical can easily make the changes to support Cloud-init on OPC.
However, I want to highlight that given the wide adoption of Cloud-init
on other distros, if Oracle can make theses changes then not only will
you get Ubuntu, but Debian, SuSE, Gentoo, Arch, Centos, etc, etc for
free. And in terms of building out your Marketplace, it would make
working with other third-parties (like Bitnami) easier. In our
experience of working with many other clouds once Cloud-init support
lands, our cloud partners report immediate uptake and usage. .

The other big reason why making these changes to your meta-data source
would be beneficial is that it would be a migration path for users.
Users who do dev/test in house and deploy to your cloud, or users who
are on competing clouds would be able to migrate their instances into
your cloud with out modification. I can't underscore the immediate value.

Can you indicate whether these two minor changes are feasible and if so,
when might they be done?

I might add that I normally don't ask the clouds that we engage with to
change their meta-data dictionaries. In this case, I think that there is
immense value to making these minor changes.

Thanks,
Ben

[Bartłomiej Żogała (nusch)]

Hello, could someone verify it ? I reported it 4 months ago, pretty sure the report is correct - adding initrd line in grub from unsigned kernel to signed one makes it bootable again. So it's all connected with post install scripts

[Bartłomiej Żogała (nusch)]

Tagged as security, because forcing non-advanced users to use non-signed kernel lowers overall security.