Search results

This should translate to 06_9FH - which isn't listed on the Intel site at all. The "Stepping" would be D (in hex = 13 decimal) Thinking further, you might have to wait for a kernel update that adds the path for `/sys/devices/system/cpu/vulnerabilities/gather_data_sampling` to be able to tell...

See the info in post #16 on how to check.... What you've posted isn't enough information.... You should be able to cross reference the info gathered in post #16 to check properly.

For those following along, Intel have updated their vulnerable products list: https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html#tab-blade-1-0 If you look at /proc/cpuinfo - look for: cpu family...

Nice, thanks for the cherry picks etc.... Hit me up when its out and I'll try and test it all where I can. It's good that it'll add in `/sys/devices/system/cpu/vulnerabilities/gather_data_sampling` - which afaik, is the only way to easily check if you're vulnerable - and if you are, if the...

Yeah - that's what I'd think too: # dmesg | grep -i microcode [ 4.412471] microcode: Microcode Update Driver: v2.2. # journal -b | grep -i microcode Aug 11 23:32:21 syd-pm kernel: microcode: Microcode Update Driver: v2.2. It did regenerate the initramfs in the package installation - but...

Yeah - correct.... I added the `non-free-firmware` part to each line in /etc/apt/sources.list The debian wiki (https://wiki.debian.org/Microcode) has 3 different ways to check, but none of them return anything - so I'm not sure how to check if the updated microcode was loaded....

Yep, I have: /etc/apt/sources.list deb http://ftp.au.debian.org/debian bookworm main contrib deb http://ftp.au.debian.org/debian bookworm-updates main contrib deb http://security.debian.org bookworm-security main contrib /etc/apt/sources.list.d/pve-no-subscription.list deb...

I still haven't seen the update come through for either kernel or firmware / microcode :|

It's kind of both - from the changelog of kernel 6.4.9 release:

Background: * https://downfall.page/ * https://www.phoronix.com/news/New-Linux-Stable-Downfall * https://www.phoronix.com/news/Intel-20230808-Microcode The new stable point releases this afternoon that pick-up all of these AMD and Intel security fixes are Linux versions 6.4.9, 6.1.44, 5.15.125...

Interestingly, this seems to come down to some kind of network adapter problem.... I'm stuck using a USB3 Ethernet adapter on this Intel NUC - as the e1000 driver has many problems that I can't seem to overcome - and simply switching the USB port that the USB ethernet adapter was plugged into...

As I can only get into mel-pm2 via screen + keyboard at the moment, this is some of the fun in journalctl on that node:

More fun and broken things - when trying to view the Cluster information on the Web UI of mel-pm (aka node 1): Also, when looking at /etc/pve/nodes/mel-pm2/ on mel-pm, there's zero content:

Trying again to join the cluster together - after adding the Join information to the second node, the output I get is: Establishing API connection with host '172.31.1.1' Login succeeded. check cluster join API version Request addition of this node Join request OK, finishing setup locally...

Hi all, I have a two node cluster that started misbehaving a couple of days ago.... No matter what I did, I couldn't get things back up and happy again. The second node always hung on starting pveproxy in the `pvecm updatecerts` command. Once that hung, I wasn't able to recover. As the second...

That saved me a bit of time - thanks... I was just looking at the example figuring out what is what. It does work, but you still need to set the Shutdown timeout to 1 - otherwise the two tasks will block each other. Keeping the shutdown timeout to 1, and that script as a hookscript does seem...

I did not - just testing again now.... Doesn't seem to make a difference... 1 or 3 doesn't seem to make a difference - I set it to 3 to give me chance to bring up the logs.... It still just fails though.... Hitting STOP has always worked, but I always hit Shutdown out of habit.... So I...

Yeah, I guess that the key is that I want it to work the same way no matter which way it's called..... so it looks like the hook might be an idea...

Oh, if I changed the shutdown timeout to 3, I get the following error when sending a shutdown: Looks like the hookscript might be the way to go.

Ahhhh h- I've seen that a million times and it never occurred to me :) For the sake of the Google results: That in theory should be fine if I set it to like 3 seconds. I'll have a play with it, and if that doesn't fit, I'll go with the hookscript route....