MX-17 Beta 2 Feedback

[timkb4cq]

According to the debian changelog, the Intel-microcode package that we include is supposed to have the fixes for both Skylake & Kaby Lake processors.
Reading the whole thread, it appears the original test to determine which processors are susceptible included some newer processors without the problem. I suspect the warning is due to an over-broad test in the kernel, which would explain why a later kernel gets rid of the message.

[spsf64]

That error goes away if you install the 4.13.0-1 kernel in the test repo. We may make it the default.

I tried; updated the kernel, remastered, " live usb kernel updater" and no go

demo@mx1:~/Desktop
$ uname -a
Linux mx1 4.13.0-1-amd64 #1 SMP Debian 4.13.13-1mx17 (2017-11-18) x86_64 GNU/Linux
demo@mx1:~/Desktop
$ dmesg | grep microcode
[ 0.000000] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later)
[ 0.451446] microcode: sig=0x306c3, pf=0x2, revision=0x19
[ 0.451761] microcode: Microcode Update Driver: v2.2.

Did I miss something?

[timkb4cq]

I have backported the newer intel-microcode from Buster (64bit only so far)
http://teharris.net/misc/intel-microcod ... _amd64.deb
Please install it and see if the message is still there at reboot.

edit: the backported intel-microcode for both arches is now available in the MX-17 testing repository, so you can get it with the MX-Tools Package Installer.

[spsf64]

I have backported the newer intel-microcode from Buster (64bit only so far)
http://teharris.net/misc/intel-microcod ... _amd64.deb
Please install it and see if the message is still there at reboot.

edit: the backported intel-microcode for both arches is now available in the MX-17 testing repository, so you can get it with the MX-Tools Package Installer.

Still the same message, not working in live USB...
Once again I did the same procedure; updated the package / remaster / update kernel (is this the right sequence?)
I think this problem is related to remaster, as I said before it is working fine in the in this same machine with system installed to HDD (It was already working with the original beta2 kernel).

edit: by "working" I mean loading microcode is ok, no message displayed during boot.

[entropyfoe]

Stability testing....OK, I got the first crash with beta2. It had been up 4 days as of last night.

I came down this morning to a blank screen. The fans are spinning, but no keyboard or mouse would make the system come back.
As before, a crash at idle, nothing much was going on, a browser with 2 windows, maybe 20 tabs, a few other applications, but basically sitting idle.
So I had to hit the reset button...clearing some orphaned inodes....and now back.
So, not as stable as the antix 17 with the 4.10 kernel where I got 8 and 9 days uptime in two stretches with NO crashes.

[BitJam]

During boot in live USB mode I see this msg:

[Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later)

I already tried to reinstall intel microcode, remaster and update kernel but the message persists...
Note: After Installation to HD there is no such message
This is part of the log from /var/log/dmesg
========================================================
[ 0.000000] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later)
========================================================

The timestamp on that message shows that it is occurring very early in the boot process while the live initrd is running. In order to get rid of that message the new microcode will need to be added to the live initrd since we are many seconds away from having the main file system available where the microcode was installed.

The basic procedure for this is straightforward:

Code: Select all

sudo su -
/live/bin/unpack-initrd
[ copy microcode, modules, whatever to newly created initrd/ directory]
/live/bin/unpack-initrd -r
exit

The first line changes to the root user. Then we unpack the live initrd into the initrd/ directory. Add the microcode and perhaps modules or whatever (if needed) under this new directory and then when you are done, the -r (--reverse) flag cause unpack-initrd to repackage the live initrd so it will be used on the next boot.

If the microcode is getting loaded when the "real" system starts a few seconds later, it might be okay to live with the error message on the live system. This depends on what the new microcode fixes.

[tradonal]

the first update of the index takes a while because there isn't an exisiting index. later updates should be faster.

re,
votre note est correcte, le problème est parti
your rating is correct, the problem is gone

Have you let the index finish building?

yes

thx

[Stevo]

That error goes away if you install the 4.13.0-1 kernel in the test repo. We may make it the default.

I tried; updated the kernel, remastered, " live usb kernel updater" and no go

demo@mx1:~/Desktop
$ uname -a
Linux mx1 4.13.0-1-amd64 #1 SMP Debian 4.13.13-1mx17 (2017-11-18) x86_64 GNU/Linux
demo@mx1:~/Desktop
$ dmesg | grep microcode
[ 0.000000] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later)
[ 0.451446] microcode: sig=0x306c3, pf=0x2, revision=0x19
[ 0.451761] microcode: Microcode Update Driver: v2.2.

Did I miss something?

Oh, I was just seeing the same error at first startup in Virtual Box with the bpo kernel, and the kernel update made that go away from the boot screen. I didn't check to see if it was still in dmesg.

[Stevo]

Icons in the system tray are still limited to 22 pixels max as the default, and that is too small for higher DPI screens. Is there any downside to raising the maximum size on the ISO?

[dolphin_oracle]

Icons in the system tray are still limited to 22 pixels max as the default, and that is too small for higher DPI screens. Is there any downside to raising the maximum size on the ISO?

they can get pretty "cartoony" on high-dpi monitors. at 64 (the max), the default panel takes up almost the whole left side of the screen of a 1600x900 monitor.