MX Linux Forum

Posted: **Fri Jul 31, 2020 4:24 pm**

UPDATE: MX-19 users should see a new version of GRUB - GRUB 2.04-9~mx19+5 come as a regular update

Initially dolphin_oracle (our lead dev and master of ceremonies) asked me to post a request for testing here on the newly updated GRUB 2.04-9~mx19+1 that was in the MX Test Repo. But it was deemed stable and safe for use.

If a window opens asking you were to install GRUB, you can check several ways to see where it is installed before you make a choice in that window.

And if all fails, booting a live USB, then using the fine MX Boot Repair can fix the problem easy.

You can verify the version of GRUB is updated and being used at boot by pressing “e” and the title should show the new one. Then you can press ESC to go back.

This version of GRUB was packaged to address anyone's' concerns over the recent CVE-2020-10713. While that CVE is very very limited in allowing someone to actually hijack a system, it made sense to address it sooner rather than later, and keep any chatter down about it.

Because this is a critical part of a Linux system, it was tested numerous time with multiple minor revisions , hence the +5 at the end.

Please provide feedback or your update status if you would like, after enough time has passed (maybe a week) I will ask this thread to be closed though.

Posted: **Fri Jul 31, 2020 8:42 pm**

After installing: The good news, Manjaro entries do retain their "special" µcode initrd loader line like this:

Code: Select all

initrd /boot/intel-ucode.img /boot/initramfs-5.6-x86_64.img

within the generated grub.cfg. So I assume, some of our mx grub-specific patches have been applied.
And just upgrading from testrepo would gives the default boot menu with working menuentries and no theme changes:

grub_ok.png

So all appears to be fine...
After purge and reinstall I got this menu:

grub.png

which indicates at least one mx-patch we had are missing regarding the line GRUB_DISTRIBUTOR and the "Gnu/Linux" part of that line within 10_linux. The theming change is another topic, on it's own.

Posted: **Fri Jul 31, 2020 10:00 pm**

Thank you fehlix for testing.

When I packaged this new version I made sure to pull both previous packages that Stevo had in our last version.

I annotated that in the changelog

Code: Select all

  * Add mkconfig-os-prober-early-initrd.patch, courtesy of fehlix.
  * Copy over mkconfig-ubuntu-MX-distributor.patch from previous release.

fehlix wrote: Fri Jul 31, 2020 8:42 pm After purge and reinstall I got this menu:
grub.png
which indicates at least one mx-patch we had are missing regarding the line GRUB_DISTRIBUTOR and the "Gnu/Linux" part of that line within 10_linux. The theming change is another topic, on it's own.

Are you saying that possibly the second one is not being applied properly or working?
If it is not being applied properly would it possibly need refreshed for this version of Grub?

Posted: **Sat Aug 01, 2020 3:49 am**

SwampRabbit wrote: Fri Jul 31, 2020 10:00 pm Thank you fehlix for testing.

When I packaged this new version I made sure to pull both previous packages that Stevo had in our last version.

I annotated that in the changelog
Code: Select all
  * Add mkconfig-os-prober-early-initrd.patch, courtesy of fehlix.
  * Copy over mkconfig-ubuntu-MX-distributor.patch from previous release.
fehlix wrote: Fri Jul 31, 2020 8:42 pm After purge and reinstall I got this menu:
grub.png
which indicates at least one mx-patch we had are missing regarding the line GRUB_DISTRIBUTOR and the "Gnu/Linux" part of that line within 10_linux. The theming change is another topic, on it's own.

Are you saying that possibly the second one is not being applied properly or working?
If it is not being applied properly would it possibly need refreshed for this version of Grub?

Ah, right the patches are applied properly. I guess, those where made originally rather a from minimalist point of view, not taking a purge into account. So suggest adding the missing pieces, freshly. I'll have a look...

Posted: **Sat Aug 01, 2020 5:02 am**

fehlix wrote: Sat Aug 01, 2020 3:49 am Ah, right the patches are applied properly. I guess, those where made originally rather a from minimalist point of view, not taking a purge into account. So suggest adding the missing pieces, freshly. I'll have a look...

Thank you, I do have the build logs still, they are rather long but let me know if they may be useful.

Posted: **Sat Aug 01, 2020 6:13 am**

Installed successfully to sda20 on an MBR-partitioned drive. Only to pbr, though. Chainloading from main loader (grub4dos) still works fine as previously.

Posted: **Sat Aug 01, 2020 7:27 am**

Hello SwampRabbit

a MXahsKDE5beta2 install machine and
a MX-19.2_x64 October 21 2019 install machine
both normal on new grub 2.04-9~mx19+1; 100%

Posted: **Sat Aug 01, 2020 10:42 am**

baldyeti wrote: Sat Aug 01, 2020 6:13 am Installed successfully to sda20 on an MBR-partitioned drive. Only to pbr, though. Chainloading from main loader (grub4dos) still works fine as previously.

i_ri wrote: Sat Aug 01, 2020 7:27 am Hello SwampRabbit

a MXahsKDE5beta2 install machine and
a MX-19.2_x64 October 21 2019 install machine
both normal on new grub 2.04-9~mx19+1; 100%

Thank you both very much for testing!

Edit: can you both verify the version of GRUB is being used at boot? You can do this by pressing “e” and the title should show the new one. I had one system at one point that installed but wasn’t using it actually. I’ll update the first post now with that.

Posted: **Sat Aug 01, 2020 11:53 am**

yes i had actually checked and should have mentioned it in my post, the version displayed in that "edit" window is the exact same one as this thread's title

Posted: **Sat Aug 01, 2020 12:19 pm**

baldyeti wrote: Sat Aug 01, 2020 11:53 am yes i had actually checked and should have mentioned it in my post, the version displayed in that "edit" window is the exact same one as this thread's title

Thanks again.

Posted: **Wed Aug 05, 2020 9:00 pm**

A new version of GRUB (GRUB 2.04-9~mx19+5) is in the MX Test Repo for those willing to test.
ABOVE INFORMATION IS OLD, THIS IS NOW IN THE STABLE REPO

Again please do NOT test this on production machines unless you can recover from a back up.

If you are going to test, please use the MX Test Repo tab in MX Package Installer (the packages will show as up-gradable there), please do NOT enable the MX Test Repo manually.

It has been reviewed and tested - Note we are going from a +1 at the end of the file to a +5 thanks to all the hard work by fehlix over the last few days.
Right now we don't know if there is a small chance of this breaking anything or not, but its good to play it safe until some more users can report they don't have issues.

IF you are willing to test, please post your QSI.

Thanks!

Posted: **Wed Aug 05, 2020 9:31 pm**

installed and running. no questions during startup.

my sda and sdb designations switched AFTER the grub updated. don't know what that's about but I had to run a second update-grub to correct the issue.

output from the update:

Code: Select all

2020-08-05 21:19:01.552 DBG default: "The following packages will be upgraded:\n  grub-common grub-efi-amd64-bin grub-efi-ia32-bin grub-pc grub-pc-bin grub2"
2020-08-05 21:19:01.556 DBG default: "grub2-common"
2020-08-05 21:19:01.868 DBG default: "7 upgraded, 0 newly installed, 0 to remove and 113 not upgraded.\nNeed to get 5,651 kB of archives.\nAfter this operation, 1,024 B of additional disk space will be used.\nGet:1 http://mxrepo.com/mx/testrepo buster/test amd64 grub-efi-amd64-bin amd64 2.04-9~mx19+5 [696 kB]"
2020-08-05 21:19:02.502 DBG default: "Get:2 http://mxrepo.com/mx/testrepo buster/test amd64 grub2 amd64 2.04-9~mx19+5 [2,580 B]"
2020-08-05 21:19:02.523 DBG default: "Get:3 http://mxrepo.com/mx/testrepo buster/test amd64 grub2-common amd64 2.04-9~mx19+5 [586 kB]"
2020-08-05 21:19:02.884 DBG default: "Get:4 http://mxrepo.com/mx/testrepo buster/test amd64 grub-pc amd64 2.04-9~mx19+5 [131 kB]"
2020-08-05 21:19:02.975 DBG default: "Get:5 http://mxrepo.com/mx/testrepo buster/test amd64 grub-pc-bin amd64 2.04-9~mx19+5 [966 kB]"
2020-08-05 21:19:03.689 DBG default: "Get:6 http://mxrepo.com/mx/testrepo buster/test amd64 grub-efi-ia32-bin amd64 2.04-9~mx19+5 [658 kB]"
2020-08-05 21:19:04.183 DBG default: "Get:7 http://mxrepo.com/mx/testrepo buster/test amd64 grub-common amd64 2.04-9~mx19+5 [2,612 kB]"
2020-08-05 21:19:07.019 DBG default: "Preconfiguring packages ..."
2020-08-05 21:19:07.239 DBG default: "Fetched 5,651 kB in 4s (1,280 kB/s)"
2020-08-05 21:19:08.242 DBG default: "(Reading database ... 486234 files and directories currently installed.)"
2020-08-05 21:19:08.281 DBG default: "Preparing to unpack .../0-grub-efi-amd64-bin_2.04-9~mx19+5_amd64.deb ..."
2020-08-05 21:19:08.293 DBG default: "Unpacking grub-efi-amd64-bin (2.04-9~mx19+5) over (2.04-9~mx19+3) ..."
2020-08-05 21:19:08.531 DBG default: "Preparing to unpack .../1-grub2_2.04-9~mx19+5_amd64.deb ..."
2020-08-05 21:19:08.562 DBG default: "Unpacking grub2 (2.04-9~mx19+5) over (2.04-9~mx19+3) ..."
2020-08-05 21:19:08.689 DBG default: "Preparing to unpack .../2-grub2-common_2.04-9~mx19+5_amd64.deb ..."
2020-08-05 21:19:08.701 DBG default: "Unpacking grub2-common (2.04-9~mx19+5) over (2.04-9~mx19+3) ..."
2020-08-05 21:19:08.923 DBG default: "Preparing to unpack .../3-grub-pc_2.04-9~mx19+5_amd64.deb ..."
2020-08-05 21:19:08.960 DBG default: "Unpacking grub-pc (2.04-9~mx19+5) over (2.04-9~mx19+3) ..."
2020-08-05 21:19:09.088 DBG default: "Preparing to unpack .../4-grub-pc-bin_2.04-9~mx19+5_amd64.deb ..."
2020-08-05 21:19:09.100 DBG default: "Unpacking grub-pc-bin (2.04-9~mx19+5) over (2.04-9~mx19+3) ..."
2020-08-05 21:19:09.328 DBG default: "Preparing to unpack .../5-grub-efi-ia32-bin_2.04-9~mx19+5_amd64.deb ..."
2020-08-05 21:19:09.337 DBG default: "Unpacking grub-efi-ia32-bin (2.04-9~mx19+5) over (2.04-9~mx19+3) ..."
2020-08-05 21:19:09.566 DBG default: "Preparing to unpack .../6-grub-common_2.04-9~mx19+5_amd64.deb ..."
2020-08-05 21:19:09.624 DBG default: "Unpacking grub-common (2.04-9~mx19+5) over (2.04-9~mx19+3) ..."
2020-08-05 21:19:10.145 DBG default: "Setting up grub-common (2.04-9~mx19+5) ..."
2020-08-05 21:19:10.214 DBG default: "Setting up grub-efi-amd64-bin (2.04-9~mx19+5) ..."
2020-08-05 21:19:10.227 DBG default: "Setting up grub-efi-ia32-bin (2.04-9~mx19+5) ..."
2020-08-05 21:19:10.243 DBG default: "Setting up grub2-common (2.04-9~mx19+5) ..."
2020-08-05 21:19:10.256 DBG default: "Setting up grub-pc-bin (2.04-9~mx19+5) ...\nSetting up grub-pc (2.04-9~mx19+5) ..."
2020-08-05 21:19:11.180 WRN default: "Generating grub configuration file ..."
2020-08-05 21:19:11.184 WRN default: ""
2020-08-05 21:19:11.457 WRN default: "Found theme: /boot/grub/themes/mx_linux/theme.txt"
2020-08-05 21:19:12.021 WRN default: "Found linux image: /boot/vmlinuz-5.6.0-2-amd64"
2020-08-05 21:19:12.036 WRN default: "Found initrd image: /boot/initrd.img-5.6.0-2-amd64"
2020-08-05 21:19:13.227 WRN default: "Found mtest-64.efi image: /uefi-mt/mtest-64.efi"
2020-08-05 21:19:18.417 WRN default: "Found Windows Boot Manager on /dev/sda1@/EFI/Microsoft/Boot/bootmgfw.efi"
2020-08-05 21:19:20.207 WRN default: "Found MX 19.1 patito feo (19.1 ) on /dev/sda5"
2020-08-05 21:19:22.743 WRN default: "Found MX 19.2 patito feo (19.2 ) on /dev/sda7"
2020-08-05 21:19:26.172 WRN default: "Found Ubuntu 20.04 LTS (20.04) on /dev/sda8"
2020-08-05 21:19:29.561 WRN default: "Adding boot menu entry for EFI firmware configuration"
2020-08-05 21:19:29.581 WRN default: "done"
2020-08-05 21:19:29.582 WRN default: ""
2020-08-05 21:19:29.654 DBG default: "Setting up grub2 (2.04-9~mx19+5) ..."
2020-08-05 21:19:29.674 DBG default: "Processing triggers for man-db (2.8.5-2) ..."
2020-08-05 21:19:30.541 DBG default: "Processing triggers for install-info (6.5.0.dfsg.1-4+b1) ..."
2020-08-05 21:19:30.570 WRN default: "install-info: warning: no info dir entry in `/usr/share/info/gtkdialog.info.gz'"

these entries are found on sda when the update happens, but on next boot they were sdb. the only entry really adversly affected was the windows boot manager entry.

Code: Select all

"Found Windows Boot Manager on /dev/sda1@/EFI/Microsoft/Boot/bootmgfw.efi"
2020-08-05 21:19:20.207 WRN default: "Found MX 19.1 patito feo (19.1 ) on /dev/sda5"
2020-08-05 21:19:22.743 WRN default: "Found MX 19.2 patito feo (19.2 ) on /dev/sda7"
2020-08-05 21:19:26.172 WRN default: "Found Ubuntu 20.04 LTS (20.04) on /dev/sda8"

after the update-grub after the reboot, the entries were all found on sdb, and work on subsequent boots.

Now I have no idea how to deal with that, but its worth knowing in case it crops up after the update.

Posted: **Wed Aug 05, 2020 9:45 pm**

Those messages about sda,sdb etc. are not relevant as grub.cfg is using UUID's and not (unreliable) device names like sda/sdb, if not turned off intentionally within /etc/default/grub.

Posted: **Wed Aug 05, 2020 10:09 pm**

fehlix wrote: Wed Aug 05, 2020 9:45 pm Those messages about sda,sdb etc. are not relevant as grub.cfg is using UUID's and not (unreliable) device names like sda/sdb, if not turned off intentionally within /etc/default/grub.

I wouldn't have thought so, but I often have to redo my grub menu when the drive letters switch. which happens when I change kernels sometimes.

AFAICT, its just the windows boot loader with issues.. this probalby happened the other day to when I though installing the extra ia32 bin file would fixed things. It was probably just the extra update-grub.

Posted: **Wed Aug 05, 2020 10:15 pm**

dolphin_oracle wrote: Wed Aug 05, 2020 10:09 pm
fehlix wrote: Wed Aug 05, 2020 9:45 pm Those messages about sda,sdb etc. are not relevant as grub.cfg is using UUID's and not (unreliable) device names like sda/sdb, if not turned off intentionally within /etc/default/grub.
I wouldn't have thought so, but I often have to redo my grub menu when the drive letters switch. which happens when I change kernels sometimes.

check for the line in /etc/default/grub:
GRUB_DISABLE_LINUX_UUID=true
The gnerate grub.cfg does not need any device name/drive letter if GRUB_DISABLE_LINUX_UUID is not set to true.
The default is to have this line commented out:
#GRUB_DISABLE_LINUX_UUID=true

Posted: **Wed Aug 05, 2020 10:24 pm**

grub-pc:
Installed: 2.04-9~mx19+5
Candidate: 2.04-9~mx19+5
Version table:
*** 2.04-9~mx19+5 100
100 /var/lib/dpkg/status
2.04-3mx19+3 500
500 http://la.mxrepo.com/mx/repo buster/main i386 Packages
2.02+dfsg1-20+deb10u2 500
500 http://deb.debian.org/debian buster/main i386 Packages
500 http://deb.debian.org/debian-security buster/updates/main i386 Packages
demo@mx1:~/Desktop

Hello SwampRabbit
On a mx1 live
MX-19_386 patito feo October 21 2019
4.19.0-6-686-pae i686
persist static root
from grub 2.04-3mx19+3
to grub 2.04-9~mx19+5[_i386]
It starts. (live on a machine with MX-16 installed.)

Posted: **Wed Aug 05, 2020 10:32 pm**

i_ri wrote: Wed Aug 05, 2020 10:24 pm grub-pc:
Installed: 2.04-9~mx19+5
Candidate: 2.04-9~mx19+5
Version table:
*** 2.04-9~mx19+5 100
100 /var/lib/dpkg/status
2.04-3mx19+3 500
500 http://la.mxrepo.com/mx/repo buster/main i386 Packages
2.02+dfsg1-20+deb10u2 500
500 http://deb.debian.org/debian buster/main i386 Packages
500 http://deb.debian.org/debian-security buster/updates/main i386 Packages
demo@mx1:~/Desktop

Hello SwampRabbit
On a mx1 live
MX-19_386 patito feo October 21 2019
4.19.0-6-686-pae i686
persist static root
from grub 2.04-3mx19+3
to grub 2.04-9~mx19+5[_i386]
It starts. (live on a machine with MX-16 installed.)

The grub installation/upgrade is not used within the a LiveUSB/ Live installed system,
The GRUB upgrade is only relevant/used within an installed (non-live) system .
The Live-System does use it's own (Live-)Grub, which cannot be updated through a grub-package upgrade.

Posted: **Thu Aug 06, 2020 12:40 am**

Hello SwampRabbit and fehlix and … everyone . Do you wish the live post deleted?
.+5 , using , MX 19.2_64,
starts. Normal

Code: Select all

grub-common:
  Installed: 2.04-9~mx19+5
  Candidate: 2.04-9~mx19+5
  Version table:
 *** 2.04-9~mx19+5 100
        100 /var/lib/dpkg/status
     2.04-3mx19+3 500
        500 http://mxrepo.com/mx/repo buster/main amd64 Packages
     2.02+dfsg1-20+deb10u2 500
        500 http://deb.debian.org/debian-security buster/updates/main amd64 Packages
     2.02+dfsg1-20 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
grub2-common:
  Installed: 2.04-9~mx19+5
  Candidate: 2.04-9~mx19+5
  Version table:
 *** 2.04-9~mx19+5 100
        100 /var/lib/dpkg/status
     2.04-3mx19+3 500
        500 http://mxrepo.com/mx/repo buster/main amd64 Packages
     2.02+dfsg1-20+deb10u2 500
        500 http://deb.debian.org/debian-security buster/updates/main amd64 Packages
     2.02+dfsg1-20 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
grub-pc:
  Installed: 2.04-9~mx19+5
  Candidate: 2.04-9~mx19+5
  Version table:
 *** 2.04-9~mx19+5 100
        100 /var/lib/dpkg/status
     2.04-3mx19+3 500
        500 http://mxrepo.com/mx/repo buster/main amd64 Packages
     2.02+dfsg1-20+deb10u2 500
        500 http://deb.debian.org/debian-security buster/updates/main amd64 Packages
     2.02+dfsg1-20 500
        500 http://deb.debian.org/debian buster/main amd64 Packages

System:    Host: WallEp6330f Kernel: 4.19.0-9-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 
           Desktop: Xfce 4.14.2 tk: Gtk 3.24.5 info: xfce4-panel wm: xfwm4 dm: LightDM 1.26.0 
           Distro: MX-19.2_x64 patito feo October 21  2019 base: Debian GNU/Linux 10 (buster) 
Machine:   Type: Desktop System: HP-Pavilion product: AY022AA-ABA p6330f v: N/A 
           serial: <root required> Chassis: Hewlett-Packard type: 3 serial: <root required> 
           Mobo: MSI model: IONA v: 1.0 serial: <root required> BIOS: American Megatrends 
           v: 5.15 date: 06/25/2010 
CPU:       Topology: Dual Core model: Intel Core i3 530 bits: 64 type: MT MCP arch: Nehalem 
           rev: 2 L2 cache: 4096 KiB bogomips: 23408 
           Speed: 1437 MHz min/max: 1200/2933 MHz Core speeds (MHz): 1: 1400 2: 1378 3: 1325 
           4: 1435 
           Flags: acpi aperfmperf apic arat arch_perfmon bts clflush cmov constant_tsc cpuid 
           cx16 cx8 de ds_cpl dtes64 dtherm dts ept est flexpriority flush_l1d fpu fxsr ht ibpb 
           ibrs lahf_lm lm mca mce mmx monitor msr mtrr nonstop_tsc nopl nx pae pat pbe pdcm 
           pebs pge pni popcnt pse pse36 pti rdtscp rep_good sep ss ssbd sse sse2 sse4_1 sse4_2 
           ssse3 stibp syscall tm tm2 tpr_shadow tsc vme vmx vnmi vpid xtopology xtpr 
Graphics:  Device-1: Intel Core Processor Integrated Graphics vendor: Hewlett-Packard 
           driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:0042 
           Display: x11 server: X.Org 1.20.4 driver: intel resolution: 1920x1080~60Hz 
           OpenGL: renderer: Mesa DRI Intel Ironlake Desktop v: 2.1 Mesa 18.3.6 
           direct render: Yes 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
           vendor: Hewlett-Packard driver: r8169 v: kernel port: d800 bus ID: 01:00.0 
           chip ID: 10ec:8168 
           Device-2: Realtek RTL8188EUS 802.11n Wireless Network Adapter type: USB 
           driver: r8188eu bus ID: 1-1.3:3 chip ID: 0bda:8179 serial: 00E04C0001 
Drives:    Local Storage: total: 1.82 TiB used: 12.27 GiB (0.7%) 
           ID-1: /dev/sda vendor: Toshiba model: DT01ACA200 size: 1.82 TiB speed: 3.0 Gb/s 
           rotation: 7200 rpm serial: 335RBPGKS rev: ABB0 scheme: MBR 
Weather:   Temperature: 25.9 C (79 F) Conditions: Overcast clouds 
           Wind: from SE at 1.8 m/s (6 km/h, 4 mph) Cloud Cover: 45% Humidity: 67% 
           Dew Point: 19.3 C (67 F) Pressure: 1013.6 mb (34 in) 
           Location: Washington, D.C., DC, US, 20500 
           Current Time: Wed 05 Aug 2020 11:50:28 PM EDT 
           Observation Time: 2020-08-05 22:44:00 (America/New_York -0400) Source: WeatherBit.io 
Info:      Processes: 199 Uptime: 12m Memory: 7.66 GiB used: 574.5 MiB (7.3%) Init: SysVinit 
           v: 2.93 runlevel: 5 default: 5 Compilers: gcc: 8.3.0 alt: 8 Shell: bash v: 5.0.3 
           running in: xfce4-terminal inxi: 3.0.36 
Packages: 2260 (dpkg) 
hithere@WallEp6330f:~
$ hello everyone

Machine runs vintage* MX-19.2. pre*mxfluxbox.
Already MX 19.2 Vintage, before end of life.

Posted: **Thu Aug 06, 2020 12:48 am**

i_ri wrote: Thu Aug 06, 2020 12:40 am Hello SwampRabbit and fehlix and … everyone . Do you wish the live post deleted?
.+5 , using , MX 19.2_64,

No it is ok i_ri, it may help if another user comes asking the same thing.

And thank you, We do appreciate the testing!

Posted: **Thu Aug 06, 2020 2:13 am**

Tested 2nd candidate on same system as before, same OK outcome

baldyeti wrote: Sat Aug 01, 2020 6:13 am Installed successfully to sda20 on an MBR-partitioned drive. Only to pbr, though. Chainloading from main loader (grub4dos) still works fine as previously.

This time i was not offered the choice to install to mbr/pbr/both, but the upgrade correctly installed to pbr only, so no complaint.

Posted: **Thu Aug 06, 2020 3:36 am**

Hello SwampRabbit and everyone . is 32bit testing needed?
.+5, using, started,
MX-19ahs_KDE5-beta2

Code: Select all

grub-pc:
  Installed: 2.04-9~mx19+5
  Candidate: 2.04-9~mx19+5
  Version table:
 *** 2.04-9~mx19+5 100
        100 /var/lib/dpkg/status
     2.04-3mx19+3 500
        500 http://la.mxrepo.com/mx/repo buster/main amd64 Packages
     2.02+dfsg1-20+deb10u2 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
        500 http://deb.debian.org/debian-security buster/updates/main amd64 Packages

System:    Host: WallE Kernel: 5.6.0-2-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 Desktop: KDE Plasma 5.14.5 wm: kwin_x11 
           dm: SDDM Distro: MX-19.2_KDE-beta2_x64 patito feo July 5  2020 base: Debian GNU/Linux 10 (buster) 
Machine:   Type: Desktop System: HP-Pavilion product: AY022AA-ABA p6330f v: N/A serial: <root required> 
           Chassis: Hewlett-Packard type: 3 serial: <root required> 
           Mobo: MSI model: IONA v: 1.0 serial: <root required> BIOS: American Megatrends v: 5.15 date: 06/25/2010 
CPU:       Topology: Dual Core model: Intel Core i3 530 bits: 64 type: MT MCP arch: Nehalem rev: 2 L2 cache: 4096 KiB 
           bogomips: 23406 
           Speed: 2533 MHz min/max: 1200/2933 MHz Core speeds (MHz): 1: 2533 2: 1934 3: 1969 4: 2073 
           Flags: acpi aperfmperf apic arat arch_perfmon bts clflush cmov constant_tsc cpuid cx16 cx8 de ds_cpl dtes64 dtherm 
           dts est flush_l1d fpu fxsr ht ibpb ibrs lahf_lm lm mca mce mmx monitor msr mtrr nonstop_tsc nopl nx pae pat pbe 
           pdcm pebs pge pni popcnt pse pse36 pti rdtscp rep_good sep ssbd sse sse2 sse4_1 sse4_2 ssse3 stibp syscall tm tm2 
           tsc vme xtopology xtpr 
Graphics:  Device-1: Intel Core Processor Integrated Graphics vendor: Hewlett-Packard driver: i915 v: kernel bus ID: 00:02.0 
           chip ID: 8086:0042 
           Display: x11 server: X.Org 1.20.4 driver: intel compositor: kwin_x11 resolution: 1920x1080~60Hz 
           OpenGL: renderer: Mesa DRI Intel HD Graphics (ILK) v: 2.1 Mesa 20.0.7 direct render: Yes 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Hewlett-Packard driver: r8169 v: kernel 
           port: d800 bus ID: 01:00.0 chip ID: 10ec:8168 
           Device-2: Realtek RTL8188EUS 802.11n Wireless Network Adapter type: USB driver: r8188eu bus ID: 1-1.3:3 
           chip ID: 0bda:8179 serial: 00E04C0001 
Drives:    Local Storage: total: 465.76 GiB used: 7.54 GiB (1.6%) 
           ID-1: /dev/sda vendor: Seagate model: ST3500841AS size: 465.76 GiB speed: 3.0 Gb/s serial: 3PM1RFLA rev: M 
           temp: 42 C scheme: MBR 
Weather:   Temperature: 24.6 C (76 F) Conditions: Overcast clouds Wind: from WNW at 0.9 m/s (3 km/h, 2 mph) Cloud Cover: 100% 
           Humidity: 70% Dew Point: 18.8 C (66 F) Pressure: 1013 mb (34 in) Location: Washington, D.C., DC, US, 20500 
           Current Time: Thu 06 Aug 2020 03:13:28 AM EDT Observation Time: 2020-08-06 02:59:00 (America/New_York -0400) 
           Source: WeatherBit.io 
Info:      Processes: 217 Uptime: 4m Memory: 7.64 GiB used: 1.31 GiB (17.2%) Init: SysVinit v: 2.93 runlevel: 5 default: 5 
           Compilers: gcc: 8.3.0 alt: 8 Shell: bash v: 5.0.3 running in: qterminal inxi: 3.0.36 
Packages: 2346 (dpkg) 
patitok5obb2@WallE:~
$ hello everyone

Posted: **Thu Aug 06, 2020 7:50 am**

Hello SwampRabbit and everyone
.+5, using, install usb2.0 level, Mx-19.2ahs_KDE-beta2. starts. Normal

Code: Select all

grub-pc:
  Installed: 2.04-9~mx19+5
  Candidate: 2.04-9~mx19+5
  Version table:
 *** 2.04-9~mx19+5 100
        100 /var/lib/dpkg/status
     2.04-3mx19+3 500
        500 http://mirrors.rit.edu/mxlinux/mx-packages/mx/repo buster/main amd64 Packages
     2.02+dfsg1-20+deb10u2 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
        500 http://deb.debian.org/debian-security buster/updates/main amd64 Packages
System:    Host: heap Kernel: 5.6.0-2-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 Desktop: KDE Plasma 5.14.5 wm: kwin_x11 
           dm: SDDM Distro: MX-19.2_KDE-beta2_x64 patito feo July 5  2020 base: Debian GNU/Linux 10 (buster) 
Machine:   Type: Laptop System: Hewlett-Packard product: HP EliteBook 8440p v: N/A serial: <root required> Chassis: type: 10 
           serial: <root required> 
           Mobo: Hewlett-Packard model: 172A v: KBC Version 30.35 serial: <root required> BIOS: Hewlett-Packard 
           v: 68CCU Ver. F.60 date: 11/11/2015 
Battery:   ID-1: BAT0 charge: 45.0 Wh condition: 46.8/46.8 Wh (100%) volts: 12.3/11.1 model: Hewlett-Packard Primary 
           type: Li-ion serial: 01595 2011/08/15 status: Unknown 
           Device-1: hidpp_battery_0 model: Logitech Wireless Keyboard K360 serial: 4004-13-87-a8-bd 
           charge: 100% (should be ignored) rechargeable: yes status: Discharging 
CPU:       Topology: Dual Core model: Intel Core i5 M 560 bits: 64 type: MT MCP arch: Nehalem rev: 5 L2 cache: 3072 KiB 
           bogomips: 21283 
           Speed: 1424 MHz min/max: 1199/2667 MHz boost: enabled Core speeds (MHz): 1: 1424 2: 1296 3: 1355 4: 1357 
           Flags: acpi aes aperfmperf apic arat arch_perfmon bts clflush cmov constant_tsc cpuid cx16 cx8 de ds_cpl dtes64 
           dtherm dts est flush_l1d fpu fxsr ht ibpb ibrs ida lahf_lm lm mca mce mmx monitor msr mtrr nonstop_tsc nopl nx pae 
           pat pbe pcid pclmulqdq pdcm pebs pge pni popcnt pse pse36 pti rdtscp rep_good sep smx ssbd sse sse2 sse4_1 sse4_2 
           ssse3 stibp syscall tm tm2 tsc vme xtopology xtpr 
Graphics:  Device-1: Intel Core Processor Integrated Graphics vendor: Hewlett-Packard driver: i915 v: kernel bus ID: 00:02.0 
           chip ID: 8086:0046 
           Display: x11 server: X.Org 1.20.4 driver: intel compositor: kwin_x11 resolution: 1600x900~60Hz, 1280x1024~60Hz 
           OpenGL: renderer: Mesa DRI Intel HD Graphics (ILK) v: 2.1 Mesa 20.0.7 direct render: Yes 
Network:   Device-1: Intel 82577LM Gigabit Network vendor: Hewlett-Packard driver: e1000e v: 3.2.6-k port: 5020 
           bus ID: 00:19.0 chip ID: 8086:10ea 
           Device-2: Intel Centrino Advanced-N 6200 driver: iwlwifi v: kernel port: 5000 bus ID: 43:00.0 chip ID: 8086:4239 
Drives:    Local Storage: total: 14.91 GiB used: 6.65 GiB (44.6%) 
           ID-1: /dev/sda type: USB vendor: SanDisk model: Cruzer Glide size: 14.91 GiB speed: <unknown> 
           serial: 2006107973054D5273CF rev: 1.00 scheme: MBR 
Weather:   Temperature: 22.8 C (73 F) Conditions: Overcast clouds Wind: from E at 0.5 m/s (2 km/h, 1 mph) Cloud Cover: 75% 
           Humidity: 88% Dew Point: 20.7 C (69 F) Pressure: 1007.9 mb (34 in) Location: Washington, D.C., DC, US, 20500 
           Current Time: Thu 06 Aug 2020 07:24:59 AM EDT Observation Time: 2020-08-06 06:48:00 (America/New_York -0400) 
           Source: WeatherBit.io 
Info:      Processes: 191 Uptime: 12m Memory: 3.65 GiB used: 577.9 MiB (15.5%) Init: SysVinit v: 2.93 runlevel: 5 default: 5 
           Compilers: gcc: 8.3.0 alt: 8 Shell: bash v: 5.0.3 running in: konsole inxi: 3.0.36 
Packages: 2326 (dpkg) 
keremxoid@heap:~
$ hello everyone

Posted: **Thu Aug 06, 2020 9:41 am**

baldyeti wrote: Thu Aug 06, 2020 2:13 am Tested 2nd candidate on same system as before, same OK outcome
baldyeti wrote: Sat Aug 01, 2020 6:13 am Installed successfully to sda20 on an MBR-partitioned drive. Only to pbr, though. Chainloading from main loader (grub4dos) still works fine as previously.
This time i was not offered the choice to install to mbr/pbr/both, but the upgrade correctly installed to pbr only, so no complaint.

Thanks for testing and the information baldyeti!

Posted: **Thu Aug 06, 2020 9:42 am**

i_ri wrote: Thu Aug 06, 2020 3:36 am Hello SwampRabbit and everyone . is 32bit testing needed?

i_ri if you would like to test 32bit, that would be great, I tested it a few versions ago and don't have time right now to test again.

Posted: **Thu Aug 06, 2020 11:22 am**

fehlix wrote: Wed Aug 05, 2020 10:15 pm
dolphin_oracle wrote: Wed Aug 05, 2020 10:09 pm
fehlix wrote: Wed Aug 05, 2020 9:45 pm Those messages about sda,sdb etc. are not relevant as grub.cfg is using UUID's and not (unreliable) device names like sda/sdb, if not turned off intentionally within /etc/default/grub.
I wouldn't have thought so, but I often have to redo my grub menu when the drive letters switch. which happens when I change kernels sometimes.
check for the line in /etc/default/grub:
GRUB_DISABLE_LINUX_UUID=true
The gnerate grub.cfg does not need any device name/drive letter if GRUB_DISABLE_LINUX_UUID is not set to true.
The default is to have this line commented out:
#GRUB_DISABLE_LINUX_UUID=true

I'll check but it should be commented out. I haven't changed it.

Posted: **Thu Aug 06, 2020 11:58 am**

dolphin_oracle wrote: Thu Aug 06, 2020 11:22 am
fehlix wrote: Wed Aug 05, 2020 10:15 pm
dolphin_oracle wrote: Wed Aug 05, 2020 10:09 pm

I wouldn't have thought so, but I often have to redo my grub menu when the drive letters switch. which happens when I change kernels sometimes.
check for the line in /etc/default/grub:
GRUB_DISABLE_LINUX_UUID=true
The gnerate grub.cfg does not need any device name/drive letter if GRUB_DISABLE_LINUX_UUID is not set to true.
The default is to have this line commented out:
#GRUB_DISABLE_LINUX_UUID=true
I'll check but it should be commented out. I haven't changed it.

The windows entry might look like thos:

Code: Select all

menuentry 'Windows Boot Manager (on /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-efi-XXXX-YYYY' {
	insmod part_gpt
	insmod fat
	set root='hd0,gpt1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1  XXXX-YYYY
	else
	  search --no-floppy --fs-uuid --set=root XXXX-YYYY
	fi
	chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

The /dev/sda1 is only used titel and "hd0,gpt1" is actulay rather a "hint".
As the search for UUID XXXX-YYYY, would re-set the root anyway.
So the question would be: The first grub.cfg generated even shown the wrong sdb instead of sda, would it have generated the same entry, with the correct UUID's. But using a diffferent "fallback" like set root='hd1,gpt1'
ANd if even with the correct UUID's the entry would not load into Windows, that would mean the fallback is used, which is an issue on it's own, as UUID shall work. But OK, they might have a reason why they added the fallback
Strange is that 2nd manual update-grub run creates the correct" fallback set root='hd0,gpt1'.
Not sure whether this is a generic case or rather a special one with this pc.
In theory we could add a 2nd update-grub with the postinst, but would rather avoid if that a more rar situation.

Posted: **Thu Aug 06, 2020 12:01 pm**

fehlix wrote: Thu Aug 06, 2020 11:58 am
dolphin_oracle wrote: Thu Aug 06, 2020 11:22 am
fehlix wrote: Wed Aug 05, 2020 10:15 pm
check for the line in /etc/default/grub:
GRUB_DISABLE_LINUX_UUID=true
The gnerate grub.cfg does not need any device name/drive letter if GRUB_DISABLE_LINUX_UUID is not set to true.
The default is to have this line commented out:
#GRUB_DISABLE_LINUX_UUID=true
I'll check but it should be commented out. I haven't changed it.
The windows entry might look like thos:
Code: Select all
menuentry 'Windows Boot Manager (on /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-efi-XXXX-YYYY' {
	insmod part_gpt
	insmod fat
	set root='hd0,gpt1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1  XXXX-YYYY
	else
	  search --no-floppy --fs-uuid --set=root XXXX-YYYY
	fi
	chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
The /dev/sda1 is only used titel and "hd0,gpt1" is actulay rather a "hint".
As the search for UUID XXXX-YYYY, would re-set the root anyway.
So the question would be: The first grub.cfg generated even shown the wrong sdb instead of sda, would it have generated the same entry, with the correct UUID's. But using a diffferent "fallback" like set root='hd1,gpt1'
ANd if even with the correct UUID's the entry would not load into Windows, that would mean the fallback is used, which is an issue on it's own, as UUID shall work. But OK, they might have a reason why they added the fallback
Strange is that 2nd manual update-grub run creates the correct" fallback set root='hd0,gpt1'.
Not sure whether this is a generic case or rather a special one with this pc.
In theory we could add a 2nd update-grub with the postinst, but would rather avoid if that a more rar situation.

nah, don't worry about it. Its just weird.

if I can duplicate it I'll post the original grub.cfg for comparison.

Posted: **Thu Aug 06, 2020 12:22 pm**

dolphin_oracle wrote: Thu Aug 06, 2020 12:01 pm
fehlix wrote: Thu Aug 06, 2020 11:58 am
dolphin_oracle wrote: Thu Aug 06, 2020 11:22 am

I'll check but it should be commented out. I haven't changed it.
The windows entry might look like thos:
Code: Select all
menuentry 'Windows Boot Manager (on /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-efi-XXXX-YYYY' {
	insmod part_gpt
	insmod fat
	set root='hd0,gpt1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1  XXXX-YYYY
	else
	  search --no-floppy --fs-uuid --set=root XXXX-YYYY
	fi
	chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
The /dev/sda1 is only used titel and "hd0,gpt1" is actulay rather a "hint".
As the search for UUID XXXX-YYYY, would re-set the root anyway.
So the question would be: The first grub.cfg generated even shown the wrong sdb instead of sda, would it have generated the same entry, with the correct UUID's. But using a diffferent "fallback" like set root='hd1,gpt1'
ANd if even with the correct UUID's the entry would not load into Windows, that would mean the fallback is used, which is an issue on it's own, as UUID shall work. But OK, they might have a reason why they added the fallback
Strange is that 2nd manual update-grub run creates the correct" fallback set root='hd0,gpt1'.
Not sure whether this is a generic case or rather a special one with this pc.
In theory we could add a 2nd update-grub with the postinst, but would rather avoid if that a more rar situation.
nah, don't worry about it. Its just weird.

if I can duplicate it I'll post the original grub.cfg for comparison.

Another theoretical possiblity: On both drives is an ESP with the same UUID. E.g. in case those drive of been cloned, without changin the UUID's. If so, it founds the wrong ESP.

Posted: **Thu Aug 06, 2020 1:11 pm**

fehlix wrote: Thu Aug 06, 2020 12:22 pm
dolphin_oracle wrote: Thu Aug 06, 2020 12:01 pm
fehlix wrote: Thu Aug 06, 2020 11:58 am

The windows entry might look like thos:
Code: Select all
menuentry 'Windows Boot Manager (on /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-efi-XXXX-YYYY' {
	insmod part_gpt
	insmod fat
	set root='hd0,gpt1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1  XXXX-YYYY
	else
	  search --no-floppy --fs-uuid --set=root XXXX-YYYY
	fi
	chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
The /dev/sda1 is only used titel and "hd0,gpt1" is actulay rather a "hint".
As the search for UUID XXXX-YYYY, would re-set the root anyway.
So the question would be: The first grub.cfg generated even shown the wrong sdb instead of sda, would it have generated the same entry, with the correct UUID's. But using a diffferent "fallback" like set root='hd1,gpt1'
ANd if even with the correct UUID's the entry would not load into Windows, that would mean the fallback is used, which is an issue on it's own, as UUID shall work. But OK, they might have a reason why they added the fallback
Strange is that 2nd manual update-grub run creates the correct" fallback set root='hd0,gpt1'.
Not sure whether this is a generic case or rather a special one with this pc.
In theory we could add a 2nd update-grub with the postinst, but would rather avoid if that a more rar situation.
nah, don't worry about it. Its just weird.

if I can duplicate it I'll post the original grub.cfg for comparison.
Another theoretical possiblity: On both drives is an ESP with the same UUID. E.g. in case those drive of been cloned, without changin the UUID's. If so, it founds the wrong ESP.

hmm.....I may have to check that one. I did at one time try to clone on my oldrive onto the newer SSD. I ended up reinstalling but its very possible I didn't overwrite the ESP.

Posted: **Thu Aug 06, 2020 6:02 pm**

Hello SwampRabbit
The 32bit
took that live usb with 2.04-9~mx19+5 installed, ran it through remaster with live kernel updater, got this install that first start, verifi by press e, and every start is with +5. It knows no other grub. Now full upgrade and snappy. Desktop starts faster than you can strike a match.
MX-19.2_386

Code: Select all

grub-pc:
  Installed: 2.04-9~mx19+5
System:    Host: phoemx Kernel: 4.19.0-10-686-pae i686 bits: 32 compiler: gcc v: 8.3.0 
           Desktop: Xfce 4.14.2 tk: Gtk 3.24.5 info: xfce4-panel wm: xfwm4 dm: LightDM 1.26.0 
           Distro: MX-19.2_386 patito feo October 21  2019 base: Debian GNU/Linux 10 (buster) 
Machine:   Type: Portable System: Dell product: MM061 v: N/A serial: <root required> Chassis: 
           type: 8 serial: <root required> 
           Mobo: Dell model: 0KD882 serial: <root required> BIOS: Dell v: A17 date: 06/13/2007 
Battery:   ID-1: BAT0 charge: 66.9 Wh condition: 69.1/84.2 Wh (82%) volts: 12.5/10.8 
           model: Samsung SDI DELL type: Li-ion serial: 1692 status: Charging 
CPU:       Topology: Dual Core model: Intel T2300 bits: 32 type: MCP arch: M Yonah rev: 8 
           L2 cache: 2048 KiB bogomips: 6657 
           Speed: 999 MHz min/max: 1000/1667 MHz Core speeds (MHz): 1: 999 2: 999 
           Flags: acpi aperfmperf apic arch_perfmon bts clflush cmov constant_tsc cpuid cx8 de 
           dtherm dts est fpu fxsr ht mca mce mmx monitor msr mtrr nx pae pbe pdcm pge pni pse 
           pti sep ss sse sse2 tm tm2 tsc vme xtpr 
Graphics:  Device-1: Intel Mobile 945GM/GMS 943/940GML Express Integrated Graphics vendor: Dell 
           driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:27a2 
           Display: x11 server: X.Org 1.20.4 driver: intel unloaded: fbdev,modesetting,vesa 
           resolution: 1280x800~60Hz 
           OpenGL: renderer: Mesa DRI Intel 945GM x86/MMX/SSE2 v: 1.4 Mesa 18.3.6 
           direct render: Yes 
Network:   Device-1: Broadcom Limited BCM4401-B0 100Base-TX vendor: Dell Inspiron 6400 
           driver: b44 v: 2.0 port: 10c0 bus ID: 03:00.0 chip ID: 14e4:170c 
           Device-2: Intel PRO/Wireless 3945ABG [Golan] Network driver: iwl3945 v: in-tree:s 
           port: 10c0 bus ID: 0b:00.0 chip ID: 8086:4222 
Drives:    Local Storage: total: 465.76 GiB used: 5.88 GiB (1.3%) 
           ID-1: /dev/sda vendor: Hitachi model: HTS725050A7E630 size: 465.76 GiB 
           speed: <unknown> rotation: 7200 rpm serial: TF0500Y9K9D1RC rev: A3C0 scheme: MBR 
Weather:   Temperature: 27.4 C (81 F) Conditions: Scattered clouds 
           Wind: from SSE at 4.2 m/s (15 km/h, 9 mph) Cloud Cover: 100% Humidity: 70% 
           Dew Point: 21.4 C (71 F) Pressure: 1013 mb (34 in) 
           Location: Washington, D.C., DC, US, 20500 
           Current Time: Thu 06 Aug 2020 05:45:45 PM EDT 
           Observation Time: 2020-08-06 17:14:00 (America/New_York -0400) Source: WeatherBit.io 
Info:      Processes: 159 Uptime: 16m Memory: 1.96 GiB used: 350.5 MiB (17.5%) Init: SysVinit 
           v: 2.93 runlevel: 5 default: 5 Compilers: gcc: 8.3.0 alt: 8 Shell: bash v: 5.0.3 
           running in: xfce4-terminal inxi: 3.0.36 
Packages: 1979 (dpkg) 
hereir@phoemx:~
$ hello everyone

Posted: **Thu Aug 06, 2020 6:52 pm**

i_ri wrote: Thu Aug 06, 2020 6:02 pm Hello SwampRabbit
The 32bit
took that live usb with 2.04-9~mx19+5 installed, ran it through remaster with live kernel updater, got this install that first start, verifi by press e, and every start is with +5. It knows no other grub. Now full upgrade and snappy. Desktop starts faster than you can strike a match.
MX-19.2_386

Thank you i_ri!

Posted: **Thu Aug 06, 2020 6:56 pm**

dolphin_oracle wrote: Thu Aug 06, 2020 1:11 pm
fehlix wrote: Thu Aug 06, 2020 12:22 pm
dolphin_oracle wrote: Thu Aug 06, 2020 12:01 pm

nah, don't worry about it. Its just weird.

if I can duplicate it I'll post the original grub.cfg for comparison.
Another theoretical possiblity: On both drives is an ESP with the same UUID. E.g. in case those drive of been cloned, without changin the UUID's. If so, it founds the wrong ESP.
hmm.....I may have to check that one. I did at one time try to clone on my oldrive onto the newer SSD. I ended up reinstalling but its very possible I didn't overwrite the ESP.

that was it. my ESP's have the same UUID. so mystery solved.

I'm good to send it out to the main repo now.

Posted: **Thu Aug 06, 2020 6:59 pm**

dolphin_oracle wrote: Thu Aug 06, 2020 6:56 pm that was it. my ESP's have the same UUID. so mystery solved.

I'm good to send it out to the main repo now.

I'll send the PM then

Posted: **Thu Aug 06, 2020 7:26 pm**

dolphin_oracle wrote: Thu Aug 06, 2020 6:56 pm that was it. my ESP's have the same UUID. so mystery solved.

Posted: **Fri Aug 07, 2020 2:06 am**

I got this in my upgrades this morning, installed it, and am still able to boot both MX and Windows, so no problems here.

Posted: **Fri Aug 07, 2020 2:36 am**

JayM wrote: Fri Aug 07, 2020 2:06 am I got this in my upgrades this morning, installed it, and am still able to boot both MX and Windows, so no problems here.

Thanks Jay! That is good news indeed, I think I'll feel a little uncomfortable until some time passes.

Seen lots of horror stories on other distros lately. But if fehlix and d.o. say we're good I trust them were 99.99% golden

Posted: **Fri Aug 07, 2020 3:12 am**

At worst case I have a snapshot and full backup that I made less than a week ago. I could have reinstalled the old grub from my snapshot USB or even done a full reinstall, so I decided to go for it.

Posted: **Fri Aug 07, 2020 12:09 pm**

Also upgraded here, works fine no problem. The install window is a bit confusing though, offering to install to sda and sda1 and then erroring out if you don't have it installed to sda1 (like me!).

Posted: **Fri Aug 07, 2020 12:41 pm**

Snod Blatter wrote: Fri Aug 07, 2020 12:09 pm Also upgraded here, works fine no problem. The install window is a bit confusing though, offering to install to sda and sda1 and then erroring out if you don't have it installed to sda1 (like me!).

Yes that can be a bit confusing at times.

I don't believe we (MX) can do anything about that, its a GRUB thing, although fehlix would know best.

One good thing is, while that window is open, you can check several ways to see where it is installed before you make a choice in that window.

And if all fails, booting a live USB and using the fine MX Boot Repair to fix the problem easy.

I actually need to update the first post and title of this thread now.

Posted: **Fri Aug 07, 2020 2:47 pm**

After installing the update I was unable to boot. I got a grub rescue prompt.

I booted a live USB and selected grub from the boot menu, then selected the current bootloader and was up. I ran grub repair which completed successfully, but reboot brought me to grub rescue. Next time I ran grub customizer -- same result.

Even though the fixes seem to work, they don't. Any suggestions?

Posted: **Fri Aug 07, 2020 3:05 pm**

arjaybe wrote: Fri Aug 07, 2020 2:47 pm After installing the update I was unable to boot. I got a grub rescue prompt.

I booted a live USB and selected grub from the boot menu, then selected the current bootloader and was up. I ran grub repair which completed successfully, but reboot brought me to grub rescue. Next time I ran grub customizer -- same result.

Even though the fixes seem to work, they don't. Any suggestions?

First question to ask, is UEFI or or legacy/MBR booting?

Posted: **Fri Aug 07, 2020 3:23 pm**

fehlix wrote: Fri Aug 07, 2020 3:05 pm
arjaybe wrote: Fri Aug 07, 2020 2:47 pm After installing the update I was unable to boot. I got a grub rescue prompt.

I booted a live USB and selected grub from the boot menu, then selected the current bootloader and was up. I ran grub repair which completed successfully, but reboot brought me to grub rescue. Next time I ran grub customizer -- same result.

Even though the fixes seem to work, they don't. Any suggestions?
First question to ask, is UEFI or or legacy/MBR booting?

Legacy. Also, during the grub update I chose to replace a file, but when I checked the differences, it was a blank.

Posted: **Fri Aug 07, 2020 3:34 pm**

arjaybe wrote: Fri Aug 07, 2020 3:23 pm
fehlix wrote: Fri Aug 07, 2020 3:05 pm
arjaybe wrote: Fri Aug 07, 2020 2:47 pm After installing the update I was unable to boot. I got a grub rescue prompt.

I booted a live USB and selected grub from the boot menu, then selected the current bootloader and was up. I ran grub repair which completed successfully, but reboot brought me to grub rescue. Next time I ran grub customizer -- same result.

Even though the fixes seem to work, they don't. Any suggestions?
First question to ask, is UEFI or or legacy/MBR booting?
Legacy. Also, during the grub update I chose to replace a file, but when I checked the differences, it was a blank.

OK, and you had GRUB customizer installed and used to change the menu.right? OK, I need to check GRUB customizer first ...

Posted: **Fri Aug 07, 2020 3:45 pm**

SwampRabbit wrote: Wed Aug 05, 2020 9:00 pm A new version of GRUB (GRUB 2.04-9~mx19+5) is in the MX Test Repo for those willing to test.

If you are going to test, please use the MX Test Repo tab in MX Package Installer (the packages will show as up-gradable there), please do NOT enable the MX Test Repo manually.

Thanks!

I have the test repo enabled, but the grub has not been updated. I use MBR.

Posted: **Fri Aug 07, 2020 3:59 pm**

zoli62 wrote: Fri Aug 07, 2020 3:45 pm
SwampRabbit wrote: Wed Aug 05, 2020 9:00 pm A new version of GRUB (GRUB 2.04-9~mx19+5) is in the MX Test Repo for those willing to test.

If you are going to test, please use the MX Test Repo tab in MX Package Installer (the packages will show as up-gradable there), please do NOT enable the MX Test Repo manually.

Thanks!
I have the test repo enabled, but the grub has not been updated. I use MBR.

That is an old post, I should have edited that first line, but I did post later that this is now a Stable update.
I also updated the first post in the topic. But I apologize for the confusion.

It seems you may have missed the bold sentence above too.

Please disable the MX Test Repo, you should never really have this manually enabled anyway.

After you disable the MX Test Repo, please check for updates using MX Updater in the panel.
If you don't see it still, it may mean that the repository mirror you are using has not sync'd for updates.
It shouldn't take more than a day or two at most.

Posted: **Fri Aug 07, 2020 4:45 pm**

arjaybe wrote: Fri Aug 07, 2020 3:23 pm
fehlix wrote: Fri Aug 07, 2020 3:05 pm
arjaybe wrote: Fri Aug 07, 2020 2:47 pm After installing the update I was unable to boot. I got a grub rescue prompt.

I booted a live USB and selected grub from the boot menu, then selected the current bootloader and was up. I ran grub repair which completed successfully, but reboot brought me to grub rescue. Next time I ran grub customizer -- same result.

Even though the fixes seem to work, they don't. Any suggestions?
First question to ask, is UEFI or or legacy/MBR booting?
Legacy. Also, during the grub update I chose to replace a file, but when I checked the differences, it was a blank.

OK, not sure why it was not working for you in the way it was intended.
But anyway, here a manual way to get it refreshed.
Frist do boot into the installed system e.g. using LiveUSB -> boot rescue -> grub menu
Within the booted install system open a terminal (as normal user)
First let's clear all grub related stuff from the command line, including grub-customizer:

Code: Select all

sudo apt purge "grub*"

It will remove quite some stuff, don't worry we reinstall again.
Now remove any remainng "debris" including GRUB-customizer changes:

Code: Select all

sudo rm /etc/default/grub*
sudo rm -r /etc/grub.d

Now let's re-install:

Code: Select all

 sudo apt install grub-common grub-efi-amd64-bin grub-efi-ia32-bin grub-pc grub-pc-bin  grub-themes-mx grub2-common   os-prober mx-apps mx-bootrepair mx-installer

( ignore the message : cannot stat '/etc/default/grub_preinst_grub-pc' )
It will mainly ask to select the GRUB Device to install the grub-loader onto, e.g. choose sda or sdb, in doubt choose all.
Now, we reapply MX-theming:

Code: Select all

sudo cp  /usr/local/share/live-files/general-files/etc/default/grub  /etc/default/grub

and get back the menuentry for memtest:

Code: Select all

sudo cp -vi  /usr/local/share/live-files/files/etc/grub.d/20_memtest86+ /etc/grub.d/20_memtest86+

OK, let's re-generate the grub-menu again:

Code: Select all

sudo update-grub

Now reboot.

Posted: **Fri Aug 07, 2020 6:07 pm**

I got grub-rescue again. Was able to use live USB and grub menu, which found the new grub installation and got me here.

I've been telling it to install to the root directory. Should I try the MBR?

edit: I ran boot repair again and sent grub to the MBR. It works.

Posted: **Fri Aug 07, 2020 7:31 pm**

arjaybe wrote: Fri Aug 07, 2020 6:07 pm I got grub-rescue again. Was able to use live USB and grub menu, which found the new grub installation and got me here.

I've been telling it to install to the root directory. Should I try the MBR?

edit: I ran boot repair again and sent grub to the MBR. It works.

Yes, legacy GRUB-loader needs to get installed into MBR of the drive in order to boot from that bootloader straight from BIOS. The PBR (Partition Boot Record) of the root-partition is only needed/useful if you want to "chainload" from another bootloader.

Posted: **Sat Aug 08, 2020 1:00 am**

I must be confused about what I have then, because I've been Installing grub my root partition for ages.

Posted: **Sat Aug 08, 2020 6:51 am**

arjaybe wrote: Sat Aug 08, 2020 1:00 am I must be confused about what I have then, because I've been Installing grub my root partition for ages.

GRUB does not change very often. So you simply had luck, that the exiting embedded grub-bootloader on the MBR was still funtioning. This time we released a newer version, which is binary incompatible to any previous version. The embedded core-loader from the MBR still needs to load some modules from /boot/grub/i386-pc . And this time those newer modules to load failed and you ended up at the grub-prompt.

Posted: **Sat Aug 08, 2020 10:45 am**

fehlix wrote: Sat Aug 08, 2020 6:51 am
arjaybe wrote: Sat Aug 08, 2020 1:00 am I must be confused about what I have then, because I've been Installing grub my root partition for ages.
GRUB does not change very often. So you simply had luck, that the exiting embedded grub-bootloader on the MBR was still funtioning. This time we released a newer version, which is binary incompatible to any previous version. The embedded core-loader from the MBR still needs to load some modules from /boot/grub/i386-pc . And this time those newer modules to load failed and you ended up at the grub-prompt.

I seem to be in the same boat (on another computer, MX19). During updates yesterday I was surprised to be offered some choice re grub, I chose boot partition, then continued using computer. Maybe I should have come on here and gotten advice before I proceeded?
On re-booting today I get the "grub rescue" prompt.
It's legacy, 64bit, HP. I usually boot in to systemd.

I don't understand a word of the above. What is MBR? I'm not criticizing, I am just not a developer, I enjoy using MX and have offered some help where I was competent to do so.
How do I get back to booting up? I still have the live usb if I need it.
Thanks.

edit: the message I get is

"GRUB loading.
Welcome to GRUB!

error: symbol 'grub_calloc' not found.
grub rescue> "

Posted: **Sat Aug 08, 2020 12:00 pm**

LinnitXa wrote: Sat Aug 08, 2020 10:45 am
fehlix wrote: Sat Aug 08, 2020 6:51 am
arjaybe wrote: Sat Aug 08, 2020 1:00 am I must be confused about what I have then, because I've been Installing grub my root partition for ages.
GRUB does not change very often. So you simply had luck, that the exiting embedded grub-bootloader on the MBR was still funtioning. This time we released a newer version, which is binary incompatible to any previous version. The embedded core-loader from the MBR still needs to load some modules from /boot/grub/i386-pc . And this time those newer modules to load failed and you ended up at the grub-prompt.
I seem to be in the same boat (on another computer, MX19). During updates yesterday I was surprised to be offered some choice re grub, I chose boot partition, then continued using computer. Maybe I should have come on here and gotten advice before I proceeded?
On re-booting today I get the "grub rescue" prompt.
It's legacy, 64bit, HP. I usually boot in to systemd.

I don't understand a word of the above. What is MBR? I'm not criticizing, I am just not a developer, I enjoy using MX and have offered some help where I was competent to do so.
How do I get back to booting up? I still have the live usb if I need it.
Thanks.

edit: the message I get is

"GRUB loading.
Welcome to GRUB!

error: symbol 'grub_calloc' not found.
grub rescue> "

Boot the live USB, run tools - boot repair and choose MBR.

Posted: **Sat Aug 08, 2020 1:51 pm**

arjaybe wrote: Sat Aug 08, 2020 12:00 pm
LinnitXa wrote: Sat Aug 08, 2020 10:45 am
fehlix wrote: Sat Aug 08, 2020 6:51 am
GRUB does not change very often. So you simply had luck, that the exiting embedded grub-bootloader on the MBR was still funtioning. This time we released a newer version, which is binary incompatible to any previous version. The embedded core-loader from the MBR still needs to load some modules from /boot/grub/i386-pc . And this time those newer modules to load failed and you ended up at the grub-prompt.
I seem to be in the same boat (on another computer, MX19). During updates yesterday I was surprised to be offered some choice re grub, I chose boot partition, then continued using computer. Maybe I should have come on here and gotten advice before I proceeded?
On re-booting today I get the "grub rescue" prompt.
It's legacy, 64bit, HP. I usually boot in to systemd.

I don't understand a word of the above. What is MBR? I'm not criticizing, I am just not a developer, I enjoy using MX and have offered some help where I was competent to do so.
How do I get back to booting up? I still have the live usb if I need it.
Thanks.

edit: the message I get is

"GRUB loading.
Welcome to GRUB!

error: symbol 'grub_calloc' not found.
grub rescue> "
Boot the live USB, run tools - boot repair and choose MBR.

Thanks.
Ok, I'm at MX Boot Repair window - 4 options - do I choose "Restore MBR or PBR from backup (legacy boot only)"?

Posted: **Sat Aug 08, 2020 1:58 pm**

LinnitXa wrote: Sat Aug 08, 2020 1:51 pm
arjaybe wrote: Sat Aug 08, 2020 12:00 pm
LinnitXa wrote: Sat Aug 08, 2020 10:45 am

I seem to be in the same boat (on another computer, MX19). During updates yesterday I was surprised to be offered some choice re grub, I chose boot partition, then continued using computer. Maybe I should have come on here and gotten advice before I proceeded?
On re-booting today I get the "grub rescue" prompt.
It's legacy, 64bit, HP. I usually boot in to systemd.

I don't understand a word of the above. What is MBR? I'm not criticizing, I am just not a developer, I enjoy using MX and have offered some help where I was competent to do so.
How do I get back to booting up? I still have the live usb if I need it.
Thanks.

edit: the message I get is

"GRUB loading.
Welcome to GRUB!

error: symbol 'grub_calloc' not found.
grub rescue> "
Boot the live USB, run tools - boot repair and choose MBR.
Thanks.
Ok, I'm at MX Boot Repair window - 4 options - do I choose "Restore MBR or PBR from backup (legacy boot only)"?

no, you use the top reinstall option. then on the next screen make sure mbr is selected and the target drive is correct.

Posted: **Sat Aug 08, 2020 2:14 pm**

Ok, I've done that

Install on: MBR
Location: sda 298.1G Hitachi-etc (the only other option the live usb)
select root location: sda1 512M ext4 boot (the other options sda2 276G crypto_LUKS ; SDA3 2G crypto_LUKS - those are the FDE and the swap; also liveISO and EFI-Live)

and got
Error Could not set up chroot environment. please double-check the selected location

Thanks for your help again, I'm hoping not to wreck things.

Posted: **Sat Aug 08, 2020 2:21 pm**

if you can boot into the system with the grub rescue menu, it may make more sense to try the grub reinstall from there.

Posted: **Sat Aug 08, 2020 2:31 pm**

dolphin_oracle wrote: Sat Aug 08, 2020 2:21 pm if you can boot into the system with the grub rescue menu, it may make more sense to try the grub reinstall from there.

Well, what is the rescue menu? I didn't see that. And how do I re-install grub from there?

(I searched for grub; grub reinstall; reinstall in the manual..)

Posted: **Sat Aug 08, 2020 2:34 pm**

when you boot a live-usb, there should be a choice to use grub and then grub rescue menus. it will scan your drive looking for grub setups it can boot.

Posted: **Sat Aug 08, 2020 2:58 pm**

dolphin_oracle wrote: Sat Aug 08, 2020 2:34 pm when you boot a live-usb, there should be a choice to use grub and then grub rescue menus. it will scan your drive looking for grub setups it can boot.

ok, that worked up to a point, I found Boot rescue menues > searched > found a boot grub loader @HD1.MSDOS1) boot
I selected it and enter and it brought me straight to my FDE password window, logged in all ok.
But - to test if it was fixed I re-booted and the same error message I got originally

"Welcome to GRUB!
error: symbol 'grub_calloc' not found
grub rescue> _ "

Posted: **Sat Aug 08, 2020 3:01 pm**

you would still need to run the boot repair, did you do that?

Posted: **Sat Aug 08, 2020 3:04 pm**

LinnitXa wrote: Sat Aug 08, 2020 2:58 pm
dolphin_oracle wrote: Sat Aug 08, 2020 2:34 pm when you boot a live-usb, there should be a choice to use grub and then grub rescue menus. it will scan your drive looking for grub setups it can boot.
ok, that worked up to a point, I found Boot rescue menues > searched > found a boot grub loader @HD1.MSDOS1) boot
I selected it and enter and it brought me straight to my FDE password window, logged in all ok.
But - to test if it was fixed I re-booted and the same error message I got originally

"Welcome to GRUB!
error: symbol 'grub_calloc' not found
grub rescue> _ "

Once you're in your OS, run the boot repair from there.

Posted: **Sat Aug 08, 2020 3:20 pm**

You can actually repair grub either from within the booted encrypted install, booting via LiveUSB Rescue Menus.
Or alternativeyl run MX Boot Repair from the LiveUSB directly.
The trick when you run from LiveUSB, you need to select the encrypted root as root location (e.g. sda2) not boot (sda1).
The grub target for the MBR would be the drive sda.
You will be asked to enter the Luks-encryption password:

MXBR1.png

MXBR2_root_enc.png

MXBR2_root_enc2.png

MXBR2_root_enc3.png

Posted: **Sat Aug 08, 2020 3:33 pm**

dolphin_oracle wrote: Sat Aug 08, 2020 3:01 pm you would still need to run the boot repair, did you do that?

I've done that now and this time it worked, using the same locations. I've tested with a re-boot and all is fine now on that pc.

Now - this pc I'm typing on has 40 updates pending - if I get that window again re grub options, what should I choose? I hope to avoid all this fixing, but I am grateful for the very prompt help I've had today.

But if the window with the grub choices could be done more clearly, perhaps not in the middle of 40 updates, with more info for the less expert users like me, it would be better.

Posted: **Sat Aug 08, 2020 3:40 pm**

arjaybe - thanks, got that!

fehlix - great, I've taken screenshot of that, as well as Dolphin's soluttions.

Posted: **Sat Aug 08, 2020 4:00 pm**

LinnitXa wrote: Sat Aug 08, 2020 3:33 pm if I get that window again re grub options, what should I choose?

You choose as the GRUB-Device target to install the GRUB-loader onto the boot-drive: In your case sda.
With this the grub-bootloader gets installed into the MBR (Master Boot Record) of the drive/device sda
BIOS can only boot from the MBR of a drive, not from a PBR (Partition Boot Record) of a partition.
See this:
grub upgrade:
Grub Device selection:

grub-upgrade-GRUB-installe-devices.png

which comes with a help on mouse hoover and help-button:

grub-upgrade-GRUB-installe-devices-HELP.png

you select the full boot drive. not any partition

grub-upgrade-GRUB-installe-devices-to-SDA-MBR.png

Posted: **Sat Aug 08, 2020 4:37 pm**

Thanks fehlix, I'll use that.

Posted: **Sat Aug 08, 2020 7:34 pm**

fehlix wrote: Sat Aug 08, 2020 3:20 pm You can actually repair grub either from within the booted encrypted install, booting via LiveUSB Rescue Menus.
Or alternativeyl run MX Boot Repair from the LiveUSB directly.
The trick when you run from LiveUSB, you need to select the encrypted root as root location (e.g. sda2) not boot (sda1).
The grub target for the MBR would be the drive sda.
You will be asked to enter the Luks-encryption password:
MXBR1.pngMXBR2_root_enc.pngMXBR2_root_enc2.pngMXBR2_root_enc3.png

That's awesome fehlix, I was looking to do screenshots, but you are the expert on this so the extra info is great for users.

Should we maybe to a HOWTO for that forum section, maybe add this stuff to the wiki?

Posted: **Sat Aug 08, 2020 8:01 pm**

SwampRabbit wrote: Sat Aug 08, 2020 7:34 pm Should we maybe to a HOWTO for that forum section, maybe add this stuff to the wiki?

That would be awesome

Posted: **Sun Aug 09, 2020 7:46 am**

Hello, everyone,

since yesterday i also have the problem, after an update that only boots grub in secure mode.
I have removed everything like on page 5 here... reinstalled everything... and also tried the repair options. nothing helps.
With the MX Boot Repair option Grub reinstalled I get the error

grub-install: Warning: This GPT partition label has no BIOS boot partition, embedding would be impossible.
grub-install: Warning: Embedding is not possible. GRUB can only be installed using blocklists in this configuration. Blocklists are unreliable and their use is not recommended.
installation completed. No errors occurred.

I am desperate here... please help.

Posted: **Sun Aug 09, 2020 8:29 am**

PeterPiper wrote: Sun Aug 09, 2020 7:46 am Hello, everyone,

since yesterday i also have the problem, after an update that only boots grub in secure mode.
I have removed everything like on page 5 here... reinstalled everything... and also tried the repair options. nothing helps.
With the MX Boot Repair option Grub reinstalled I get the error

grub-install: Warning: This GPT partition label has no BIOS boot partition, embedding would be impossible.
grub-install: Warning: Embedding is not possible. GRUB can only be installed using blocklists in this configuration. Blocklists are unreliable and their use is not recommended.
installation completed. No errors occurred.

I am desperate here... please help.

Yes. As stated within the Warning text something is missing. When you originally installed MX Linux in BIOS/legacy mode, you have created all partitions yourself on this GPT drive. But a BIOS/legacy installation performed on a GPT-drive requires an extra small sized bios_grub helper partition. Otherwise GRUB complains utterly. Note, for auto-installation full disk the Installer would have created a non-GPT MBR/BIOS/msdos partion-table disk.
To fix:
Boot from LiveUSB , open Gparted and create a small 1MB sized unformatted (!!) partition on that boot drive. Give it a partition label "bios_grub" and with "Manage flags" mark this partition as "bios_grub" (!!).
Best to create this small bios_grub helper partition as close as possible to the beginning of the disk, just to avoid to have to deal with to big block numbers.
After this is done re-rerun MX Boot Repair.

Posted: **Sun Aug 09, 2020 10:51 am**

Just wanted to add my two cents worth to this discussion to say that out of three laptops I have running MX19 only one of them rebooted correctly following the latest GRUB update. I had a problem with my first attempt on an ACER E15 with just one big drive where I had created a separate boot partition. I may have missed something in the GRUB device selection during the update, but I ended up with the famous "grub_calloc not found".

I managed to use the MX boot repair tool from a live USB I'd created and as there was only one drive I must have chosen the correct place for the Legacy MBR just pointing at the drive and not a partition and it did the trick and now reboots correctly.

On my second laptop a Thinkpad T440P with two drives, forewarned by my experience, I used the boot repair to backup the MBR and noted the drive where it was located, so that during the update I made the correct choice for the GRUB update and it rebooted correctly. However on my third laptop an old X220 Thinkpad, I had all sorts of problems which I think on reflection was due to the fact I had two MBRs on different drives due to the fact that I originally had a big Windows drive, but installed MX-Linux on an m-sata SSD card then when I changed the Windows drive for a bigger one that would give me a bigger home I must have reinstalled using the second MBR. In any case, it took me several attempts using the grub rescue menu from a live USB then trying to manually change the /etc/grub file to use another drive after a grub-update to reconfigure it. This didn't work so I went back to the boot repair tool as this was the only think I had left, and finally ended up choosing the right MBR on the right drive and it at long last finally reboots correctly, but with a different coloured boot screen - don't know how that happened - but it was not an easy experience for someone who is far from expert in these matters, but I've probably installed MX-Linux on nearly a dozen different machines with never such complications.
Wouldn't it be useful to post some specific HOWTO on this update as it seems to have caused a fair few headaches for other less knowledgeable users like myself.

Posted: **Sun Aug 09, 2020 10:59 am**

... In fact, basically, I think than the grub installer should check the configuration of the computer before doing or asking something, and propose to the user the most pertinent options to install or update grub into his system.

Posted: **Sun Aug 09, 2020 11:11 am**

Thank you for your experience and feedback.

agrendel wrote: Sun Aug 09, 2020 10:51 am Wouldn't it be useful to post some specific HOWTO on this update as it seems to have caused a fair few headaches for other less knowledgeable users like myself.

Yes, this has already been discussed. If you look above a few posts in this thread, screenshots were taken, and the whole thread includes a ton of information to help users.

This is GRUB, it is going to be different for almost every system out there. The beauty and flexibility of GRUB is also sometimes a pain. I believe we have gone to great extents so far to reduce issues as best we can.

Anyone is free to create a HOWTO on the numerous items related to updating GRUB under all the different circumstances to help users.
Right now a lot of us (MX dev team) are very very busy (like most people in general), but like discussed above, a "HOWTO" and or maybe basic GRUB info for users has been discussed already. This is FOSS and 100% volunteer work after all.

Posted: **Sun Aug 09, 2020 11:13 am**

oops wrote: Sun Aug 09, 2020 10:59 am ... In fact, basically, I think than the grub installer should check the configuration of the computer before doing or asking something, and propose to the user the most pertinent options to install or update grub into his system.

File a issue/request with the developers of GRUB.

Posted: **Sun Aug 09, 2020 12:31 pm**

They do provide during upgrade help information in multiple languages:
Either click and the help button:

grub-upgrade-help.png

Or move mouse over the line with the choic

grub-upgrade-mouse-on-hoover-help.png

In text:

Grub Upgrade Help wrote:The grub-pc package is being upgraded. This menu allows you to select
which devices you'd like grub-install to be automatically run for, if
any.

Running grub-install automatically is recommended in most situations,
to prevent the installed GRUB core image from getting out of sync with
GRUB modules or grub.cfg.

If you're unsure which drive is designated as boot drive by your BIOS,
it is often a good idea to install GRUB to all of them.

Note: it is possible to install GRUB to
partition boot records as well, and some appropriate partitions are
offered here. However, this forces GRUB to use the blocklist mechanism,
which makes it less reliable, and therefore is not recommended.

The main important information:

If you're unsure which drive is designated as boot drive by your BIOS,
it is often a good idea to install GRUB to all of them.

User do simply ignore given help. Not sure what we can do about it.

Posted: **Sun Aug 09, 2020 1:23 pm**

Hey fehlix, thanks for the quick answer.
I have an ESP partition, strangely enough it is formatted on Fat32. Boot Rescue can't handle this. Do you think I should reformat the ESP partition (ext4?) and install Grub there?
I can't remember where I put Grub during the installation. :(

this entry found in grub.cfg

Code: Select all

set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2

And thanks for your support. I realize that you probably have other things to do. So... thanks a lot for the support

User do simply ignore given help. Not sure what we can do about it.

i try this 2 .. but what should i do.. nothing works ...

Posted: **Sun Aug 09, 2020 1:40 pm**

PeterPiper wrote: Sun Aug 09, 2020 1:23 pm Hey fehlix, thanks for the quick answer.
I have an ESP partition, strangely enough it is formatted on Fat32. Boot Rescue can't handle this. Do you think I should reformat the ESP partition (ext4?) and install Grub there?
I can't remember where I put Grub during the installation. :(

this entry found in grub.cfg
Code: Select all
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
And thanks for your support. I realize that you probably have other things to do. So... thanks a lot for the support

User do simply ignore given help. Not sure what we can do about it.
i try this 2 .. but what should i do.. nothing works ...

the ESP should be fat32

Posted: **Sun Aug 09, 2020 1:44 pm**

PeterPiper wrote: Sun Aug 09, 2020 1:23 pm Hey fehlix, thanks for the quick answer.
I have an ESP partition, strangely enough it is formatted on Fat32. Boot Rescue can't handle this. Do you think I should reformat the ESP partition (ext4?) and install Grub there?
I can't remember where I put Grub during the installation. :(

this entry found in grub.cfg
Code: Select all
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
And thanks for your support. I realize that you probably have other things to do. So... thanks a lot for the support

User do simply ignore given help. Not sure what we can do about it.
i try this 2 .. but what should i do.. nothing works ...

The first question to clarify. Do you actually boot in BIOS/MBR or UEFI mode. If you perefer to boot in bios mode,
do this: Shrink the boot partition with Gparted (from the right side and from booted LiveUSB) by about 2-3 MB and within that empty space create a 1MB sized unformatted bios_grub partition as describe earlier.

Posted: **Sun Aug 09, 2020 1:58 pm**

this command

Code: Select all

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

answerd with

Code: Select all

UEFI

I will try again tomorrow to fix the problem. I have a Live Systen on USB and will try to fix it then. Many thanks to you

Posted: **Sun Aug 09, 2020 2:13 pm**

SwampRabbit wrote: Sun Aug 09, 2020 11:13 am
oops wrote: Sun Aug 09, 2020 10:59 am ... In fact, basically, I think than the grub installer should check the configuration of the computer before doing or asking something, and propose to the user the most pertinent options to install or update grub into his system.
File a issue/request with the developers of GRUB.

... Yes, it will be the most efficient thing to do.

Posted: **Sun Aug 09, 2020 2:30 pm**

PeterPiper wrote: Sun Aug 09, 2020 1:58 pm this command
Code: Select all
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
answerd with
Code: Select all
UEFI
I will try again tomorrow to fix the problem. I have a Live Systen on USB and will try to fix it then. Many thanks to you

If you boot in UEFI, the grub-upgrade normaly would not ask to install to MBR. So I wonder why you would have seen the GRUB Device install window, which is only usefull for MBR/BIOS grub-install. The only reason I can think of might be, grub-upgrade detected an MBR-installation at the boot drive.
The UEFI grub loader wont be overwritten by grub update. But you can still run MX Boot Repair, to recreate the EFI-grub-loader and for UEFI you would need to select ESP to re-install the EFI-grub loader, not the MBR.

Posted: **Sun Aug 09, 2020 3:38 pm**

Thank you, MX devs!!

Posted: **Sun Aug 09, 2020 4:33 pm**

oops wrote: Sun Aug 09, 2020 2:13 pm ... Yes, it will be the most efficient thing to do.

It’s not that it’s the “most efficient”... it’s that it’s the only thing to do. I don’t think we’ll be forking GRUB any time soon. Like fehlix has pointed out, GRUB doesn’t leave you having out to dry with no info or help. And if a user needs more help, all they have to do is ask.

Another thing to understand is right now other distros are having much worse times with GRUB than we are. I think we are very lucky right now.

Posted: **Sun Aug 09, 2020 4:42 pm**

SwampRabbit wrote: Sun Aug 09, 2020 4:33 pm It’s not that it’s the “most efficient”... it’s that it’s the only thing to do. I don’t think we’ll be forking GRUB any time soon. Like fehlix has pointed out, GRUB doesn’t leave you having out to dry with no info or help. And if a user needs more help, all they have to do is ask.

Another thing to understand is right now other distros are having much worse times with GRUB than we are. I think we are very lucky right now.

... In my mind, I said the "most efficient thing to do" for all distribs and all support of distribs, not only for MX.

Posted: **Sun Aug 09, 2020 4:58 pm**

After the upgrade and reboot I got nothing but a blinking cursor in the upper left of a black screen. But I knew what to do. I rebooted with LiveUSB and ran MX Boot Repair. Then I shutdown, removed the USB key drive and rebooted using my F12 key to choose my boot disk in Legacy mode. The Grub came up and I booted into MX.

But I think the problem is that many people do not understand how a computer boots. They don't understand BIOS/MBR, UEFI, GPT, ESP, MX Boot Repair, etc. It's all very complex if you are not a techie user.

Is there a way to "postpone" the upgrade of grub when using the MX Updater icon? I know you can abort if you know what your are looking for. But if you just launch the upgrade and then get to the Grub upgrade screen from Debian and Grub can there be a choice to put it off? Skip it until you are ready? Then the user can come here and ask questions and read up on how to proceed with the Grub upgrade, partition to choose, how to recover using MX Boot Repair, etc. Now armed with this information they can re-launch the upgrade and when they get to the Grub screen they can proceed.

Seaken64

Posted: **Sun Aug 09, 2020 5:48 pm**

I don’t think that’s possible right now with just MX Updater, it’s be different if they were updating via MX Package Installer it Synaptic though.

One thing to understand is Debian already pushed a update for the stock version of GRUB that comes with Debian Buster, ours is actually newer. So there is no way to really avoid it unless you update manually.

Remember this is all because of a vulnerability in GRUB, although very limited in being exploited. Damned if we do, damned if we don’t. We made sure to minimize issues as much as possible. In time this GRUB updating issue will pass until the next one.

Posted: **Sun Aug 09, 2020 6:05 pm**

seaken64 wrote: Sun Aug 09, 2020 4:58 pm Is there a way to "postpone" the upgrade of grub when using the MX Updater icon?

Just press n, when you get asked to confirm to install.
And if you get the grub-upgrade popup for the GRUB-upgrade, do read the help text, and in doubt which boot drive to select, do select all drives.

Posted: **Sun Aug 09, 2020 9:45 pm**

Hi guys,

I don't know if this is exactly germane to the discussion you're looking for, but here goes. The update here went fine, on MX 19 with KDE. But my heart sank when I saw the dialog, because I thought of the friends and customers I had installed MX for, and how not one of them would have a clue what to do with it. I wish there could be an option to leave the configuration as it is, and that it would be set as the default, with a note saying leave it there if you don't understand what the dialog is about. I don't know if that's feasible, or if the MX team even has input into that dialog, but those are my thoughts on it.

Be well,
Paul

Posted: **Mon Aug 10, 2020 6:35 am**

paul1149 wrote: Sun Aug 09, 2020 9:45 pm Hi guys,

I don't know if this is exactly germane to the discussion you're looking for, but here goes. The update here went fine, on MX 19 with KDE. But my heart sank when I saw the dialog, because I thought of the friends and customers I had installed MX for, and how not one of them would have a clue what to do with it. I wish there could be an option to leave the configuration as it is, and that it would be set as the default, with a note saying leave it there if you don't understand what the dialog is about. I don't know if that's feasible, or if the MX team even has input into that dialog, but those are my thoughts on it.

Be well,
Paul

This popup-dialog is part of the grub package. And yes, user can decide not generate and install a new grub-loader. If they click on "Next", without selecting the boot device, the have to confirm:

grub-continue-without-installing-bios.png

If you move the mouse over the line you get a nice explanation:

You chose not to install GRUB to any devices. If you continue, the boot
loader may not be properly configured, and when this computer next
starts up it will use whatever was previously in the boot sector. If
there is an earlier version of GRUB 2 in the boot sector, it may be
unable to load modules or handle the current configuration file.

If you are already using a different boot loader and want to carry on
doing so, or if this is a special environment where you do not need a
boot loader, then you should continue anyway. Otherwise, you should
install GRUB somewhere.

FWIW, you can always re-configure the grub-package to get the the popup-dialog, this way:

Code: Select all

sudo dpkg-reconfigure grub-pc

In any case, if something goes wrong, we have three fallbacks:
1: MX Boot Repair
2: boot from LiveUSB -> Switch to Grub Boot Loader -> Boot Rescue Menus -> Find Grub loader /menus
3: from LiveUSB -> Chroot Rescue Scan: To "chroot" into the installed system and run sudo "grub-install /dev/sd[abc]" or alternatively, run as above "sudo dpkg-reconfigure grub-pc"
EDIT: no need for sudo within the chroot on the installed system.

Posted: **Mon Aug 10, 2020 7:12 am**

fehlix wrote: Mon Aug 10, 2020 6:35 am This popup-dialog is part of the grub package.

If you move the mouse over the line you get a nice explanation:
You chose not to install GRUB to any devices. If you continue, the boot
loader may not be properly configured, and when this computer next
starts up it will use whatever was previously in the boot sector. If
there is an earlier version of GRUB 2 in the boot sector, it may be
unable to load modules or handle the current configuration file.

If you are already using a different boot loader and want to carry on
doing so, or if this is a special environment where you do not need a
boot loader, then you should continue anyway. Otherwise, you should
install GRUB somewhere.
FWIW, you can always re-configure the grub-package to get the the popup-dialog, this way:
Code: Select all
sudo dpkg-reconfigure grub-pc 
In any case, if something goes wrong, we have three fallbacks:
1: MX Boot Repair
2: boot from LiveUSB -> Switch to Grub Boot Loader -> Boot Rescue Menus -> Find Grub loader /menus
3: from LiveUSB -> Chroot Rescue Scan: To "chroot" into the installed system and run sudo "grub-install /dev/sd[abc]" or alternatively, run as above "sudo dpkg-reconfigure grub-pc"
EDIT: no need for sudo within the chroot on the installed system.

Thanks, fehlix, I hadn't seen that follow-up screen, as I always made a choice at the initial one.

My philosophy is that things should be as simple as possible, or at least explained as simply as possible. I can guarantee that most if not all of my Linux "children" will have problems with that dialog and would not know to use live media for repair use. Maybe some simple guidance like, "most systems will have Grub installed on the boot sector of the main drive" would be all most would need. But it sounds like this is a grub, not an MX, issue.

Posted: **Mon Aug 10, 2020 7:47 am**

paul1149 wrote: Mon Aug 10, 2020 7:12 am I can guarantee that most if not all of my Linux "children" will have problems with that dialog and would not know to use live media for repair use.

Suggest this: When you hand over MX Linux to someone, just add one little step: Explain/show them those emergency tools, includuding re-run reconfigure of grub. If a user never had seen those tools, they certainly have no idea what todo. And they may be thankful to get self-empowered.

Posted: **Mon Aug 10, 2020 8:46 am**

fehlix wrote: Mon Aug 10, 2020 7:47 am Suggest this: When you hand over MX Linux to someone, just add one little step: Explain/show them those emergency tools, includuding re-run reconfigure of grub. If a user never had seen those tools, they certainly have no idea what todo. And they may be thankful to get self-empowered.

That's a good idea. But many units don't have optical drives these days, and I'm not going to spring for a usb stick for each machine. I probably will ask them to supply one from now on. It's good that people increase their skills and ability to deal with problems, but there is always going to be a large segment of the population that has no interest, aptitude, or time to do so. MS made a fortune catering to those people by making decisions for them, but took it too far, into the realm of self-serving control and manipulation. I would like to see Linux be more accessible to that crowd, without, of course, going anywhere near MS behavior.

Posted: **Mon Aug 10, 2020 9:36 am**

Just some feedback. I installed the new update and later rebooted. I was put in the grub screen. I did not panic tho I live cd the boot repair and alls well. Thanks anyways for this thread even if I forgot about the boot repair I would have been reminded by searching simply grub, and checking the newest entry. I guess I made the mistake by selecting sda1 instead of just sda. Or just both as the update indicated if unsure pick all. haha. oh well no worries.

Posted: **Mon Aug 10, 2020 9:51 am**

tonyB wrote: Mon Aug 10, 2020 9:36 am Just some feedback. I installed the new update and later rebooted. I was put in the grub screen. I did not panic tho I live cd the boot repair and alls well. Thanks anyways for this thread even if I forgot about the boot repair I would have been reminded by searching simply grub, and checking the newest entry. I guess I made the mistake by selecting sda1 instead of just sda. Or just both as the update indicated if unsure pick all. haha. oh well no worries.

Thank you tonyB, I'm glad you got it ironed out in the end.

No other issues since booting with the new GRUB?

Posted: **Mon Aug 10, 2020 9:59 am**

So far so good but I will let you know if anything comes up

Posted: **Mon Aug 10, 2020 10:10 am**

tonyB wrote: Mon Aug 10, 2020 9:36 am Just some feedback. I installed the new update and later rebooted. I was put in the grub screen. I did not panic tho I live cd the boot repair and alls well. Thanks anyways for this thread even if I forgot about the boot repair I would have been reminded by searching simply grub, and checking the newest entry. I guess I made the mistake by selecting sda1 instead of just sda. Or just both as the update indicated if unsure pick all. haha. oh well no worries.

Yes, the help text meant, if unsure pick all boot-drives, e.g. sda, sdb, not partitions sda1 etc.

Posted: **Mon Aug 10, 2020 1:01 pm**

fehlix wrote: Mon Aug 10, 2020 10:10 am ...Yes, the help text meant, if unsure pick all boot-drives, e.g. sda, sdb, not partitions sda1 etc.

lol ... my preferred way would be:
If you are sure, unpick the no related items or No to postpone the grub upgrade ;-)

Posted: **Tue Aug 18, 2020 3:42 pm**

sry for my late response..

its run now.. but i dont know why!

my last step.. i try to repair again.. with boot repair options .. and its works.

i use MBR and choose the ESP Partition(fat32)... i dont know why... i try before all options. But its run now perfectly.. :lipsrsealed:

Thx for help and the Developers !

Posted: **Tue Sep 29, 2020 8:02 am**

Hello
Sorry for reopening this, but I have been looking for several days and I can not find the solution to this error .. my additional problem is that I cannot create a USBLive, since I am stranded in a city and without the possibility of buying a pendrive, with just say that only a few days ago I managed to get internet to update the system and now I find this error.
I would appreciate if someone can tell me the steps to solve it from the boot menu.
From already thank you very much. Greetings

Posted: **Tue Sep 29, 2020 8:11 am**

@ Hessed: It's not so clear about which error you are talking, but I suppose it's "grub_calloc not found".
What do you see in the boot menu? Do you get a 'grub rescue' prompt?

Would it somehow be possible to write a bootable CD? Or maybe an SD card?

Posted: **Tue Sep 29, 2020 9:30 am**

Yes, sorry about that.. I was referring precisely to that error.

I attach an image of i get:

https://i.imgur.com/TrmZl17.jpg

And not, unfortunately I cant make a bootable cd either.

Mod note: image changed to link, please read the forum rules.

Posted: **Tue Sep 29, 2020 9:31 am**

Or a bootable SD card?
Apparently the normal method to get out of grub rescue doesn't work with a grub_calloc error: https://www.reddit.com/r/mynodebtc/comm ... rub_error/

Posted: **Tue Sep 29, 2020 11:01 am**

tony37 wrote: Tue Sep 29, 2020 9:31 am Or a bootable SD card?
Apparently the normal method to get out of grub rescue doesn't work with a grub_calloc error: https://www.reddit.com/r/mynodebtc/comm ... rub_error/

The "grub_calloc error" indicates a mismatch of the installed grub modules and the used grub-bootloader from the MBR. This can happen during grub-package upgrade where the grub-loader was not properly installed, perhaps by not selecting the MBR of the boot drive. The way to fix is with booting into a LiveMedia e.g. with MX Linux, and run MX Boot Repair. Another method: In case another OS is installed: If e.g. WinOS is installed, one could install Grub2Win within WinOS and let Grub2win generate a boot-menu entry for the install MX Linux system.
If another Linux is installed one could "chroot" into MX Linux and repair grub from within the chrooted system.

Posted: **Tue Sep 29, 2020 11:35 am**

fehlix wrote: Tue Sep 29, 2020 11:01 am If another Linux is installed one could "chroot" into MX Linux and repair grub from within the chrooted system.

How could you get there if your Grub is busted? Bios menu?
Ideal would be if Hessed could get into his system using some arcane commands in the grub rescue prompt but the normal procedure using 'set root', 'set prefix', 'insmod normal' doesn't seem to work with grub_calloc errors

Posted: **Tue Sep 29, 2020 12:03 pm**

tony37 wrote: Tue Sep 29, 2020 11:35 am
fehlix wrote: Tue Sep 29, 2020 11:01 am If another Linux is installed one could "chroot" into MX Linux and repair grub from within the chrooted system.
How could you get there if your Grub is busted? Bios menu?
Ideal would be if Hessed could get into his system using some arcane commands in the grub rescue prompt but the normal procedure using 'set root', 'set prefix', 'insmod normal' doesn't seem to work with grub_calloc errors

Indeed if that's a BIOS/MBR booting system with only one MBR/Drive, it might not straight forward to repair without a liveMedia or another PC.

Posted: **Tue Sep 29, 2020 12:29 pm**

@ Hessed: A final option may be to try to boot your pc from your smartphone (I suppose you're using that now to have internet). There is an app for this called DriveDroid: https://beebom.com/how-to-boot-linux-on ... oid-phone/
I never used it but I'll test it and see how it works. But I already see you need root access to your Android, which doesn't seem to be so easy and you can also lose your smartphone warranty, so I'm not sure I can recommend this to you.

Posted: **Thu Oct 01, 2020 1:00 pm**

Hi again.. I managed to get a pendrive, and burn an iso of MX .. how should I proceed now?

Posted: **Thu Oct 01, 2020 3:43 pm**

Hessed_Elohim wrote: Thu Oct 01, 2020 1:00 pm Hi again.. I managed to get a pendrive, and burn an iso of MX .. how should I proceed now?

First try to boot from the USBstick.
Next, try MX Boot Repair.
If that does not help, reboot again an on the LiveUSB Boot menu, navigate to Boot Rescue menu, and try to found Grub.cfg menus. To boot into the system.
And re-run MX Boot Repair from the booted system.
If that still does no help, post "MX Quick System Info" and someone will find a clue to get it sorted.

Posted: **Fri Oct 02, 2020 9:13 am**

news.. I did not get the grub to detect the OS

but as I already had the LiveUSB of the MX19.2 (18 was installed) I decided to do a bckup and start from scratch.
thank you all very much for your contributions and comments.
Regards

MX Linux Forum

MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+1

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+1

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+1

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+1

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+1

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+1

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+1

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+1

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+1

Re: PAUSED - REQUEST FOR TESTING: GRUB 2.04-9~mx19+1

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: PAUSED - REQUEST FOR TESTING: GRUB 2.04-9~mx19+1

Re: PAUSED - REQUEST FOR TESTING: GRUB 2.04-9~mx19+1

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update

Re: MX-19: FEEDBACK of latest GRUB 2.04-9~mx19+5 update