MX-17 Beta 3 Feedback

[Jerry3904]

Thanks again. Not sure atm what we should do about this exactly, but will do some testing.

[darth.severus]

Is it working without problems to update from beta 2 to 3 or final after beta 2 has been installed?

I updated from MX-16 to MX-17 (live distro with persistent home) and got some grafical problems (e.g fonts and no transparent background in terminal). I'm not completely happy with the visual options, e.g. in FF the current tab isn't looking well (see Attachment) with MediterranianTributeDark Theme, because it is not in one color. [EDIT: Resolved by reboot] These problem might be related because I was keeping my home dir, which is why I'd like to know if I could install MX-17B2 or B3 now, and then update later.

Thanks for the whole work, of course, I wouldn't use it if I wouldn't like. Had some Windows for some days on my new PC, not generally bad but I'll stick with MX which seems even to start much faster.

[chrispop99]

Is it working without problems to update from beta 2 to 3 or final after beta 2 has been installed?

I updated from MX-16 to MX-17 (live distro with persistent home) and got some grafical problems (e.g fonts and no transparent background in terminal). I'm not completely happy with the visual options, e.g. in FF the current tab isn't looking well (see Attachment) with MediterranianTributeDark Theme, because it is not in one color. These problem might be related because I was keeping my home dir, which is why I'd like to know if I could install MX-17B2 or B3 now, and then update later.

Thanks for the whole work, of course, I wouldn't use it if I wouldn't like. Had some Windows for some days on my new PC, not generally bad but I'll stick with MX which seems even to start much faster.

Updating from beta releases is never good practice, and most Linux distributions won't support it.

It is often the case that you can upgrade from a release candidate to final, but as there is usually only a short time between those releases, there seems little point.

Chris

[m_pav]

I tried to view a heap of pics saved as png files on a test machine and when I went to view them, feh was the default - YUK!. I ended up with over 20 instances of feh in the taskbar that had to be closed individually, a task not made easy on a laptop when no external mouse is available. Having the default set to feh needs to be a users choice, not a default, especially when it's 1000 times easier to open one image with nomacs and then arrow through all other images in the directory.

[chrispop99]

I tried to view a heap of pics saved as png files on a test machine and when I went to view them, feh was the default - YUK!. I ended up with over 20 instances of feh in the taskbar that had to be closed individually, a task not made easy on a laptop when no external mouse is available. Having the default set to feh needs to be a users choice, not a default, especially when it's 1000 times easier to open one image with nomacs and then arrow through all other images in the directory.

It's already been reported as an oversight. The default will be Nomacs, and the next release will have that pre-set as the default.

Chris

[m_pav]

Cool.

I saw a post on the MX facebook page from a user who complained about our GRUB and whether the user is right or wrong, I have to say I have experienced an issue with GRUB on not a few occasions when using my ageing Lenovo E330 laptop. This model is known for having some issues with the bios, however, the repeated failures of GRUB to "work" after installation under a certain process validate the facebook users complaint.

Here's the condition:
boot from LiveUSB, use the partitioner in the installer to blank the disk, create a new MS-DOS partition table and create 3 new partitions, 20G /, 80G /home and 3G swap. Install to existing partitions and install GRUB to MBR. On reboot without the LiveUSB, nothing, BIOS is looking for a bootable device. re-insert liveUSB, boot live and set about repairing GRUB, result = status quo, it reports nothing to repair and testing via reboot confirms nothing has changed.

This I repeated 2x last night with the same result, however, on the 3rd attempt, I let the installer use the whole drive and auto-partition it, GRUB to MBR, rebooted to GRUB and onto the fresh installation without a problem.

I repeated this procedure on 2 other machines with no issues, custom partitioning et al, boots to grub without an issue, but on my little Lenovo, nothing whatsoever.

In my opinion, this is a hardware combination issue where a number of factors determine the outcome. Lenovos shonky BIOS doesn't help, but as an aside, I'm using a M.2 128GB SSD hosted in an adapter to fit into a standard SATA port within the machine. At the time, it was the cheapest way for me to get this thing sped up and we pay more than double what other larger countries pay for their hardware while our incomes are much the same or less in dollar value.

I've had this laptop for about 4 years since new and I did not have this type of problem when I had a 2.5" 250GB SSD installed in the machine, firstly running Linux only, and secondly with with a dual boot installation with Windows7 and Linux.

In my experience, the issue reported by the facebook user is directly related to hardware and BIOS combinations and how our installer operates, NOT installed operating systems. It's no secret that in an effort to keep prices down, OEM's try to cut corners and in doing so, cater only for Microsofts products with no regard whatsoever for users choice, thereby distancing themselves from "industry standards". Claiming Ubuntu as the benchline for operations is a misnomer because they have gotten into bed with Microsoft and are therefore partially aided by the same, so it comes as no surpirse the ewwbuntu works in the fringe areas whereas ours fails.

I write all of this because we need to 1, try to find a way to make it work in the fringe area, or 2, be fully aware of it and deal with it appropriately.

[dolphin_oracle]

that is a rather exhaustive write up.

out of curiosity, when you did the manual partitioning, did you set a boot flag? I think the auto-partitioner does this.

[m_pav]

Boot flag should not be necessary with GRUB to MBR as evidenced by my other install tests to different hardware.

[dolphin_oracle]

Boot flag should not be necessary with GRUB to MBR as evidenced by my other install tests to different hardware.

maybe not, but its a difference between the auto-install and possibly manual install.

we use this:

parted -s $dev set 1 boot on

[m_pav]

OK, I've checked the other laptop I test installed onto and there are no partitions marked with the boot flag, yet it still boots. I checked the current installation and sure enough, the / partition had been marked as bootable, so I reset my E330, installed as before to manual partitions and achieved the same no-boot result. I set the boot flag and it booted to t fresh manual partition install, so it seems to me, the way forward with this on MBR drives with manual or existing partitions to set have the installer set the boot flag on the partition used for the / install, however, with efi installations, it may be a totally different matter as I have experienced the same non-boot issue there.

I'll have to spend some time on my E330 to check it further with an EFI installation, but i have family stuff to do for the rest of the day, so will try to have a go tonight.