I have just discovered that sysrescue is no longer listed in the grub
boot menu.

Did this happen since I installed dual boot MGA6??
No idea!!. I only just noticed it missing but that is the only change
made since
I can't imagine another OS knocking out the sysrescue entry in the boot
menu but something has.
The entry is still in grub.cfg

********

### END /etc/grub.d/20_ppc_terminfo ###

### BEGIN /etc/grub.d/25_sysresccd ###

menuentry "SystemRescueCd (isoloop)" {
load_video
insmod gzio
insmod part_gpt
insmod part_msdos
insmod ext2
search --no-floppy --label boot_iso --set=root
loopback loop /systemrescuecd.iso
echo 'Loading kernel ...'
linux (loop)/sysresccd/boot/x86_64/vmlinuz img_label=boot_iso img_loop=/systemrescuecd.iso archisobasedir=sysresccd copytoram setkmap=us
echo 'Loading initramfs ...'
initrd (loop)/sysresccd/boot/x86_64/sysresccd.img
}
### END /etc/grub.d/25_sysresccd ###


**********

and the systemrescuecd.iso is still in "boot_iso"" partition


But it doesn't show in the boot menu


Maybe if I don't sweat over it I will have an inspiration

It is just a bit annoying. I know it will be resolved eventually.

regards

--
faeychild
Running plasmashell 5.15.4 on 5.2.13-desktop-2.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Fri, 18 Oct 2019 14:18:58 +1100, faeychild wrote:

I have just discovered that sysrescue is no longer listed in the grub
boot menu.

Did this happen since I installed dual boot MGA6??

Before I forget it, again, If you are sharing $HOME Desktop Environment
(DE) between installs,be prepared for the possibility of running mga6
and doing something that will clobber your mga7 DE.


Based on all the information needed for the analysis and not provided,
I will guess yes.

The entry in mga7 grub.cfg was created by the script you placed in mga7's /etc/grub.d

When you installed mga6, you used mga6's /etc/grub.d which did not have
the systemrescue grub entry generation script.

After you installed mga6, you should have booted mga7 an told mga7 grub
to generate a new grub.cfg, and install it as your "Production" boot loader.

Read the last 4 lines of this reply, I'll wait . . . . . . . . . . . . .

So, as root, on booted mga7,
update-grub
grub2-install /dev/XYZ At this point I will have to guess
that XYZ is nvme0n1

--
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.



--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 18/10/19 2:39 pm, Bit Twister wrote:

Before I forget it, again, If you are sharing $HOME Desktop Environment
(DE) between installs,be prepared for the possibility of running mga6
and doing something that will clobber your mga7 DE.

It's a separate $HOME on each installation

Based on all the information needed for the analysis and not provided,
I will guess yes.

The entry in mga7 grub.cfg was created by the script you placed in mga7's /etc/grub.d

Yes

When you installed mga6, you used mga6's /etc/grub.d which did not have
the systemrescue grub entry generation script.

correct! A glimmer is showing

After you installed mga6, you should have booted mga7 an told mga7 grub
to generate a new grub.cfg, and install it as your "Production" boot loader.

Ah I seem to have two "boot" folders one on each partition -problem!!
Yes a bit convoluted

Read the last 4 lines of this reply, I'll wait . . . . . . . . . . . . .

So, as root, on booted mga7,
update-grub
grub2-install /dev/XYZ At this point I will have to guess
that XYZ is nvme0n1

I see where you are going with this. But I have stumbled across another problem

**************

lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINT
NAME SIZE FSTYPE LABEL MOUNTPOINT
sda 5.5T
└─sda1 5.5T ext4 video /video
sr0 1024M
nvme0n1 119.2G
├─nvme0n1p1 299M vfat
├─nvme0n1p2 22.3G ext4 mageia /
├─nvme0n1p3 10.6G swap swap [SWAP]
├─nvme0n1p4 12.2G ext4 tmp /tmp
├─nvme0n1p5 20.4G ext4 mageia_bu
├─nvme0n1p6 2G ext4 boot_iso
└─nvme0n1p7 24.9G ext4 mageia_6 /run/media/faeychild/mageia_6


I'm very very surprised to see "mageia_6" mount point on run media

Which means that MGA6 is mounted on "/run/media" MGA7

So the partition "nvme0n1p7" actually mounted on partition "nvme0n1p2"?

GOOD GOD what have I done??

I'm trying to visualize what happens when I select mageia_6 from the
boot menu. Because I can see mageia_6 sitting in "run/media" of mageia_7

I am having a decaying mental orbit here.

OK If I don't have a massively interrupted Saturday I'll change the
mount point of nvme0n1p7 and run update-grub and grub2-install
/dev/nvme0n1p2


Massive stuff up. I'm beginning to understand where I lost the plot but
the mount point of /run/media/ for mageia_6 has me stumped.

I would never have selected that with gparted..I'm not that demented.

I also have to pick up an Ethernet cable (printer)?

Cant post eternal-september seems to be down.

regards





--
faeychild
Running plasmashell 5.15.4 on 5.2.13-desktop-2.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sat, 19 Oct 2019 09:38:37 +1100, faeychild wrote:

I see where you are going with this. But I have stumbled across another problem

**************

lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINT
NAME SIZE FSTYPE LABEL MOUNTPOINT
sda 5.5T
└─sda1 5.5T ext4 video /video
sr0 1024M
nvme0n1 119.2G
├─nvme0n1p1 299M vfat
├─nvme0n1p2 22.3G ext4 mageia /
├─nvme0n1p3 10.6G swap swap [SWAP]
├─nvme0n1p4 12.2G ext4 tmp /tmp
├─nvme0n1p5 20.4G ext4 mageia_bu
├─nvme0n1p6 2G ext4 boot_iso
└─nvme0n1p7 24.9G ext4 mageia_6 /run/media/faeychild/mageia_6

GOOD GOD what have I done??

You do come up with some interesting problems.

First thing I would do under mga7, as root,
umount /run/media/faeychild/mageia_6
then
mkdir /mageia_6
bring up your editor and add
LABEL=mageia_6 /mageia_6 ext4 noatime,users,noauto,acl 1 2
to /etc/fstab, save, exit editor

Now try
mount /mageia_6

If looking good, fix mageia 6 install to pickup mga7 the same way.
mkdir /mageia_6/mageia
edit /mageia_6/etc/fstab
and add
LABEL=mageia /mageia ext4 noatime,users,noauto,acl 1 2
save, exit the editor.
umount /mageia_6




--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 19/10/19 11:35 am, Bit Twister wrote:

On Sat, 19 Oct 2019 09:38:37 +1100, faeychild wrote:

I see where you are going with this. But I have stumbled across another
problem

**************

lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINT
NAME SIZE FSTYPE LABEL MOUNTPOINT
sda 5.5T
└─sda1 5.5T ext4 video /video
sr0 1024M
nvme0n1 119.2G
├─nvme0n1p1 299M vfat
├─nvme0n1p2 22.3G ext4 mageia /
├─nvme0n1p3 10.6G swap swap [SWAP]
├─nvme0n1p4 12.2G ext4 tmp /tmp
├─nvme0n1p5 20.4G ext4 mageia_bu
├─nvme0n1p6 2G ext4 boot_iso
└─nvme0n1p7 24.9G ext4 mageia_6 /run/media/faeychild/mageia_6

GOOD GOD what have I done??

You do come up with some interesting problems.

Once again a severely interrupted Saturday and I am obviously cursed to
live in interesting times

First thing I would do under mga7, as root,
umount /run/media/faeychild/mageia_6
then
mkdir /mageia_6
bring up your editor and add
LABEL=mageia_6 /mageia_6 ext4 noatime,users,noauto,acl 1 2
to /etc/fstab, save, exit editor

Now try
mount /mageia_6

If looking good, fix mageia 6 install to pickup mga7 the same way.
mkdir /mageia_6/mageia
edit /mageia_6/etc/fstab
and add
LABEL=mageia /mageia ext4 noatime,users,noauto,acl 1 2
save, exit the editor.
umount /mageia_6

Will this be a dual boot of two independent systems

I think I understand you are creating a mageia 6 mount point on mageia 7
root
and creating a mageia 7 mount point on mageia 6 root
Is this so?

What will this do as far as grub is concerned

I was originally trying for two independent systems selected from the
grub2 boot menu, which actually does work although the complete Mga6 filesystem on Mga7 /run/media/*, has me wondering

I'll test it by booting Mga6. Salt the filesystem with something and
then boot Mga7 and see if it appears in the Mga6 file system in Mga7 /run/media/*

If so the recursion will do my head in.

This is a far cry from the Lilo days

regards



--
faeychild
Running plasmashell 5.15.4 on 5.2.13-desktop-2.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sat, 19 Oct 2019 18:08:38 +1100, faeychild wrote:

Will this be a dual boot of two independent systems

Yes. But I suggest one "Production" boot loader is to be in charge
of booting whichever install is desired.

I think I understand you are creating a mageia 6 mount point on mageia 7
root
and creating a mageia 7 mount point on mageia 6 root
Is this so?

Yes. One to keep you out of this /run/media thing, and more importantly,
allow a backup script to backup the other install.

What will this do as far as grub is concerned

/etc/fstab has no bearing as far as grub is concerned, about our/your
desired mount points.

I was originally trying for two independent systems selected from the
grub2 boot menu, which actually does work

Yep, mga7/grub had no knowledge of mga6 install.
mga6 grub install found mga7, and since it was installed last, it is
the boot loader in charge. After you do the grub work on mga7, it
will know/pickup mga6 and become the boot loader in charge.

although the complete Mga6
filesystem on Mga7 /run/media/*, has me wondering

That is a feature of your Desktop Environment. My suggested fstab entries should keep that from reoccurring.

I'll test it by booting Mga6. Salt the filesystem with something and
then boot Mga7 and see if it appears in the Mga6 file system in Mga7 /run/media/*

Dink around all you like. All I can do is give you suggestions on how to
make your setup a bit more manageable and easier to maintain.

If so the recursion will do my head in.

It is not a recursion. Unix/Linux allows you to mount any partition
anywhere you like, assuming you have the privileges to do the operation.

This is a far cry from the Lilo days

Yep, and I enjoy the flexibility and power provided by grub.


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 19/10/19 7:32 pm, Bit Twister wrote:

On Sat, 19 Oct 2019 18:08:38 +1100, faeychild wrote:

Will this be a dual boot of two independent systems

Yes. But I suggest one "Production" boot loader is to be in charge
of booting whichever install is desired.

I think I understand you are creating a mageia 6 mount point on mageia 7
root
and creating a mageia 7 mount point on mageia 6 root
Is this so?

Yes. One to keep you out of this /run/media thing, and more importantly, allow a backup script to backup the other install.

The run media thing is where USB sticks, phones etc are auto mounted and
is usually empty.
It was a big damn surprise to find root files system of Mga6 sitting there

I was originally trying for two independent systems selected from the
grub2 boot menu, which actually does work

Yep, mga7/grub had no knowledge of mga6 install.
mga6 grub install found mga7, and since it was installed last, it is
the boot loader in charge. After you do the grub work on mga7, it
will know/pickup mga6 and become the boot loader in charge.

That does make some sense to me also
OK Thanks Bits
Sunday is a bit quieter so I will instigate your instruction.

regards


--
faeychild
Running plasmashell 5.15.4 on 5.2.13-desktop-2.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 18/10/19 2:39 pm, Bit Twister wrote:

After you installed mga6, you should have booted mga7 an told mga7 grub
to generate a new grub.cfg, and install it as your "Production" boot loader.

I didn't know this bit

Read the last 4 lines of this reply, I'll wait . . . . . . . . . . . . .

I did run this one

So, as root, on booted mga7,
update-grub

This second instruction is the one I DIDN'T run after the installation
of Mga6

grub2-install /dev/XYZ At this point I will have to guess
that XYZ is nvme0n1

It is also nearly 23:00 and far too late be doing this .


regards
--
faeychild
Running plasmashell 5.15.4 on 5.2.13-desktop-2.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sat, 19 Oct 2019 22:42:36 +1100, faeychild wrote:

On 18/10/19 2:39 pm, Bit Twister wrote:

After you installed mga6, you should have booted mga7 an told mga7 grub
to generate a new grub.cfg, and install it as your "Production" boot loader.

I didn't know this bit

Normally it is not a problem because people usually install the
latest release last.

Read the last 4 lines of this reply, I'll wait . . . . . . . . . . . . .

I did run this one

So, as root, on booted mga7,
update-grub

That would put mga6 in mga7's grub.cfg.

This second instruction is the one I DIDN'T run after the installation
of Mga6

grub2-install /dev/XYZ At this point I will have to guess
that XYZ is nvme0n1

Which in your case leaves mga6 booting mga6's grub.cfg.

It is also nearly 23:00 and far too late be doing this .

Do keep in mind, regardless whichever grub is in charge, the default
setup is that grub will remember whichever install was booted, and
will become the default install to boot.

Case in point, you boot mga7, do all your grub work, reboot to verify systemrescuecd is back for selection, and boot mga7. Then mga7 will be
the default booted selection upon next power up.

At anytime you boot mga6, mga6 will become the default install to boot
from that point forward until you boot mga7.

For me, that setting is no good. After new kernel release, or a large
number of updates, I boot the previous release and run bkup_mga7.
That custom script mounts /hotbu and /mga7, rsync /mga7/ to /hotbu
then reboots. I do not want mag6, I want mga7 to boot.

To accomplish that I make a change to /etc/default/grub.
I change/set GRUB_SAVEDEFAULT=false
and run update-grub to implement the change, then run
grub2-set-default xxxxx to dictate which install I want as the
default install to boot.






--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 20/10/19 1:12 am, Bit Twister wrote:

On Sat, 19 Oct 2019 22:42:36 +1100, faeychild wrote:

On 18/10/19 2:39 pm, Bit Twister wrote:

After you installed mga6, you should have booted mga7 an told mga7 grub
to generate a new grub.cfg, and install it as your "Production" boot loader.

I didn't know this bit

Normally it is not a problem because people usually install the
latest release last.

The words "screwed up" do spring to mind

Do keep in mind, regardless whichever grub is in charge, the default
setup is that grub will remember whichever install was booted, and
will become the default install to boot.

Yes understood

Case in point, you boot mga7, do all your grub work, reboot to verify systemrescuecd is back for selection, and boot mga7. Then mga7 will be
the default booted selection upon next power up.

At anytime you boot mga6, mga6 will become the default install to boot
from that point forward until you boot mga7.

when I installed Mga6 "over" Mga7, I thought , This is not going to work
it's ass-about. I was surprised when it seemed to.

But after discovering that sysrescue had disappeared and Mga6 was
mounting Mga7's /run/media/etc.. I knew that it hadn't.

The current situation is a mess. Mga6 isn't important, it can go.


lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINT,PARTLABEL
NAME SIZE FSTYPE LABEL MOUNTPOINT PARTLABEL
sda 5.5T
└─sda1 5.5T ext4 video /video video
sdb 29.7G
└─sdb1 29.7G vfat /run/media/faeychild/6632-3731
sr0 1024M
nvme0n1 119.2G
├─nvme0n1p1 299M vfat efi ├─nvme0n1p2 22.3G ext4 mageia / mageia ├─nvme0n1p3 10.6G swap swap [SWAP] swap ├─nvme0n1p4 12.2G ext4 tmp /tmp tmp ├─nvme0n1p5 20.4G ext4 mageia_bu mageia_bu ├─nvme0n1p6 2G ext4 boot_iso boot_iso └─nvme0n1p7 24.9G ext4 mageia_6 /run/media/faeychild/mageia_6 mageia_6



So I am dithering,should I

implement your instructions

or run "grub2-install /dev/nvme0n1p2" from Mga7 as root

or abandon any attempt at rescue, remove mageia_6 and start again?

which is more effective/efficient??

regards



--
faeychild
Running plasmashell 5.15.4 on 5.2.13-desktop-2.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sun, 20 Oct 2019 06:34:10 +1100, faeychild wrote:

when I installed Mga6 "over" Mga7, I thought , This is not going to work
it's ass-about. I was surprised when it seemed to.

Of course it worked. You can also install other Linux OSs the same way.
Just remember last installed OS installed its bootloader.

But after discovering that sysrescue had disappeared and Mga6 was
mounting Mga7's /run/media/etc.. I knew that it hadn't.

One more time. What you are seeing is a function of your Display Environment.

Get an entry into fstab and create the mountpoint, log out/in and
magically no /run/media/etc.. for the other install.

The current situation is a mess. Mga6 isn't important, it can go.

lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINT,PARTLABEL
NAME SIZE FSTYPE LABEL MOUNTPOINT PARTLABEL sda 5.5T
└─sda1 5.5T ext4 video /video video sdb 29.7G
└─sdb1 29.7G vfat /run/media/faeychild/6632-3731
sr0 1024M
nvme0n1 119.2G
├─nvme0n1p1 299M vfat efi ├─nvme0n1p2 22.3G ext4 mageia / mageia ├─nvme0n1p3 10.6G swap swap [SWAP] swap ├─nvme0n1p4 12.2G ext4 tmp /tmp tmp ├─nvme0n1p5 20.4G ext4 mageia_bu

mageia_bu

├─nvme0n1p6 2G ext4 boot_iso

boot_iso

└─nvme0n1p7 24.9G ext4 mageia_6 /run/media/faeychild/mageia_6

mageia_6

So I am dithering,should I implement your instructions

Either that, or re-install mga7. :-D
and find out that your DE will still be helping you out by mounting
the other install in /var/run :(

or run "grub2-install /dev/nvme0n1p2" from Mga7 as root

I did not give you that command and it should get you some experience
on trying to recover mga7. :-(

or abandon any attempt at rescue, remove mageia_6 and start again?

Re-doing the mga6 install is just going to get you back to where you are
at this point in time.

which is more effective/efficient??

Based on your lack of regurgitating my instructions correctly for
mga7 boot loader install, I suggest creating the mount points,
updating /etc/fstab, installing the mga7 install media, boot it,
select rescue mode, select install boot loader, pick nvme0n1p2,
and let it re-install mga7 as the "Production" boot loader.

--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 20/10/19 7:32 am, Bit Twister wrote:

On Sun, 20 Oct 2019 06:34:10 +1100, faeychild wrote:

when I installed Mga6 "over" Mga7, I thought , This is not going to work
it's ass-about. I was surprised when it seemed to.

Of course it worked. You can also install other Linux OSs the same way.
Just remember last installed OS installed its bootloader.

I can see that now. I mistakenly expected grub to be independent of
installed OS's with a self contained boot list something like Lilo.
My error

But after discovering that sysrescue had disappeared and Mga6 was
mounting Mga7's /run/media/etc.. I knew that it hadn't.

One more time. What you are seeing is a function of your Display

Environment.

I tentatively agree but gparted shows the mount point of

/dev/nvme0n1p2 as "/run/media/faeychild/mageia_6" which I didn't declare.
I don't know if I gave it a mount point at all , I think I left it blank
like "mageia_bu" and "boot_iso" so if the DE can arrange it then I must
I agree with you

Get an entry into fstab and create the mountpoint, log out/in and
magically no /run/media/etc.. for the other install.

The current situation is a mess. Mga6 isn't important, it can go.


lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINT,PARTLABEL
NAME SIZE FSTYPE LABEL MOUNTPOINT PARTLABEL >> sda 5.5T
└─sda1 5.5T ext4 video /video video >> sdb 29.7G
└─sdb1 29.7G vfat /run/media/faeychild/6632-3731
sr0 1024M
nvme0n1 119.2G
├─nvme0n1p1 299M vfat efi
├─nvme0n1p2 22.3G ext4 mageia / mageia >> ├─nvme0n1p3 10.6G swap swap [SWAP] swap
├─nvme0n1p4 12.2G ext4 tmp /tmp tmp
├─nvme0n1p5 20.4G ext4 mageia_bu mageia_bu
├─nvme0n1p6 2G ext4 boot_iso boot_iso
└─nvme0n1p7 24.9G ext4 mageia_6 /run/media/faeychild/mageia_6 mageia_6



So I am dithering,should I implement your instructions

Either that, or re-install mga7. :-D
and find out that your DE will still be helping you out by mounting
the other install in /var/run :(

or run "grub2-install /dev/nvme0n1p2" from Mga7 as root

I did not give you that command and it should get you some experience
on trying to recover mga7. :-(

You did say:

***********
After you installed mga6, you should have booted mga7 an told mga7 grub
to generate a new grub.cfg, and install it as your "Production" boot loader.

Read the last 4 lines of this reply, I'll wait . . . . . . . . . . . . .

So, as root, on booted mga7,
update-grub
grub2-install /dev/XYZ At this point I will have to guess
that XYZ is nvme0n1
************


Which I interpreted to mean
run "grub2-install /dev/nvme0n1p2" from Mga7 as root

Based on your lack of regurgitating my instructions correctly for
mga7 boot loader install, I suggest creating the mount points,
updating /etc/fstab, installing the mga7 install media, boot it,
select rescue mode, select install boot loader, pick nvme0n1p2,
and let it re-install mga7 as the "Production" boot loader.

OK understood


--
faeychild
Running plasmashell 5.15.4 on 5.2.13-desktop-2.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sun, 20 Oct 2019 09:29:09 +1100, faeychild wrote:

On 20/10/19 7:32 am, Bit Twister wrote:

On Sun, 20 Oct 2019 06:34:10 +1100, faeychild wrote:

when I installed Mga6 "over" Mga7, I thought , This is not going to work >>> it's ass-about. I was surprised when it seemed to.

Of course it worked. You can also install other Linux OSs the same way.
Just remember last installed OS installed its bootloader.

I can see that now. I mistakenly expected grub to be independent of
installed OS's with a self contained boot list something like Lilo.

You are correct. grub.cfg is the self contained boot list used by the
installed grub, which you found out when you found a separate
grub.cfg in each install.

or run "grub2-install /dev/nvme0n1p2" from Mga7 as root

I did not give you that command and it should get you some experience
on trying to recover mga7. :-(

You did say:

***********
After you installed mga6, you should have booted mga7 an told mga7 grub
to generate a new grub.cfg, and install it as your "Production" boot loader.

Read the last 4 lines of this reply, I'll wait . . . . . . . . . . . . .

So, as root, on booted mga7,
update-grub
grub2-install /dev/XYZ At this point I will have to guess
that XYZ is nvme0n1
************

Which I interpreted to mean
run "grub2-install /dev/nvme0n1p2" from Mga7 as root

That "interpreted" is what will clobber something like the first 446
bytes of /dev/nvme0n1p2, which would probably be pointers to the start
of the list of files in that partition. :(

Read my lips, what is the difference between these two commands.

grub2-install /dev/nvme0n1p2 # hint :(
grub2-install /dev/nvme0n1 # hint :)

1 copies bytes into the start of partition nvme0n1p2 and
2 copies bytes into the start of drive nvme0n1

Those bytes tell the bios bootloader where to go to get the next
chunk of code to complete booting whatever is needed to continue what
is required to proceed with what to boot.

Based on your lack of regurgitating my instructions correctly for
mga7 boot loader install, I suggest creating the mount points,
updating /etc/fstab, installing the mga7 install media, boot it,
select rescue mode, select install boot loader, pick nvme0n1p2,
and let it re-install mga7 as the "Production" boot loader.

OK understood

Just to be clear, you are just using the mga7 rescue mode to pick
which install to use for booting, nvme0n1p2, and the installer will
use that grug and its grub.cfg, for booting and do the grub-install
to /dev/nvme0n1, not /dev/nvme0n1p2.



--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 20/10/19 9:47 am, Bit Twister wrote:

That "interpreted" is what will clobber something like the first 446
bytes of /dev/nvme0n1p2, which would probably be pointers to the start
of the list of files in that partition. :(

Read my lips, what is the difference between these two commands.

grub2-install /dev/nvme0n1p2 # hint :(
grub2-install /dev/nvme0n1 # hint :)

1 copies bytes into the start of partition nvme0n1p2 and
2 copies bytes into the start of drive nvme0n1

Ignorance on my part Bits

Sorry

Those bytes tell the bios bootloader where to go to get the next
chunk of code to complete booting whatever is needed to continue what
is required to proceed with what to boot.

I was focused on partition and not the drive and not realizing how it
all worked


I am still rendering video so I can't do anything yet other than
assemble my plan of action and go over the printed directions



regards
--
faeychild
Running plasmashell 5.15.4 on 5.2.13-desktop-2.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sun, 20 Oct 2019 15:11:17 +1100, faeychild wrote:

On 20/10/19 9:47 am, Bit Twister wrote:

That "interpreted" is what will clobber something like the first 446
bytes of /dev/nvme0n1p2, which would probably be pointers to the start
of the list of files in that partition. :(

Read my lips, what is the difference between these two commands.

grub2-install /dev/nvme0n1p2 # hint :(
grub2-install /dev/nvme0n1 # hint :)

1 copies bytes into the start of partition nvme0n1p2 and
2 copies bytes into the start of drive nvme0n1

Ignorance on my part Bits

Sorry

No apologize required. Had you looked up the program in man you
might have picked up an idea of what the command does.

Those bytes tell the bios bootloader where to go to get the next
chunk of code to complete booting whatever is needed to continue what
is required to proceed with what to boot.

I was focused on partition and not the drive and not realizing how it
all worked

I am still rendering video so I can't do anything yet other than
assemble my plan of action and go over the printed directions

Plans are good. Procedural steps with check boxes are better.


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 20/10/19 3:25 pm, Bit Twister wrote:

I am still rendering video so I can't do anything yet other than
assemble my plan of action and go over the printed directions

Plans are good. Procedural steps with check boxes are better.

Not a bad idea. I have the time to implement it


It's better than jumping back and forth through notes
--
faeychild
Running plasmashell 5.15.4 on 5.2.13-desktop-2.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Sun, 20 Oct 2019 15:35:17 +1100, faeychild wrote:

On 20/10/19 3:25 pm, Bit Twister wrote:

I am still rendering video so I can't do anything yet other than
assemble my plan of action and go over the printed directions

Plans are good. Procedural steps with check boxes are better.

Not a bad idea. I have the time to implement it

It's better than jumping back and forth through notes

Also best to break up the work where possible.

For instance, mkdir /mageia_6, add a line in /etc/fstab,
mount/umount /mageia_6 for verification, logout of user account,
log in and verify mga6 not mounted in /run directory. :)

I just noticed your .signature contents, looking like you are missing
a few updates.

$ uname -r
5.3.6-desktop-2.mga7

--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 20/10/19 4:17 pm, Bit Twister wrote:

$ uname -r
5.3.6-desktop-2.mga7

~]$ uname -r
5.2.13-desktop-2.mga7

There was an update about two days ago
Maybe my mirror is behind



--
faeychild
Running plasmashell 5.15.4 on 5.2.13-desktop-2.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 21/10/19 8:53 am, faeychild wrote:

On 20/10/19 4:17 pm, Bit Twister wrote:

$ uname -r
5.3.6-desktop-2.mga7

 ~]$ uname -r
5.2.13-desktop-2.mga7

There was an update about two days ago
Maybe my mirror is behind

No
kernel-desktop-5.3.6-2 is installed. I am just not running it :-(

I can't reboot yet either - still rendering


--
faeychild
Running plasmashell 5.15.4 on 5.2.13-desktop-2.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Mon, 21 Oct 2019 09:35:49 +1100, faeychild wrote:

On 21/10/19 8:53 am, faeychild wrote:

On 20/10/19 4:17 pm, Bit Twister wrote:

$ uname -r
5.3.6-desktop-2.mga7

 ~]$ uname -r
5.2.13-desktop-2.mga7

There was an update about two days ago
Maybe my mirror is behind

No
kernel-desktop-5.3.6-2 is installed. I am just not running it :-(

Yup, I can guess as a result of magaia_6 boot loader not being updated
after installing new mga7 kernel. :(


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 21/10/19 9:40 am, Bit Twister wrote:

Yup, I can guess as a result of magaia_6 boot loader not being updated
after installing new mga7 kernel. :(

I have rebooted.
It seems that I selected an older kernel sometime in the past or what
you said :-(

~]$ uname -r
5.3.6-desktop-2.mga7

Thanks for the heads up

--
faeychild
Running plasmashell 5.15.4 on 5.3.6-desktop-2.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 20/10/19 4:17 pm, Bit Twister wrote:

I found some free time today, Bits and almost made it

I reinstall of grub halted with
grub2-install error: cannot find EFI directory

There was no /boot/EFI directory in Mga7
There is an empty one in Mga6.
I created one in Mga7 but grub failed at the same point
Or is it looking for the EFI partition

What information do you require?


fstab Mga7

********************************************************************
#*
#* /etc/fstab Version 1.4
#* Created by ./fstab-label-3.sh Tue 17 Sep 06:41 2019
#*
#********************************************************************

LABEL=mageia / ext4 noatime,acl 1 1
LABEL=mageia_6 /mageia_6 ext4 noatime,users,noauto,acl 1 2
PARTLABEL=efi /efi vfat users,noauto,umask=000,iocharset=utf8 0 0
none /proc proc defaults 0 0
LABEL=tmp /tmp ext4 noatime,acl 1 2
LABEL=video /video ext4 noatime,acl 1 2
PARTLABEL=swap swap swap defaults 0 0
#****************** end /etc/fstab ******************


fstab Mga6

/dev/nvme0n1p7 / ext4 noatime,acl 1 1
LABEL=mageia /mageia ext4 noatime,users,noauto,acl 1 2
/dev/nvme0n1p1 /boot/EFI vfat umask=000,iocharset=utf8 0 0
none /proc proc defaults 0 0
/dev/nvme0n1p4 /tmp ext4 noatime,acl 1 2
# Entry for /dev/sda1 :
UUID=ddce96e5-77d9-45dd-b1c7-4bf10d42fff7 /video ext4 noatime,acl 1 2 /dev/nvme0n1p3 swap swap defaults 0 0



~]$ lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINT,PARTLABEL
NAME SIZE FSTYPE LABEL MOUNTPOINT PARTLABEL
sda 5.5T
└─sda1 5.5T ext4 video /video video
sr0 1024M
nvme0n1 119.2G
├─nvme0n1p1 299M vfat efi
├─nvme0n1p2 22.3G ext4 mageia / mageia
├─nvme0n1p3 10.6G swap swap [SWAP] swap
├─nvme0n1p4 12.2G ext4 tmp /tmp tmp
├─nvme0n1p5 20.4G ext4 mageia_bu mageia_bu
├─nvme0n1p6 2G ext4 boot_iso boot_iso
└─nvme0n1p7 24.9G ext4 mageia_6 mageia_6




regards
--
faeychild
Running plasmashell 5.15.4 on 5.2.13-desktop-2.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Tue, 22 Oct 2019 14:58:23 +1100, faeychild wrote:

On 20/10/19 4:17 pm, Bit Twister wrote:

I found some free time today, Bits and almost made it

I reinstall of grub halted with
grub2-install error: cannot find EFI directory

change efi line in /etc/fstab on mga7, to look like mga6
after change it could look like

# PARTLABEL=efi /efi vfat users,noauto,umask=000,iocharset=utf8 0 0 /dev/nvme0n1p1 /boot/EFI vfat umask=000,iocharset=utf8 0 0

after saving change, try
mount /boot/EFI
and run the grub2-install command again.

There was no /boot/EFI directory in Mga7
There is an empty one in Mga6.
I created one in Mga7 but grub failed at the same point
Or is it looking for the EFI partition

What information do you require?

fstab Mga7

********************************************************************
#*
#* /etc/fstab Version 1.4
#* Created by ./fstab-label-3.sh Tue 17 Sep 06:41 2019
#*
#********************************************************************

LABEL=mageia / ext4 noatime,acl 1 1
LABEL=mageia_6 /mageia_6 ext4 noatime,users,noauto,acl 1 2
PARTLABEL=efi /efi vfat users,noauto,umask=000,iocharset=utf8 0 0
none /proc proc defaults 0 0
LABEL=tmp /tmp ext4 noatime,acl 1 2
LABEL=video /video ext4 noatime,acl 1 2
PARTLABEL=swap swap swap defaults 0 0
#****************** end /etc/fstab ******************

fstab Mga6

/dev/nvme0n1p7 / ext4 noatime,acl 1 1
LABEL=mageia /mageia ext4 noatime,users,noauto,acl 1 2
/dev/nvme0n1p1 /boot/EFI vfat umask=000,iocharset=utf8 0 0
none /proc proc defaults 0 0
/dev/nvme0n1p4 /tmp ext4 noatime,acl 1 2
# Entry for /dev/sda1 :
UUID=ddce96e5-77d9-45dd-b1c7-4bf10d42fff7 /video ext4 noatime,acl 1 2 /dev/nvme0n1p3 swap swap defaults 0 0

~]$ lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINT,PARTLABEL
NAME SIZE FSTYPE LABEL MOUNTPOINT PARTLABEL
sda 5.5T
└─sda1 5.5T ext4 video /video video
sr0 1024M
nvme0n1 119.2G
├─nvme0n1p1 299M vfat efi
├─nvme0n1p2 22.3G ext4 mageia / mageia
├─nvme0n1p3 10.6G swap swap [SWAP] swap
├─nvme0n1p4 12.2G ext4 tmp /tmp tmp
├─nvme0n1p5 20.4G ext4 mageia_bu mageia_bu
├─nvme0n1p6 2G ext4 boot_iso boot_iso
└─nvme0n1p7 24.9G ext4 mageia_6 mageia_6

regards

--
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.

--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 22/10/19 3:49 pm, Bit Twister wrote:

I reinstall of grub halted with
grub2-install error: cannot find EFI directory

change efi line in /etc/fstab on mga7, to look like mga6
after change it could look like

# PARTLABEL=efi /efi vfat users,noauto,umask=000,iocharset=utf8 0 0 /dev/nvme0n1p1 /boot/EFI vfat umask=000,iocharset=utf8 0 0

after saving change, try
mount /boot/EFI
and run the grub2-install command again.

[root@unimatrix /]# mount /boot/EFI

[the first run failed to find "/boot/EFI"
I intended to log out but rebooted instead]

still!

mount: /boot/EFI: /dev/nvme0n1p1 already mounted on /boot/EFI.
[good now]

[root@unimatrix /]# grub2-install
Installing for x86_64-efi platform.
Installation finished. No error reported.

Systemrescue is back!!
and it works



Brilliant!,Bits
I couldn't pretend to follow what you did

You seemed to be mounting "A" on "B" and then mounting "B total" back
onto "A"

And as for fstab. I'll have to study that long and hard

Thank you Bits

Regards


--
faeychild
Running plasmashell 5.15.4 on 5.2.13-desktop-2.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Tue, 22 Oct 2019 18:00:17 +1100, faeychild wrote:

On 22/10/19 3:49 pm, Bit Twister wrote:

I reinstall of grub halted with
grub2-install error: cannot find EFI directory

change efi line in /etc/fstab on mga7, to look like mga6
after change it could look like

# PARTLABEL=efi /efi vfat users,noauto,umask=000,iocharset=utf8 0 0
/dev/nvme0n1p1 /boot/EFI vfat umask=000,iocharset=utf8 0 0

after saving change, try
mount /boot/EFI
and run the grub2-install command again.

[root@unimatrix /]# mount /boot/EFI

[the first run failed to find "/boot/EFI"
I intended to log out but rebooted instead]

still!

mount: /boot/EFI: /dev/nvme0n1p1 already mounted on /boot/EFI.
[good now]

[root@unimatrix /]# grub2-install
Installing for x86_64-efi platform.
Installation finished. No error reported.

Systemrescue is back!!
and it works

All right. You can now fix the fstab entry by removing the
# PARTLABEL=efi /efi vfat users,noauto,umask=000,iocharset=utf8 0 0

and change the /dev/nvme0n1p1 to PARTLABEL=efi Example:

PARTLABEL=efi /boot/EFI vfat umask=000,iocharset=utf8 0 0

Brilliant!,Bits
I couldn't pretend to follow what you did

Sorry for all the trouble with efi. I have no experience with it since
I set my bios to boot legacy OS. I had expected grub install to find
your efi directory via the partition flags. :(

You seemed to be mounting "A" on "B" and then mounting "B total" back
onto "A"

Not sure about what you are talking about. mga6 fstab is using the
efi partition. I had you comment out mga7 where I had suggested there
was no reason to be mounting it. I was wrong. It appears efi mode
needed /boot/EFI to be mounted whenever grub-install was executed.

If you are talking about mounting mga6 on mga7, and mga7 mounted on mga6.
That was to allow access from either install, needed for easier automation
of backing up the "Production" install and get you out of the /var/run/.... mounting of the other install by your Desktop Environment.

Oh, yeah, you might want to consider removing the older kernels on mga7
to reduce the mga 7 selections in the grub menu.



--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 22/10/19 6:44 pm, Bit Twister wrote:
\
I was intending posting last night but somewhere DNS fell over and the
only stuff that worked were addresses in the hosts file

All right. You can now fix the fstab entry by removing the
# PARTLABEL=efi /efi vfat users,noauto,umask=000,iocharset=utf8 0 0

and change the /dev/nvme0n1p1 to PARTLABEL=efi Example:

PARTLABEL=efi /boot/EFI vfat umask=000,iocharset=utf8 0 0

#********************************************************************
#*
#* /etc/fstab Version 1.4
#* Created by ./fstab-label-3.sh Tue 17 Sep 06:41 2019
#*
#********************************************************************

LABEL=mageia / ext4 noatime,acl 1 1
LABEL=mageia_6 /mageia_6 ext4 noatime,users,noauto,acl 1 2
#PARTLABEL=efi /efi vfat users,noauto,umask=000,iocharset=utf8 0 0 PARTLABEL=efi /boot/EFI vfat umask=000,iocharset=utf8 0 0
none /proc proc defaults 0 0
LABEL=tmp /tmp ext4 noatime,acl 1 2
LABEL=video /video ext4 noatime,acl 1 2
PARTLABEL=swap swap swap defaults 0 0
#****************** end /etc/fstab ******************

Brilliant!,Bits
I couldn't pretend to follow what you did

Sorry for all the trouble with efi. I have no experience with it since
I set my bios to boot legacy OS.

Why is your preference for legacy OS?

I had it a while back with Mga5 or 6 because either Diskdrake or I
couldn't get out stuff together.

I got lost in the bios setup to, and stampeded by a sense of urgency to
get a system up and running.

The problem with these activities is that are years apart and trying to remembering what you did last time

NOTES!!!!! :-) take notes!
Don't lose them




I had expected grub install to find

your efi directory via the partition flags. :(

not a problem
I like command line stuff. It's oddly satisfying

If something goes wrong/fails in a GUI, you are stuffed; what can you do?
Well you can strace or somewhat ironically, launch from a terminal - but
no guarantees!

But with command line, if it fails then the command either doesn't exist
or it's not in the path - easy to check - or usually in my case it's a typo

And that it self instructing


All my Kernels!! I don't know where they come from. It wasn't long ago I cleaned up last time.

Regards

--
faeychild
Running plasmashell 5.15.4 on 5.3.6-desktop-2.mga7 kernel.
Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Wed, 23 Oct 2019 07:47:10 +1100, faeychild wrote:

On 22/10/19 6:44 pm, Bit Twister wrote:
\
I was intending posting last night but somewhere DNS fell over and the
only stuff that worked were addresses in the hosts file

Yup, that is why I have static ip addresses wherever possible and I
installed bind to have named do look ups. Seen too many articles about criminals cracking into routers and changing dns server ip addresses.

All right. You can now fix the fstab entry by removing the
# PARTLABEL=efi /efi vfat users,noauto,umask=000,iocharset=utf8 0 0

and change the /dev/nvme0n1p1 to PARTLABEL=efi Example:

PARTLABEL=efi /boot/EFI vfat umask=000,iocharset=utf8 0 0

#********************************************************************
#*
#* /etc/fstab Version 1.4
#* Created by ./fstab-label-3.sh Tue 17 Sep 06:41 2019
#*
#********************************************************************

LABEL=mageia / ext4 noatime,acl 1 1
LABEL=mageia_6 /mageia_6 ext4 noatime,users,noauto,acl 1 2
#PARTLABEL=efi /efi vfat users,noauto,umask=000,iocharset=utf8 0 0 PARTLABEL=efi /boot/EFI vfat umask=000,iocharset=utf8 0 0
none /proc proc defaults 0 0
LABEL=tmp /tmp ext4 noatime,acl 1 2
LABEL=video /video ext4 noatime,acl 1 2
PARTLABEL=swap swap swap defaults 0 0
#****************** end /etc/fstab ******************

Go ahead and remove the #PARTLABEL= line.

Sorry for all the trouble with efi. I have no experience with it since
I set my bios to boot legacy OS.

Why is your preference for legacy OS?

As you have see so far, efi is more of a maintenance headache.
There is no extra entry in my fstab for it and grub-install does not
require gub_boot partition to be mounted.

I had it a while back with Mga5 or 6 because either Diskdrake or I
couldn't get our stuff together.

Yup, I have seen different grub2 releases fail to boot if grub-install
was not executed.

The problem with these activities is that are years apart and trying to remembering what you did last time

NOTES!!!!! :-) take notes!
Don't lose them

I'll repeat it, Procedural steps are better if you have not written
a script to do all the work for you.

All my Kernels!! I don't know where they come from. It wasn't long ago I cleaned up last time.

I hear that. I settled on a cron job to nag me about more than one
kernel installed. After kernel removal/reboot, I then run my backup
script just in case some other future update or a fat finger, senior moment, trashes my setup.



--- MBSE BBS v1.0.7.12A (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)