On 07/21/2016 08:05 PM, Jianxun Zhang wrote: > >> On Jul 21, 2016, at 2:50 PM, Tom Zanussi <[email protected]> wrote: >> >> On 07/21/2016 04:35 PM, Jianxun Zhang wrote: >>> >>>> On Jul 21, 2016, at 1:07 PM, Tom Zanussi <[email protected]> >>>> wrote: >>>> >>>> On 07/21/2016 02:22 PM, Jianxun Zhang wrote: >>>>> >>>>>> On Jul 21, 2016, at 11:37 AM, Tom Zanussi <[email protected]> >>>>>> 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? 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 > -- _______________________________________________ meta-intel mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-intel
