I have been having problems with grub2. I have two installations-- in my
case of Mageia-- on a two partitions on a disk. Bothe partions gave a
/boot/grub2/. On say partition 1 I run MCC wich finds the installation
on partion 2 and and enters it into the grub.cfg on partion 1 withe the
right parameters (eg that root is /dev/nvme0n1p2 for the installation
on partition 2.) I would have expected that is what grub would use at
bootup-- that is certainlly what shows up in the grub menu on bootup.
However, in partition2 in the /boot/grub2/grub.cfg, it says that the
root is partition 1. When I chose from the bootup grub menu the
partition 2 installation, instead of choosing partition 2 as the root,
it chooses partition 1 as the root. Ie, grub looks into the
/boot/grub2/grub.cfg for the root location and boots that up instead.

To try to make this clearer

Lets say the UUID of partition 1 is XXXX and of partition 2 is YYYY.

In parttion 1 grub.cfg there are two stanzas

$menuentry "Mageia 1" ....
......
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root XXXX
else
search --no-floppy --fs-uuid --set=root XXXX
fi
linux /boot/vmlinuz... root=UUID-XXXX ...
......
$menuentry "Mageia 2" ....
....
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root YYYY
else
search --no-floppy --fs-uuid --set=root YYYY
fi
linux /boot/vmlinuz... root=UUID=YYYYY

and on partition2's grub.cfg

$menuentry "Mageia"
.....
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root XXXX
else
search --no-floppy --fs-uuid --set=root XXXX
fi
linux /boot/vmlinuz... root=UUID-XXXX ...

which is wrong, but I would never expect grub to see it

But what happens is that I see
Mageia 1
Mageia 2
in the grub menu. But when I choose Mageia 2
it uses partition 1 as its root (UUID=XXXX) even though the Mageai 2
menu item explicitly said it should use UUID=YYYY.
When it boots into Mageia 2 it seems to look into the grub.cfg of
partition 2, and use the root from there.

This seems to me to be a bug, or I do not understand grub at all (
which is probable)
It should be using the data from the grub menu that was displayed at
boot, not from some other wrong menu in partition 2 which was never
displayed.

I ran into this when I copied an Mga7 which was working from partition
1 to partition 2, so that I could use the Mga8 upgrade to partition 2.
I did the upgrade (which failed, leaving the grub.cfg on partitoin 2, which pointed to
partition 1 alone).

I booted into partition 1 ( which worked) run MCC to install menu items
to both partition 1 and 2 in the menu, and tried to boot into partition
2. I could not. No matter what menu item I chose, I always ended up in
partition 1, even though the grug.cfg menu clearly pointed to the root
on partition 2. Once it booted, the root was always from partion 1.
When I went to the grub.cfg on partition 2 and manually altered the
root= entry frm XXXX to YYYY (Ie so that it pointed to partition 2 as
the root) the boot process worked. That is NOT how I believe it should
work.

On Wed, 12 May 2021 17:14:20 -0000 (UTC), William Unruh wrote:
>
> But what happens is that I see
> Mageia 1
> Mageia 2
> in the grub menu. But when I choose Mageia 2
> it uses partition 1 as its root (UUID=XXXX) even though the Mageai 2
> menu item explicitly said it should use UUID=YYYY.
> When it boots into Mageia 2 it seems to look into the grub.cfg of
> partition 2, and use the root from there.
>
> This seems to me to be a bug, or I do not understand grub at all (
> which is probable)
> It should be using the data from the grub menu that was displayed at
> boot, not from some other wrong menu in partition 2 which was never
> displayed.
>
>
> I ran into this when I copied an Mga7 which was working from partition
> 1 to partition 2, so that I could use the Mga8 upgrade to partition 2.
> I did the upgrade (which failed, leaving the grub.cfg on partitoin 2, which pointed to
> partition 1 alone).
>
> I booted into partition 1 ( which worked) run MCC to install menu items
> to both partition 1 and 2 in the menu, and tried to boot into partition
> 2. I could not. No matter what menu item I chose, I always ended up in
> partition 1, even though the grug.cfg menu clearly pointed to the root
> on partition 2. Once it booted, the root was always from partion 1.
> When I went to the grub.cfg on partition 2 and manually altered the
> root= entry frm XXXX to YYYY (Ie so that it pointed to partition 2 as
> the root) the boot process worked. That is NOT how I believe it should
> work.

Is this a UEFI or CMS/legacy OS boot?

What command was used to copy mga7 to the mga8 partition?

My guess is you used something other than rsync.

in a root terminal run
lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINT,LABEL,UUID
and verify UUIDs are unique.

Now run update-grub
and verify that there are no failures, That command generates
/boot/grub2/grub.cfg

I do not use UEFI boot. I use cms/legay boot which requires
a bios grub partition. As a result I have to run grub2-install.

That tells grub which /boot/grub2/grub.cfg to use as a menu.
Otherwise grub would not know which of the nine grub.cfg I
currently have.

Be aware that a Mageia out-of-the-box grub install defaults
to booting the last menu selection that was booted.

On 2021-05-12, Bit Twister <BitTwister@mouse-potato.com> wrote:
> On Wed, 12 May 2021 17:14:20 -0000 (UTC), William Unruh wrote:
>>
>> But what happens is that I see
>> Mageia 1
>> Mageia 2
>> in the grub menu. But when I choose Mageia 2
>> it uses partition 1 as its root (UUID=XXXX) even though the Mageai 2
>> menu item explicitly said it should use UUID=YYYY.
>> When it boots into Mageia 2 it seems to look into the grub.cfg of
>> partition 2, and use the root from there.
>>
>> This seems to me to be a bug, or I do not understand grub at all (
>> which is probable)
>> It should be using the data from the grub menu that was displayed at
>> boot, not from some other wrong menu in partition 2 which was never
>> displayed.
>>
>>
>> I ran into this when I copied an Mga7 which was working from partition
>> 1 to partition 2, so that I could use the Mga8 upgrade to partition 2.
>> I did the upgrade (which failed, leaving the grub.cfg on partitoin 2, which pointed to
>> partition 1 alone).
>>
>> I booted into partition 1 ( which worked) run MCC to install menu items
>> to both partition 1 and 2 in the menu, and tried to boot into partition
>> 2. I could not. No matter what menu item I chose, I always ended up in
>> partition 1, even though the grug.cfg menu clearly pointed to the root
>> on partition 2. Once it booted, the root was always from partion 1.
>> When I went to the grub.cfg on partition 2 and manually altered the
>> root= entry frm XXXX to YYYY (Ie so that it pointed to partition 2 as
>> the root) the boot process worked. That is NOT how I believe it should
>> work.
>
> Is this a UEFI or CMS/legacy OS boot?

UEFI

>
> What command was used to copy mga7 to the mga8 partition?

rsync -avxAHX / /mga8 (where the second partition was mounted)

>
> My guess is you used something other than rsync.

Nope.
>
> in a root terminal run
> lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINT,LABEL,UUID
> and verify UUIDs are unique.

I did. They are.

>
> Now run update-grub
> and verify that there are no failures, That command generates
> /boot/grub2/grub.cfg
>
> I do not use UEFI boot. I use cms/legay boot which requires
> a bios grub partition. As a result I have to run grub2-install.
>
> That tells grub which /boot/grub2/grub.cfg to use as a menu.
> Otherwise grub would not know which of the nine grub.cfg I
> currently have.

I used the Boot in MCC to generate the grub on partition 1

>
> Be aware that a Mageia out-of-the-box grub install defaults
> to booting the last menu selection that was booted.

I have the menu up for 5 sec and choose which one it is supposed to boot
to. Yes, it does remember which one it did last time.
But I choose a different one ( and I have done it a few times to make
sure it was behaving weirdly)

>

On Wed, 12 May 2021 13:14:20 -0400, William Unruh <unruh@invalid.ca> wrote:

> I have been having problems with grub2. I have two installations-- in my
> case of Mageia-- on a two partitions on a disk. Bothe partions gave a

I don't normally use os-prober and keep each install separate. With os-prober,
I have too many installs/kernels that are too similar in the way grub2 shows
the menu to make it easy to figure out which install will be booted from which
grub2 menu entry, plus the boot menu no longer fits on one screen.

With grub legacy, I used to install the boot loader to the partition containing
/boot, and used the gag boot loader to select which grub install to run to allow
selecting which kernel to boot.

With grub2, the Mageia tools do not allow selecting a partition for it to be
installed on, just a drive, so I now use one install per drive and use the
bios boot menu to select which one to boot.

Having more than one install share the same boot drive can be done, but extreme
care must be taken to ensure the configurations are compatible.

Which ever install was last used to update-grub in the drive's mbr will control
which partition the grub2 menu is loaded from, and which /etc/default/grub
file will be used, so care must be taken to keep that file identical on all
installs or be prepared for options change depending on which install was
last used to update-grub.

On uefi systems I now strongly recommend switching to refind. Only needs to
be installed once, and doesn't need to be updated after each kernel install
or uninstall.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

On Wed, 12 May 2021 20:58:51 -0000 (UTC), William Unruh wrote:
> On 2021-05-12, Bit Twister <BitTwister@mouse-potato.com> wrote:

>>
>> Now run update-grub
>> and verify that there are no failures, That command generates
>> /boot/grub2/grub.cfg

>
> I used the Boot in MCC to generate the grub on partition 1

Thank you for not doing what I indicated.

That removes one more data point in the debug process towards
figuring out what is causing your problem.0

On 2021-05-12, Bit Twister <BitTwister@mouse-potato.com> wrote:
> On Wed, 12 May 2021 20:58:51 -0000 (UTC), William Unruh wrote:
>> On 2021-05-12, Bit Twister <BitTwister@mouse-potato.com> wrote:
>
>
>>>
>>> Now run update-grub
>>> and verify that there are no failures, That command generates
>>> /boot/grub2/grub.cfg
>
>
>>
>> I used the Boot in MCC to generate the grub on partition 1
>
> Thank you for not doing what I indicated.
>
> That removes one more data point in the debug process towards
> figuring out what is causing your problem.0

This was done in the past. And I am not going to use another hour of my
life to do it again your way, to see if that also breaks things.
I finally got things to work by editing the
/boot/grub2/grub.cfg on partition 2 by hand, inserting the UUID for
partition 2 into the various root and root= refernces in grub.cfg That
worked. I was then able to do the update for Mga7 to Mga (on the third
try, since I had used the Mageai Mirror stanza for the urpmi.cfg file
which picked up some mirror where Mageai 8 pointed to cauldron, and had
a bunch of Mga9 files in it which totally messed up the update. I had to
re-rsync the original Mga 7 partion, do those same by had edits of
grub.cfg and /etc/fstab, this time using the princeton mirror for Mga8
which I had checked that it had no mga9 packages in it. This time it
worked (updating almost 4000 packages) and I am using that Mga8 as I
type.
But I am still curious ( and thoroughly pissed off) at the way grub.cfg
worked and wasted a couple of hours of my life. And I would like to know
if this is a bug in grub2 or if it is a "feature".

>

On Wed, 12 May 2021 23:39:26 -0000 (UTC), William Unruh wrote:
> On 2021-05-12, Bit Twister <BitTwister@mouse-potato.com> wrote:

>> Thank you for not doing what I indicated.
>>
>> That removes one more data point in the debug process towards
>> figuring out what is causing your problem.0
>
> This was done in the past. And I am not going to use another hour of my
> life to do it again your way,

Have it your own way. It does not take an hour for doing the test.

> to see if that also breaks things.

It is not to see if it breaks things. It verifies that the operation
completed usefully or if you have problems unique to your system.

> But I am still curious ( and thoroughly pissed off) at the way grub.cfg
> worked and wasted a couple of hours of my life. And I would like to know
> if this is a bug in grub2 or if it is a "feature".

Simple logic indicates to me the real problem is between the chair
and keyboard.

If it a grub2 problem it sure as hell would have found/reported by now.

Editing /boot/grub2/grub.cfg is the wrong way to fix this kind of problem.

Next kernel update will wipe out your fix or might not booting the
correct kernel.

Glad I could answer your question about is is a grub2 problem.

On 2021-05-13, Bit Twister <BitTwister@mouse-potato.com> wrote:
> On Wed, 12 May 2021 23:39:26 -0000 (UTC), William Unruh wrote:
>> On 2021-05-12, Bit Twister <BitTwister@mouse-potato.com> wrote:
>
>
>>> Thank you for not doing what I indicated.
>>>
>>> That removes one more data point in the debug process towards
>>> figuring out what is causing your problem.0
>>
>> This was done in the past. And I am not going to use another hour of my
>> life to do it again your way,
>
> Have it your own way. It does not take an hour for doing the test.
>
>> to see if that also breaks things.
>
> It is not to see if it breaks things. It verifies that the operation
> completed usefully or if you have problems unique to your system.
>
>
>> But I am still curious ( and thoroughly pissed off) at the way grub.cfg
>> worked and wasted a couple of hours of my life. And I would like to know
>> if this is a bug in grub2 or if it is a "feature".
>
> Simple logic indicates to me the real problem is between the chair
> and keyboard.

It may be. However, I set up grub on partition 1 in such a way that
displayed a menu on boot which differentiated between Mga7 on partition
1 and Mga7 on partion 2, and looking at grub.cfg, it looked like
everything was pointing at the right partion. root referred to UUID
which was the partition 2 UUID in both the linux vmlinux.... root=UUID=
stanzas, etc. And everything in that that grub.cfg showed up in the menu
when I booted up. Ie, the menu and the grub.cfg were completely in sync.
The boot/grub2/grub.cfg on partition 2 pointed back at partition 1
(since it was a copy of the old partition 1 before I ran the MCC Boot
process).

But despite everything on partition 1 being what it should be, when I
selected the copy on partition 2 in the menu, what I got was a boot into
partition 1.
That had nothing to do with me.

When I edited /root/grub2/grub.cfg on partition 2 to point to partition
2 (ie the UUID of partition 2 in the various places in the grub.cfg on
partition 2) and changed nothing in partition 1, the selection from the
menu of the Mga7 ( partition 2) (ie exactly the same as before) now booted into partition 2.

That suggests to me that problem was not between the keyboard and the
chair, but a problem with grub itself.

Unless of course this is the way grub is supposed to behave.

Your theory that if this were a problem with grub2 then it would have
shown up before now assumes that Someone else tried what I did, and did
not simply throw up their hands at the hopelessness of trying to
understand grub2 (It is a rather rats nest of incomprehensible stuff.)

>
> If it a grub2 problem it sure as hell would have found/reported by now.
>
> Editing /boot/grub2/grub.cfg is the wrong way to fix this kind of problem.

Oh, I agree, but it is a way of figuring out where the problem lies.

>
> Next kernel update will wipe out your fix or might not booting the
> correct kernel.
>
> Glad I could answer your question about is is a grub2 problem.

Yes, you did give an answer, unfortunately not one which is consistant
with the symptoms I tried to describe.
>
>

On Thu, 13 May 2021 01:05:34 -0000 (UTC), William Unruh wrote:

> Yes, you did give an answer, unfortunately not one which is consistant
> with the symptoms I tried to describe.

Well since you would not let me vefify that grub works as designed,
it is a waste of bandwidth, Usenet resources, and everyone's time.

For any lurkers, running a terminal as root, the verification steps are:

o mount | grep ' / '
and verify you are running on the desired partition.

o update-grub
will rebuild /boot/grub2/boot.cfg and no errors indicates it worked.

o grub2-install
will install grub boot loader and the location of /boot/grub2/boot.cfg

For users who want to do a release upgrade and still have the old
release I suggest that you:
o boot a rescue cd or live iso
o use gparted to format/label the new partition
o rsync the old release into the new partition
o edit the new /etc/fstab and change / to use the new partition
o boot the old release
o run update-grub to pickup the new install
o boot the new install and verify the correct partition is mounted on /
o run update-grub to pickup the new install
o run grub2-install so it uses the new install's grub.cfg
o reboot and verify that new install is booted when the first grub
selection is selected.
o change media mirror from old release to new release.
o download all new release packages and test that they will install.
o If test passes, do the install.
o power down
o boot new install to verify it works

On 2021-05-13, Bit Twister <BitTwister@mouse-potato.com> wrote:
> On Thu, 13 May 2021 01:05:34 -0000 (UTC), William Unruh wrote:
>
>> Yes, you did give an answer, unfortunately not one which is consistant
>> with the symptoms I tried to describe.
>
> Well since you would not let me vefify that grub works as designed,
> it is a waste of bandwidth, Usenet resources, and everyone's time.
>
> For any lurkers, running a terminal as root, the verification steps are:
>
> o mount | grep ' / '
> and verify you are running on the desired partition.
>
> o update-grub
> will rebuild /boot/grub2/boot.cfg and no errors indicates it worked.
>
> o grub2-install
> will install grub boot loader and the location of /boot/grub2/boot.cfg
>
> For users who want to do a release upgrade and still have the old
> release I suggest that you:
> o boot a rescue cd or live iso
> o use gparted to format/label the new partition
> o rsync the old release into the new partition
> o edit the new /etc/fstab and change / to use the new partition
> o boot the old release
> o run update-grub to pickup the new install
> o boot the new install and verify the correct partition is mounted on /

This is where the problem occured. The system booted the old install,
not the new one, even though I had picked the new one in the menu.

> o run update-grub to pickup the new install

The problem is which grub.cfg gets changed, the new one or the old. I
suspect that the new one is.
> o run grub2-install so it uses the new install's grub.cfg
> o reboot and verify that new install is booted when the first grub
> selection is selected.
> o change media mirror from old release to new release.
> o download all new release packages and test that they will install.
> o If test passes, do the install.
> o power down
> o boot new install to verify it works

>
>

About the only change from what I did is that I used MCC boot. I assume
that the Mageia folks had the process do essntially what you do.
Further more, as I said, the grub.cfg that was created was exactly what
I wanted-- it had two groups, one based on the new partition and one on
the old. And the grub menu that was created was exactly what I wanted--
to groups, one on the new partition and one on the old. The only problem
was that when I chose the new partition, the old one would come up.

Ie, you assume that you know what the outcome of those processes are.
They are not.

On Thu, 13 May 2021 05:06:47 -0000 (UTC), William Unruh wrote:
> On 2021-05-13, Bit Twister <BitTwister@mouse-potato.com> wrote:

>> o run update-grub to pickup the new install
>
> The problem is which grub.cfg gets changed,

update-grub will change /boot/grub2/grub.cfg in the booted/mounted
partition.

> About the only change from what I did is that I used MCC boot. I assume
> that the Mageia folks had the process do essntially what you do.

I do not understand the last sentence. The new install upgrade has
a new kernel which triggers an update-grub execution generating
a new /boot/grub2/grub.cfg.

In no way does the update follow "my process"

> Further more, as I said, the grub.cfg that was created was exactly what
> I wanted-- it had two groups, one based on the new partition and one on
> the old.

Which tells me at least most of the /etc/grub.d/scripts ran ok, but
I wanted update-grub executed in a root terminal to absolutely know
there were no problems.

> The only problem
> was that when I chose the new partition, the old one would come up.

Sounds absolutely correct and normal if you have not told the grub
boot loader to use /boot/grub2/grub.cfg in the new partition.

> Ie, you assume that you know what the outcome of those processes are.

Trust me, I know what my process steps do and the great majority of
my knowledge comes from forgetting to change/etc/fstab, forgetting to
run grub update, or grub install, or getting the wrong drive with grub
install at one time or another.

> They are not.

And yet only you and faeychild are here with grub problems on mga8
and both solutions seem to be to tell the boot loader which
/boot/grub2/grub.cfg to use.

If my commands/steps do not correct your problem. Then the only thing
left is you are not installing the mga8 boot loader in the device being
used for booting.

On 2021-05-13, Bit Twister <BitTwister@mouse-potato.com> wrote:
> On Thu, 13 May 2021 05:06:47 -0000 (UTC), William Unruh wrote:
>> On 2021-05-13, Bit Twister <BitTwister@mouse-potato.com> wrote:
>
>
>>> o run update-grub to pickup the new install
>>
>> The problem is which grub.cfg gets changed,
>
> update-grub will change /boot/grub2/grub.cfg in the booted/mounted
> partition.

And that was what happened.
>
>
>
>> About the only change from what I did is that I used MCC boot. I assume
>> that the Mageia folks had the process do essntially what you do.
>
> I do not understand the last sentence. The new install upgrade has
> a new kernel which triggers an update-grub execution generating
> a new /boot/grub2/grub.cfg.

No This was before the upgrade. I went to MCC, chose Boot, and had it
install a new boot. It checked through the partitions to find all
partitions with Mageia installations and put them into the grub.cfg on
the partition which I was booted into. The grub.cfg changed. It also
then set up the boot to place the menue production into the base of the
disk from which I was booting (my M.2 SSD). This sounds to me like what
MCC->Boot does is exactly what you call update-grub and install-grub.
Before I did this there was just a single menu on bootup, pointing the
various kernels in the original partitions. After I did this there were
two menus-- one pointing to the original Mga7 and the other pointing to
the copied Mga7, with a label giving the partition on which those two
Mga7 partitions resided. However when I chose the second, new partition,
I got booted into the old first partition. When I went to the grub.cfg
on the new partition ( and changed all the UUID references there from
the first old partition to the second neww partition, (editing the new
grub.cfg by hand) the system now booted to the second new partition when
I chose it in the menu, instead of the old first partition. The only
change was to grub.cfg on the second new partition, ( which was NOT the
unified menu).

>
> In no way does the update follow "my process"

I suspect strongly that what MCC does is to run update-grub and
install-grub, exactly what you told me to do. Perhaps someone who knows
MCC Boot can verify, or deny this.

>
>> Further more, as I said, the grub.cfg that was created was exactly what
>> I wanted-- it had two groups, one based on the new partition and one on
>> the old.
>
> Which tells me at least most of the /etc/grub.d/scripts ran ok, but
> I wanted update-grub executed in a root terminal to absolutely know
> there were no problems.

As I said, I ran MCC BOOT not update-grub, but I also expect that
update-grub is exactly what MCC runs.

>
>> The only problem
>> was that when I chose the new partition, the old one would come up.
>
> Sounds absolutely correct and normal if you have not told the grub
> boot loader to use /boot/grub2/grub.cfg in the new partition.

Oh dear, lets go through it all again.

On the old partion, I run MCC-BOOT, which creates a new grub.cfg on the
old partition which contains menu items for both booting the old
partition AND the new partition.

>
>> Ie, you assume that you know what the outcome of those processes are.
>
> Trust me, I know what my process steps do and the great majority of
> my knowledge comes from forgetting to change/etc/fstab, forgetting to
> run grub update, or grub install, or getting the wrong drive with grub
> install at one time or another.
>
>> They are not.
>
> And yet only you and faeychild are here with grub problems on mga8
> and both solutions seem to be to tell the boot loader which
> /boot/grub2/grub.cfg to use.

>
> If my commands/steps do not correct your problem. Then the only thing
> left is you are not installing the mga8 boot loader in the device being
> used for booting.

The boot menu that comes up changes. So, the bootloader IS being
installed on the device used for booting. And the menu that comes up is
exactly what the is in the old partition's new grub.chg.

So, lets go through it again.

I have Mga7 in an old partition, which I will call partition 1. The boot
menu points to partition 1, and when I boot, it boots up with partition
1 being the root partitions.

I now rsync partition 1 to the new partition, partition 2. (being booted
with partition 1 mounted on /) I change
/etc/fstab in partition 2 so that partition 2 is mounted on /. The
grub.cfg on both partitions are identical. Both say that the root is
partition 1.

I now run MCC BOOT (with partition 1 mounted on / and partition 2
unmounted). grub.chg on partition 1 is now changed and has stanzas with root
pointing to partition 1 and root pointing to partition 2. grub.cfg on
partition 2 is unchanged. and root there points to partition 1.

I reboot, and the boot menu that comes up has menu items which say they
they will boot up Mga7 on partition1 and menu items which say that they
will boot up Mga7 on partition 2. These correspond to the items in the
grub.cfg in partition 1's grub.cfg, and do NOT correspond to what is
in partitions 2's grub.cfg.

However, if I now chose from the menu to boot into Mga7 on partition 2
what comes up is Mga7 with partition 1 mounted on /

IF I now manually edit the grub.cfg on partition 2 ( which is still
exactly the same as it was originally on partition 1 with only items
pointing to partition 1) so that all the UUIDS for partition 1 are
changed to partition 2 (I do NOT run MCC Boot, I do not do a update-grub
or install grub, I only manually edit partition 2's grub.cfg to replace
all of partition 1's UUIDs with partition 2's UUIDs) then when I chose
partition 2's MGA7 on the boot menu, I get Mga7 with partition 2 mounted
on /.

Ie, the boot menu is partition 1's grub.cfg's menu, but what actually
gets mounted is partition 2's stuff from its grub.cfg.

But nothing, especially grub should be reading partition 2's grub.cfg. I
am booting partition 1's grub.cfg, as is evidenced by the menu items on
the boot menu.

All that either MCC BOOT or update-grub/install-grub do is to set up and
change the grub.cfg files ( and presumably the pointers in
/boot/EFI/EFI/mageia/grub64.efi)

So why is the grub.cfg on partition 2 affecting the bootup which should
be being controlled by the grub.cfg on partition 1?

>

Op Wed, 12 May 2021 19:19:59 -0500, schreef Bit Twister:

> On Wed, 12 May 2021 23:39:26 -0000 (UTC), William Unruh wrote:
>> On 2021-05-12, Bit Twister <BitTwister@mouse-potato.com> wrote:
>
>
>>> Thank you for not doing what I indicated.
>>>
>>> That removes one more data point in the debug process towards figuring
>>> out what is causing your problem.0
>>
>> This was done in the past. And I am not going to use another hour of my
>> life to do it again your way,
>
> Have it your own way. It does not take an hour for doing the test.
>
>> to see if that also breaks things.
>
> It is not to see if it breaks things. It verifies that the operation
> completed usefully or if you have problems unique to your system.
>
>
>> But I am still curious ( and thoroughly pissed off) at the way grub.cfg
>> worked and wasted a couple of hours of my life. And I would like to
>> know if this is a bug in grub2 or if it is a "feature".
>
> Simple logic indicates to me the real problem is between the chair and
> keyboard.
>
> If it a grub2 problem it sure as hell would have found/reported by now.

I hate to against Bittwister, but there is a problem with Mageia/grub2 and
I opened a bug report on this, the bug is still open; bug 22675.
It only shows up when the number of entries on the grub menu exceeds some
limit.
In my case the laptop has Win10, M8 for real use, another M8 for testing
updates and (for the time being) an M7 for the same purpose. I have to
remember quite strictly to remove older kernels from any of the Mageia
installations when new kernels come along, but that sometimes is
forgotten and then it goes wrong. I even had once the situation when I
installed kernel 5.10.29 (if I remember well, and in the same MCC
operation removed kernel 5.10.20 - there was a 27 in between), the
default entry in the resulting grub menu pointed to the 5.10.20 kernel
which wasn't there anymore, go figure.
I mostly use grub-customizer to get things straightened out.

Herman Viaene

On Thu, 13 May 2021 12:22:25 +0000 (UTC), Herman Viaene wrote:
> Op Wed, 12 May 2021 19:19:59 -0500, schreef Bit Twister:

>> If it a grub2 problem it sure as hell would have found/reported by now.
>
> I hate to against Bittwister,

Do not ever worry about that, I still make mistakes and need
to be corrected from time to time.

> but there is a problem with Mageia/grub2 and
> I opened a bug report on this, the bug is still open; bug 22675.
> It only shows up when the number of entries on the grub menu exceeds some
> limit.

Ah frap I did forget about
https://bugs.mageia.org/show_bug.cgi?id=22675

@William: what kind of boot is being done, efi or cms?

How many kernels are in /boot/?
Mine has
$ ls /boot/vmlinuz-*mga* | wc -l
1

I do a cms with mbr install and there are 9 installs with one kernel
because I always remove old kernel if there is no problems show up
during new kernel boot.

On 5/12/21 5:16 PM, David W. Hodgins wrote:
> On uefi systems I now strongly recommend switching to refind. Only needs to
> be installed once, and doesn't need to be updated after each kernel install
> or uninstall.

I have never used uefi, so I know next to nothing about it. Nor do I, at
this point in time, have any desire to start using it. So far, mbr and
grub2 are working just fine for me.

However, I seem to remember complaints a couple of years ago regarding
Mageia grub2 updates messing up refind. Is that still a thing, or is it
recommended that grub2 be uninstalled if refind is being used?

TJ

On Thu, 13 May 2021 04:34:29 -0400, William Unruh <unruh@invalid.ca> wrote:
> Mga7 partitions resided. However when I chose the second, new partition,
> I got booted into the old first partition. When I went to the grub.cfg
> on the new partition ( and changed all the UUID references there from
> the first old partition to the second neww partition, (editing the new
> grub.cfg by hand) the system now booted to the second new partition when
> I chose it in the menu, instead of the old first partition. The only
> change was to grub.cfg on the second new partition, ( which was NOT the
> unified menu).

My guess is that the initrd was not rebuilt in the new install, so the boot
loaded the initrd from the new install but that initrd has the hard coded
uuid of the old install and the old fstab, so that's what it boots.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

On 2021-05-13, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
> On Thu, 13 May 2021 04:34:29 -0400, William Unruh <unruh@invalid.ca> wrote:
>> Mga7 partitions resided. However when I chose the second, new partition,
>> I got booted into the old first partition. When I went to the grub.cfg
>> on the new partition ( and changed all the UUID references there from
>> the first old partition to the second neww partition, (editing the new
>> grub.cfg by hand) the system now booted to the second new partition when
>> I chose it in the menu, instead of the old first partition. The only
>> change was to grub.cfg on the second new partition, ( which was NOT the
>> unified menu).
>
> My guess is that the initrd was not rebuilt in the new install, so the boot
> loaded the initrd from the new install but that initrd has the hard coded
> uuid of the old install and the old fstab, so that's what it boots.

Well, no, because if I change the root UUID pointer by hand in the new
(partition2) grub.cfg, the boot works properly and boots to the new partition.
Ie, I do not change initrd, or anything else. Just the UUID in grub.cfg
which is not the grub.cfg that the system is supposed to be booting
from.

So the question still is "why is the grub boot looking into a grub.cfg
which NOT the one that produces the boot menu"? Note that there is
nothing in grub.cfg which does produce the boot menu which points to or
references the other grub.cfg

>
> Regards, Dave Hodgins
>

On Thu, 13 May 2021 09:36:49 -0400, TJ <TJ@noneofyour.business> wrote:
> However, I seem to remember complaints a couple of years ago regarding
> Mageia grub2 updates messing up refind. Is that still a thing, or is it
> recommended that grub2 be uninstalled if refind is being used?

Not one I've encountered. The only thing about having both is that update-grub
has to be run manually after each kernel update.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

On Thu, 13 May 2021 14:44:01 -0400, David W. Hodgins wrote:
> On Thu, 13 May 2021 04:34:29 -0400, William Unruh <unruh@invalid.ca> wrote:
>> Mga7 partitions resided. However when I chose the second, new partition,
>> I got booted into the old first partition. When I went to the grub.cfg
>> on the new partition ( and changed all the UUID references there from
>> the first old partition to the second neww partition, (editing the new
>> grub.cfg by hand) the system now booted to the second new partition when
>> I chose it in the menu, instead of the old first partition. The only
>> change was to grub.cfg on the second new partition, ( which was NOT the
>> unified menu).
>
> My guess is that the initrd was not rebuilt in the new install, so the boot
> loaded the initrd from the new install but that initrd has the hard coded
> uuid of the old install and the old fstab, so that's what it boots.

I would have thought that the first mga8 kernel would have picked up
the mga8 partition, The next mga8 kernel update would then be in sync
for sure let alone the others.

$ uidx kernel-desktop-devel updates-0008 64.rpm
kernel-desktop-devel-latest-5.10.19-1.mga8.x86_64.rpm 64K 27-Feb-2021 00:49
kernel-desktop-devel-latest-5.10.20-2.mga8.x86_64.rpm 64K 05-Mar-2021 22:06
kernel-desktop-devel-latest-5.10.25-1.mga8.x86_64.rpm 63K 20-Mar-2021 21:16
kernel-desktop-devel-latest-5.10.27-1.mga8.x86_64.rpm 62K 31-Mar-2021 03:31
kernel-desktop-devel-latest-5.10.30-1.mga8.x86_64.rpm 62K 14-Apr-2021 15:21
kernel-desktop-devel-latest-5.10.33-1.mga8.x86_64.rpm 61K 28-Apr-2021 19:20

On Thu, 13 May 2021 08:34:29 -0000 (UTC), William Unruh wrote:

Which mode did you set the bios, efi or cms/letacy ?

Did you do the rsync on Original while Original 7 was running? (yes/no)

What you say does not make sense to me.

Tell me which grub menu is to in control, Original 7 or Cloned 7?

I would like to see the results of
grep ' / ' /etc/fstab
from both installs.

I would like to see the results of
lsblk -o NAME,TYPE,MOUNTPOINT,LABEL,UUID

On 2021-05-15, Bit Twister <BitTwister@mouse-potato.com> wrote:
> On Thu, 13 May 2021 08:34:29 -0000 (UTC), William Unruh wrote:
>
>
> Which mode did you set the bios, efi or cms/letacy ?

EFI

But with the old partition table.
>
> Did you do the rsync on Original while Original 7 was running? (yes/no)

Yes.

>
> What you say does not make sense to me.

I am just reporting.

>
> Tell me which grub menu is to in control, Original 7 or Cloned 7?

When I had all of the problems, it was
Original 7. I could not boot into Cloned 7. I run drakboot on the
Original 7 and it installed stanzas for both the Original 7 and Cloned
7, as shown by direct inspection of Original 7 /boot/grub2/grub.cfg and
the boot menu which came up when I tried to reboot into Cloned 7. But it
failed, apparently because the Cloned 7 /boot/grub2/grub.cfg still
pointed to UUID of the partition of Original 7.

Now after I edited by hand the cloned grub.cfg to have the Cloned 7 grub point to the
cloned partition UUID, I finally could boot into the cloned partition and
update it to Mga8, and Mageia drakboot then installed the boot onto
the cloned grub.cfg.
So, now everything works. But it is still mysterious why it behaved the
way it did.

>
> I would like to see the results of
> grep ' / ' /etc/fstab

on original
/dev/nvme0n1p1 / ext4 noatime,acl 1 1
on cloned
/dev/nvme0n1p2 / ext4 noatime,acl 1 1

As I said, I made sure that I changed the cloned partitions /etc/fstab
to point to the correct partition.

> from both installs.
>
>
> I would like to see the results of
> lsblk -o NAME,TYPE,MOUNTPOINT,LABEL,UUID
NAME TYPE MOUNTPOINT LABEL UUID

sr0 rom
nvme0n1 disk
├─nvme0n1p1 part /mga7 e76f54d8-f768-467f-82b1-d486efbd6553
├─nvme0n1p2 part / f6eb6173-2ec7-4a23-9531-3e1ba6cc1c8a
├─nvme0n1p3 part
├─nvme0n1p5 part [SWAP] 15151eca-592a-498d-a348-80af8a151965
├─nvme0n1p7 part /boot/EFI B528-DEB3
└─nvme0n1p8 part /local ab3dffdc-b651-4d58-ad5e-ae71f3c0bf52

So, no, no repeated UUIDs, as I have told you.

On Sat, 15 May 2021 04:07:38 -0000 (UTC), William Unruh wrote:
> On 2021-05-15, Bit Twister <BitTwister@mouse-potato.com> wrote:

>> Did you do the rsync on Original while Original 7 was running? (yes/no)
>
> Yes.

Not good. the contents of all the temp/in memory only stuff would
be copied to the target partition. :(

Those sub-directories should not have files in them. You will need
to keep that in mind anytime you are wondering about missing disk space.

You did not answer my question. I do not want to hear what is happening.
I want YOU to to indicate which partition YOU want to proved the boot menu.

Tell me which grub menu is to in control, Original 7 or Cloned 7?

> So, no, no repeated UUIDs, as I have told you.

Hehe, if this was a court of law, everything up to your reply
was hearsay and no facts.

I just making sure of the facts to make sure of what you do have
and more impotently, how things were mounted after grub.
There were a few things I needed to rule out.
I also needed facts so I know what advice/commands I might what
to give at anytime in the future.

Thank you for the hard copy. I am assuming you did not trim anything
from the outputs.

FYI For any lurkers:
Unless you keep current with what is mounted in memory only,
I can recommend not rsync'ing a mounted / to another partition.
William's lsblk indicates only two OS partitions.
I that setup the only option is to boot a live iso or a rescue cd.
to do the rsync operation. rsync arguments I use are --delete -aAHSXxv

On 2021-05-15, Bit Twister <BitTwister@mouse-potato.com> wrote:
> On Sat, 15 May 2021 04:07:38 -0000 (UTC), William Unruh wrote:
>> On 2021-05-15, Bit Twister <BitTwister@mouse-potato.com> wrote:
>
>>> Did you do the rsync on Original while Original 7 was running? (yes/no)

>>
>> Yes.
>
> Not good. the contents of all the temp/in memory only stuff would
> be copied to the target partition. :(
>
> Those sub-directories should not have files in them. You will need
> to keep that in mind anytime you are wondering about missing disk space.

But completely irrelevant to the problem at hand. Also, those temporary
directories are erased on a reboot, and I did the rsync immediately
after booting into Original 7.

>
> You did not answer my question. I do not want to hear what is happening.
> I want YOU to to indicate which partition YOU want to proved the boot menu.

??? Yes, I did answer every one of your questions.
>
> Tell me which grub menu is to in control, Original 7 or Cloned 7?

I gave you the evidence that I have that both are in "control"
The grub.cfg are the original ones, since I made an exact copy of the
Original 7 partition by cloning it. I then booted into Original
Partition and run drakboot. That changed Original 7 grub.cfg, but did
not change Clone 7 grub.cfg. The original 7 had pointers to both the
Original 7 partition and to the Clone 7 partition and evidenced by the
UUID to which the stanzas pointed. The Clone7 grub.cfg only pointed to
the Original 7 partition, since drakboot did not change it at all. The
boot menu corresponded to the new contents of the Original 7
partition's grub.cfg (each entry in its grub.cfg correspoinded to a
line in the boot menu.) However there were both entries in there which
pointed to the Original 7 partition AND to the Clone partition in
different stanzas. The menu had two main entries -- to Mageia and to
Mageia 7 (on partitin nvme0n1p2), and had Advanced menu entries to the
individual kernels and their recovery brothers on the two partition.

However If I chose the entry labeled Mageia 7 (on nvme0n1p2) which
should have booted me into the Clone 7 partition, instead it booted me
into the Orignal 7 partition. However when I changed the UUIDs in the
Clone 7 grub.cfg to point to the clone partition ( remember these had
not been touched by drakeboot and thus still pointed to Orinal 7
partition) then it did boot into the Clone 7 partition.

(This is only the 4th time I have explained this.

>
>> So, no, no repeated UUIDs, as I have told you.
>
>
> Hehe, if this was a court of law, everything up to your reply
> was hearsay and no facts.

Uh, no. It was reports of investigations I had carried out. It was not
hearsay. It was a report of my direct observations. You simply refused
to accept them.

>
> I just making sure of the facts to make sure of what you do have
> and more impotently, how things were mounted after grub.
> There were a few things I needed to rule out.
> I also needed facts so I know what advice/commands I might what
> to give at anytime in the future.

Fine, I have given them to you.

>
> Thank you for the hard copy. I am assuming you did not trim anything
> from the outputs.
>
> FYI For any lurkers:
> Unless you keep current with what is mounted in memory only,
> I can recommend not rsync'ing a mounted / to another partition.
> William's lsblk indicates only two OS partitions.
> I that setup the only option is to boot a live iso or a rescue cd.
> to do the rsync operation. rsync arguments I use are --delete -aAHSXxv

I used --delete -avxAHX

But it really is irrelevant to this problem. grub.cfg is NOT a hard
link, does not have non-trivial acls, etc. and is certainly NOT a sparse
file.

>
>
>
>

On Sat, 15 May 2021 05:47:47 -0000 (UTC), William Unruh wrote:
> On 2021-05-15, Bit Twister <BitTwister@mouse-potato.com> wrote:
>> On Sat, 15 May 2021 04:07:38 -0000 (UTC), William Unruh wrote:
>>> On 2021-05-15, Bit Twister <BitTwister@mouse-potato.com> wrote:
>>
>>>> Did you do the rsync on Original while Original 7 was running? (yes/no)
>
>
>>>
>>> Yes.
>>
>> Not good. the contents of all the temp/in memory only stuff would
>> be copied to the target partition. :(
>>
>> Those sub-directories should not have files in them. You will need
>> to keep that in mind anytime you are wondering about missing disk space.
>
> But completely irrelevant to the problem at hand.

Very true.

> Also, those temporary
> directories are erased on a reboot, and I did the rsync immediately
> after booting into Original 7.

And the ones I am talking about are created before you can get
to a login prompt.

For example:
[bittwister@wb ~]$ ls -1A /sys/ | wc -l
11
[bittwister@wb ~]$ ls -1A /mga6/sys/ | wc -l
0

[bittwister@wb ~]$ ls -1A /dev/ | wc -l
231
[bittwister@wb ~]$ ls -1A /mga6/dev/ | wc -l
0

>
>>
>> You did not answer my question. I do not want to hear what is happening.
>> I want YOU to to indicate which partition YOU want to proved the boot menu.
>
> ??? Yes, I did answer every one of your questions.
>>
>> Tell me which grub menu is to in control, Original 7 or Cloned 7?

Damn it, RTFQ. You are not answering MY question.
Just tell me which grug.cfg you want to be in control.
Original 7 or Cloned 7?
All I am asking is which one you want in control upon boot.

The answer YOU need to give is Original or Cloned???

This is only the 4th time I have explained this.
And yet again I am not asking for that explanation.
Read the above again.

> But it really is irrelevant to this problem. grub.cfg is NOT a hard
> link, does not have non-trivial acls, etc. and is certainly NOT a sparse
> file.

Very true, but if you are copying / I suggest to you need an exact copy
of /, not just grub.cfg.

Always keep in mind I am always reply to a post but I am writing
for any lurkers or anyone who runs across this thread in the future.

On 2021-05-15, Bit Twister <BitTwister@mouse-potato.com> wrote:
> On Sat, 15 May 2021 05:47:47 -0000 (UTC), William Unruh wrote:
>> On 2021-05-15, Bit Twister <BitTwister@mouse-potato.com> wrote:
>>> On Sat, 15 May 2021 04:07:38 -0000 (UTC), William Unruh wrote:
>>>> On 2021-05-15, Bit Twister <BitTwister@mouse-potato.com> wrote:
>>>
>>>>> Did you do the rsync on Original while Original 7 was running? (yes/no)
>>
>>
>>>>
>>>> Yes.
>>>
>>> Not good. the contents of all the temp/in memory only stuff would
>>> be copied to the target partition. :(
>>>
>>> Those sub-directories should not have files in them. You will need
>>> to keep that in mind anytime you are wondering about missing disk space.
>>
>> But completely irrelevant to the problem at hand.
>
> Very true.
>
>> Also, those temporary
>> directories are erased on a reboot, and I did the rsync immediately
>> after booting into Original 7.
>
> And the ones I am talking about are created before you can get
> to a login prompt.
>

rsync -axvAHX
The -x says stay within the one filesystem. /sys is a separate
filesystem

> For example:
> [bittwister@wb ~]$ ls -1A /sys/ | wc -l
> 11
> [bittwister@wb ~]$ ls -1A /mga6/sys/ | wc -l
> 0
>
> [bittwister@wb ~]$ ls -1A /dev/ | wc -l
> 231
> [bittwister@wb ~]$ ls -1A /mga6/dev/ | wc -l
> 0

Yup. Thats what -x does for you.

>
>>
>>>
>>> You did not answer my question. I do not want to hear what is happening.
>>> I want YOU to to indicate which partition YOU want to proved the boot menu.
>>
>> ??? Yes, I did answer every one of your questions.
>>>
>>> Tell me which grub menu is to in control, Original 7 or Cloned 7?
>
> Damn it, RTFQ. You are not answering MY question.
> Just tell me which grug.cfg you want to be in control.
> Original 7 or Cloned 7?
> All I am asking is which one you want in control upon boot.

Eventually Clone 7. But at the time Original 7, because I wanted to get
into Clone 7.

>
> The answer YOU need to give is Original or Cloned???

At the time Original 7 (I thought that was clear) Once I had updated
clone7 to Mga8, I wanted clone 7 (now 8) to be in charge. But the
problem was what was happening when Original 7 was supposed to be in
charge, but Clone 7 was getting involved when it should not be.

Ie again, all evidence from the format of Original 7 grub.cfg, and the
boot menu was that Original 7 was in charge, but from the boot behaviour,
Clone 7 grub.cfg was in charge IF I choose Clone 7 partition to boot from in the menu.
>
>
>
> This is only the 4th time I have explained this.
> And yet again I am not asking for that explanation.
> Read the above again.
>
>> But it really is irrelevant to this problem. grub.cfg is NOT a hard
>> link, does not have non-trivial acls, etc. and is certainly NOT a sparse
>> file.
>
> Very true, but if you are copying / I suggest to you need an exact copy
> of /, not just grub.cfg.

mount /dev/nvme0e1p2 /mga7
Again rsync -avxAHX / /mga7/
makes an exact copy of / (from /dev/nvme0n1p1) to nvme0n1p2. Amongst
which it makes an exact copy of grub.cfg

>
> Always keep in mind I am always reply to a post but I am writing
> for any lurkers or anyone who runs across this thread in the future.

Fine, but you need to read what I write, so the lurkers do not have to
read me giving the same information 4 or 5 tmes.

>