On Sat, 15 May 2021 09:06:52 -0000 (UTC), William Unruh wrote:

All right. What I hear you telling me is you want
/dev/nvme0n1p1 to be in charge of booting.

That is what I call "The Production bootloader"

Lets talk about what you did here

> mount /dev/nvme0e1p2 /mga7
> Again rsync -avxAHX / /mga7/
> makes an exact copy of / (from /dev/nvme0n1p1) to nvme0n1p2.

That is not true. Click up a root terminal and run
lsof

You should see more than a few open files.
One or more files may have pending writes.
Sql operations may have ongoing transactions which
may cause problems in the clone. Some cron job
might run during the rsync,....

FACT: you do not have an exact copy and could
cause weird problems in the clone at some point.

I noticed you have a /local partition.
Since you might have to do the mga7 to mga8 more than once
you might consider writing a cloning script in
that partition. I suggest using labels to make
script writing a bit easier and lowers the chance
of a /dev/nvmeVWXYZ typeo.

As far as I am concerned, the clone is corrupt
so the clone contents need removal.

You are booting efi and therefore might have
grub problems if too many kernels are installed.
Solution is to remove all un-needed kernels.
I would create mount points /mga7 and /mga8 and
add the /mga8 mount point to /etc/fstab with
,noauto argument.

run grub2-install to set mga7 as the bootloader
in charge of booting.

Day one cloning an install for update testing follows:

Download latest (~717M) systemrescue iso from
https://www.system-rescue.org/Download/
burn it to usb thumb drive using instructions at
https://www.system-rescue.org/Installing-SystemRescue-on-a-USB-memory-stick/

Boot it. Slide mouse over icons in bottom task bar
to find/launch gparted.

Create/format/label target partition to be the clone.
In your case I would Label File System it mga8.
While in gparted, I would use Label File System to set nvme0n1p1 media label as mga7.
I would use Name Partition to set partition label
same as partition label. I do/OK each step instead
of doing several operation at at time.

Exit gparted.
Let's do the clone
mkdir /src
mkdir /dest
mount -t auto LABEL=mga7 /src
mount -t auto LABEL=mga8 /dest
rsync -aAHSXxv /src/ /dest

Now modify clone's fstab
geany /dest/etc/fstab
change /dev/nvme0n1p1 /
to /dev/nvme0n1p2 /

change /dev/nvme0n1p2 /mga8
to /dev/nvme0n1p1 /mga7

save/exit geany

umount /src /dest

I would run poweroff, remove usb drive
power on the system and boot the mga7 install and run update-grub to pickup the new install

boot the new install and verify the correct partition is mounted on /
run dracut -f
run update-grub to pickup the new install just
to have a good grub.cfg on /mga8

NOTE: Mageia will continue to boot mga8 by default
until you boot mga7.

Since mga7's grub.cfg is the "Production bootloader"
the menu will not boot the mga8 kernel after you
do the mga7 to mga8 upgrade.

After the upgrade, boot mga7 and run
update-grub to pick up the upgraded mga8 kernel.

Any mga8 kernel updates will require you to
boot mga7 and run update-grub to get the new
kernel in the mga7 "Production bootloader" menu.

I highly recommend that you download/burn the Mageia-8-x86_64.iso so that you can use the
Rescue mode to re-install the desired bootloader
in the event of grub menu will not work at all.

On Sat, 15 May 2021 07:10:41 -0500, Bit Twister wrote:
> On Sat, 15 May 2021 09:06:52 -0000 (UTC), William Unruh wrote:
>
> All right. What I hear you telling me is you want
> /dev/nvme0n1p1 to be in charge of booting.
>
> That is what I call "The Production bootloader"

WARNING: you need to make the system boot using mga7's grub.cfg
before you start my instructions.

If you can not boot mga7 (original) and make it use
/boot/grub2/grub.cfg from /dev/nvme0n1p1 then you will need
to re-install the boot loader via the Rescue mode from the
Mageia-8-x86_64.iso

On Sat, 15 May 2021 07:23:53 -0500, Bit Twister wrote:
> On Sat, 15 May 2021 07:10:41 -0500, Bit Twister wrote:
>> On Sat, 15 May 2021 09:06:52 -0000 (UTC), William Unruh wrote:
>>
>> All right. What I hear you telling me is you want
>> /dev/nvme0n1p1 to be in charge of booting.
>>
>> That is what I call "The Production bootloader"
>
> WARNING: you need to make the system boot using mga7's grub.cfg
> before you start my instructions.

And to be clear, the Original mga7's grub.cfg better boot Original
mga7

>
> If you can not boot mga7 (original) and make it use
> /boot/grub2/grub.cfg from /dev/nvme0n1p1 then you will need
> to re-install the boot loader via the Rescue mode from the
> Mageia-8-x86_64.iso
>

--
The warranty and liability expired as you read this message.
If the above breaks your system, it's yours and you keep both pieces.
Practice safe computing. Backup the file before you change it.
Do a, man command_here or cat command_here, before using it.

On 2021-05-15, Bit Twister <BitTwister@mouse-potato.com> wrote:
> On Sat, 15 May 2021 09:06:52 -0000 (UTC), William Unruh wrote:
>
> All right. What I hear you telling me is you want
> /dev/nvme0n1p1 to be in charge of booting.
>
> That is what I call "The Production bootloader"
>
> Lets talk about what you did here
>
>> mount /dev/nvme0e1p2 /mga7
>> Again rsync -avxAHX / /mga7/
>> makes an exact copy of / (from /dev/nvme0n1p1) to nvme0n1p2.
>
> That is not true. Click up a root terminal and run
> lsof

Yes. it is true. It is an exact copy of / at a certain time. You are
correct that there is a danger of open files being in a somewhat werid
state when you copy them, but that is low probability on a pretty quiet
fielsystem. Far far less than the probability of having trouble if you
do a fresh install.
And many of them are open for reading (eg all the library files)
>
> You should see more than a few open files.
> One or more files may have pending writes.
> Sql operations may have ongoing transactions which
> may cause problems in the clone. Some cron job
> might run during the rsync,....
>
> FACT: you do not have an exact copy and could
> cause weird problems in the clone at some point.
>
> I noticed you have a /local partition.
> Since you might have to do the mga7 to mga8 more than once
> you might consider writing a cloning script in
> that partition. I suggest using labels to make
> script writing a bit easier and lowers the chance
> of a /dev/nvmeVWXYZ typeo.
Since I cannot boot from /local, running the script from /local does not
alleviate the problem you are pointing out.
>
> As far as I am concerned, the clone is corrupt
> so the clone contents need removal.
We differ. But this is also completely irrelevant to the problem I am
trying to understand. Why is Clone 7 grub.cfg getting involved in a boot
where the menu is from the grub.cfg on Original 7?

>
> You are booting efi and therefore might have
> grub problems if too many kernels are installed.
> Solution is to remove all un-needed kernels.
> I would create mount points /mga7 and /mga8 and
> add the /mga8 mount point to /etc/fstab with
> ,noauto argument.

Not a problem. There were three kernels involved in each of the 7
partitions.
>
> run grub2-install to set mga7 as the bootloader
> in charge of booting.
>
grub2 is one of the most idiotic user programs around. It has around a
million completely incomprehensible options, any one of which wrong
gives nonesense.]

>
> Day one cloning an install for update testing follows:
>
> Download latest (~717M) systemrescue iso from
> https://www.system-rescue.org/Download/
> burn it to usb thumb drive using instructions at
> https://www.system-rescue.org/Installing-SystemRescue-on-a-USB-memory-stick/
>
> Boot it. Slide mouse over icons in bottom task bar
> to find/launch gparted.
>
> Create/format/label target partition to be the clone.
> In your case I would Label File System it mga8.
> While in gparted, I would use Label File System to set nvme0n1p1 media label as mga7.
> I would use Name Partition to set partition label
> same as partition label. I do/OK each step instead
> of doing several operation at at time.
>
> Exit gparted.
> Let's do the clone
> mkdir /src
> mkdir /dest
> mount -t auto LABEL=mga7 /src
> mount -t auto LABEL=mga8 /dest
> rsync -aAHSXxv /src/ /dest
>
> Now modify clone's fstab
> geany /dest/etc/fstab
> change /dev/nvme0n1p1 /
> to /dev/nvme0n1p2 /
>
> change /dev/nvme0n1p2 /mga8
> to /dev/nvme0n1p1 /mga7
>
> save/exit geany
>
> umount /src /dest
>
> I would run poweroff, remove usb drive
> power on the system and boot the mga7 install and run update-grub to pickup the new install
>
> boot the new install and verify the correct partition is mounted on /

Which was where everything fell apart. I could NOT boot into the new
install. It consistantly grabbed the wrong (the old install) as the root
partition, despite the grub.cfg listing the new one as as the install
directory.

Everything else was fine. Your suggestion to make a copy using
systemrescue it a good sugestion, but irrelevant to the problem I was
having.

> run dracut -f
> run update-grub to pickup the new install just
> to have a good grub.cfg on /mga8
>
> NOTE: Mageia will continue to boot mga8 by default
> until you boot mga7.

Of course.

>
> Since mga7's grub.cfg is the "Production bootloader"
> the menu will not boot the mga8 kernel after you
> do the mga7 to mga8 upgrade.

fine

>
> After the upgrade, boot mga7 and run
> update-grub to pick up the upgraded mga8 kernel.
>
> Any mga8 kernel updates will require you to
> boot mga7 and run update-grub to get the new
> kernel in the mga7 "Production bootloader" menu.

I acually want mga8 to be the production bootloader finally, but yes,
once I managed to be able to boot into mga8 by manually editing the mga8
grub.cfg, I could run drakboot to make mga8 the production bootloader.

>
> I highly recommend that you download/burn the Mageia-8-x86_64.iso so that you can use the
> Rescue mode to re-install the desired bootloader
> in the event of grub menu will not work at all.

Which uses drakboot essentially to install the bootloader. Which is what
I do anyway.

>
>
>
>
>

.. On 13/5/21 3:14 am, William Unruh 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
> /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 put it at its simplest, you don't need two installations of Grub on
one machine. In the days of LILO, you had only the one bootloader, and
it chose the OS to run. GRUB and Grub2 both work in exactly the same
way that LILO used to.
>

On 2021-05-15, Doug Laidlaw <laidlaws@hotkey.net.au> wrote:
> . On 13/5/21 3:14 am, William Unruh 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
>> /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 put it at its simplest, you don't need two installations of Grub on
> one machine. In the days of LILO, you had only the one bootloader, and
> it chose the OS to run. GRUB and Grub2 both work in exactly the same
> way that LILO used to.

The question is not if I need them, but if a second version of grub.cfg, one
that does NOT determine the boot menu, exits, it seems to affect the
boot process. There was nothing with lilo that prevented two lilo.conf
existing. It was just that only one of them (chosen by your on setup)
conrols the boot process. The contents of the other do not matter. With
grub2 the contents of the non-controlling grub.cfg seem to affect the
boot process, which I agree it should not.

>>

On Sat, 15 May 2021 16:35:06 -0000 (UTC), William Unruh wrote:
> On 2021-05-15, Bit Twister <BitTwister@mouse-potato.com> wrote:
>> On Sat, 15 May 2021 09:06:52 -0000 (UTC), William Unruh wrote:
>>
>> All right. What I hear you telling me is you want
>> /dev/nvme0n1p1 to be in charge of booting.
>>
>> That is what I call "The Production bootloader"
>>
>> Lets talk about what you did here
>>
>>> mount /dev/nvme0e1p2 /mga7
>>> Again rsync -avxAHX / /mga7/
>>> makes an exact copy of / (from /dev/nvme0n1p1) to nvme0n1p2.
>>
>> That is not true. Click up a root terminal and run
>> lsof
>
> Yes. it is true.

I am beginning to believe you have to have the last word in any
argument/discussion.

> It is an exact copy of / at a certain time.

FRAP, The Point of this process to have a WORKING clone of mga7 in which
to do an upgrade. To start out with an incontinent/incomplete setup.

> You are
> correct that there is a danger of open files being in a somewhat werid
> state when you copy them, but that is low probability on a pretty quiet
> fielsystem.

I suggest to you it is not as auiet as you think. You might want
to run top and just watch it for two minutes.

> Far far less than the probability of having trouble if you
> do a fresh install.
> And many of them are open for reading (eg all the library files)

Yes but that is no germane to this argument we are having.

I am done arguing about this. For any lurkers, I am saying is is
a bad methodology to rsync an running /. To get a valid cone it
needs to done when / is not use.

>>
>> As far as I am concerned, the clone is corrupt
>> so the clone contents need removal.
> We differ. But this is also completely irrelevant to the problem I am
> trying to understand. Why is Clone 7 grub.cfg getting involved in a boot
> where the menu is from the grub.cfg on Original 7?

The given process is get the current install to a known/desired state,
clone it correctly, configure the clone to boot with the new /. and
get the clone in the boot menu of the Original install.

It is not to get you to understand why you have an intermixed
original/clone problem.
>
>
>>
>> You are booting efi and therefore might have
>> grub problems if too many kernels are installed.
>> Solution is to remove all un-needed kernels.
>> I would create mount points /mga7 and /mga8 and
>> add the /mga8 mount point to /etc/fstab with
>> ,noauto argument.
>
> Not a problem. There were three kernels involved in each of the 7
> partitions.

Which means the efi grub menu will have 6 kernels and gets you
closer to having the efi grub menu problems.

Yes /local is not able to boot.
You would boot the sysrecue usb drive, bring up a terminal and
mkdir /local
mount -t auto LABEL=local /local
/local/clone_mga7

System would power off, you would remove usb drive and power up.

Dead simple/foolproof if the /local/clone_mga7 script is written
correctly.

On 2021-05-15, Bit Twister <BitTwister@mouse-potato.com> wrote:
> On Sat, 15 May 2021 16:35:06 -0000 (UTC), William Unruh wrote:
>> On 2021-05-15, Bit Twister <BitTwister@mouse-potato.com> wrote:
>>> On Sat, 15 May 2021 09:06:52 -0000 (UTC), William Unruh wrote:
>>>
>>> All right. What I hear you telling me is you want
>>> /dev/nvme0n1p1 to be in charge of booting.
>>>
>>> That is what I call "The Production bootloader"
>>>
>>> Lets talk about what you did here
>>>
>>>> mount /dev/nvme0e1p2 /mga7
>>>> Again rsync -avxAHX / /mga7/
>>>> makes an exact copy of / (from /dev/nvme0n1p1) to nvme0n1p2.
>>>
>>> That is not true. Click up a root terminal and run
>>> lsof
>>
>> Yes. it is true.
>
> I am beginning to believe you have to have the last word in any
> argument/discussion.

If You tell me something is not true, when it is true, yes. If you tell
me something that helps me figure out what is going on, then I am more
than happy to let you have the last word (except for my thanking you.)

>
>
>> It is an exact copy of / at a certain time.
>
> FRAP, The Point of this process to have a WORKING clone of mga7 in which
> to do an upgrade. To start out with an incontinent/incomplete setup.

It was a working copy of Mga7. I upgraded it without problem after I
fixed the problem a not booting into the copy I wanted to upgrade ( and
then the problem of the mirror chosen by Mageia being an incompetent
mirror). I am running Mga8 now without issue. Maybe I am lucky.
>
>> You are
>> correct that there is a danger of open files being in a somewhat werid
>> state when you copy them, but that is low probability on a pretty quiet
>> fielsystem.
>
> I suggest to you it is not as auiet as you think. You might want
> to run top and just watch it for two minutes.
>
>> Far far less than the probability of having trouble if you
>> do a fresh install.
>> And many of them are open for reading (eg all the library files)
>
> Yes but that is no germane to this argument we are having.
>
> I am done arguing about this. For any lurkers, I am saying is is
> a bad methodology to rsync an running /. To get a valid cone it
> needs to done when / is not use.

And I have accepted that. Yes, for you lurkers, it is good idea to copy
a non-active partition. The copy will be a good copy, but it may have
problems due to open files which are being written to and the rsync
producing the copy just as the file is in the midst of a write.
I happen not to be as worried about it, but if you believe in "better
safe than sorry" do the copy from and to partitions which are not in use
while the copy is taking place.

>
>>>
>>> As far as I am concerned, the clone is corrupt
>>> so the clone contents need removal.
>> We differ. But this is also completely irrelevant to the problem I am
>> trying to understand. Why is Clone 7 grub.cfg getting involved in a boot
>> where the menu is from the grub.cfg on Original 7?
>
> The given process is get the current install to a known/desired state,
> clone it correctly, configure the clone to boot with the new /. and
> get the clone in the boot menu of the Original install.
>
> It is not to get you to understand why you have an intermixed
> original/clone problem.

I agree. That has always been my question and desire. But there is zero
evidence that a bad copy was the source of my problems. That I could fix
the problem by a hand edit of a grub.cfg (a very bad idea in general,
but this was for diagnosing the problem) indicates that it being a bad
copy was not the problem.

>>
>>
>>>
>>> You are booting efi and therefore might have
>>> grub problems if too many kernels are installed.
>>> Solution is to remove all un-needed kernels.
>>> I would create mount points /mga7 and /mga8 and
>>> add the /mga8 mount point to /etc/fstab with
>>> ,noauto argument.
>>
>> Not a problem. There were three kernels involved in each of the 7
>> partitions.
>
> Which means the efi grub menu will have 6 kernels and gets you
> closer to having the efi grub menu problems.
>
> Yes /local is not able to boot.
> You would boot the sysrecue usb drive, bring up a terminal and
> mkdir /local
> mount -t auto LABEL=local /local
> /local/clone_mga7
>
> System would power off, you would remove usb drive and power up.
>
> Dead simple/foolproof if the /local/clone_mga7 script is written
> correctly.

I disagree. The problem was not with a bad clone, as I have tried to say
many times, and give evidence for that conclusion. And I still do not
have an aswer to the question: Why is grub, booted from a menu controlled
by grub.cfg on Original 7, using the grub.cfg on Clone 7 to determine
the bootup?
>
>
>
>

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

>> FRAP, The Point of this process to have a WORKING clone of mga7 in which
>> to do an upgrade. To start out with an incontinent/incomplete setup.
>
> It was a working copy of Mga7. I upgraded it without problem after I
> fixed the problem a not booting into the copy I wanted to upgrade ( and
> then the problem of the mirror chosen by Mageia being an incompetent
> mirror).

Then I can guess that mga8 is now set as the "Production bootloader"

I would boot the mga7 install and run update-grub just to have a
valid/known mga7 grub.cfg. Note that I did not say to run mcc.

> I am running Mga8 now without issue. Maybe I am lucky.

I would say so. I did a MariaDB update once which clobbered the database.
My update script will now stop the mysqld service, do the update and
start the mysqld service.

>>
>> Yes /local is not able to boot.
>> You would boot the sysrecue usb drive, bring up a terminal and
>> mkdir /local
>> mount -t auto LABEL=local /local
>> /local/clone_mga7
>>
>> System would power off, you would remove usb drive and power up.
>>
>> Dead simple/foolproof if the /local/clone_mga7 script is written
>> correctly.
>
> I disagree.

Hehehehehehe, I am saying the script would create a valid clone.

> The problem was not with a bad clone, as I have tried to say
> many times,

Which I am not arguing about.

My process produces a reliable/repeatable setup which should have
a known/correct/working grub.cfg. If no mistakes are made and grub.cfg
has to be modified, then there is a bug that would need to be reported.

At this point in time I can see I have no further interest in this thread.

Oh yeah, I assume you have removed the mga7 kernels from the mga8 install
and will continue to keep installed kernels to around 3 to keep away from
the too many kernels grub menu problem.