Bug 12886

Summary: Removal of VM_DEFAULT_KERNEL in Sumo breaks booting initramfs kernel
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Ferry <ferry.toth>
Component: deploymentAssignee: He Zhe <zhe.he>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium+ CC: akuster, california.l.sullivan, ferry.toth, randy.macleod
Version: 2.5.1   
Target Milestone: 2.8 M2   
Hardware: x86   
OS: Multiple   
Whiteboard: Move to YP 2.6.2, YP 2.5.3
OS type for building Yocto: --- Type of Regression: Regression (Used to work)
Verified: Documentation change: Don't know

Description Ferry 2018-08-14 07:19:17 UTC 
We are generating a initramfs kernel and depending on VM_DEFAULT_KERNEL to 
install that into our boot hddimg as vmlinuz, which a U-Boot script looks 
for to load. This works nicely in Rocko but fails in Sumo.

The patch 5493bb5b 'live-vm-common.bbclass: Don't use vmlinuz or VM_DEFAULT_KERNEL' for Sumo causes U-Boot to not find vmlinuz as the kernel in hddimg is now called bzImage.

After changing the U-Boot script to load bzImage, kernel won't boot as it has no initramfs, i.e. the wrong kernel is installed. But without VM_DEFAULT_KERNEL we have no way to select which kernel gets installed.

Is there any other way in Sumo to install bzImage-initramfs-edison.bin 
instead of bzImage into hddimg?

If not, shouldn't we revert this commit?

Thanks,
Ferry
Comment 1 Armin Kuster 2018-08-16 14:49:05 UTC 
If this issue does not exist in Master, then its possible some of Cal's InitRamFS changes to Master did not get backported to Sumo
Comment 2 Ferry 2018-08-16 15:23:00 UTC 
I think I checked and saw this is also in master. Not 1005 sure.

BTW Alex Tereschenko found a workaround by replacing:

VM_DEFAULT_KERNEL = "bzImage-initramfs-edison.bin"

by

KERNEL_IMAGETYPE_pn-edison-image = "bzImage-initramfs-edison.bin"

See here: https://github.com/edison-fw/meta-intel-edison/pull/42/commits/82ebb5ddd4bb669d71aa9facfef65988b35c53af

Question remains: what was the intended way to select the kernel?
Comment 3 Randy MacLeod 2019-02-22 01:49:11 UTC 
Zhe won't be able to get to this next week for M3 so I've moved it to M4.
Comment 4 Randy MacLeod 2019-05-30 15:02:12 UTC 
The workaround is the best way to handle this sort of problem. Reopen if you disagree.