Inline
> On Apr 4, 2018, at 5:28 PM, Luiz Angelo Daros de Luca
> wrote:
>
> When '-k' is used, sysupgrade inserts into backup a new file
> /etc/sysupgrade.installed which contains pkgname and
> origin (rom, overlay, unknown).
>
> It's maily used to reinstall all extra packages:
>
> # opkg upd
Is there a downside to forcing AMD to also do early firmware updates?
> On Apr 17, 2018, at 12:50 PM, Tomasz Maciej Nowak wrote:
>
> Create initrd enries for x86 images, that'll load intel microcode as
> early as possible. Also restrict the late load of microcode to AMD
> processors.
>
> Sign
On 17-04-18 19:16, Lucian Cristian wrote:
On 16.04.2018 01:53, Hauke Mehrtens wrote:
This allows us to link the other tools against our libz and we do not
need the system zlib any more.
Only the static linked library is copied to the staging directory so we
have a statically linked library on
Create initrd image with packed microcode. This'll allow to load it at
early boot stage.
Signed-off-by: Tomasz Maciej Nowak
---
package/firmware/intel-microcode/Makefile | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/package/firmware/intel-microcode/Makefile
Create initrd enries for x86 images, that'll load intel microcode as
early as possible. Also restrict the late load of microcode to AMD
processors.
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/x86/base-files/lib/preinit/02_load_x86_ucode | 6 --
target/linux/x86/image/Makefile
It is not necessary to have iucode-tool present on target system to have
functional intel-microcode package. The build time dependency is kept.
Signed-off-by: Tomasz Maciej Nowak
---
package/firmware/intel-microcode/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pac
Add files to bootfs image from selected as built-in packages, which want
to install files to targets boot file system.
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/x86/image/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/i
Mount boot file system with rw option to allow installation of packages
which install files to /boot directory.
Signed-off-by: Tomasz Maciej Nowak
---
.../linux/x86/base-files/lib/preinit/79_move_config | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/target/linu
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 starti
Currently every file in /boot directory is copied over target /boot on
root file system and is usually inaccessible because appropriate boot
file system is mounted on top of it. Therefore move /boot with contents
to staging directory for later processing, which in result will also
save space on tar
On 16.04.2018 01:53, Hauke Mehrtens wrote:
This allows us to link the other tools against our libz and we do not
need the system zlib any more.
Only the static linked library is copied to the staging directory so we
have a statically linked library on all systems and not only on Linux.
This also
Hi Kofi,
On Tue, Apr 17, 2018 at 07:32:57AM -0600, Kofi Agor wrote:
> Hi Enrico,
>
> Some minor changes to our patch:
>
>1. We (Craig Matsuura) found that disabling/enable the txtasklet worked
>better than tearing down and recreating the txtasklet each time. It also
>resolved a kerne
The question has come up on the forums about the status of a 18.05 release.
Back on 1 April 2018, Hauke wrote:
> I would propose this timeline:
> 1. Branch of openwrt-18.05 at 7. April
> 2. Create openwrt-18.05-rc1 release on 14. April
> 3. Create openwrt-18.05-rc2 release on 28. April
> 4. Creat
On Tue, Apr 17, 2018 at 2:56 PM, Felix Fietkau wrote:
> On 2018-04-17 13:50, Kristian Evensen wrote:
>> This is with the same image as last time (commit
>> f6e6eadc99c6274207f8f2ebc739063549959a1f) and configuration (radios
>> used as clients). I see that mt76 has been updated during the weekend
>
On 2018-04-17 13:50, Kristian Evensen wrote:
> This is with the same image as last time (commit
> f6e6eadc99c6274207f8f2ebc739063549959a1f) and configuration (radios
> used as clients). I see that mt76 has been updated during the weekend
> so I will go ahead and compile a new image with the latest
Hello,
This patch, as I see in patchwork, is accepted but I can'tÂ
find it in https://github.com/openwrt/openwrt.
Is there any issues or questions with this patch?
Best regards,
Evgeniy Didin
On Mon, 2018-04-02 at 19:25 +0300, Evgeniy Didin wrote:
> Update Linux kernel version from 4.9 to 4.14
Hi,
On Thu, Apr 12, 2018 at 3:28 PM, Kristian Evensen
wrote:
> Thanks for the pointer. I compiled a new image KALLSYMS, but now I am
> not able to reproduce the error. Perhaps there was something dirty in
> my build directory. I will keep the image KALLSYMS on the routers and
> keep checking for
Hi Jaap,
On Tue, Apr 17, 2018 at 10:03:10AM +0200, Jaap Buurman wrote:
> Hello all,
>
> Today I discovered that pulling packages from the feeds is done over
> http by default instead of https. I understand it is always going to
> be a trade-off between space requirements and features/security.
>
On Tue, Apr 17, 2018 at 11:23 AM, Linus Walleij
wrote:
> On Tue, Apr 17, 2018 at 12:34 AM, Roman Yeryomin wrote:
>
>> I've found why it didn't work:
>> [5.845199] Warning! fotg210_hcd should always be loaded before uhci_hcd
>> and ohci_hcd, not after
>>
>> After fixing kernel config and apply
On Tue, Apr 17, 2018 at 12:34 AM, Roman Yeryomin wrote:
> I've found why it didn't work:
> [5.845199] Warning! fotg210_hcd should always be loaded before uhci_hcd
> and ohci_hcd, not after
>
> After fixing kernel config and applying your patch it works.
> So your patch works and is needed ind
Hi,
if I understand lynxis staging tree [1] correctly, future squashfs
images will be reproducible.
Will this be merged to master before the next 18.x release?
Best,
Paul
[1]
https://git.openwrt.org/?p=openwrt/staging/lynxis.git;a=commit;h=1fd818d4f8255cbaa0173d856f09f24bd88a6209
___
Dear Sven,
I wasn't aware of signature checking and hence I agree with yours and
Jo-Philipp's sentiment that this would be a bad idea. Please disregard
my suggestion. Thank you very much for teaching me about the signature
verification system.
Yours sincerely,
Jaap Buurman
On Tue, Apr 17, 2018
On Dienstag, 17. April 2018 10:03:10 CEST Jaap Buurman wrote:
> Hello all,
>
> Today I discovered that pulling packages from the feeds is done over
> http by default instead of https. I understand it is always going to
> be a trade-off between space requirements and features/security.
> However, p
Hello,
> Today I discovered that pulling packages from the feeds is done over
> http by default instead of https. I understand it is always going to
> be a trade-off between space requirements and features/security.
> However, pulling in packages over an unencrypted connection will
> allow for
Dear Alberto Bursi,
I did not know about signature verification. I agree that there are no
secrets to hide and hence signature verification should be sufficient
to avoid tampering. Thank you very much for your reassurance.
Yours sincerely,
Jaap Buurman
On Tue, Apr 17, 2018 at 10:13 AM, Alberto
Hello all,
Today I discovered that pulling packages from the feeds is done over
http by default instead of https. I understand it is always going to
be a trade-off between space requirements and features/security.
However, pulling in packages over an unencrypted connection will allow
for easy mani
26 matches
Mail list logo
