MX-17 Release Candidate 1 - Feedback

[dolphin_oracle]

Great release 17 rc1 i HAVE A DESKTOP THAT NOW WORKS THE FAILSAFE F6 OPTION ON BOOT OF DVD SOLVED THE BOOT ISSUE--My old computer likes all changes made to solve the 32 bit problemns.Thanks for all work done the new system is great and fast.I've also have a 64 bit system which also runs great John

yay!

[golden45]

here is the system infoSystem: Host: mx1 Kernel: 4.13.0-1-686-pae i686 bits: 32 Desktop: Xfce 4.12.3
Distro: MX-17.RC1_386 Horizon December 10, 2017
Machine: Device: desktop Mobo: ASUSTeK model: P4SP-MX v: REV 1.xx serial: N/A
BIOS: Award v: ASUS P4SP-MX 1006 Beta 002 date: 04/14/2006
CPU: Single core Intel Pentium 4 (-MT-) cache: 1024 KB
clock speeds: max: 1994 MHz 1: 1994 MHz 2: 1994 MHz
Graphics: Card: Silicon Integrated Systems [SiS] 65x/M650/740 PCI/AGP VGA Display Adapter
Display Server: x11 (X.Org 1.19.2 ) drivers: vesa (unloaded: modesetting,fbdev)
Resolution: 1280x1024@0.00hz
OpenGL: renderer: Gallium 0.4 on llvmpipe (LLVM 3.9, 128 bits) version: 3.3 Mesa 13.0.6
Audio: Card Silicon Integrated Systems [SiS] SiS7012 AC'97 Sound Controller
driver: snd_intel8x0
Sound: Advanced Linux Sound Architecture v: k4.13.0-1-686-pae
Network: Card: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet driver: sis900
IF: eth0 state: up speed: 100 Mbps duplex: full mac: 00:11:2f:99:eb:dc
Drives: HDD Total Size: 30.8GB (18.6% used)
ID-1: /dev/sda model: Maxtor_6E030L0 size: 30.8GB
Partition: ID-1: / size: 28G used: 5.3G (20%) fs: ext4 dev: /dev/sda1
ID-2: swap-1 size: 0.10GB used: 0.00GB (0%) fs: swap dev: /dev/sda2
Sensors: None detected - is lm-sensors installed and configured?
Info: Processes: 168 Uptime: 40 min Memory: 691.8/1987.8MB Client: Shell (bash) inx

[Jerry3904]

Please edit that post and use the code tags. Thanks.

[Eadwine Rose]

Mind, just have to say that I really like how crisp and clean MX17 looks. Well done!!

[felicity]

Welcome to the Forum! Can you post the output of this from your current beta 3

Code: Select all

inxi -G

Thanks Jerry3904.

Code: Select all

$ inxi -G
Graphics:  Card: Intel 82915G/GV/910GL Integrated Graphics Controller
           Display Server: x11 (X.Org 1.19.2 ) drivers: intel (unloaded: modesetting,fbdev,vesa)
           Resolution: 1280x1024@60.02hz
           OpenGL: renderer: Mesa DRI Intel 915G x86/MMX/SSE2 version: 2.1 Mesa 13.0.6

Let me add that I fiddled with the graphics-related boot parameters. Here's the relevant part of the Grub Customizer Entry Editor window:

Code: Select all

echo  'Loading Linux 4.13.0-1-686-pae ...'
linux /boot/vmlinuz-4.13.0-1-686-pae root=UUID=087920e3-6bb0-4eab-bb4a-345e13e0d895 ro  vga=795 gfxsave video=1280x1024 failsafe

I did that because the MX-17 & antiX-17 standard kernels tend to boot into 1024x768 display resolution. And what's worse, they end up in some state that prevents me from changing the display resolution at all from this most unacceptable 1024x768. (I have no idea if these boot params are rational.)

But wait, there's more... Even though I can get the kernel into 1280x1024 resolution, I then change its default version of this resolution (for reasons explained later). The kernel likes to boot into video mode "1280x1024 (0x45) 108.879MHz" as below. But I force it into mode " 1280x1024 (0x9e) 108.000MHz" with a start-up script.

Code: Select all

$ sudo xrandr -q --verbose
Screen 0: minimum 8 x 8, current 1280 x 1024, maximum 32767 x 32767
VGA1 connected 1280x1024+0+0 (0x9d) normal (normal left inverted right x axis y axis) 0mm x 0mm
...
  1280x1024 (0x9e) 108.000MHz +HSync +VSync +preferred
        h: width  1280 start 1328 end 1440 total 1688 skew    0 clock  63.98KHz
        v: height 1024 start 1025 end 1028 total 1066           clock  60.02Hz
  1280x1024 (0x45) 108.879MHz -HSync +VSync
        h: width  1280 start 1360 end 1496 total 1712 skew    0 clock  63.60KHz
        v: height 1024 start 1025 end 1028 total 1060           clock  60.00Hz

I do this because I dual boot with XP (whose security vulnerabilities forced me into Linux) and XP chooses (I believe) this mode. Also, this mode (" 1280x1024 (0x9e) 108.000MHz") is the only one that my monitor's manual says it will accept (it's the standard VESA mode) at this resolution. This Acer AL1715 LCD monitor has a cranky module (the DAC?) and often refuses to do it's self-adjust thing successfully (especially when cold), so I want to stick with this one resolution.

Hello felicity the problem is not with MX Linux but the problem is on your side to me also it happened like that my PC used to boot with 1024x768 resolution to get rid of it i used a startup script it worked fine later i replaced my monitor VGA or Display cable other than power supply to the monitor after that my system deducted 1280x1024 and many resolutions i think try this out. By the way what do you see when you open display option could you see any resolutions ??

Thanks..

Thanks for commenting, vamsi. It's been some time since I had an MX-17 or antiX-17 install frozen at 1024x768 resolution, but as I recall, I could see the other resolutions in Display Manager, but selecting them would be without effect. Likewise, issuing the appropriate sudo xrandr command was also ineffectual. (By "appropriate" I mean conforming to the monitor's specifications.) Also xrandr would report the monitor's name as "default" rather than the "VGA1" that it does when the OS is not frozen at 1024x768 res. Web searching, I did find a few other references to this problem with Ubuntu or Debian. But any solutions given did not seem simply or directly related to my system, involving as they did, re-installing or changing the config file parameters of software that was not part of my system.

Thanks, in particular, for your advice to replace the "monitor VGA or Display cable." That might work. But I know that this old Acer monitor has limited capability of communicating with the OS, that is, it has support for only the earlier, more primitive, version of the DDC protocol, the DDC2 one, not the more advanced DDC-CI protocol. See
Display Data Channel
https://en.wikipedia.org/wiki/Display_Data_Channel

So I suspect the current Linux kernels being used for MX-17 or antiX-17 have some trouble configuring themselves for this older hardware. And even if the VGA cable or monitor does not trip them up, possibly the on-board Intel chip display adapter may.

By the way, for the record, here is my complete inxi -F output (the first responder to my post, Jerry3904, only asked for the inxi -G one):

Code: Select all

$ inxi -F
System:    Host: mx17 Kernel: 4.13.0-1-686-pae i686 bits: 32 Desktop: Xfce 4.12.3
           Distro: MX-17.b3_386 Horizon November 28, 2017
Machine:   Device: desktop System: Dell product: OptiPlex GX280 serial: N/A
           Mobo: Dell model: 0H5354 serial: N/A BIOS: Dell v: A08 date: 03/03/2006
CPU:       Single core Intel Pentium 4 (-UP-) cache: 1024 KB speed: 2794 MHz (max)
Graphics:  Card: Intel 82915G/GV/910GL Integrated Graphics Controller
           Display Server: x11 (X.Org 1.19.2 ) drivers: intel (unloaded: modesetting,fbdev,vesa)
           Resolution: 1280x1024@60.02hz
           OpenGL: renderer: Mesa DRI Intel 915G x86/MMX/SSE2 version: 2.1 Mesa 13.0.6
Audio:     Card Intel 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller
           driver: snd_intel8x0
           Sound: Advanced Linux Sound Architecture v: k4.13.0-1-686-pae
Network:   Card: Broadcom Limited NetXtreme BCM5751 Gigabit Ethernet PCIE driver: tg3
           IF: eth0 state: down mac: 00:0f:1f:da:c7:04
Drives:    HDD Total Size: 1000.2GB (20.4% used)
           ID-1: /dev/sda model: TOSHIBA_DT01ACA1 size: 1000.2GB
Partition: ID-1: / size: 77G used: 5.1G (8%) fs: ext4 dev: /dev/sda9
           ID-2: /home size: 23G used: 87M (1%) fs: ext4 dev: /dev/sda10
           ID-3: swap-1 size: 5.24GB used: 0.00GB (0%) fs: swap dev: /dev/sda3
Sensors:   None detected - is lm-sensors installed and configured?
Info:      Processes: 157 Uptime: 12 min Memory: 231.8/994.3MB Client: Shell (bash) inxi: 2.3.43 

Going back to looking for a software, rather than a hardware solution, MX-16 & Windows XP never had this problem of display resolution being frozen at 1024x768. And antiX-17 also had it initially. But then I found a way to prevent it from being frozen at 1024x768 that has been stable with no video-related crashes occurring. That way was to install from an optical disk (CD or DVD) with the Virtual Machine mode boot parameter. (That is, for some reason, only an option from a disk but not a USB flash drive install.) Then there are a only a couple of complaints from the kernel during boot-up (without the quiet boot parameter). It says it's disabling some Virtual Machine features (presumably, the kernel can detect that it is not in a VM, but in physical hardware), but then antiX-17 has been stable and it does allow me to change video mode freely. (So actually I currently have a quadruple, not a dual boot system: Windows XP Professional, MX-16.1, MX-17 beta 3, antiX-17.)

Can anybody kindly tell me if the graphics-related boot parameters I have manually chosen for MX-15 beta 3 are rational, or suggest any better ones to prevent booting into 1024x768 display resolution and then being unable to change from it to my LCD monitor's highest possible one, 1024x1280? Again, here's the relevant part of the Grub Customizer Entry Editor window:

Code: Select all

echo  'Loading Linux 4.13.0-1-686-pae ...'
linux /boot/vmlinuz-4.13.0-1-686-pae root=UUID=087920e3-6bb0-4eab-bb4a-345e13e0d895 ro  vga=795 gfxsave video=1280x1024 failsafe

MX-15 beta 3 is currently unstable with these; it is having video-related crashes, although it is not frozen in 1024x768 display resolution.

[Stevo]

I never thought I'd feel this way, but I'm hoping a MX-17 final release is not too soon. It'll take me 10+ hours to download RC1 on dial-up & I was having video related crashes with beta 3. So now I'm hoping I'll have enough time to post data on the crashes if they continue in RC1 --- and somebody will have time to resolve them before final.

We also have two different ways to create an RC 1 ISO from the beta 3--either download and apply the delta file, or use the zsync method. Both need about 170 MB of download total. Zsync can make an ISO from any input file, but the closer it is to the desired output, the less you'll have to download.

[Stevo]

(kernel problems stuff)
.

It is possible to install and boot the standard Debian 4.9 kernel to check if it has the same issue, though I realize this is more of a task with dial up service.

[felicity]

Code: Select all

eadwine@eadwinemx17rc1:~
$ inxi -F
System:    Host: eadwinemx17rc1 Kernel: 4.13.0-1-amd64 x86_64 bits: 64 Desktop: Xfce 4.12.3
           Distro: MX-17.RC1_x64 Horizon December 10, 2017
Machine:   Device: desktop Mobo: ASUSTeK model: M4A785TD-V EVO v: Rev X.0x serial: N/A
           BIOS: American Megatrends v: 2005 date: 04/15/2010
CPU:       Quad core AMD Athlon II X4 635 (-MCP-) cache: 2048 KB
           clock speeds: max: 2900 MHz 1: 2200 MHz 2: 1700 MHz 3: 1700 MHz 4: 1700 MHz
Graphics:  Card: NVIDIA GK208 [GeForce GT 640 Rev. 2]
           Display Server: x11 (X.Org 1.19.2 ) driver: nvidia Resolution: 1920x1080@60.00hz
           OpenGL: renderer: GeForce GT 640/PCIe/SSE2 version: 4.5.0 NVIDIA 387.34
Audio:     Card-1 NVIDIA GK208 HDMI/DP Audio Controller driver: snd_hda_intel
           Card-2 Advanced Micro Devices [AMD/ATI] SBx00 Azalia (Intel HDA) driver: snd_hda_intel
           Card-3 Logitech QuickCam E 3500 driver: USB Audio
           Sound: Advanced Linux Sound Architecture v: k4.13.0-1-amd64
Network:   Card-1: Realtek RTL8111/8168/8411 PCIE Gigabit Ethernet Controller driver: r8169
           IF: eth0 state: up speed: 1000 Mbps duplex: full mac: 48:5b:39:f4:93:4e
           Card-2: Ralink MT7601U Wireless Adapter driver: mt7601u
           IF: wlan0 state: N/A mac: N/A
Drives:    HDD Total Size: 1640.4GB (3.7% used)
           ID-1: /dev/sda model: WDC_WD5000AAKS size: 500.1GB
           ID-2: /dev/sdb model: Hitachi_HDT72106 size: 640.1GB
           ID-3: USB /dev/sdc model: HDP725050GLA360 size: 500.1GB
Partition: ID-1: / size: 48G used: 4.9G (11%) fs: ext4 dev: /dev/sda1
           ID-2: /home size: 384G used: 123M (1%) fs: ext4 dev: /dev/sda2
           ID-3: swap-1 size: 2.10GB used: 0.00GB (0%) fs: swap dev: /dev/sda3
Sensors:   System Temperatures: cpu: 37.0C mobo: 34.0C gpu: 37C
           Fan Speeds (in rpm): cpu: 2490 psu: 0 sys-1: 820
Info:      Processes: 211 Uptime: 10 min Memory: 860.7/7986.9MB Client: Shell (bash) inxi: 2.3.53 

Hey all.. I am running into something. The ID-3: USB /dev/sdc (ntfs) drive's partitions always used to open when I clicked on it in thunar, now it requires a root password. Apparently ownership is set to root, and that ain't right. I couldn't find how to fix it in the manual, so... maybe one of you knows how to sort this so I don't have to enter the root password anymore?



Also.. this drive is always on and connected to the system. Used to appear in fstab. This is the currect fstab on mx17rc1. I will take a looksee on the MX16 install how this has been fiddled there.

Code: Select all

# /etc/fstab: static file system information
#
# Created by make-fstab on Sun Dec 10 23:03:03 CET 2017

# <file system>                            <mount point>                               <type>     <options>                       <dump/pass>

#-> /dev/sda1  label=rootMX17
UUID=4cb8c6e4-55d3-46c7-8283-2a30208a7beb  /                                           ext4       defaults                        1 1
#-> /dev/sda2  label=homeMX17
UUID=b115300c-9005-4829-b6c2-cff24cb448d9  /home                                       ext4       defaults                        1 2
#-> /dev/sda3  label=MXswap
UUID=92d96fbc-c28a-49b9-b27b-5e96f78d8a96  swap                                        swap       defaults                        0 0

I used to have this problem, too. And for years I just accepted it as a security feature. However, in my recent experience I have stumbled on a solution: use the Disk Manager app. Then you only have to enter the root password once to open the app. Once you have it open click the "Enable" check boxes for the partitions/drives you want to just open in Thunar w/o entering the root pw. Disk Manager automatically configures fstab for you (but it allows you some ability to fiddle & experiment with changing its choices, too).

[felicity]

(kernel problems stuff)
.

It is possible to install and boot the standard Debian 4.9 kernel to check if it has the same issue, though I realize this is more of a task with dial up service.

Let me see... So you would like me do a kernel download and set up MX-17 beta 3 to be able to boot not only from its given kernel, but from this alternate "Debian 4.9 kernel" as well. Is that right?

If that's correct, would I use the handy MX Package Installer app under Kernels? I am in MX-16.1 right now and I see two Debian kernels listed. But they are both greyed out because they are already available. (I also only have 33.3 minutes remaining of dial-up time tonight. Although the ISP's meter should reset at midnight EST, when I will again have another 10 hours of connect time available per 24 hour period.)

[Eadwine Rose]

Posting about the panel this time :) [SOLVED!]

I had an easy backup and restore thing going on:

copy the folder .restore into
/home/username/
Of course replacing the one that was there.

hit the restore from backup button in MX tools – MX default look


Now.. the latter is gone by the looks [no it's not, it's a checkbox now!], and when I log out and in the default panel is there still. I even unchecked save session to see if that made a difference, but nope. Did something change from 16 to 17? :)