I find there to be some inconsistencies with the results of
"update-grub2"
But curiously the systemrescuecd entry does not show in the boot menu
and the boot messages (text) is still in low res vga eg: large full
screen.
\
I have had these effects come and go when booting different partitions -
MGA 6 MGA 7 MGA 8-
I have gained them and then lost them again
I am still considering installing just Mageia 6 and Mageia 8 so the situation isn't critical. It's one of ancillary consideration that crop
up when messing around
And I can't understand what the inconstancy is. I suspect that I am
missing something
I have the systemrescuecd installed in a separate partition and the menu entry is in /etc/grub.d
And I can't understand what the inconstancy is. I suspect that I am
missing something
On Tue, 11 May 2021 22:21:01 -0400, faeychild <faeychild@nomail.afraid.org> wrote:
I have the systemrescuecd installed in a separate partition and the menu
entry is in /etc/grub.d
And I can't understand what the inconstancy is. I suspect that I am
missing something
Is the partition with the systemrescuecd always mounted when update-grub is run?
On Wed, 12 May 2021 01:27:20 -0400, David W. Hodgins wrote:
On Tue, 11 May 2021 22:21:01 -0400, faeychild <faeychild@nomail.afraid.org> wrote:
I have the systemrescuecd installed in a separate partition and the menu >>> entry is in /etc/grub.d
And I can't understand what the inconstancy is. I suspect that I am
missing something
Is the partition with the systemrescuecd always mounted when update-grub is run?
I am curious as to why that would matter.
update-grub looks through the partition table, mounts unmounted partitions then looks for OS images to boot. That partition umount is what causes update-grub to take a long time to complete.
On Tue, 11 May 2021 22:21:01 -0400, faeychild
<faeychild@nomail.afraid.org> wrote:
I have the systemrescuecd installed in a separate partition and the menu
entry is in /etc/grub.d
And I can't understand what the inconstancy is. I suspect that I am
missing something
Is the partition with the systemrescuecd always mounted when update-grub
is run?
Unless you are making changes or system hardware is intermittent
your update-grub2 should be consistent.
If you are booting different installs and running update-grub2
then I would expect different results because /etc/default/grub and /etc/grub.d/* do not contain the same contents.
I do not boot UEFI. I boot cms/legacy os. As a result I pick an install
to be the "Production" boot. As a result that is the booted install where
I run update-grub2 then grub2-install.
On 12/5/21 1:15 pm, Bit Twister wrote:
Unless you are making changes or system hardware is intermittent
your update-grub2 should be consistent.
If you are booting different installs and running update-grub2
then I would expect different results because /etc/default/grub and
/etc/grub.d/* do not contain the same contents.
Ummm Yes grub.d contains add on modules if I understand it
/default/grub is basic template, it seems
I do not boot UEFI. I boot cms/legacy os. As a result I pick an install
to be the "Production" boot. As a result that is the booted install where
I run update-grub2 then grub2-install.
I haven't run grub2-install.
I did run update-grub2 from the Mageia 6 partition and it picked up the resolution change. The sysemrscuecd entry though doesn't exist in Mageai 6
Running update-grub2 from Mageia 8 does not pick up the resolution
change nor the systemrescue entry. It seems to be impervious to modification
I will put in grub.d later today, see what happens
Boot mga8. Make make your /etc/default/grub and etc/grub.d changes
in the mga8 install. Run update-grub2 to create /boot/grub2/grub.cfg
you then have to run install-grub to have it boot using the mga8 /boot/grub2/grub.cfg
On 13/5/21 8:28 am, Bit Twister wrote:
Boot mga8. Make make your /etc/default/grub and etc/grub.d changes
in the mga8 install. Run update-grub2 to create /boot/grub2/grub.cfg
you then have to run install-grub to have it boot using the mga8
/boot/grub2/grub.cfg
I have booted Mageia 8
cat /etc/issue
Mageia release 8 (Official) for x86_64
Kernel 5.10.33-desktop-1.mga8 on an 8-processor x86_64 / \l
[root@unimatrix ~]# cat /etc/default/grub
GRUB_GFXMODE=1920x1080x24
grub2-install
Installing for x86_64-efi platform.
Installation finished. No error reported.
I have booted Mageia 8
cat /etc/issue
Mageia release 8 (Official) for x86_64
Kernel 5.10.33-desktop-1.mga8 on an 8-processor x86_64 / \l
[root@unimatrix ~]# cat /etc/default/grub
GRUB_GFXMODE=1920x1080x24
On one of your boots you indicated small font instead of the
current large font. You would need to copy those from that boot's /etc/default/grub into this boot's /etc/default/grub
and run update-grub2. I will guess there is no requirement to
run grub2-install
********** WARNING *************
The warranty and liability expired as you read this message.
If the following breaks your system, it's yours and you keep both pieces.
To set small font boot info/menu I have
$ grep GRUB_GF /etc/default/grub
GRUB_GFXMODE=1280x1024x32
GRUB_GFXPAYLOAD_LINUX=1280x1024x32
guessing that you need to change x24 to x32 since your
monitor/display is much better than mine.
#**********************************************************
#* You damn sure better have a bootable systenrescue media.
#**********************************************************
dinking with GFXMODE/GRUB_GFXPAYLOAD_LINUX might cause grub2
to abort and leave you with no means of booting anything.
In this kind of situation you would boot the install cd in the
Rescue mode to reinstall the bootloader, pick the old release
That will get a grub menu. You boot the old install, run update-grub
to pick up the new release. Now you can boot the new release and
dink with /etc/default/grub, update-grub, grub-install and try again.
Having a standalone bootable systenrescue media would allow you
to back out your changes that are broke in the event you completely
mess up both old and new install.
The bad news is I do not have the commands to chroot the install
and do the grub update/install.
grub2-install
I am impressed because I thought grub2-install required where the
bootloader was to be installed.
Installing for x86_64-efi platform.
Installation finished. No error reported.
Ok, guessing an efi bootloader does not require you to enter
a location.
The arrangement is very erratic currently
I have the printer and scanner running on MGA6.
I have them running on the test MGA8 partition
I can't get xsane to run on production MGA8
xsane does run on my Mga8. It keeps finding my Logitech webcam as its
choice for the xsane device, but does give my Epson 1660 as an option,
so it works.
On 13/5/21 9:19 pm, Bit Twister wrote:
To set small font boot info/menu I have
$ grep GRUB_GF /etc/default/grub
GRUB_GFXMODE=1280x1024x32
This was all that it used to need to switch to the high res font and now
it doesn't work
guessing that you need to change x24 to x32 since your
monitor/display is much better than mine.
It can be 24 or 32 depending on the installation and that Nvidia driver.
It is not satisfactory
GRUB_GFXPAYLOAD_LINUX=1280x1024x32
dinking with GFXMODE/GRUB_GFXPAYLOAD_LINUX might cause grub2
to abort and leave you with no means of booting anything.
gfxpayload never used to be involved in this palaver
The current systemrescue partition does not work. Once it starts up it complains of not being able to find its own files. This is an old
problem which I think you solved long ago with linking.
I have forgotten what I did
So I think installing systemrescue on a stick, while not as elegant,
is much easier.
I have never actually used a rescue disk. My understanding was that you
run the rescue. Use fdisk to ID the partition. then mount it and cd into
the mount point and away you go. But reinstalling bootloaders and
chrooting is out of my pay grade
The other view is the with the reinstalling taking only a few minutes,
is it worth the time dinking about with rescue disk.
The arrangement is very erratic currently
I have the printer and scanner running on MGA6.
I have them running on the test MGA8 partition
I can't get xsane to run on production MGA8
And along with the the 640x480 size boot font, it's been a
glaring at the monitor and WTF time. :-)
All this could be some interaction with all the grub defaults and
grub.d's on all the partitions. Maybe update-grub is lost down the
rabbit hole because I remember seeing the systemrescue entry in grub.cfg
on the partition I was booting but it would not show on the boot menu.
I could go crazy, reformat everything and install one only
Still
I'll download the new sysrescue iso and rustle up a stick
On Fri, 14 May 2021 09:16:32 +1000, faeychild wrote:
On 13/5/21 9:19 pm, Bit Twister wrote:
To set small font boot info/menu I have
$ grep GRUB_GF /etc/default/grub
GRUB_GFXMODE=1280x1024x32
This was all that it used to need to switch to the high res font and now
it doesn't work
I understand, I have both because I want to to see boot
messages in a small font let alone the menu.
guessing that you need to change x24 to x32 since your
monitor/display is much better than mine.
It can be 24 or 32 depending on the installation and that Nvidia driver.
Ah so I see says the blind man. I am going to guess you have
picked a video setting that requires the Nvidia driver but
it is not installed yet.
You will need to start the grub boot, hit Esc key and have grub
dump resolution values it will use.
I have the printer and scanner running on MGA6.
I have them running on the test MGA8 partition
I can't get xsane to run on production MGA8
Grub should have no impact on xsane.
And along with the the 640x480 size boot font, it's been a
glaring at the monitor and WTF time. :-)
All this could be some interaction with all the grub defaults and
grub.d's on all the partitions. Maybe update-grub is lost down the
rabbit hole because I remember seeing the systemrescue entry in grub.cfg
on the partition I was booting but it would not show on the boot menu.
I could go crazy, reformat everything and install one only
I see no change in using that methodology.
I has to be some problem in the setup.
We have been in this conversation in another thread where I
indicated what I did for setting up my scanner/printer.
Still
I'll download the new sysrescue iso and rustle up a stick
Ok, in the mean time, make a hard copy of your setup.
Boot the Classic Iso dvd. Use the Rescue option and just look
at how it works.
At the which partition to use, you may have to hit the
power/reset button to get loose from the rescue mode
of the Classic DVD.
On 14/5/21 12:53 pm, Bit Twister wrote:
On Fri, 14 May 2021 15:07:53 +1000, faeychild wrote:
On 14/5/21 12:53 pm, Bit Twister wrote:
The Classic iso is the big dvd iso. not one of the live iso.
The monitor resolutions you see after boot are the ones the
Nvidia driver can use based on information pulled from your monitor.
You need to pick a value from the grub command line command vbeinfo
My hindbrain made me finally remember that the /etc/grub.d/ sysresccd
grub script did not use the downloaded iso name. Glancing at
my grub rescue script I see
loopback loop /systemrescuecd.iso
and looking in the directory where systemrescuecd iso is stored
I see
# ls -l systemrescue*
-rw-r--r-- 1 browser browser 751828992 May 12 17:03 systemrescue-8.03-amd64.iso
lrwxrwxrwx 1 root document 27 May 12 17:05 systemrescuecd.iso -> systemrescue-8.03-amd64.iso
That is the link that is needed by my grub.d script.
For burning the rescue cd to a usb thumb drive you need to use the instructions from the https://www.system-rescue.org/Download/ page's Installation on a USB stick or internal disk.
Clicking the USB stickslink gets you to https://www.system-rescue.org/Installing-SystemRescue-on-a-USB-memory-stick/
Checking my faeychild file I notice I do not have what Mageia iso
was used in your Mageia 8 install. The Classic DVD Iso is Mageia-8-x86_64.iso and is the one with the Rescue mode.
On 14/5/21 6:14 pm, Bit Twister wrote:
For burning the rescue cd to a usb thumb drive you need to use the
instructions from the https://www.system-rescue.org/Download/ page's
Installation on a USB stick or internal disk.
Clicking the USB stickslink gets you to
https://www.system-rescue.org/Installing-SystemRescue-on-a-USB-memory-stick/
I'm unaware of that one. I used isodumper to install sysrescuecd on
the USB stick
You are correct. I didn't notice the typo in the signature. It should
read "installed via Mageia-8-x86_64-DVD.iso"
On Fri, 14 May 2021 23:10:18 +1000, faeychild wrote:
You are correct. I didn't notice the typo in the signature. It should
read "installed via Mageia-8-x86_64-DVD.iso"
And is still there on your reply. :)
On 15/5/21 12:29 am, Bit Twister wrote:
FWIW Bits
I changed both entries GFXMODE and GFXPAYLOAD in /etc/default/grub to reflect the smaller text font for the boot menu and the kernel messages
GRUB_CMDLINE_LINUX_DEFAULT="nokmsboot noiswmd resume=UUID=0f26b0d8-adf7-45cf-a963-cc5d89c1a8e4 audit=0 vga=791" GRUB_DEFAULT=saved
GRUB_DISABLE_OS_PROBER=false
GRUB_DISABLE_RECOVERY=false
GRUB_DISABLE_SUBMENU=n
GRUB_DISTRIBUTOR=Mageia
GRUB_ENABLE_CRYPTODISK=y
GRUB_GFXMODE=1920x1080x32
GRUB_GFXPAYLOAD_LINUX=1920x1080x32
GRUB_SAVEDEFAULT=true
GRUB_TERMINAL_OUTPUT=gfxterm
GRUB_THEME=/boot/grub2/themes/maggy/theme.txt
GRUB_TIMEOUT=10
then ran update-gru2 and rebooted
and the text is still large 640x480 type
So.... Clearly the font size is influenced somewhere else.
He He You've gotta love stuff, Bits
One more time. I believe what you are seeing is if grub can not get
the indicated/desired resolution so t will default to 640x480.
You have to use values given by the grub vbeinfo command.
Ignore that you can get more values after you log in.
From the grub command line
vbeinfo does nothing
videoinfo produces
Adapter EFI GOP driver
640 x 480 x 32
800 x 600 32
1024 x 768 x 32
1280 x 1024 x 32
1920 x 1080 x 32
So I changed both GFXMODE and GFXPAYLOAD to 1280x1024x32
and ran update-grub2.
I now have smaller text, still spread across the monitor because the
kerning is large.
So I changed both GFXMODE and GFXPAYLOAD to 1280x1024x32
and ran update-grub2.
I now have smaller text, still spread across the monitor because the
kerning is large.
I would have tried the 1920x1080x32 in that case.
On 16/5/21 8:49 am, Bit Twister wrote:
So I changed both GFXMODE and GFXPAYLOAD to 1280x1024x32
and ran update-grub2.
I now have smaller text, still spread across the monitor because the
kerning is large.
I would have tried the 1920x1080x32 in that case.
That was the res I was running just before the 1280x1024 change over.
I try 1920 again later when I can reboot
I would have tried the 1920x1080x32 in that case.
That was the res I was running just before the 1280x1024 change over.
I try 1920 again later when I can reboot
On 16/5/21 9:16 am, faeychild wrote:
=20
=20=20
I would have tried the 1920x1080x32 in that case.
=20
That was the res I was running just before the 1280x1024 change
over.
=20
I try 1920 again later when I can reboot =20
After having rebooted several times, Bits it is entirely possible
that resolution was never 1920x1080. The current 1280x1024 is
starting to look more and more normal.
=20
Maybe it never was 1920x1080 and I have been gas lighting myself and
it never will achieve the maximum resolution
=20
The assumption made was that the old small text was the maximum=20 resolution
--
faeychild
Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via
Mageia-8-x86_64-DVD.iso
... in it, but I found that this no longer gave me the correct screen resolution — my monitor is 1920 x 1080. So I changed that to...
GRUB_GFXMODE=1920x1080x32
GRUB_GFXPAYLOAD_LINUX=keep
... and ran...
$ sudo update-grub
... and ever since then, I've got an even higher screen resolution in
the boot menu than I originally had when I installed Manjaro, leading
me to suspect that the "auto" setting would have picked something like
1600 x 900 instead of 1920 x 1080.
On Thu, 13 May 2021 07:22:03 +1000, faeychild wrote:
On 12/5/21 1:15 pm, Bit Twister wrote:
Unless you are making changes or system hardware is intermittent
your update-grub2 should be consistent.
If you are booting different installs and running update-grub2
then I would expect different results because /etc/default/grub and
/etc/grub.d/* do not contain the same contents.
Ummm Yes grub.d contains add on modules if I understand it
All install will have grub.d modules.
If you want the same selections in grub.cfg then /etc/default/grub
and /etc/grub.d/ then all installs would need the same contents.
Note I am not talking about your sysrescye install since I have
never done that. I just download the iso and boot it.
/default/grub is basic template, it seems
Each distribution decides its contents.
I do not boot UEFI. I boot cms/legacy os. As a result I pick an install
to be the "Production" boot. As a result that is the booted install where >>> I run update-grub2 then grub2-install.
I haven't run grub2-install.
I did run update-grub2 from the Mageia 6 partition and it picked up the
resolution change. The sysemrscuecd entry though doesn't exist in Mageai 6 >>
Running update-grub2 from Mageia 8 does not pick up the resolution
change nor the systemrescue entry. It seems to be impervious to modification
update-grub2 will only generate whatever is in /etc/default/grub and
whatever scripts are in /etc/grub.d.
I will put in grub.d later today, see what happens
update-grub2 will only create a /boot/grub2/grub.cfg for the booted
install. It will not change what /boot/grub2/grub.cfg was/is chosen for
boot selection.
Boot mga8. Make make your /etc/default/grub and etc/grub.d changes
in the mga8 install. Run update-grub2 to create /boot/grub2/grub.cfg
you then have to run install-grub to have it boot using the mga8 /boot/grub2/grub.cfg
If the installed version of grub.cfg came from another OS, you MUST run grub2-install and update-grub2.
On 18/5/21 8:36 am, Doug Laidlaw wrote:
If the installed version of grub.cfg came from another OS, you MUST run
grub2-install and update-grub2.
Is the order important??
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 236:24:11 |
| Calls: | 6,624 |
| Files: | 12,172 |
| Messages: | 5,319,829 |