Re: [gentoo-user] Is sys-firmware/intel-microcode-20180108 complete?

[Adam Carter]

> It looks as though my CPU hasn't been fixed yet. Is that right?
>>
>
> That's odd - i wonder why the checksum of the file changed;
>
> # grep 06-3f-02 intel-firmware-md5s-9jan2018.txt
> intel-firmware-md5s-10jan2018.txt
> intel-firmware-md5s-9jan2018.txt:194c362f2c45d8a45e2ab58d5f2c9749
> /lib/firmware/intel-ucode/06-3f-02
> intel-firmware-md5s-10jan2018.txt:b6e684762e7212054271c9441048fa93
> /lib/firmware/intel-ucode/06-3f-02
>
>
And with intel-microcode-20180108-r1 its back to what it was;

# grep 06-3f-02 intel-firmware-md5s-9jan2018.txt
intel-firmware-md5s-10jan2018.txt intel-firmware-md5s-11jan2018.txt
intel-firmware-md5s-9jan2018.txt:194c362f2c45d8a45e2ab58d5f2c9749
/lib/firmware/intel-ucode/06-3f-02
intel-firmware-md5s-10jan2018.txt:b6e684762e7212054271c9441048fa93
/lib/firmware/intel-ucode/06-3f-02
intel-firmware-md5s-11jan2018.txt:194c362f2c45d8a45e2ab58d5f2c9749
/lib/firmware/intel-ucode/06-3f-02

Looks like there was an issue with intel-microcode-20180108.

50/94 files are different from intel-microcode-20171117_p20171215-r1 to
intel-microcode-20180108-r1, they are;
06-05-00
06-05-02
06-05-03
06-06-0a
06-06-0d
06-08-01
06-08-03
06-08-06
06-08-0a
06-09-05
06-0b-01
06-0b-04
06-0e-0c
06-0f-02
06-0f-06
06-0f-07
06-0f-0b
06-0f-0d
06-16-01
06-17-06
06-17-0a
06-1c-02
06-1c-0a
06-26-01
06-3e-04
06-3f-04
06-46-01
06-47-01
06-4f-01
06-55-04
06-56-02
06-56-03
06-5c-09
06-5e-03
06-7a-01
06-8e-09
06-8e-0a
06-9e-09
06-9e-0a
06-9e-0b
0f-00-07
0f-00-0a
0f-02-04
0f-02-05
0f-02-07
0f-02-09
0f-04-01
0f-04-08
0f-04-0a
0f-06-04

Re: [gentoo-user] Is sys-firmware/intel-microcode-20180108 complete?

[Adam Carter]

On Wed, Jan 10, 2018 at 10:01 PM, Peter Humphrey 
wrote:

> I've just gone through the procedure to update the microcode on this
> haswell
> i7 box, but the version is the same now as before today's portage update.
> On
> looking again at the output of 'emerge intel-microcode' I see the date
> hasn't changed:
>
> intel-ucode/06-3f-02
> signature: 0x306f2
> flags: 0x6f
> revision:  0x3b
> date:  2017-11-17
> size:  33792
>
> It looks as though my CPU hasn't been fixed yet. Is that right?
>

That's odd - i wonder why the checksum of the file changed;

# grep 06-3f-02 intel-firmware-md5s-9jan2018.txt
intel-firmware-md5s-10jan2018.txt
intel-firmware-md5s-9jan2018.txt:194c362f2c45d8a45e2ab58d5f2c9749
/lib/firmware/intel-ucode/06-3f-02
intel-firmware-md5s-10jan2018.txt:b6e684762e7212054271c9441048fa93
/lib/firmware/intel-ucode/06-3f-02

Re: [gentoo-user] Re: No sleep when closing the lid (OpenRC)

[Andrew Barchuk]

Hi Melleus,

Please share some details of the solution (e.g. reference the manuals)
you've found so other people with similar problems that would stumble
upon you email can use it too.

---
Andrew

[gentoo-user] Re: No sleep when closing the lid (OpenRC)

[Melleus]

I've found the manuals, sorry for the noise.

Re: [gentoo-user] Re: Is sys-firmware/intel-microcode-20180108 complete?

[Mick]

On Wednesday, 10 January 2018 19:49:25 GMT Nikos Chantziaras wrote:
> On 10/01/18 20:12, Mick wrote:
> > On Wednesday, 10 January 2018 17:06:46 GMT Peter Humphrey wrote:
> >> On Wednesday, 10 January 2018 15:47:25 GMT Wolfgang Mueller wrote:
>  It looks as though my CPU hasn't been fixed yet. Is that right?
> >>> 
> >>> It seems that patches are being pushed out as they are being received,
> >>> so back when that one was released, no other updates were available.
> >>> 
> >>> See https://bugs.gentoo.org/643430#c10
> >>> 
> >>> We should get the full range of updates in the next few days.
> >> 
> >> Right. Patience is a virtue, they say.
> > 
> > So what are we to do with our old PCs, which will no longer receive
> > Intel's
> > microcode blessing?  Are we to throw them away in a landfill and of course
> > take our custom elsewhere, or will the kernel patches suffice for both
> > bugs
> > and all variants?
> 
> The spectre bug needs a microcode update. It can't be closed by software.
> 
> Intel has a page somewhere for people asking "why do I do with my old
> PC", and they tell you to kindly fuck off (not in those words exactly,
> but it's what they mean) and direct you to their latest CPUs and places
> where you can buy them. And of course you'll also need to buy new
> mainboards and new RAM.
> 
> Millions and millions of computers are out there running Sandy Bridge
> and Ivy Bridge CPUs, since they're almost as fast as the latest CPUs.
> People use them as their main machines, or as secondary machines.
> They're all over the place. And they're all going to be vulnerable from
> here on out.
> 
> Strangely, nobody in the press called Intel out on it. Everybody acts as
> if this perfectly acceptable.

Strange that ...

I can see a class action lawsuit kicking off in the very litigious US of A, 
assuming enough people wake up to this.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: glibc emerge error

[Nikos Chantziaras]

On 10/01/18 19:55, Corbin Bird wrote:

Is anyone else having a sys-libs/glibc emerge compile failure?


checking for python3... python3
checking LD_LIBRARY_PATH variable... contains current directory
configure: error:
*** LD_LIBRARY_PATH shouldn't contain the current directory when
*** building glibc. Please change the environment variable
*** and run configure again.
  * ERROR: sys-libs/glibc-2.25-r10::gentoo failed (configure phase):
  *   failed to configure glibc


sys-libs/glibc-2.25-r9 was set to masked / prompting this upgrade /
re-compile:

https://packages.gentoo.org/packages/sys-libs/glibc

Same error regardless of the version of glibc I attempt to emerge.


Why are you setting LD_LIBRARY_PATH system-wide to begin with? Don't do 
that.

Re: [gentoo-user] Re: Is sys-firmware/intel-microcode-20180108 complete?

[netfab]

Le 10/01/18 à 21:49, Nikos Chantziaras a tapoté :
> Intel has a page somewhere

source, please.

[gentoo-user] Re: Is sys-firmware/intel-microcode-20180108 complete?

[Nikos Chantziaras]

On 10/01/18 20:12, Mick wrote:

On Wednesday, 10 January 2018 17:06:46 GMT Peter Humphrey wrote:

On Wednesday, 10 January 2018 15:47:25 GMT Wolfgang Mueller wrote:

It looks as though my CPU hasn't been fixed yet. Is that right?


It seems that patches are being pushed out as they are being received,
so back when that one was released, no other updates were available.

See https://bugs.gentoo.org/643430#c10

We should get the full range of updates in the next few days.


Right. Patience is a virtue, they say.


So what are we to do with our old PCs, which will no longer receive Intel's
microcode blessing?  Are we to throw them away in a landfill and of course
take our custom elsewhere, or will the kernel patches suffice for both bugs
and all variants?


The spectre bug needs a microcode update. It can't be closed by software.

Intel has a page somewhere for people asking "why do I do with my old 
PC", and they tell you to kindly fuck off (not in those words exactly, 
but it's what they mean) and direct you to their latest CPUs and places 
where you can buy them. And of course you'll also need to buy new 
mainboards and new RAM.


Millions and millions of computers are out there running Sandy Bridge 
and Ivy Bridge CPUs, since they're almost as fast as the latest CPUs. 
People use them as their main machines, or as secondary machines. 
They're all over the place. And they're all going to be vulnerable from 
here on out.


Strangely, nobody in the press called Intel out on it. Everybody acts as 
if this perfectly acceptable.

Re: [gentoo-user] glibc emerge error

[Matthias Hanft]

Corbin Bird wrote:
> Is anyone else having a sys-libs/glibc emerge compile failure?
>> *** LD_LIBRARY_PATH shouldn't contain the current directory when
>> *** building glibc. Please change the environment variable
>> *** and run configure again.
> Same error regardless of the version of glibc I attempt to emerge.

Sure - this error always comes up here, too. Just enter

export LD_LIBRARY_PATH=

immediately before emerge, and it works.

-Matt

PS: And if you get some message concerning some variables which
are too big (or something like that), enter
  mount -t tmpfs none /var/tmp/portage
just before emerge (and "umount /var/tmp/portage" afterwards).
I have to do this for the emerge of a few packages - I think
it's because of my 17 TB filesystem.

Re: [gentoo-user] Is sys-firmware/intel-microcode-20180108 complete?

[Mick]

On Wednesday, 10 January 2018 17:06:46 GMT Peter Humphrey wrote:
> On Wednesday, 10 January 2018 15:47:25 GMT Wolfgang Mueller wrote:
> > > It looks as though my CPU hasn't been fixed yet. Is that right?
> > 
> > It seems that patches are being pushed out as they are being received,
> > so back when that one was released, no other updates were available.
> > 
> > See https://bugs.gentoo.org/643430#c10
> > 
> > We should get the full range of updates in the next few days.
> 
> Right. Patience is a virtue, they say.

So what are we to do with our old PCs, which will no longer receive Intel's 
microcode blessing?  Are we to throw them away in a landfill and of course 
take our custom elsewhere, or will the kernel patches suffice for both bugs 
and all variants?

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] glibc emerge error

[Corbin Bird]

Is anyone else having a sys-libs/glibc emerge compile failure?

> checking for python3... python3
> checking LD_LIBRARY_PATH variable... contains current directory
> configure: error:
> *** LD_LIBRARY_PATH shouldn't contain the current directory when
> *** building glibc. Please change the environment variable
> *** and run configure again.
>  * ERROR: sys-libs/glibc-2.25-r10::gentoo failed (configure phase):
>  *   failed to configure glibc

sys-libs/glibc-2.25-r9 was set to masked / prompting this upgrade /
re-compile:

https://packages.gentoo.org/packages/sys-libs/glibc

Same error regardless of the version of glibc I attempt to emerge.

Corbin

[gentoo-user] No sleep when closing the lid (OpenRC)

[Melleus]

I used to think that when I close the lid the system goes to sleep. But
it's not. I did not use that functionality for quite a long time so I
can't say when it was broken. Meantime I would like to get that feature
back but I'm more a scientist than an IT specialist, so I need help with
that. To begin with, acpi_listen sees events lid LID close and lid LID
open. And I have the packages:

acpid-2.0.28
laptop-mode-tools-1.71-r1
pm-utils-1.4.10-r7

installed on my system. And it used to work on my system once, as I
think. Or maybe there is some guide/manual which I couldn't find, then a
link to it will be just Ok.

Thanks ahead of time.

Re: [gentoo-user] Is sys-firmware/intel-microcode-20180108 complete?

[Peter Humphrey]

On Wednesday, 10 January 2018 15:47:25 GMT Wolfgang Mueller wrote:
> > It looks as though my CPU hasn't been fixed yet. Is that right?
> 
> It seems that patches are being pushed out as they are being received,
> so back when that one was released, no other updates were available.
> 
> See https://bugs.gentoo.org/643430#c10
> 
> We should get the full range of updates in the next few days.

Right. Patience is a virtue, they say.

-- 
Regards,
Peter.

Re: [gentoo-user] Is sys-firmware/intel-microcode-20180108 complete?

[Håkon Alstadheim]

I've got this in my boot directory:
-rwxr-xr-x 1 root root   67584 Jan 10 15:12 /boot/microcode.bin
-rwxr-xr-x 1 root root   33792 Jan  7 23:56 /boot/microcode.bin.prev

These are the split ucode file for my cpu, specifically a copy of
/lib/firmware/intel-ucode/06-3f-02.

I'm running xen, an xl dmesg says (from loading microcode at boot):
(XEN) microcode: CPU0 updated from revision 0x39 to 0x3b, date = 2017-11-17
(XEN) xstate: size: 0x340 and states: 0x7

0x3b is the same as with the previous microcode, but the size of the
file has changed. What is up with that?

Den 10. jan. 2018 16:47, skrev Wolfgang Mueller:
>> It looks as though my CPU hasn't been fixed yet. Is that right?
> 
> It seems that patches are being pushed out as they are being received,
> so back when that one was released, no other updates were available.
> 
> See https://bugs.gentoo.org/643430#c10
> 
> We should get the full range of updates in the next few days.
> 

Re: [gentoo-user] Is sys-firmware/intel-microcode-20180108 complete?

[Wolfgang Mueller]

> It looks as though my CPU hasn't been fixed yet. Is that right?

It seems that patches are being pushed out as they are being received,
so back when that one was released, no other updates were available.

See https://bugs.gentoo.org/643430#c10

We should get the full range of updates in the next few days.

-- 
Wolfgang Mueller / vehk.de / GPG 0xc543cfce9465f573


signature.asc
Description: PGP signature

[gentoo-user] Is sys-firmware/intel-microcode-20180108 complete?

[Peter Humphrey]

I've just gone through the procedure to update the microcode on this haswell 
i7 box, but the version is the same now as before today's portage update. On 
looking again at the output of 'emerge intel-microcode' I see the date 
hasn't changed:

intel-ucode/06-3f-02
signature: 0x306f2
flags: 0x6f
revision:  0x3b
date:  2017-11-17
size:  33792

It looks as though my CPU hasn't been fixed yet. Is that right?

-- 
Regards,
Peter.

[gentoo-user] FYI new sys-firmware/intel-microcode

[Adam Carter]

On ~amd64 sys-firmware/intel-microcode-20180108 just came through. The
checksum on every file in /lib/firmware/intel-ucode/ has changed with this
update. My skylake system went from;

microcode: sig=0x406e3, pf=0x80, revision=0xba

to

microcode: sig=0x406e3, pf=0x80, revision=0xc2