> > The old behavior was that the kernel would wait after the "fdc0 ..." line
> > until fd0 attaches. Now it does the waiting in the background and continues
> > booting. I agree that it's a bit ugly, but it makes booting about 5 seconds
> > faster.
>
> It's not just a bit ugly... It's
> The old behavior was that the kernel would wait after the "fdc0 ..." line
> until fd0 attaches. Now it does the waiting in the background and continues
> booting. I agree that it's a bit ugly, but it makes booting about 5 seconds
> faster.
It's not just a bit ugly... It's horrible. It has to
Hi,
I am writing this from a Thinkpad T420 with Coreboot flashed and the
Intel Management Engine disabled!
recently there was a lot of work done regarding disabling/neutralizing
the ME.
Have a look at this:
http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
Dave,
You might want to take a look at both the Libreboot and Coreboot open
source projects. The challenge with the IME is that if you literally
disable it, it will shut down the system - and it's code is pretty
heavily encrypted. The Coreboot project has had some limited success
It can't be used to attack you from the public Internet unless (a) you don't
have a firewall or (b) you have forwarded the IME port on your firewall to a
host on your LAN. You are, however, susceptible to other hosts on your LAN
guessing the IME password, so be sure to use a strong password.
While this isn't specifically an OpenBSD issue, since OpenBSD emphasizes
security this seems like a good place to ask.
As far as I can tell the "Intel Management Engine" (IME) is a gaping
backdoor into every recent Intel-based system. My searches on the 'net
haven't turned up much useful
You mean OpenBSD 6.1 right?
On September 8, 2017 2:33:46 PM GMT+02:00, Artur Pedziwilk
wrote:
>Have anyone of you got that model of Intel NUC?
>
>Intel® NUC Kit DE3815TYKHE
>https://ark.intel.com/products/78577/Intel-NUC-Kit-DE3815TYKHE
Have anyone of you got that model of Intel NUC?
Intel® NUC Kit DE3815TYKHE
https://ark.intel.com/products/78577/Intel-NUC-Kit-DE3815TYKHE
https://www.intel.com/content/dam/support/us/en/documents/boardsandkits/DE3815TYBE_TechProdSpec.pdf
I am trying to find some small computer to use with
On 17/09/08 09:51, Stuart Henderson wrote:
On 2017-09-08, Niels Kobschätzki wrote:
On 17/09/08 08:42, Niels Kobschätzki wrote:
Hi,
after I updated to the snapshot from September 7th, I cannot log into X
anymore. xdm comes up but logging in brings me directly back to
On 2017-09-08, Niels Kobschätzki wrote:
> On 17/09/08 08:42, Niels Kobschätzki wrote:
>>Hi,
>>
>>after I updated to the snapshot from September 7th, I cannot log into X
>>anymore. xdm comes up but logging in brings me directly back to xdm.
>>The xenodm.log say "XIO:
On Wednesday, 6 September 2017 19:18:49 CEST Rui Ribeiro wrote:
> I once booted netbsd in my Banana Pi/Lamobo R1, which is a similar machine
> from "the same manufacturer"; the bigger problem is that outside Linux,
> there is no support for the Broadcom switching chipset.
The R2 is a completely
On Thursday, 7 September 2017 19:15:31 CEST Arfnokill wrote:
> Using snapshots on amd64. Since two days ago the kernel prints this fd0 at
> fdc0 drive 0: density unknown very late during boot.
>
> It starts reordering libraries, and BAM... fd0 at fdc0 drive 0: density
> unknown in blue
On 17/09/08 08:42, Niels Kobschätzki wrote:
Hi,
after I updated to the snapshot from September 7th, I cannot log into X
anymore. xdm comes up but logging in brings me directly back to xdm.
The xenodm.log say "XIO: fatail IO error 35"
dmesg, Xorg.0.log and xenodm.log are attached.
Any help is
Hi,
after I updated to the snapshot from September 7th, I cannot log into X
anymore. xdm comes up but logging in brings me directly back to xdm.
The xenodm.log say "XIO: fatail IO error 35"
dmesg, Xorg.0.log and xenodm.log are attached.
Any help is appreciated.
Niels
xdm info (pid 31376):
14 matches
Mail list logo