Bug 8462 - wic should be able to create EFI-friendly FAT partitions
Summary: wic should be able to create EFI-friendly FAT partitions
Status: VERIFIED WONTFIX
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: deployment (show other bugs)
Version: 1.9
Hardware: All Multiple
: Medium+ normal
Target Milestone: 2.1
Assignee: Ed Bartosh
QA Contact: Bogdan Alexandru Voiculescu
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2015-10-08 10:54 UTC by Ross Burton
Modified: 2015-11-17 10:26 UTC (History)
1 user (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ross Burton 2015-10-08 10:54:38 UTC
I'm reliably informed that wic's rootfs plugin can't create EFI-compatible FAT partitions (I'm not sure how this relates to bug 6513).
Comment 1 Ed Bartosh 2015-10-21 12:36:10 UTC
I need more details on this. wic can create FAT EFI partitions. Without this EFI images would not even boot. Wic has at least two canned efi images: mkefidisk and mkgummidisk. Both are fully functional as far as I know.
Comment 2 Ross Burton 2015-10-21 12:46:00 UTC
I asked Igor about this on IM:

I wanted to use the rootfs plugin to create it
the reason is that I am doing something a bit exotic: I do not use a generic bootloader - which is what is supported by default
instead i use a blob which includes an efi stub, the kernel and the rootfs
the recipes and wic were making too many assumptions that didn't match my scenario
otoh the rootfs plugin would have worked, as it simply dumps whatever files it finds
but it didn't supprot VFAT filesystem, which is a must for EFI
Comment 3 Ed Bartosh 2015-10-21 12:58:14 UTC
After discussing this with Igor and Ross we agreed to close it as this functionality is not needed anymore. Feel free to reopen it if there will be a need in it.
Comment 4 Bogdan Alexandru Voiculescu 2015-11-17 10:26:13 UTC
verified per above comments.