> On Jul 22, 2016, at 9:45 AM, Tom Zanussi <tom.zanu...@linux.intel.com> wrote: > > On 07/22/2016 12:12 AM, Jianxun Zhang wrote: >> >>> On Jul 21, 2016, at 8:13 PM, Tom Zanussi <tom.zanu...@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.zanu...@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.zanu...@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.zanu...@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. >> > > You're already hacking systemd-boot, so why is this an obstacle? > okay. I will put this into to-do list if I don’t see other corner cases. Installer should also be changed not to deploy default entries on a supported board.
> When you say, "A downside is you won’t see default entry which carries a > command line from APPENDS in build time", please explain. default entries are generated at build time. cmdline in default entries are from APPEND. The command line in an RMC entry file is what as developer puts in the text file. RMC entry is static file-based blob in source, not artifacts generated. I think as long as you know what should be in cmdline and RMC makes it effective at runtime, we should be fine. > > I'm still failing to see why anyone would want to see two boot entries, > the one you specify via RMC and the default boot entry, or why anyone > would want to set things up that way. Okay. with 2nd approach in systemd-boot, a supported board will not load any conf files from ESP (that FAT system of EFI image) if there is any RMC entries fetched successfully. I now have no objection to make RMC boot more intelligently and clean until we hear cries from another group of developers. > Tom > >> () 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 -- _______________________________________________ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
