mbox series

[OpenWrt-Devel,v4,0/6] intel-microcode: load as early as possible

Message ID 20181120162044.16371-1-tomek_n@o2.pl
Headers show
Series intel-microcode: load as early as possible | expand

Message

Tomasz Maciej Nowak Nov. 20, 2018, 4:20 p.m. UTC
This small series addresses current problem with late loading of Intel
microcode in OpenWrt. Following the commit messages [1] and later
discussion, late loading off the microcode can be ineffective for some
processors [2] and for others disabled [3]. Also it is discouraged for
any processor starting from Haswell and Silvermont.
Therefore this series converts the Intel microcode bundle to an initial
ram disk which is loaded with grub, so kernel has access to it as early
as possible.
Previous patch series:
https://patchwork.ozlabs.org/project/lede/list/?series=39372

1. https://lore.kernel.org/patchwork/cover/348236
2. https://lore.kernel.org/patchwork/cover/348236/#508603
3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7

Changes in v4:
  - copy also hidden files:
    x86: add packages files to image bootfs
  - no changes:
    1) include/rootfs.mk: remove boot directory
    2) x86: mount writable bootfs
    3) intel-microcode: remove dependency on iucode-tool
    4) x86: add intel microcode entries to grub config
    5) intel-microcode: create early load microcode image

Change suggested by Philip Prindeville.

Changes in v3:
  - replaced "include/rootfs.mk: move boot directory for later use"
    with "include/rootfs.mk: remove boot directory"; the final rootfs is
    always created after targets rootfs, so there's no need to save
    files for later use, also there was side effect to this approach,
    it kept the old files if packages version changed and buildroot
    wasn't cleaned beforehand
  - reflect the changes in "include/rootfs.mk: remove boot directory":
    x86: add packages files to image bootfs
  - expand commit message, narrow down the test in grub config:
    x86: add intel microcode entries to grub config
  - no changes:
    1) x86: mount writable bootfs
    2) intel-microcode: remove dependency on iucode-tool
    3) intel-microcode: create early load microcode image

Changes in v2:
  - three new commits allowing buildsystem to properly handle packages
    installing files to /boot directory, mainly for x86 target:
    1) include/rootfs.mk: move boot directory for later use
    2) x86: mount writable bootfs
    3) x86: add packages files to image bootfs
  - uncomplicate test for AMD processors in:
    x86: add intel microcode entries to grub config
  - remove package specific hook in x86 image Makefile, remove
    postinst/prerm scripts and install microcode directly to /boot:
    intel-microcode: create early load microcode image
  - no changes:
    intel-microcode: remove dependency on iucode-tool

All changes in v2 suggested by Matthias Schiffer and Philip Prindeville.

Tomasz Maciej Nowak (6):
  include/rootfs.mk: remove boot directory
  x86: mount writable bootfs
  x86: add packages files to image bootfs
  intel-microcode: remove dependency on iucode-tool
  x86: add intel microcode entries to grub config
  intel-microcode: create early load microcode image

 include/rootfs.mk                                |  1 +
 package/firmware/intel-microcode/Makefile        | 16 +++++++++-------
 .../x86/base-files/lib/preinit/02_load_x86_ucode |  6 ++++--
 .../x86/base-files/lib/preinit/79_move_config    | 12 ++++--------
 target/linux/x86/image/Makefile                  |  6 ++++--
 target/linux/x86/image/grub-iso.cfg              |  3 +++
 target/linux/x86/image/grub.cfg                  |  3 +++
 7 files changed, 28 insertions(+), 19 deletions(-)

Comments

Lucian Cristian Nov. 26, 2018, 8:44 p.m. UTC | #1
On 20.11.2018 18:20, Tomasz Maciej Nowak wrote:
> This small series addresses current problem with late loading of Intel
> microcode in OpenWrt. Following the commit messages [1] and later
> discussion, late loading off the microcode can be ineffective for some
> processors [2] and for others disabled [3]. Also it is discouraged for
> any processor starting from Haswell and Silvermont.
> Therefore this series converts the Intel microcode bundle to an initial
> ram disk which is loaded with grub, so kernel has access to it as early
> as possible.
> Previous patch series:
> https://patchwork.ozlabs.org/project/lede/list/?series=39372
>
> 1. https://lore.kernel.org/patchwork/cover/348236
> 2. https://lore.kernel.org/patchwork/cover/348236/#508603
> 3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7
>
> Changes in v4:
>    - copy also hidden files:
>      x86: add packages files to image bootfs
>    - no changes:
>      1) include/rootfs.mk: remove boot directory
>      2) x86: mount writable bootfs
>      3) intel-microcode: remove dependency on iucode-tool
>      4) x86: add intel microcode entries to grub config
>      5) intel-microcode: create early load microcode image
>
> Change suggested by Philip Prindeville.
>
> Changes in v3:
>    - replaced "include/rootfs.mk: move boot directory for later use"
>      with "include/rootfs.mk: remove boot directory"; the final rootfs is
>      always created after targets rootfs, so there's no need to save
>      files for later use, also there was side effect to this approach,
>      it kept the old files if packages version changed and buildroot
>      wasn't cleaned beforehand
>    - reflect the changes in "include/rootfs.mk: remove boot directory":
>      x86: add packages files to image bootfs
>    - expand commit message, narrow down the test in grub config:
>      x86: add intel microcode entries to grub config
>    - no changes:
>      1) x86: mount writable bootfs
>      2) intel-microcode: remove dependency on iucode-tool
>      3) intel-microcode: create early load microcode image
>
> Changes in v2:
>    - three new commits allowing buildsystem to properly handle packages
>      installing files to /boot directory, mainly for x86 target:
>      1) include/rootfs.mk: move boot directory for later use
>      2) x86: mount writable bootfs
>      3) x86: add packages files to image bootfs
>    - uncomplicate test for AMD processors in:
>      x86: add intel microcode entries to grub config
>    - remove package specific hook in x86 image Makefile, remove
>      postinst/prerm scripts and install microcode directly to /boot:
>      intel-microcode: create early load microcode image
>    - no changes:
>      intel-microcode: remove dependency on iucode-tool
>
> All changes in v2 suggested by Matthias Schiffer and Philip Prindeville.
>
> Tomasz Maciej Nowak (6):
>    include/rootfs.mk: remove boot directory
>    x86: mount writable bootfs
>    x86: add packages files to image bootfs
>    intel-microcode: remove dependency on iucode-tool
>    x86: add intel microcode entries to grub config
>    intel-microcode: create early load microcode image
>
>   include/rootfs.mk                                |  1 +
>   package/firmware/intel-microcode/Makefile        | 16 +++++++++-------
>   .../x86/base-files/lib/preinit/02_load_x86_ucode |  6 ++++--
>   .../x86/base-files/lib/preinit/79_move_config    | 12 ++++--------
>   target/linux/x86/image/Makefile                  |  6 ++++--
>   target/linux/x86/image/grub-iso.cfg              |  3 +++
>   target/linux/x86/image/grub.cfg                  |  3 +++
>   7 files changed, 28 insertions(+), 19 deletions(-)
>
>

this series I think are braking the boot on Via CPU's

grub complains with


error: can't find command '['.

error: file '/boot/amd-ucode.img' not found.

error: can't find command '['.

error: file '/boot/intel-ucode.img' not found.


Press any key to continue...


And you have to press any key..


Regards
Tomasz Maciej Nowak Nov. 26, 2018, 9:11 p.m. UTC | #2
W dniu 26.11.2018 o 21:44, Lucian Cristian pisze:
> On 20.11.2018 18:20, Tomasz Maciej Nowak wrote:
>> This small series addresses current problem with late loading of Intel
>> microcode in OpenWrt. Following the commit messages [1] and later
>> discussion, late loading off the microcode can be ineffective for some
>> processors [2] and for others disabled [3]. Also it is discouraged for
>> any processor starting from Haswell and Silvermont.
>> Therefore this series converts the Intel microcode bundle to an initial
>> ram disk which is loaded with grub, so kernel has access to it as early
>> as possible.
>> Previous patch series:
>> https://patchwork.ozlabs.org/project/lede/list/?series=39372
>>
>> 1. https://lore.kernel.org/patchwork/cover/348236
>> 2. https://lore.kernel.org/patchwork/cover/348236/#508603
>> 3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7
>>
>> Changes in v4:
>>    - copy also hidden files:
>>      x86: add packages files to image bootfs
>>    - no changes:
>>      1) include/rootfs.mk: remove boot directory
>>      2) x86: mount writable bootfs
>>      3) intel-microcode: remove dependency on iucode-tool
>>      4) x86: add intel microcode entries to grub config
>>      5) intel-microcode: create early load microcode image
>>
>> Change suggested by Philip Prindeville.
>>
>> Changes in v3:
>>    - replaced "include/rootfs.mk: move boot directory for later use"
>>      with "include/rootfs.mk: remove boot directory"; the final rootfs is
>>      always created after targets rootfs, so there's no need to save
>>      files for later use, also there was side effect to this approach,
>>      it kept the old files if packages version changed and buildroot
>>      wasn't cleaned beforehand
>>    - reflect the changes in "include/rootfs.mk: remove boot directory":
>>      x86: add packages files to image bootfs
>>    - expand commit message, narrow down the test in grub config:
>>      x86: add intel microcode entries to grub config
>>    - no changes:
>>      1) x86: mount writable bootfs
>>      2) intel-microcode: remove dependency on iucode-tool
>>      3) intel-microcode: create early load microcode image
>>
>> Changes in v2:
>>    - three new commits allowing buildsystem to properly handle packages
>>      installing files to /boot directory, mainly for x86 target:
>>      1) include/rootfs.mk: move boot directory for later use
>>      2) x86: mount writable bootfs
>>      3) x86: add packages files to image bootfs
>>    - uncomplicate test for AMD processors in:
>>      x86: add intel microcode entries to grub config
>>    - remove package specific hook in x86 image Makefile, remove
>>      postinst/prerm scripts and install microcode directly to /boot:
>>      intel-microcode: create early load microcode image
>>    - no changes:
>>      intel-microcode: remove dependency on iucode-tool
>>
>> All changes in v2 suggested by Matthias Schiffer and Philip Prindeville.
>>
>> Tomasz Maciej Nowak (6):
>>    include/rootfs.mk: remove boot directory
>>    x86: mount writable bootfs
>>    x86: add packages files to image bootfs
>>    intel-microcode: remove dependency on iucode-tool
>>    x86: add intel microcode entries to grub config
>>    intel-microcode: create early load microcode image
>>
>>   include/rootfs.mk                                |  1 +
>>   package/firmware/intel-microcode/Makefile        | 16 +++++++++-------
>>   .../x86/base-files/lib/preinit/02_load_x86_ucode |  6 ++++--
>>   .../x86/base-files/lib/preinit/79_move_config    | 12 ++++--------
>>   target/linux/x86/image/Makefile                  |  6 ++++--
>>   target/linux/x86/image/grub-iso.cfg              |  3 +++
>>   target/linux/x86/image/grub.cfg                  |  3 +++
>>   7 files changed, 28 insertions(+), 19 deletions(-)
>>
>>
> 
> this series I think are braking the boot on Via CPU's
> 
> grub complains with
> 
> 
> error: can't find command '['.
> 
> error: file '/boot/amd-ucode.img' not found.
> 
> error: can't find command '['.
> 
> error: file '/boot/intel-ucode.img' not found.
> 
> 
> Press any key to continue...
> 
> 
> And you have to press any key..

Damn, one case I didn't test. To be sure is this after sysupgrade? If yes please revert these commits:

546fced2a23557e95dd34246744c3aa6cad92fe6 x86: add intel microcode entries to grub config
022ffb56b2491fd7d8051ac6e6c7622ecc313d8f intel-microcode: create early load microcode image
a822283c7e56bb3b409712e0eb9af5a91aac247d x86: add amd microcode entries to grub config
975019b3a755ec3b91864b60b45e5ee104075096 amd64-microcode: create early load microcode image

I'll try to come up with better transition.

> 
> 
> Regards
>
Lucian Cristian Nov. 26, 2018, 9:47 p.m. UTC | #3
On 26.11.2018 23:11, Tomasz Maciej Nowak wrote:
> W dniu 26.11.2018 o 21:44, Lucian Cristian pisze:
>> On 20.11.2018 18:20, Tomasz Maciej Nowak wrote:
>>> This small series addresses current problem with late loading of Intel
>>> microcode in OpenWrt. Following the commit messages [1] and later
>>> discussion, late loading off the microcode can be ineffective for some
>>> processors [2] and for others disabled [3]. Also it is discouraged for
>>> any processor starting from Haswell and Silvermont.
>>> Therefore this series converts the Intel microcode bundle to an initial
>>> ram disk which is loaded with grub, so kernel has access to it as early
>>> as possible.
>>> Previous patch series:
>>> https://patchwork.ozlabs.org/project/lede/list/?series=39372
>>>
>>> 1. https://lore.kernel.org/patchwork/cover/348236
>>> 2. https://lore.kernel.org/patchwork/cover/348236/#508603
>>> 3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7
>>>
>>> Changes in v4:
>>>     - copy also hidden files:
>>>       x86: add packages files to image bootfs
>>>     - no changes:
>>>       1) include/rootfs.mk: remove boot directory
>>>       2) x86: mount writable bootfs
>>>       3) intel-microcode: remove dependency on iucode-tool
>>>       4) x86: add intel microcode entries to grub config
>>>       5) intel-microcode: create early load microcode image
>>>
>>> Change suggested by Philip Prindeville.
>>>
>>> Changes in v3:
>>>     - replaced "include/rootfs.mk: move boot directory for later use"
>>>       with "include/rootfs.mk: remove boot directory"; the final rootfs is
>>>       always created after targets rootfs, so there's no need to save
>>>       files for later use, also there was side effect to this approach,
>>>       it kept the old files if packages version changed and buildroot
>>>       wasn't cleaned beforehand
>>>     - reflect the changes in "include/rootfs.mk: remove boot directory":
>>>       x86: add packages files to image bootfs
>>>     - expand commit message, narrow down the test in grub config:
>>>       x86: add intel microcode entries to grub config
>>>     - no changes:
>>>       1) x86: mount writable bootfs
>>>       2) intel-microcode: remove dependency on iucode-tool
>>>       3) intel-microcode: create early load microcode image
>>>
>>> Changes in v2:
>>>     - three new commits allowing buildsystem to properly handle packages
>>>       installing files to /boot directory, mainly for x86 target:
>>>       1) include/rootfs.mk: move boot directory for later use
>>>       2) x86: mount writable bootfs
>>>       3) x86: add packages files to image bootfs
>>>     - uncomplicate test for AMD processors in:
>>>       x86: add intel microcode entries to grub config
>>>     - remove package specific hook in x86 image Makefile, remove
>>>       postinst/prerm scripts and install microcode directly to /boot:
>>>       intel-microcode: create early load microcode image
>>>     - no changes:
>>>       intel-microcode: remove dependency on iucode-tool
>>>
>>> All changes in v2 suggested by Matthias Schiffer and Philip Prindeville.
>>>
>>> Tomasz Maciej Nowak (6):
>>>     include/rootfs.mk: remove boot directory
>>>     x86: mount writable bootfs
>>>     x86: add packages files to image bootfs
>>>     intel-microcode: remove dependency on iucode-tool
>>>     x86: add intel microcode entries to grub config
>>>     intel-microcode: create early load microcode image
>>>
>>>    include/rootfs.mk                                |  1 +
>>>    package/firmware/intel-microcode/Makefile        | 16 +++++++++-------
>>>    .../x86/base-files/lib/preinit/02_load_x86_ucode |  6 ++++--
>>>    .../x86/base-files/lib/preinit/79_move_config    | 12 ++++--------
>>>    target/linux/x86/image/Makefile                  |  6 ++++--
>>>    target/linux/x86/image/grub-iso.cfg              |  3 +++
>>>    target/linux/x86/image/grub.cfg                  |  3 +++
>>>    7 files changed, 28 insertions(+), 19 deletions(-)
>>>
>>>
>> this series I think are braking the boot on Via CPU's
>>
>> grub complains with
>>
>>
>> error: can't find command '['.
>>
>> error: file '/boot/amd-ucode.img' not found.
>>
>> error: can't find command '['.
>>
>> error: file '/boot/intel-ucode.img' not found.
>>
>>
>> Press any key to continue...
>>
>>
>> And you have to press any key..
> Damn, one case I didn't test. To be sure is this after sysupgrade? If yes please revert these commits:
>
> 546fced2a23557e95dd34246744c3aa6cad92fe6 x86: add intel microcode entries to grub config
> 022ffb56b2491fd7d8051ac6e6c7622ecc313d8f intel-microcode: create early load microcode image
> a822283c7e56bb3b409712e0eb9af5a91aac247d x86: add amd microcode entries to grub config
> 975019b3a755ec3b91864b60b45e5ee104075096 amd64-microcode: create early load microcode image
>
> I'll try to come up with better transition.
>
>>
>> Regards
>>
I think that you must enforce the microcode selection but for me this 
error persists if I select the cpu microcode (any, tested on hyper-v 
intel cpu)


error: can't find command '['.
error: can't find command '['.

Press any key to continue...



Regards
Tomasz Maciej Nowak Nov. 26, 2018, 9:58 p.m. UTC | #4
W dniu 26.11.2018 o 22:47, Lucian Cristian pisze:
> On 26.11.2018 23:11, Tomasz Maciej Nowak wrote:
>> W dniu 26.11.2018 o 21:44, Lucian Cristian pisze:
>>> On 20.11.2018 18:20, Tomasz Maciej Nowak wrote:
>>>> This small series addresses current problem with late loading of Intel
>>>> microcode in OpenWrt. Following the commit messages [1] and later
>>>> discussion, late loading off the microcode can be ineffective for some
>>>> processors [2] and for others disabled [3]. Also it is discouraged for
>>>> any processor starting from Haswell and Silvermont.
>>>> Therefore this series converts the Intel microcode bundle to an initial
>>>> ram disk which is loaded with grub, so kernel has access to it as early
>>>> as possible.
>>>> Previous patch series:
>>>> https://patchwork.ozlabs.org/project/lede/list/?series=39372
>>>>
>>>> 1. https://lore.kernel.org/patchwork/cover/348236
>>>> 2. https://lore.kernel.org/patchwork/cover/348236/#508603
>>>> 3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7
>>>>
>>>> Changes in v4:
>>>>     - copy also hidden files:
>>>>       x86: add packages files to image bootfs
>>>>     - no changes:
>>>>       1) include/rootfs.mk: remove boot directory
>>>>       2) x86: mount writable bootfs
>>>>       3) intel-microcode: remove dependency on iucode-tool
>>>>       4) x86: add intel microcode entries to grub config
>>>>       5) intel-microcode: create early load microcode image
>>>>
>>>> Change suggested by Philip Prindeville.
>>>>
>>>> Changes in v3:
>>>>     - replaced "include/rootfs.mk: move boot directory for later use"
>>>>       with "include/rootfs.mk: remove boot directory"; the final rootfs is
>>>>       always created after targets rootfs, so there's no need to save
>>>>       files for later use, also there was side effect to this approach,
>>>>       it kept the old files if packages version changed and buildroot
>>>>       wasn't cleaned beforehand
>>>>     - reflect the changes in "include/rootfs.mk: remove boot directory":
>>>>       x86: add packages files to image bootfs
>>>>     - expand commit message, narrow down the test in grub config:
>>>>       x86: add intel microcode entries to grub config
>>>>     - no changes:
>>>>       1) x86: mount writable bootfs
>>>>       2) intel-microcode: remove dependency on iucode-tool
>>>>       3) intel-microcode: create early load microcode image
>>>>
>>>> Changes in v2:
>>>>     - three new commits allowing buildsystem to properly handle packages
>>>>       installing files to /boot directory, mainly for x86 target:
>>>>       1) include/rootfs.mk: move boot directory for later use
>>>>       2) x86: mount writable bootfs
>>>>       3) x86: add packages files to image bootfs
>>>>     - uncomplicate test for AMD processors in:
>>>>       x86: add intel microcode entries to grub config
>>>>     - remove package specific hook in x86 image Makefile, remove
>>>>       postinst/prerm scripts and install microcode directly to /boot:
>>>>       intel-microcode: create early load microcode image
>>>>     - no changes:
>>>>       intel-microcode: remove dependency on iucode-tool
>>>>
>>>> All changes in v2 suggested by Matthias Schiffer and Philip Prindeville.
>>>>
>>>> Tomasz Maciej Nowak (6):
>>>>     include/rootfs.mk: remove boot directory
>>>>     x86: mount writable bootfs
>>>>     x86: add packages files to image bootfs
>>>>     intel-microcode: remove dependency on iucode-tool
>>>>     x86: add intel microcode entries to grub config
>>>>     intel-microcode: create early load microcode image
>>>>
>>>>    include/rootfs.mk                                |  1 +
>>>>    package/firmware/intel-microcode/Makefile        | 16 +++++++++-------
>>>>    .../x86/base-files/lib/preinit/02_load_x86_ucode |  6 ++++--
>>>>    .../x86/base-files/lib/preinit/79_move_config    | 12 ++++--------
>>>>    target/linux/x86/image/Makefile                  |  6 ++++--
>>>>    target/linux/x86/image/grub-iso.cfg              |  3 +++
>>>>    target/linux/x86/image/grub.cfg                  |  3 +++
>>>>    7 files changed, 28 insertions(+), 19 deletions(-)
>>>>
>>>>
>>> this series I think are braking the boot on Via CPU's
>>>
>>> grub complains with
>>>
>>>
>>> error: can't find command '['.
>>>
>>> error: file '/boot/amd-ucode.img' not found.
>>>
>>> error: can't find command '['.
>>>
>>> error: file '/boot/intel-ucode.img' not found.
>>>
>>>
>>> Press any key to continue...
>>>
>>>
>>> And you have to press any key..
>> Damn, one case I didn't test. To be sure is this after sysupgrade? If yes please revert these commits:
>>
>> 546fced2a23557e95dd34246744c3aa6cad92fe6 x86: add intel microcode entries to grub config
>> 022ffb56b2491fd7d8051ac6e6c7622ecc313d8f intel-microcode: create early load microcode image
>> a822283c7e56bb3b409712e0eb9af5a91aac247d x86: add amd microcode entries to grub config
>> 975019b3a755ec3b91864b60b45e5ee104075096 amd64-microcode: create early load microcode image
>>
>> I'll try to come up with better transition.
>>
>>>
>>> Regards
>>>
> I think that you must enforce the microcode selection but for me this error persists if I select the cpu microcode (any, tested on hyper-v intel cpu)

No, Your grub doesn't understand *if* command because it's old an doesn't have "test" module enabled. It's left there because sysupgrade doesn't upgrade grub, it updates only boot and root partitions. If You'll write the created image not by sysupgrade but by dd'ing to boot medium, It'll start properly without interruptions.
BTW thank You for the report.

> 
> 
> error: can't find command '['.
> error: can't find command '['.
> 
> Press any key to continue...
> 
> 
> 
> Regards
> 
>
Lucian Cristian Nov. 27, 2018, 1:47 p.m. UTC | #5
On 26.11.2018 23:58, Tomasz Maciej Nowak wrote:
> W dniu 26.11.2018 o 22:47, Lucian Cristian pisze:
>> On 26.11.2018 23:11, Tomasz Maciej Nowak wrote:
>>> W dniu 26.11.2018 o 21:44, Lucian Cristian pisze:
>>>> On 20.11.2018 18:20, Tomasz Maciej Nowak wrote:
>>>>> This small series addresses current problem with late loading of Intel
>>>>> microcode in OpenWrt. Following the commit messages [1] and later
>>>>> discussion, late loading off the microcode can be ineffective for some
>>>>> processors [2] and for others disabled [3]. Also it is discouraged for
>>>>> any processor starting from Haswell and Silvermont.
>>>>> Therefore this series converts the Intel microcode bundle to an initial
>>>>> ram disk which is loaded with grub, so kernel has access to it as early
>>>>> as possible.
>>>>> Previous patch series:
>>>>> https://patchwork.ozlabs.org/project/lede/list/?series=39372
>>>>>
>>>>> 1. https://lore.kernel.org/patchwork/cover/348236
>>>>> 2. https://lore.kernel.org/patchwork/cover/348236/#508603
>>>>> 3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7
[...]
>>>>> No, Your grub doesn't understand *if* command because it's old an doesn't have "test" module enabled. It's left there because sysupgrade doesn't upgrade grub, it updates only boot and root partitions. If You'll write the created image not by sysupgrade but by dd'ing to boot medium, It'll start properly without interruptions.
>>>>> BTW thank You for the report.
>>>>>
>>
>> error: can't find command '['.
>> error: can't find command '['.
>>
>> Press any key to continue...
>>
>>
>>
>> Regards
>>
>>
Can I repair this somehow without writing the full image ? only by 
reversing the commits ?

Regards
Tomasz Maciej Nowak Nov. 27, 2018, 3:11 p.m. UTC | #6
W dniu 27.11.2018 o 14:47, Lucian Cristian pisze:
> On 26.11.2018 23:58, Tomasz Maciej Nowak wrote:
>> W dniu 26.11.2018 o 22:47, Lucian Cristian pisze:
>>> On 26.11.2018 23:11, Tomasz Maciej Nowak wrote:
>>>> W dniu 26.11.2018 o 21:44, Lucian Cristian pisze:
>>>>> On 20.11.2018 18:20, Tomasz Maciej Nowak wrote:
>>>>>> This small series addresses current problem with late loading of Intel
>>>>>> microcode in OpenWrt. Following the commit messages [1] and later
>>>>>> discussion, late loading off the microcode can be ineffective for some
>>>>>> processors [2] and for others disabled [3]. Also it is discouraged for
>>>>>> any processor starting from Haswell and Silvermont.
>>>>>> Therefore this series converts the Intel microcode bundle to an initial
>>>>>> ram disk which is loaded with grub, so kernel has access to it as early
>>>>>> as possible.
>>>>>> Previous patch series:
>>>>>> https://patchwork.ozlabs.org/project/lede/list/?series=39372
>>>>>>
>>>>>> 1. https://lore.kernel.org/patchwork/cover/348236
>>>>>> 2. https://lore.kernel.org/patchwork/cover/348236/#508603
>>>>>> 3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7
> [...]
>>>>>> No, Your grub doesn't understand *if* command because it's old an doesn't have "test" module enabled. It's left there because sysupgrade doesn't upgrade grub, it updates only boot and root partitions. If You'll write the created image not by sysupgrade but by dd'ing to boot medium, It'll start properly without interruptions.
>>>>>> BTW thank You for the report.
>>>>>>
>>>
>>> error: can't find command '['.
>>> error: can't find command '['.
>>>
>>> Press any key to continue...
>>>
>>>
>>>
>>> Regards
>>>
>>>
> Can I repair this somehow without writing the full image ? only by reversing the commits ?

No, not at the moment. I'm trying to figure out best way to update grub on sysupgrade, until then reverting the mentioned commits will bring back old behavior, and no manual intervention on boot will be necessary.

> 
> Regards
>
John Crispin Nov. 27, 2018, 5:04 p.m. UTC | #7
On 27/11/2018 16:11, Tomasz Maciej Nowak wrote:
> W dniu 27.11.2018 o 14:47, Lucian Cristian pisze:
>> On 26.11.2018 23:58, Tomasz Maciej Nowak wrote:
>>> W dniu 26.11.2018 o 22:47, Lucian Cristian pisze:
>>>> On 26.11.2018 23:11, Tomasz Maciej Nowak wrote:
>>>>> W dniu 26.11.2018 o 21:44, Lucian Cristian pisze:
>>>>>> On 20.11.2018 18:20, Tomasz Maciej Nowak wrote:
>>>>>>> This small series addresses current problem with late loading of Intel
>>>>>>> microcode in OpenWrt. Following the commit messages [1] and later
>>>>>>> discussion, late loading off the microcode can be ineffective for some
>>>>>>> processors [2] and for others disabled [3]. Also it is discouraged for
>>>>>>> any processor starting from Haswell and Silvermont.
>>>>>>> Therefore this series converts the Intel microcode bundle to an initial
>>>>>>> ram disk which is loaded with grub, so kernel has access to it as early
>>>>>>> as possible.
>>>>>>> Previous patch series:
>>>>>>> https://patchwork.ozlabs.org/project/lede/list/?series=39372
>>>>>>>
>>>>>>> 1. https://lore.kernel.org/patchwork/cover/348236
>>>>>>> 2. https://lore.kernel.org/patchwork/cover/348236/#508603
>>>>>>> 3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7
>> [...]
>>>>>>> No, Your grub doesn't understand *if* command because it's old an doesn't have "test" module enabled. It's left there because sysupgrade doesn't upgrade grub, it updates only boot and root partitions. If You'll write the created image not by sysupgrade but by dd'ing to boot medium, It'll start properly without interruptions.
>>>>>>> BTW thank You for the report.
>>>>>>>
>>>> error: can't find command '['.
>>>> error: can't find command '['.
>>>>
>>>> Press any key to continue...
>>>>
>>>>
>>>>
>>>> Regards
>>>>
>>>>
>> Can I repair this somehow without writing the full image ? only by reversing the commits ?
> No, not at the moment. I'm trying to figure out best way to update grub on sysupgrade, until then reverting the mentioned commits will bring back old behavior, and no manual intervention on boot will be necessary.


shall we revert the series ?

     John


>> Regards
>>
Lucian Cristian Nov. 27, 2018, 5:14 p.m. UTC | #8
On 27.11.2018 19:04, John Crispin wrote:
>
> On 27/11/2018 16:11, Tomasz Maciej Nowak wrote:
>> W dniu 27.11.2018 o 14:47, Lucian Cristian pisze:
>>> On 26.11.2018 23:58, Tomasz Maciej Nowak wrote:
>>>> W dniu 26.11.2018 o 22:47, Lucian Cristian pisze:
>>>>> On 26.11.2018 23:11, Tomasz Maciej Nowak wrote:
>>>>>> W dniu 26.11.2018 o 21:44, Lucian Cristian pisze:
>>>>>>> On 20.11.2018 18:20, Tomasz Maciej Nowak wrote:
>>>>>>>> This small series addresses current problem with late loading 
>>>>>>>> of Intel
>>>>>>>> microcode in OpenWrt. Following the commit messages [1] and later
>>>>>>>> discussion, late loading off the microcode can be ineffective 
>>>>>>>> for some
>>>>>>>> processors [2] and for others disabled [3]. Also it is 
>>>>>>>> discouraged for
>>>>>>>> any processor starting from Haswell and Silvermont.
>>>>>>>> Therefore this series converts the Intel microcode bundle to an 
>>>>>>>> initial
>>>>>>>> ram disk which is loaded with grub, so kernel has access to it 
>>>>>>>> as early
>>>>>>>> as possible.
>>>>>>>> Previous patch series:
>>>>>>>> https://patchwork.ozlabs.org/project/lede/list/?series=39372
>>>>>>>>
>>>>>>>> 1. https://lore.kernel.org/patchwork/cover/348236
>>>>>>>> 2. https://lore.kernel.org/patchwork/cover/348236/#508603
>>>>>>>> 3. 
>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7
>>> [...]
>>>>>>>> No, Your grub doesn't understand *if* command because it's old 
>>>>>>>> an doesn't have "test" module enabled. It's left there because 
>>>>>>>> sysupgrade doesn't upgrade grub, it updates only boot and root 
>>>>>>>> partitions. If You'll write the created image not by sysupgrade 
>>>>>>>> but by dd'ing to boot medium, It'll start properly without 
>>>>>>>> interruptions.
>>>>>>>> BTW thank You for the report.
>>>>>>>>
>>>>> error: can't find command '['.
>>>>> error: can't find command '['.
>>>>>
>>>>> Press any key to continue...
>>>>>
>>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>>
>>> Can I repair this somehow without writing the full image ? only by 
>>> reversing the commits ?
>> No, not at the moment. I'm trying to figure out best way to update 
>> grub on sysupgrade, until then reverting the mentioned commits will 
>> bring back old behavior, and no manual intervention on boot will be 
>> necessary.
>
>
> shall we revert the series ?
>
>     John
>
>
>>> Regards
>>>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

sysupgrade will break things bad if you can't press any key on reboot, 
so it's better to revert for the moment


Regards
Tomasz Maciej Nowak Nov. 27, 2018, 5:15 p.m. UTC | #9
W dniu 27.11.2018 o 18:04, John Crispin pisze:
> 
> On 27/11/2018 16:11, Tomasz Maciej Nowak wrote:
>> W dniu 27.11.2018 o 14:47, Lucian Cristian pisze:
>>> On 26.11.2018 23:58, Tomasz Maciej Nowak wrote:
>>>> W dniu 26.11.2018 o 22:47, Lucian Cristian pisze:
>>>>> On 26.11.2018 23:11, Tomasz Maciej Nowak wrote:
>>>>>> W dniu 26.11.2018 o 21:44, Lucian Cristian pisze:
>>>>>>> On 20.11.2018 18:20, Tomasz Maciej Nowak wrote:
>>>>>>>> This small series addresses current problem with late loading of Intel
>>>>>>>> microcode in OpenWrt. Following the commit messages [1] and later
>>>>>>>> discussion, late loading off the microcode can be ineffective for some
>>>>>>>> processors [2] and for others disabled [3]. Also it is discouraged for
>>>>>>>> any processor starting from Haswell and Silvermont.
>>>>>>>> Therefore this series converts the Intel microcode bundle to an initial
>>>>>>>> ram disk which is loaded with grub, so kernel has access to it as early
>>>>>>>> as possible.
>>>>>>>> Previous patch series:
>>>>>>>> https://patchwork.ozlabs.org/project/lede/list/?series=39372
>>>>>>>>
>>>>>>>> 1. https://lore.kernel.org/patchwork/cover/348236
>>>>>>>> 2. https://lore.kernel.org/patchwork/cover/348236/#508603
>>>>>>>> 3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7
>>> [...]
>>>>>>>> No, Your grub doesn't understand *if* command because it's old an doesn't have "test" module enabled. It's left there because sysupgrade doesn't upgrade grub, it updates only boot and root partitions. If You'll write the created image not by sysupgrade but by dd'ing to boot medium, It'll start properly without interruptions.
>>>>>>>> BTW thank You for the report.
>>>>>>>>
>>>>> error: can't find command '['.
>>>>> error: can't find command '['.
>>>>>
>>>>> Press any key to continue...
>>>>>
>>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>>
>>> Can I repair this somehow without writing the full image ? only by reversing the commits ?
>> No, not at the moment. I'm trying to figure out best way to update grub on sysupgrade, until then reverting the mentioned commits will bring back old behavior, and no manual intervention on boot will be necessary.
> 
> 
> shall we revert the series ?

Yes, but not the whole series only these commits:

546fced2a23557e95dd34246744c3aa6cad92fe6 x86: add intel microcode entries to grub config
022ffb56b2491fd7d8051ac6e6c7622ecc313d8f intel-microcode: create early load microcode image
a822283c7e56bb3b409712e0eb9af5a91aac247d x86: add amd microcode entries to grub config
975019b3a755ec3b91864b60b45e5ee104075096 amd64-microcode: create early load microcode image

The rest is okay, won't cause any regressions and will save the effort.

Thank You.

> 
>     John
> 
> 
>>> Regards
>>>
John Crispin Nov. 27, 2018, 5:59 p.m. UTC | #10
On 27/11/2018 18:15, Tomasz Maciej Nowak wrote:
> W dniu 27.11.2018 o 18:04, John Crispin pisze:
>> On 27/11/2018 16:11, Tomasz Maciej Nowak wrote:
>>> W dniu 27.11.2018 o 14:47, Lucian Cristian pisze:
>>>> On 26.11.2018 23:58, Tomasz Maciej Nowak wrote:
>>>>> W dniu 26.11.2018 o 22:47, Lucian Cristian pisze:
>>>>>> On 26.11.2018 23:11, Tomasz Maciej Nowak wrote:
>>>>>>> W dniu 26.11.2018 o 21:44, Lucian Cristian pisze:
>>>>>>>> On 20.11.2018 18:20, Tomasz Maciej Nowak wrote:
>>>>>>>>> This small series addresses current problem with late loading of Intel
>>>>>>>>> microcode in OpenWrt. Following the commit messages [1] and later
>>>>>>>>> discussion, late loading off the microcode can be ineffective for some
>>>>>>>>> processors [2] and for others disabled [3]. Also it is discouraged for
>>>>>>>>> any processor starting from Haswell and Silvermont.
>>>>>>>>> Therefore this series converts the Intel microcode bundle to an initial
>>>>>>>>> ram disk which is loaded with grub, so kernel has access to it as early
>>>>>>>>> as possible.
>>>>>>>>> Previous patch series:
>>>>>>>>> https://patchwork.ozlabs.org/project/lede/list/?series=39372
>>>>>>>>>
>>>>>>>>> 1. https://lore.kernel.org/patchwork/cover/348236
>>>>>>>>> 2. https://lore.kernel.org/patchwork/cover/348236/#508603
>>>>>>>>> 3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7
>>>> [...]
>>>>>>>>> No, Your grub doesn't understand *if* command because it's old an doesn't have "test" module enabled. It's left there because sysupgrade doesn't upgrade grub, it updates only boot and root partitions. If You'll write the created image not by sysupgrade but by dd'ing to boot medium, It'll start properly without interruptions.
>>>>>>>>> BTW thank You for the report.
>>>>>>>>>
>>>>>> error: can't find command '['.
>>>>>> error: can't find command '['.
>>>>>>
>>>>>> Press any key to continue...
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>>
>>>> Can I repair this somehow without writing the full image ? only by reversing the commits ?
>>> No, not at the moment. I'm trying to figure out best way to update grub on sysupgrade, until then reverting the mentioned commits will bring back old behavior, and no manual intervention on boot will be necessary.
>>
>> shall we revert the series ?
> Yes, but not the whole series only these commits:
>
> 546fced2a23557e95dd34246744c3aa6cad92fe6 x86: add intel microcode entries to grub config
> 022ffb56b2491fd7d8051ac6e6c7622ecc313d8f intel-microcode: create early load microcode image
> a822283c7e56bb3b409712e0eb9af5a91aac247d x86: add amd microcode entries to grub config
> 975019b3a755ec3b91864b60b45e5ee104075096 amd64-microcode: create early load microcode image
>
> The rest is okay, won't cause any regressions and will save the effort.
>
> Thank You.
>
done ....
Lucian Cristian Nov. 28, 2018, 7:34 p.m. UTC | #11
On 27.11.2018 19:59, John Crispin wrote:
>
> On 27/11/2018 18:15, Tomasz Maciej Nowak wrote:
>> W dniu 27.11.2018 o 18:04, John Crispin pisze:
>>> On 27/11/2018 16:11, Tomasz Maciej Nowak wrote:
>>>> W dniu 27.11.2018 o 14:47, Lucian Cristian pisze:
>>>>> On 26.11.2018 23:58, Tomasz Maciej Nowak wrote:
>>>>>> W dniu 26.11.2018 o 22:47, Lucian Cristian pisze:
>>>>>>> On 26.11.2018 23:11, Tomasz Maciej Nowak wrote:
>>>>>>>> W dniu 26.11.2018 o 21:44, Lucian Cristian pisze:
>>>>>>>>> On 20.11.2018 18:20, Tomasz Maciej Nowak wrote:
>>>>>>>>>> This small series addresses current problem with late loading 
>>>>>>>>>> of Intel
>>>>>>>>>> microcode in OpenWrt. Following the commit messages [1] and 
>>>>>>>>>> later
>>>>>>>>>> discussion, late loading off the microcode can be ineffective 
>>>>>>>>>> for some
>>>>>>>>>> processors [2] and for others disabled [3]. Also it is 
>>>>>>>>>> discouraged for
>>>>>>>>>> any processor starting from Haswell and Silvermont.
>>>>>>>>>> Therefore this series converts the Intel microcode bundle to 
>>>>>>>>>> an initial
>>>>>>>>>> ram disk which is loaded with grub, so kernel has access to 
>>>>>>>>>> it as early
>>>>>>>>>> as possible.
>>>>>>>>>> Previous patch series:
>>>>>>>>>> https://patchwork.ozlabs.org/project/lede/list/?series=39372
>>>>>>>>>>
>>>>>>>>>> 1. https://lore.kernel.org/patchwork/cover/348236
>>>>>>>>>> 2. https://lore.kernel.org/patchwork/cover/348236/#508603
>>>>>>>>>> 3. 
>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7
>>>>> [...]
>>>>>>>>>> No, Your grub doesn't understand *if* command because it's 
>>>>>>>>>> old an doesn't have "test" module enabled. It's left there 
>>>>>>>>>> because sysupgrade doesn't upgrade grub, it updates only boot 
>>>>>>>>>> and root partitions. If You'll write the created image not by 
>>>>>>>>>> sysupgrade but by dd'ing to boot medium, It'll start properly 
>>>>>>>>>> without interruptions.
>>>>>>>>>> BTW thank You for the report.
>>>>>>>>>>
>>>>>>> error: can't find command '['.
>>>>>>> error: can't find command '['.
>>>>>>>
>>>>>>> Press any key to continue...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>>
>>>>> Can I repair this somehow without writing the full image ? only by 
>>>>> reversing the commits ?
>>>> No, not at the moment. I'm trying to figure out best way to update 
>>>> grub on sysupgrade, until then reverting the mentioned commits will 
>>>> bring back old behavior, and no manual intervention on boot will be 
>>>> necessary.
>>>
>>> shall we revert the series ?
>> Yes, but not the whole series only these commits:
>>
>> 546fced2a23557e95dd34246744c3aa6cad92fe6 x86: add intel microcode 
>> entries to grub config
>> 022ffb56b2491fd7d8051ac6e6c7622ecc313d8f intel-microcode: create 
>> early load microcode image
>> a822283c7e56bb3b409712e0eb9af5a91aac247d x86: add amd microcode 
>> entries to grub config
>> 975019b3a755ec3b91864b60b45e5ee104075096 amd64-microcode: create 
>> early load microcode image
>>
>> The rest is okay, won't cause any regressions and will save the effort.
>>
>> Thank You.
>>
> done ....
>
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

turns out that grub will boot automatically after a time out despite the 
errors (some seconds), but there was another problem that didn't kept 
the sysupgrade settings and that made my system ureachable


Regards
Tomasz Maciej Nowak Nov. 28, 2018, 7:56 p.m. UTC | #12
W dniu 28.11.2018 o 20:34, Lucian Cristian pisze:
> On 27.11.2018 19:59, John Crispin wrote:
>>
>> On 27/11/2018 18:15, Tomasz Maciej Nowak wrote:
>>> W dniu 27.11.2018 o 18:04, John Crispin pisze:
>>>> On 27/11/2018 16:11, Tomasz Maciej Nowak wrote:
>>>>> W dniu 27.11.2018 o 14:47, Lucian Cristian pisze:
>>>>>> On 26.11.2018 23:58, Tomasz Maciej Nowak wrote:
>>>>>>> W dniu 26.11.2018 o 22:47, Lucian Cristian pisze:
>>>>>>>> On 26.11.2018 23:11, Tomasz Maciej Nowak wrote:
>>>>>>>>> W dniu 26.11.2018 o 21:44, Lucian Cristian pisze:
>>>>>>>>>> On 20.11.2018 18:20, Tomasz Maciej Nowak wrote:
>>>>>>>>>>> This small series addresses current problem with late loading of Intel
>>>>>>>>>>> microcode in OpenWrt. Following the commit messages [1] and later
>>>>>>>>>>> discussion, late loading off the microcode can be ineffective for some
>>>>>>>>>>> processors [2] and for others disabled [3]. Also it is discouraged for
>>>>>>>>>>> any processor starting from Haswell and Silvermont.
>>>>>>>>>>> Therefore this series converts the Intel microcode bundle to an initial
>>>>>>>>>>> ram disk which is loaded with grub, so kernel has access to it as early
>>>>>>>>>>> as possible.
>>>>>>>>>>> Previous patch series:
>>>>>>>>>>> https://patchwork.ozlabs.org/project/lede/list/?series=39372
>>>>>>>>>>>
>>>>>>>>>>> 1. https://lore.kernel.org/patchwork/cover/348236
>>>>>>>>>>> 2. https://lore.kernel.org/patchwork/cover/348236/#508603
>>>>>>>>>>> 3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7
>>>>>> [...]
>>>>>>>>>>> No, Your grub doesn't understand *if* command because it's old an doesn't have "test" module enabled. It's left there because sysupgrade doesn't upgrade grub, it updates only boot and root partitions. If You'll write the created image not by sysupgrade but by dd'ing to boot medium, It'll start properly without interruptions.
>>>>>>>>>>> BTW thank You for the report.
>>>>>>>>>>>
>>>>>>>> error: can't find command '['.
>>>>>>>> error: can't find command '['.
>>>>>>>>
>>>>>>>> Press any key to continue...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>>
>>>>>> Can I repair this somehow without writing the full image ? only by reversing the commits ?
>>>>> No, not at the moment. I'm trying to figure out best way to update grub on sysupgrade, until then reverting the mentioned commits will bring back old behavior, and no manual intervention on boot will be necessary.
>>>>
>>>> shall we revert the series ?
>>> Yes, but not the whole series only these commits:
>>>
>>> 546fced2a23557e95dd34246744c3aa6cad92fe6 x86: add intel microcode entries to grub config
>>> 022ffb56b2491fd7d8051ac6e6c7622ecc313d8f intel-microcode: create early load microcode image
>>> a822283c7e56bb3b409712e0eb9af5a91aac247d x86: add amd microcode entries to grub config
>>> 975019b3a755ec3b91864b60b45e5ee104075096 amd64-microcode: create early load microcode image
>>>
>>> The rest is okay, won't cause any regressions and will save the effort.
>>>
>>> Thank You.
>>>
>> done ....
>>
>>
>>
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> turns out that grub will boot automatically after a time out despite the errors (some seconds), but there was another problem that didn't kept the sysupgrade settings and that made my system ureachable

Yes, but still I think this error is unacceptable.

Sorry about the sysupgrade problem, and thanks for the report.

> 
> 
> Regards
>