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.
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
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
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:
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.
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.
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:
o run update-grub to pickup the new install
The problem is which grub.cfg gets changed,
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.
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 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.
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,
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.
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.
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).
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
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?
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.
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 ofNAME TYPE MOUNTPOINT LABEL UUID
lsblk -o NAME,TYPE,MOUNTPOINT,LABEL,UUID
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.
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?
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
??? Yes, I did answer every one of your questions.
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?
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.
mount /dev/nvme0e1p2 /mga7
Again rsync -avxAHX / /mga7/
makes an exact copy of / (from /dev/nvme0n1p1) to nvme0n1p2.
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"
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 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.Since I cannot boot from /local, running the script from /local does not alleviate the problem you are pointing out.
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 corruptWe differ. But this is also completely irrelevant to the problem I am
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.
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.
. 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, 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)
We differ. But this is also completely irrelevant to the problem I am
As far as I am concerned, the clone is corrupt
so the clone contents need removal.
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.
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.
We differ. But this is also completely irrelevant to the problem I am
As far as I am concerned, the clone is corrupt
so the clone contents need removal.
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:
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.
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,
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 482 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 70:26:20 |
| Calls: | 9,571 |
| Calls today: | 2 |
| Files: | 13,663 |
| Messages: | 6,142,256 |