Page 3 of 11
Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5
Posted: Thu Aug 06, 2020 3:36 am
by 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
Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5
Posted: Thu Aug 06, 2020 7:50 am
by 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
Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5
Posted: Thu Aug 06, 2020 9:41 am
by SwampRabbit
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!
Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5
Posted: Thu Aug 06, 2020 9:42 am
by SwampRabbit
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.
Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5
Posted: Thu Aug 06, 2020 11:22 am
by dolphin_oracle
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.
Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5
Posted: Thu Aug 06, 2020 11:58 am
by fehlix
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.
Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5
Posted: Thu Aug 06, 2020 12:01 pm
by dolphin_oracle
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.
Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5
Posted: Thu Aug 06, 2020 12:22 pm
by fehlix
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.
Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5
Posted: Thu Aug 06, 2020 1:11 pm
by dolphin_oracle
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.
Re: REQUEST FOR TESTING: GRUB 2.04-9~mx19+5
Posted: Thu Aug 06, 2020 6:02 pm
by 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