[meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
Jianxun Zhang
jianxun.zhang at linux.intel.com
Thu Jul 21 22:12:11 PDT 2016
> On Jul 21, 2016, at 8:13 PM, Tom Zanussi <tom.zanussi at linux.intel.com> wrote:
>
> On 07/21/2016 08:05 PM, Jianxun Zhang wrote:
>>
>>> On Jul 21, 2016, at 2:50 PM, Tom Zanussi <tom.zanussi at linux.intel.com> wrote:
>>>
>>> On 07/21/2016 04:35 PM, Jianxun Zhang wrote:
>>>>
>>>>> On Jul 21, 2016, at 1:07 PM, Tom Zanussi <tom.zanussi at linux.intel.com> wrote:
>>>>>
>>>>> On 07/21/2016 02:22 PM, Jianxun Zhang wrote:
>>>>>>
>>>>>>> On Jul 21, 2016, at 11:37 AM, Tom Zanussi <tom.zanussi at linux.intel.com> wrote:
>>>>>>>
>>>>>>> Hi Jianxun,
>>>>>>>
>>>>>>> On 07/21/2016 03:37 AM, Jianxun Zhang wrote:
>>>>>>>> V3 addresses feedbacks for V2, also includes other fixes:
>>>>>>>>
>>>>>>>> () Explicitly tell user overriding is a temporary solution in README
>>>>>>>>
>>>>>>>> () Move back two readme files back to top dir
>>>>>>>>
>>>>>>>> () Move RMC README to /documentation/rmc/
>>>>>>>>
>>>>>>>> () Replace wrong EFI_PROVIDER info with Distro feature in RMC README
>>>>>>>>
>>>>>>>> () patches have been squashed
>>>>>>>>
>>>>>>>> () Now any new change of files in a board dir can be effective with a rebuild.
>>>>>>>>
>>>>>>>> () removing tmp dir in build won't cause build issue. (it is uncesesary either)
>>>>>>>>
>>>>>>>> () amend commit messages
>>>>>>>>
>>>>>>>> () amend installation logic in database recipe
>>>>>>>>
>>>>>>>
>>>>>>> It seems to be working in general and I see updates when I change, but I
>>>>>>> seem to be getting extra boot menu items I didn't ask for.
>>>>>>>
>>>>>>> I have a BOOTENTRY.CONFIG with just this:
>>>>>>>
>>>>>>> boot.conf
>>>>>>>
>>>>>>> and in boot.conf:
>>>>>>>
>>>>>>> title NextUnitofComputing Gen3 boot
>>>>>>> linux /vmlinuz
>>>>>>> initrd /initrd
>>>>>>> options LABEL=mybootlabel
>>>>>>>
>>>>>>> I do see that 'NextUnitofComputing Gen3 boot" menu item, but I also see
>>>>>>> two entries before it:
>>>>>>>
>>>>>>> boot
>>>>>>> install
>>>>>>>
>>>>>>> I would expect to see only what I have in my configuration. Or am I
>>>>>>> doing something wrong?
>>>>>>>
>>>>>> Tom,
>>>>>> No, you don’t do anything wrong. It is designed that way. Any boot entry you pack in RMC are addition to the two default entries “boot” and “install” which are built from OE. There are different routes to add entries.
>>>>>>
>>>>>> OE allows user to bring their own boot entries in build (GUMMIBOOT_ENTRIES), so we should not override these.
>>>>>>
>>>>>> However, we cannot assume which entry should be replaced/overridden at runtime too because what you see in boot menu is title filed which could be anything from user.
>>>>>>
>>>>>> User could be confused when he realize there are two boot or install options, but he can quickly change titles in conf file to differentiate.
>>>>>>
>>>>>
>>>>> Yes, I certainly was confused to see two boot entries. Even if I rename
>>>>> them like you suggest, how do I rename them to avoid confusion for the
>>>>> user i.e. which boot do I use, and if I'm supposed to ignore the other
>>>>> one, why is it there?
>>>> I think we shouldn’t enforce any naming policy here at this point. This is out of RMC control. Will user complain for confusion caused be another “boot” from a conf file added via the existing GUMMIBOOT_ENTRIES?
>>>>
>>>
>>> You're the one suggesting renaming some to avoid confusing the user
>>> (because apparently we can't get rid of the two boot entries we didn't
>>> specify in rmc), nobody mentioned a naming policy.
>> Sorry if I miss your point. What we are discussing is (a) if titles could be confusing, or (b) if you have multiple boot entries to boot a board. For the naming aspect (a), it is totally up to developer or users. For the later case (b), it could depend on what functionality behind an entry, like “ubuntu 3.2.6” or “mem-test x86”. I could just say “RMC NUC 6 boot” below a “boot” to mark it from RMC feature for NUC 6. Is this exact you are concerned?
>>
>>>
>>>> I am not suggesting user to “ignore” other boot entries. I should say RMC just provides another source of boot entries. It is totally up to user for how to provide an entry, what should be in that entry, and eventually which entry to boot system.
>>>>
>>>
>>> Multiple sources of boot entries is just confusing.
>>>
>> I don’t think sources are the real problem or I could misunderstand this comment. I don’t think sources are confusing. The existing gummiboot/systemd-boot already supports multiple sources, not only reading conf files from ESP.
>>
>>>> If we overrides any entries, I guess we will miss corner cases when people still want to boot a supported target with default settings...
>>>>
>>>
>>> So how can we not make the corner cases drive the default of what most
>>> users would expect? i.e. make the default be that the user only sees
>>> the menu entries specified via rmc? with a fallback for the corner case
>>> users to see the other entries?
>>
>> I suggest we don’t guess it for most of users since we don’t have solid data. But what I could do later is to hack systemd-boot so it won’t load _any_ entries from disk once RMC entries for the board are available. But that means you cannot add an new entry and make it effective on a live-boot disk. I feel this arbitrary solution, well, could bring more corner cases.
>>
>> Let me know if this can be in a fix plan.
>>
>>
>>>
>>>>>
>>>>> To me it seems reasonable to assume that an rmc user would expect rmc
>>>>> menu management to be owned by rmc and not be surprised by other options
>>>>> from the base bootloader. Or to say it a different way, what's the use
>>>>> case for an rmc user to want to manage menu items in two separate
>>>>> places, the base bootloader and rmc?
>>>>>
>>>>>> An expectation is installer. RMC deployment is always effective no matter which install option is selected so that RMC deployment on a supported board is guaranteed.
>>>>>>
>>>>>
>>>>> I can see cases where an 'install' menu item isn't wanted or needed,
>>>>> like for example on an already-installed system.
>>>>
>>>> If you mean not to show “RMC install” on an installed system, this is achieved by not putting conf files of installation in INSTALLER.CONFIG.
>>>>
>>>
>>> No, I'm not asking about what gets installed, I was just mentioning a
>>> case where you wouldn't want to see the install entry.
>>>
>>> Maybe the question to ask is - how do I get rid of those two extra boot
>>> and install entries? And maybe the answer should be the default..
>> sorry, I still don’t get it. If you don’t want to see install.conf from RMC, you just don’t put it in board dir, or delete, or comment out them in BOOTENTRY.CONFIG if you still want them checked in the board dir.
>>
>
> So for a BOOTENTRY.CONFIG containing just one boot entry:
> boot.conf
>
> And this is boot.conf:
>
> title boot NUC Gen6
> linux /vmlinuz
> initrd /initrd
> options LABEL=boot
>
> I was expecting to boot and see just:
>
> boot NUC Gen6
>
> but instead I see:
>
> boot
> install
> boot NUC Gen6
>
> I really just wanted one entry, 'boot NUC Gen6', so how do I get rid of
> the other 2?
I have two possible solutions. (again, what you want to get rid of is not controlled by RMC :-(
() LABELS variable in OE is the interface to generate entries. Maybe you can set LABEL = “” in conf file so no any default entries will be generated. But the downside is you won’t be able to boot a board not supported by RMC DB because there is no default boot entry. Only board supported in RMC DB can boot.
() Or, like what I proposed in previous comment, I can hack systemd-boot to make it won’t read any entries from ESP when there is any RMC entries fetched successfully. Boards not supported will get any default entries. Board supported will only show RMC entries. A downside is you won’t see default entry which carries a command line from APPENDS in build time. What’s effective is a cmdline part in RMC entry file plus global fragment.
() Or, don’t have RMC entries, you can just use KBOOTPARAM which is boot-specific if a board-specific cmdline is the only thing you want to customize.
it could be nice to show only board-specific entries intelligently as you suggested. Do you think 2nd can be in a fix plan?
>
> Tom
>
>>>
>>> Tom
>>>
>>>> NUC 6 example can be a reference. It has two RMC boot entries, but only directs installer to put boot.conf on target. :-) So you won’t see “install” after installation.
>>>>
>>>> Showing it or not, this is a “policy” defined by you as user. RMC provides you a runtime mechanism to make policies effective.
>>>>
>>>> Thanks
>>>>
>>>>>
>>>>> Tom
>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>>
>>>>>>>> Jianxun Zhang (6):
>>>>>>>> rmc: Add Runtime Machine Configuration (RMC) project
>>>>>>>> gnu-efi: Add GUID for SMBIOS 3 entry point structure
>>>>>>>> systemd-boot: load board-specific entry and kernel cmdline
>>>>>>>> EFI installer: deploy board-specific data and kernel cmdline
>>>>>>>> rmc: add recipe and bbclass for RMC feature
>>>>>>>> rmc: document and examples for RMC feature
>>>>>>>>
>>>>>>>> classes/rmc-db.bbclass | 92 ++++++
>>>>>>>> classes/rmc-systemd-boot.bbclass | 12 +
>>>>>>>> ...d-GUID-for-SMBIOS-3-entry-point-structure.patch | 32 ++
>>>>>>>> common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend | 2 +
>>>>>>>> .../rmc/boards/T100-32bit/BOOTENTRY.CONFIG | 2 +
>>>>>>>> .../rmc/boards/T100-32bit/T100-32bit.fp | Bin 0 -> 116 bytes
>>>>>>>> common/recipes-bsp/rmc/boards/T100-32bit/boot.conf | 4 +
>>>>>>>> .../recipes-bsp/rmc/boards/T100-32bit/install.conf | 4 +
>>>>>>>> .../rmc/boards/minnowmax/BOOTENTRY.CONFIG | 1 +
>>>>>>>> common/recipes-bsp/rmc/boards/minnowmax/boot.conf | 4 +
>>>>>>>> .../recipes-bsp/rmc/boards/minnowmax/minnowmax.fp | Bin 0 -> 143 bytes
>>>>>>>> .../rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG | 1 +
>>>>>>>> .../recipes-bsp/rmc/boards/minnowmaxB3/boot.conf | 4 +
>>>>>>>> .../rmc/boards/minnowmaxB3/minnowmaxB3.fp | Bin 0 -> 148 bytes
>>>>>>>> .../rmc/boards/nucgen6/BOOTENTRY.CONFIG | 2 +
>>>>>>>> .../rmc/boards/nucgen6/INSTALLER.CONFIG | 6 +
>>>>>>>> common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM | 1 +
>>>>>>>> common/recipes-bsp/rmc/boards/nucgen6/boot.conf | 4 +
>>>>>>>> common/recipes-bsp/rmc/boards/nucgen6/install.conf | 4 +
>>>>>>>> common/recipes-bsp/rmc/boards/nucgen6/mylib.conf | 7 +
>>>>>>>> common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp | Bin 0 -> 149 bytes
>>>>>>>> common/recipes-bsp/rmc/rmc-db.bb | 46 +++
>>>>>>>> common/recipes-bsp/rmc/rmc.bb | 46 +++
>>>>>>>> .../recipes-bsp/systemd-boot/systemd-boot.bbappend | 20 ++
>>>>>>>> ...d-boot-Link-RMC-libraries-into-bootloader.patch | 31 ++
>>>>>>>> ...d-board-specific-boot-entries-from-RMC-da.patch | 241 +++++++++++++++
>>>>>>>> ...pport-global-kernel-command-line-fragment.patch | 66 ++++
>>>>>>>> .../initrdscripts/files/init-install-efi.sh | 315 +++++++++++++++++++
>>>>>>>> .../initramfs-live-install-efi_%.bbappend | 1 +
>>>>>>>> conf/layer.conf | 16 +
>>>>>>>> documentation/rmc/README | 337 +++++++++++++++++++++
>>>>>>>> 31 files changed, 1301 insertions(+)
>>>>>>>> create mode 100644 classes/rmc-db.bbclass
>>>>>>>> create mode 100644 classes/rmc-systemd-boot.bbclass
>>>>>>>> create mode 100644 common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch
>>>>>>>> create mode 100644 common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/boot.conf
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/install.conf
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/boot.conf
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/minnowmax.fp
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/boot.conf
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/minnowmaxB3.fp
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/BOOTENTRY.CONFIG
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/INSTALLER.CONFIG
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/boot.conf
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/install.conf
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/mylib.conf
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/rmc-db.bb
>>>>>>>> create mode 100644 common/recipes-bsp/rmc/rmc.bb
>>>>>>>> create mode 100644 common/recipes-bsp/systemd-boot/systemd-boot.bbappend
>>>>>>>> create mode 100644 common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-libraries-into-bootloader.patch
>>>>>>>> create mode 100644 common/recipes-bsp/systemd-boot/systemd-boot/0002-sd-boot-Load-board-specific-boot-entries-from-RMC-da.patch
>>>>>>>> create mode 100644 common/recipes-bsp/systemd-boot/systemd-boot/0003-sd-boot-Support-global-kernel-command-line-fragment.patch
>>>>>>>> create mode 100644 common/recipes-core/initrdscripts/files/init-install-efi.sh
>>>>>>>> create mode 100644 common/recipes-core/initrdscripts/initramfs-live-install-efi_%.bbappend
>>>>>>>> create mode 100644 documentation/rmc/README
More information about the meta-intel
mailing list