Page 7 of 7
Re: MX-17 to MX-18 update testing
Posted: Tue Dec 11, 2018 3:56 pm
by darth.severus
I just want to be sure that I got it right: There will be an automatic update from MX-17.1 to MX-18? When I use the dev repo I'm just a bit ahead of what happens anyway? Or I maybe need an additional Kernel upgrade later, but that's all?
Re: MX-17 to MX-18 update testing
Posted: Tue Dec 11, 2018 3:58 pm
by dolphin_oracle
darth.severus wrote: Tue Dec 11, 2018 3:56 pm
I just want to be sure that I got it right: There will be an automatic update from MX-17.1 to MX-18? When I use the dev repo I'm just a bit ahead of what happens anyway? Or I maybe need an additional Kernel upgrade later, but that's all?
pretty much, yep
Re: MX-17 to MX-18 update testing
Posted: Tue Dec 11, 2018 4:21 pm
by Stevo
If your hardware is running just fine with the current kernel, you might want to stick with it, though the 4.19.5 kernel does offer more Spectre and Meltdown protection for 32-bit users...at the cost of a somewhat variable performance loss, unless you disable that with the "nopti" kernel boot command.
Users can install spectre-meltdown-checker and run
to see how vunerable they are.
Re: MX-17 to MX-18 update testing
Posted: Wed Dec 12, 2018 9:52 am
by darth.severus
Thanks for the answers. My system is 64-Bit. One CVE is open because I need a Microkernel upgrade. I'd like using the newest kernel I'm able to use.
My question has the background that MX-18 may be longer supported if there is a difference to MX-17.1, so I have to decide if I wait or not. If MX-17.1 becomes MX-18, or at least could become, then there is no reason to wait for MX-18 final. I probably don't need the system encryption installer because I do that myself, with btrfs subvolumes instead of LVM.
Re: MX-17 to MX-18 update testing
Posted: Wed Dec 12, 2018 4:56 pm
by Stevo
Yes, we already went with the same kind of transition with MX 15 to MX 16, both of which had the same Jessie base.
We're still going to label our packages as MX 17 versions, since they will be compatible with both 17 and 18, unless they are specifically for MX 18, such as artwork.
Re: MX-17 to MX-18 update testing
Posted: Wed Dec 12, 2018 5:00 pm
by dolphin_oracle
Think
"How long will the stretch based series be supported" rather than a given number series.
You could also think of the update to mx18 as part of that support.
Re: MX-17 to MX-18 update testing
Posted: Thu Dec 13, 2018 1:55 pm
by darth.severus
Okay, thanks. For me it now sounds like it will be the same. So I'll go with MX-17.1 and upgrade later.
dolphin_oracle wrote: Wed Dec 12, 2018 5:00 pm
You could also think of the update to mx18 as part of that support.
My thinking was, if something is different and can't be upgraded later without a new install e.g. Kernel, it won't last as long as MX-18.
Re: MX-17 to MX-18 update testing
Posted: Fri Dec 14, 2018 6:41 am
by mx-ian
Stevo wrote: Tue Dec 11, 2018 4:21 pm
If your hardware is running just fine with the current kernel, you might want to stick with it, though the 4.19.5 kernel does offer more Spectre and Meltdown protection for 32-bit users...at the cost of a somewhat variable performance loss, unless you disable that with the "nopti" kernel boot command.
Users can install spectre-meltdown-checker and run
to see how vunerable they are.
I ran the spectre-meltdown-checker installed from the Synaptic Package Manager. The cpu is not vulnerable.
Steps to add the "nopti" option to the kernel boot command:
1. Open the Grub Customizer application
2. Edit the first entry, in this case "MX 18 Continuum"
3. Scroll down to the line "linux /boot/vmlinuz- ..." and add "nopti" at the end of the line without quotes
4. Click the OK button
5. Clck the Save button in Grub Customizer and close the application
6. Reboot
7. Open the Xfce Terminal and type "cat /proc/cmdline" to confirm the "nopti" option
Re: MX-17 to MX-18 update testing
Posted: Mon Dec 17, 2018 3:26 am
by ChrisUK
All OK so far:
Code: Select all
System: Host: mx1742 Kernel: 4.9.0-8-amd64 x86_64 bits: 64 compiler: gcc v: 6.3.0
Desktop: Xfce 4.12.3 Distro: MX-18_x64 Continuum March 14 2018
base: Debian GNU/Linux 9 (stretch)
Machine: Type: Laptop System: SAMSUNG product: RV411/RV511/E3511/S3511/RV711 v: N/A
serial: <filter>
Mobo: SAMSUNG model: RV411/RV511/E3511/S3511/RV711 serial: <filter> BIOS: Phoenix
v: 03PA.M001.20110312.XW date: 03/12/2011
Battery: ID-1: BAT1 charge: 7.6 Wh condition: 7.6/47.5 Wh (16%) model: SAMSUNG Electronics
status: Full
CPU: Topology: Dual Core model: Intel Core i3 M 380 bits: 64 type: MT MCP arch: Nehalem
rev: 5 L2 cache: 3072 KiB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 20216
Speed: 933 MHz min/max: 933/2533 MHz Core speeds (MHz): 1: 933 2: 933 3: 933 4: 933
Graphics: Device-1: NVIDIA GT218M [GeForce 315M] driver: nouveau v: kernel bus ID: 02:00.0
Display: x11 server: X.Org 1.19.2 driver: nouveau unloaded: fbdev,modesetting,vesa
resolution: 1366x768~60Hz
OpenGL: renderer: NVA8 v: 3.3 Mesa 18.2.6 direct render: Yes
Audio: Device-1: Intel 5 Series/3400 Series High Definition Audio driver: snd_hda_intel
v: kernel bus ID: 00:1b.0
Device-2: NVIDIA High Definition Audio driver: snd_hda_intel v: kernel
bus ID: 02:00.1
Sound Server: ALSA v: k4.9.0-8-amd64
Network: Device-1: Broadcom Limited BCM4313 802.11bgn Wireless Network Adapter
driver: bcma-pci-bridge v: N/A port: 2000 bus ID: 03:00.0
Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
v: 2.3LK-NAPI port: 4000 bus ID: 05:00.0
IF: eth0 state: up speed: 100 Mbps duplex: full mac: <filter>
IF-ID-1: wlan0 state: down mac: <filter>
Drives: Local Storage: total: 931.51 GiB used: 14.75 GiB (1.6%)
ID-1: /dev/sda vendor: Seagate model: ST1000LM048-2E7172 size: 931.51 GiB
Partition: ID-1: / size: 49.26 GiB used: 14.75 GiB (29.9%) fs: ext4 dev: /dev/sda1
Sensors: System Temperatures: cpu: 47.0 C mobo: 47.0 C gpu: nouveau temp: 51 C
Fan Speeds (RPM): N/A
Info: Processes: 190 Uptime: 9m Memory: 5.70 GiB used: 654.1 MiB (11.2%) Init: SysVinit
runlevel: 5 Compilers: gcc: 6.3.0 Shell: bash v: 4.4.12 inxi: 3.0.25