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

[i_ri]

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  

[i_ri]

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  

[SwampRabbit]

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

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!

[SwampRabbit]

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.

[dolphin_oracle]

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.

[fehlix]

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.

[dolphin_oracle]

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.

[fehlix]

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.

[dolphin_oracle]

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.

[i_ri]

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