Short story:
Works a treat!
Longer story:
Details will have to wait (it's 3AM right now) but to keep it short -- I
put the two uI* files (ignored the .dtb file) onto an ext2 partition of a USB
stick. Followed the instructions on Martin's page, and successfully installed
back to the sa
On Sun, 14 Mar 2021 00:39:40 -0800 Rick Thomas wrote:
> Package: haveged
> Version: 1.9.14-1
> Severity: normal
>
> Dear Maintainer,
>
> I recently updated my OpenRD "client" ( arch = armv5tel ) from Buster to
> Bullseye and now haveged crashes.
>
I tri
reverted.
>> (the change to build/boot/arm/armel-kirkwood-u-boot-image-config
>> is obviously fine)
>>
>> I don't have an OpenRD anymore but I can probably find someone if
>> testing is required.
>
> I became aware recently that this was never fixed. Rick Th
> On Mar 14, 2019, at 1:04 AM, Richard Laager wrote:
>
> I forwarded your bug upstream:
> https://gitlab.com/NTPsec/ntpsec/issues/577
Hi!
I’m sorry to take so long getting back. I wanted to re-do my experiments in a
standard environment that your would be able to reproduce easily. Here a
Thanks!
I’ll give it a try tonight…
Rick
> On Mar 19, 2019, at 10:18 AM, Richard Laager wrote:
>
> Attached is an untested debdiff. This is the upstream change refreshed
> to apply to the package. You should be able to apply it and build a
> package locally like this:
>
> sudo apt update
> su
> On Mar 19, 2019, at 10:18 AM, Richard Laager wrote:
>
> Attached is an untested debdiff. This is the upstream change refreshed
> to apply to the package. You should be able to apply it and build a
> package locally like this:
>
> sudo apt update
> sudo apt install build-essential devscripts
Hi Richard,
I’m sorry that I was not able to try that patch for you. However, I was able
to download and (with a lot of help from Hal Murray) build the latest git
version. It worked a treat and properly handled the time lag between ntpsec
starting and dhcp finishing.
Let me know if there’s a
Thanks, yes, that did the trick.
I’ve installed it on one of my test computers. It seems to work fine. I’ve
tried a couple of things that should trigger the bug, if it’s still there.
In particular, rebooting the computer then examining the journal shows that it
does get to poll all of the con
Raspberry Pi 4B (8GB) running bullseye, but does not seem to have any version
of u-boot installed. Weird?
Running tells me that the following (among
lots of others) versions are available. Should I install one of them and see
what happens?
Package u-boot-rpi:
p 2021.01+dfsg-5 stable 500
P
A Cubox-i running Debian bullseye (11.6). According to It
has "u-boot-tools" (version 2021.01+dfsg-5) installed, but none of the
u-boot- packages installed.
If I reboot it and watch the serial console, I see it showing "U-boot
2021.01-dfsg-5" so that version must have gotten into the firmwar
Here's another Cubox-i. This one's running Bookworm.
shows a surprising number of u-boot-
packages installed, ( = exynos, imx, omap, sunxi) as well as plain
"u-boot". All of them are version 2022.04+dfsg-2+b1.
Rebooting while watching the serial console output says "U-Boot SPL
2016.05-rc2+d
Sadly, my sheevaplug was not revivable. I have a couple of OpenRD boxes and a
couple of CUBox-i boxes I can test for you, as well as a RaspberryPi-4B and a
couple of Orange-Pi boxes that can also be tested. I'll send results as I get
to them.
BTW, are there directions for installing and conf
601 - 612 of 612 matches
Mail list logo
