MX-19 Beta 3 Feedback

[bpr323]

To confirm my findings regarding 19b3 (and 19b2.1) inability to install properly, I did the following test:
1) on my working X1 g5 I downloaded the ISO's for 18.3-Sept, 19b2.1 and 19b3
2) burnt ISO's consecutively to the same USB using MX Live USB Maker oon X1 g5 running 19b2.1
3) Set the BIOS on the test bed X1 g4 - disabled Secure Boot and set boot to "UFFI Only"
Results:
1) 18.3-Sept USB booted and installed from GUI w/o a hitch. Grub was installed to ESP - perfect
2) 19b2.1 USB booted fine to live desktop, but is unable to "auto-install using entire disk". Using "custom partitions" ESP is disabled and Grub installs to MBR
3) 19b3 USB - GUI install crapped out as above. Completed "custom partitions" with Grub to MBR. Failed to boot installed os, F12 BIOS tries to boot, but reverses to selection screen

There is clearly some delta within the live GUI installation process between 18.3 and 19 betas. The 19 betas cannot install Grub to ESP, cannot auto-install using entire disk and exhibit all the kinky features of the Antix installer.
What was the reason for breaking the OS deployment process that was working perfectly well in 18.3 - Speed? Functionality?
I've installed 18.3-Sept back on the X1 g4 - hopefully I will get the same functional features of 19.3 through updates.
One huge improvement that I value in 19 over 18.3 is the removal of password keyring prompts and the ability to connect to SMB shares "anonymously" from Thunar - great stuff!

[Adrian]

Please provide installation log: /var/log/minstall.log

[SwampRabbit]

Created USB with Rufus portable on Windows 10

Booted into the Live USB, only catch was I had to add the following to GRUB:

Code: Select all

amd_iommu=on iommu=pt

This is a known issue with this motherboard though.

Updated, installed to whole disk with GRUB to ESP, rebooted.

Code: Select all

System:    Host: mx19b3 Kernel: 4.19.0-6-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-amd64 
           root=UUID=9643d157-63d7-40cb-8691-9c4c177dce58 ro quiet amd_iommu=on iommu=pt splash 
           Desktop: Xfce 4.14.1 tk: Gtk 3.24.5 info: xfce4-panel wm: xfwm4 dm: LightDM 1.26.0 
           Distro: MX-19beta-3_x64 patito feo September 22  2019 
           base: Debian GNU/Linux 10 (buster) 
Machine:   Type: Desktop System: Gigabyte product: N/A v: N/A serial: <filter> Chassis: type: 3 
           serial: <filter> 
           Mobo: Gigabyte model: 990FXA-UD3 R5 v: x.x serial: <filter> UEFI: American Megatrends 
           v: F2 date: 04/01/2015 
CPU:       Topology: 8-Core model: AMD FX-8300 bits: 64 type: MCP arch: Bulldozer 
           family: 15 (21) model-id: 2 stepping: N/A microcode: 6000852 L2 cache: 2048 KiB 
           flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 53042 
           Speed: 1401 MHz min/max: 1400/3300 MHz boost: enabled Core speeds (MHz): 1: 1401 
           2: 1404 3: 1405 4: 1406 5: 1405 6: 1400 7: 1403 8: 1401 
           Vulnerabilities: Type: l1tf status: Not affected 
           Type: mds status: Not affected 
           Type: meltdown status: Not affected 
           Type: spec_store_bypass 
           mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 
           mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling 
Graphics:  Device-1: AMD Ellesmere [Radeon RX 470/480] vendor: Micro-Star MSI driver: amdgpu 
           v: kernel bus ID: 01:00.0 chip ID: 1002:67df 
           Display: x11 server: X.Org 1.20.4 driver: amdgpu,ati 
           unloaded: fbdev,modesetting,radeon,vesa resolution: 1920x1080~60Hz 
           OpenGL: 
           renderer: Radeon RX 570 Series (POLARIS10 DRM 3.27.0 4.19.0-6-amd64 LLVM 7.0.1) 
           v: 4.5 Mesa 18.3.6 direct render: Yes 
Audio:     Device-1: AMD SBx00 Azalia vendor: Gigabyte driver: snd_hda_intel v: kernel 
           bus ID: 00:14.2 chip ID: 1002:4383 
           Device-2: AMD Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590] 
           vendor: Micro-Star MSI driver: snd_hda_intel v: kernel bus ID: 01:00.1 
           chip ID: 1002:aaf0 
           Sound Server: ALSA v: k4.19.0-6-amd64 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Gigabyte 
           driver: r8169 v: kernel port: d000 bus ID: 04:00.0 chip ID: 10ec:8168 
           IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 268.29 GiB used: 5.19 GiB (1.9%) 
           ID-1: /dev/sda vendor: Silicon Power model: SPCC Solid State Disk size: 238.47 GiB 
           block size: physical: 512 B logical: 512 B speed: 6.0 Gb/s serial: <filter> rev: 4A0 
           scheme: GPT 
           ID-2: /dev/sdb type: USB vendor: SanDisk model: Cruzer Glide 3.0 size: 29.81 GiB 
           block size: physical: 512 B logical: 512 B serial: <filter> rev: 1.00 scheme: MBR 
Partition: ID-1: / raw size: 236.19 GiB size: 231.49 GiB (98.01%) used: 5.19 GiB (2.2%) fs: ext4 
           dev: /dev/sda2 
           ID-2: swap-1 size: 2.00 GiB used: 0 KiB (0.0%) fs: swap swappiness: 15 (default 60) 
           cache pressure: 100 (default) dev: /dev/sda3 
Sensors:   System Temperatures: cpu: 24.8 C mobo: N/A gpu: amdgpu temp: 27 C 
           Fan Speeds (RPM): N/A gpu: amdgpu fan: 1128 
Repos:     No active apt repos in: /etc/apt/sources.list 
           Active apt repos in: /etc/apt/sources.list.d/antix.list 
           1: deb http://iso.mxrepo.com/antix/buster buster main
           Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
           1: deb http://deb.debian.org/debian buster-updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/debian.list 
           1: deb http://deb.debian.org/debian buster main contrib non-free
           2: deb http://deb.debian.org/debian-security buster/updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/mx.list 
           1: deb http://mxrepo.com/mx/repo/ buster main non-free
           No active apt repos in: /etc/apt/sources.list.d/various.list 
Info:      Processes: 237 Uptime: N/A Memory: 15.63 GiB used: 540.1 MiB (3.4%) Init: SysVinit 
           v: 2.93 runlevel: 5 default: 5 Compilers: gcc: 8.3.0 alt: 8 Shell: bash v: 5.0.3 
           running in: quick-system-in inxi: 3.0.36 

No issues so far.

[bpr323]

Please provide installation log: /var/log/minstall.log

I already have, but received no feedback
https://forum.mxlinux.org/viewtopic.php ... 52#p531952

[BitJam]

What was the reason for breaking the OS deployment process that was working perfectly well in 18.3 - Speed? Functionality?

We revamped the installer because it was not working well for everyone. There is ample evidence of this in the forums shortly after the MX-18 release. IIUC we fixed some major problems but it appears we also introduced other bugs that affect a different set of people. Sorry for the inconvenience and thank you for helping us try to improve it and get it working for more people.

The major type of problem people had previously was they would do the install, the installer would say everything was fine but then they couldn't boot into the new system. In addition to revamping the installer we also addressed this problem with the live grub rescue system written by fehlix and the chroot-rescue system I wrote, both of which let you get into and repair an installed system from our live system. Of course, fixing the installer is the best solution but these rescue/repair tools are always useful to have around.

[dolphin_oracle]

I've got one other report of the installer failING to update nvram. It.might.be worth looking the the series of grub install commands again. IIRC the version on 18 only has one blanket install command.

[fehlix]

Please provide installation log: /var/log/minstall.log

I already have, but received no feedback
https://forum.mxlinux.org/viewtopic.php ... 52#p531952

I do see within the provided log some issues related to partitions:

Code: Select all

Exec #45: "mkfs.ext4 -F /dev/nvme0n1p2 -L \"rootMX19\""
SErr #45: "mke2fs 1.44.5 (15-Dec-2018)\nThe file /dev/nvme0n1p2 does not exist and no size was specified.\n"

and here:

Code: Select all

"chroot /mnt/antiX grub-install --no-nvram --force-extra-removable --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=MX19 --recheck"
"Installing for x86_64-efi platform.\ngrub-install: error: /boot/efi doesn't look like an EFI partition.\n"

[bpr323]

What was the reason for breaking the OS deployment process that was working perfectly well in 18.3 - Speed? Functionality?

We revamped the installer because it was not working well for everyone. There is ample evidence of this in the forums shortly after the MX-18 release. IIUC we fixed some major problems but it appears we also introduced other bugs that affect a different set of people. Sorry for the inconvenience and thank you for helping us try to improve it and get it working for more people.

The major type of problem people had previously was they would do the install, the installer would say everything was fine but then they couldn't boot into the new system. In addition to revamping the installer we also addressed this problem with the live grub rescue system written by fehlix and the chroot-rescue system I wrote, both of which let you get into and repair an installed system from our live system. Of course, fixing the installer is the best solution but these rescue/repair tools are always useful to have around.

Mate, no inconvenience at all - apart from not being able to enjoy 19b3
As for regression in the installer - maybe you're fixing the wrong thing and get a false positive.
In my test result 3 (above) the os completed the install, but failed to boot - clearly, b/c Grub was installed to MBR (ESP was disabled by the proggy - but why?).
May I suggest you avoid testing on VM's for starters? And please include the test scenario where a snapshot from one machine is installed on a different machine (both with and w/o personalisation)
Was my minstall.log any helpful in isolating the problem?

[bpr323]

Please provide installation log: /var/log/minstall.log

I already have, but received no feedback
https://forum.mxlinux.org/viewtopic.php ... 52#p531952

I do see within the provided log some issues related to partitions:

Code: Select all

Exec #45: "mkfs.ext4 -F /dev/nvme0n1p2 -L \"rootMX19\""
SErr #45: "mke2fs 1.44.5 (15-Dec-2018)\nThe file /dev/nvme0n1p2 does not exist and no size was specified.\n"

and here:

Code: Select all

"chroot /mnt/antiX grub-install --no-nvram --force-extra-removable --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=MX19 --recheck"
"Installing for x86_64-efi platform.\ngrub-install: error: /boot/efi doesn't look like an EFI partition.\n"

1) After the failed install (where Grub bombed out) I was also seeing in Gparted that the mount point for ESP partition was smth weird like "/temp/temp" and the flags were not set on any partition
2) The installer was also complaining (on a personalised snapshot USB) that "Folder Downloads does not exist" .. I wanted to keep some deb files for installing on a new machine, usually I "exclude all" when making a snapshot

[entropyfoe]

I had two crashes with the beta 2.1 on the signature machine. And I had three with the beta 3 in one day. I think not hardware because after the 2.1 crashes, I ran with MX-18.3 for 10 days with no crash. By crash I mean black screen, fans running, no KB or mouse response. One case I could REISUB, but others, hit the reset button.

So I reinstalled b3 again, but this time left off the nvidia install, remaining on noveau driver.But then I saw one last night while trying to use the MX Package installer to get a different kernel. In that one, mouse and KB frozen, but the screen was still on. So nvidia is not the problem.

So my only thought was to try the different kernel. I used MXPI to get the 5.2 kernel, and rebooted. Well I got up this morning, and the 5.2 kernel was still running. Last time with the stock kernel, in the morning it was crashed, so maybe this is better.

Not sure what was the difference in the betas or kernels relative to 18.3 or the beta1, where I had good stability.

Also without installing nvidia, I do not see the KVM: disabled by BIOS message during boot. In the beta 1, I could not install nvidia with the 5.2 kernel, would not boot, so maybe the building for 5.2 is not ready. I have not yet tried sgfxi as anti suggested.