• Will Mageia 8 upgrade an MBR Mageia 7 system

    From Jim Beard@2:250/1 to All on Sat Apr 17 16:58:27 2021
    At some point, an upgrade to a new version of Mageia offered to convert
    to UEFI and upgrade to gpt. I chose to do so for my main machine, but
    left my backup machine on MBR.

    It is running Mageia 7, and still using MBR. I am inclined to allow the Mageia version update offered by mgaapplet, but am unsure if that will
    work.

    I am willing to let it upgrade from MBR to UEFI, if it will do that automatically. If all goes to Hotel, I can simply wipe the old disk,
    install from a DVD, and then update config files followed by backing up
    my main machine to this machine once again.

    Does anyone know what the attempt to automatically upgrade will do? Yes,
    I have read the Mageia website documentation but I am not entirely happy
    with my understanding of whether UEFI and/or gpt will be installed or not.

    Recommendations? (Yes, BitTwister, I do have an empty 80GB partition
    that I could install to, but what then happens with MBR vs UEFI and a few complete systems also on the same disk?)

    Cheers!

    jim b.

    --
    UNIX is not user-unfriendly, it merely expects users to be computer-
    friendly.

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From TJ@2:250/1 to All on Sat Apr 17 19:00:31 2021
    On 4/17/21 11:58 AM, Jim Beard wrote:
    At some point, an upgrade to a new version of Mageia offered to convert
    to UEFI and upgrade to gpt. I chose to do so for my main machine, but
    left my backup machine on MBR.

    It is running Mageia 7, and still using MBR. I am inclined to allow the Mageia version update offered by mgaapplet, but am unsure if that will
    work.

    I am willing to let it upgrade from MBR to UEFI, if it will do that automatically. If all goes to Hotel, I can simply wipe the old disk,
    install from a DVD, and then update config files followed by backing up
    my main machine to this machine once again.

    Does anyone know what the attempt to automatically upgrade will do? Yes,
    I have read the Mageia website documentation but I am not entirely happy
    with my understanding of whether UEFI and/or gpt will be installed or not.

    Recommendations? (Yes, BitTwister, I do have an empty 80GB partition
    that I could install to, but what then happens with MBR vs UEFI and a few complete systems also on the same disk?)

    Cheers!

    jim b.

    I just did one yesterday, and there were no problems. The was no offer
    to change anything having to do with the file systems themselves.
    Essentially, what it did was replace the M7 repos with M8 repos, then
    proceed as if it were any other big update. When finished, I rebooted
    just like with any other extensive update like that, and everything was
    good.

    I was given the option of downloading all the files at once if I wanted,
    but I declined because I was unsure of the free space available at that
    point off the top of my head. Somewhere near 2400 packages had to be downloaded and installed, and I was warned that it might take several
    hours, but it actually only took about 30 minutes, with a wifi
    connection on my home network.

    This was my brother's computer, and he doesn't have much of anything
    special installed, so YMMV.

    TJ

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Sat Apr 17 20:29:13 2021
    On Sat, 17 Apr 2021 11:58:27 -0400, Jim Beard <jim.beard@verizon.net> wrote:

    At some point, an upgrade to a new version of Mageia offered to convert
    to UEFI and upgrade to gpt. I chose to do so for my main machine, but
    left my backup machine on MBR.

    Upgrades have never supported converting like that, and it likely would not work.
    That must have been a new install erasing the existing partitions.

    The Mageia tools that handle booting check to see if /sys/firmware/efi exists. If it does, the system was booted in uefi firmware mode, and the installer and boot configuration tools will work assuming only uefi firmware mode will be used.
    If /sys/firmware/efi does not exist, only bios firmware mode will be used.

    It is running Mageia 7, and still using MBR. I am inclined to allow the Mageia version update offered by mgaapplet, but am unsure if that will
    work.

    It will, assuming no file conflicts between packages occurs, which can happen if third party rpm packages require versions of packages only available in mga7,
    which then interfere with the installation of the mga8 packages.

    So remove any third party rpm repos. The command "urpmq --list-media" should only
    show lines starting with Core, Nonfree, or Tainted. I.E. The Mageia 7 repos.

    Any packages shown by "urpmq --not-available" should be removed prior to starting
    the upgrade.

    Remove any 32 bit devel packages. See https://wiki.mageia.org/en/Mageia_8_Release_Notes#Upgrading_from_Mageia_7

    *** Make sure any screensaver has been disabled. ***

    I am willing to let it upgrade from MBR to UEFI, if it will do that automatically. If all goes to Hotel, I can simply wipe the old disk,
    install from a DVD, and then update config files followed by backing up
    my main machine to this machine once again.

    Does anyone know what the attempt to automatically upgrade will do? Yes,
    I have read the Mageia website documentation but I am not entirely happy
    with my understanding of whether UEFI and/or gpt will be installed or not.

    Recommendations? (Yes, BitTwister, I do have an empty 80GB partition
    that I could install to, but what then happens with MBR vs UEFI and a few complete systems also on the same disk?)

    Cheers!

    jim b.

    For an iso boot, the uefi boot menu will show at least two options for the Mageia
    boot media. One for uefi mode, one for bios mode. The wording varies depending on
    the uefi manufacturer, and sometimes the firmware version.

    Which one on those options is selected determines whether or not the Mageia installer
    is running in uefi mode (/sys/firmware/EFI directory exists), or bios firmware mode,
    and it will set up any install it does on the hard drive to work in the same way.

    On an upgrade using mgaapplet or urpmi, Mageia will never change between uefi and
    bios firmware mode.

    Whether the disk drive uses a mbr or gpt style partition table has nothing to do
    with whether the boot is done with uefi firmware mode or bios firmware mode.

    A drive with a mbr partition table can be used with either uefi or bios firmware
    mode.

    A drive with a gpt partition table can be used with either uefi or bios firmware
    mode.

    Exception to the above, is that some really badly written uefi firmware will not
    boot from a mbr partitioned hard drive. While I've read about the problem, I'm not
    aware of any Mageia users who have been affected by it.

    If anything is not clear, ask before you start the upgrade.

    There's no such thing as a stupid question. :-)

    Regards, Dave Hodgins

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

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Doug Laidlaw@2:250/1 to All on Sat Apr 17 20:39:31 2021
    On 18/4/21 4:00 am, TJ wrote:
    On 4/17/21 11:58 AM, Jim Beard wrote:
    At some point, an upgrade to a new version of Mageia offered to convert
    to UEFI and upgrade to gpt.  I chose to do so for my main machine, but
    left my backup machine on MBR.

    It is running Mageia 7, and still using MBR.  I am inclined to allow the
    Mageia version update offered by mgaapplet, but am unsure if that will
    work.

    I am willing to let it upgrade from MBR to UEFI, if it will do that
    automatically.  If all goes to Hotel, I can simply wipe the old disk,
    install from a DVD, and then update config files followed by backing up
    my main machine to this machine once again.

    Does anyone know what the attempt to automatically upgrade will do?  Yes, >> I have read the Mageia website documentation but I am not entirely happy
    with my understanding of whether UEFI and/or gpt will be installed or
    not.

    Recommendations?  (Yes, BitTwister, I do have an empty 80GB partition
    that I could install to, but what then happens with MBR vs UEFI and a few
    complete systems also on the same disk?)

    Cheers!

    jim b.

    I just did one yesterday, and there were no problems. The was no offer
    to change anything having to do with the file systems themselves. Essentially, what it did was replace the M7 repos with M8 repos, then proceed as if it were any other big update. When finished, I rebooted
    just like with any other extensive update like that, and everything was good.

    I was given the option of downloading all the files at once if I wanted,
    but I declined because I was unsure of the free space available at that point off the top of my head. Somewhere near 2400 packages had to be downloaded and installed, and I was warned that it might take several
    hours, but it actually only took about 30 minutes, with a wifi
    connection on my home network.

    This was my brother's computer, and he doesn't have much of anything
    special installed, so YMMV.

    TJ
    I think that TJ is right. Changing to GPT normally means wiping the
    whole drive, setting up the GPT partition table, then putting the data
    back, although theoretically it can be done on the disk as it stands. I
    don't know if anything but UEFI is available on the installation CDs
    nowadays, but updating an existing installation should not change the filesystem.

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: Aioe.org NNTP Server (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Sun Apr 18 01:09:58 2021
    On 2021-04-17, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    On Sat, 17 Apr 2021 11:58:27 -0400, Jim Beard <jim.beard@verizon.net> wrote:
    .....


    So remove any third party rpm repos. The command "urpmq --list-media" should only
    show lines starting with Core, Nonfree, or Tainted. I.E. The Mageia 7 repos.

    Any packages shown by "urpmq --not-available" should be removed prior to starting
    the upgrade.

    Hmm?
    I show 69 packages. Things like lib64digikamcore5-5.9.0-4.mga7.x86_64
    which surely should not need to be removed (it is a Mga package)


    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Sun Apr 18 02:01:25 2021
    On Sat, 17 Apr 2021 20:09:58 -0400, William Unruh <unruh@invalid.ca> wrote:
    I show 69 packages. Things like lib64digikamcore5-5.9.0-4.mga7.x86_64
    which surely should not need to be removed (it is a Mga package)

    But it's not one that was present in any of the qa testers installs when upgrades were being tested.

    The package is not in any of the Mageia 7 repos now. Most likely it was replaced
    by lib64digikamcore6 while Mageia 7 was still cauldron.

    Depending on what it and the other packages require, they may or may not cause file conflicts during upgrade. When a file conflict happens, not only does the package causing the conflict not get upgraded, but all of the other packages that
    happen to be in the same rpm transaction also do not get upgraded. How badly that
    impacts the upgrade depends on what those other packages are. It can lead to an install that will not be bootable, or where rpm itself fails to function. Fixing
    such issues can be a very difficult and tedious task.

    I don't know for a fact that any of those packages will cause problems, but I strongly recommend recommend removing them to be on the safe side.

    Regards, Dave Hodgins

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

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Jim Beard@2:250/1 to All on Sun Apr 18 16:24:26 2021
    TJ,

    I have free disk space over 60GB, so I think I will download all.
    Yes, I absolutely believe in abundance of memory, both in RAM
    and in storage disk.

    Doug,

    My main machine had two SSD plus two rust drives, with Windows
    at one time installed on an SSD from a usb 3.1 stick. Getting
    dual-boot working did involve wiping Windows at some point if I
    remember correctly, so gpt may well have been installed to a
    clean SSD or disk.

    Dave,

    urpmq --not available shows:

    brave-0.22.669-1.x86_64
    brave-browser-0.69.132-1.x86_64
    brave-keyring-1.3-1.fc30.noarch
    vivaldi-stable-1.10.867.48-1.x86_64
    opera-stable-66.0.3515.72-0.x86_64
    lib64ass5-0.13.4-1.mga5.x86_64
    lib64cdio-paranoia1-10.2.0.90.1-7.mga5.x86_64
    lib64cdio15-0.92-3.mga5.x86_64

    The last three I think came from Jeorg Schily's cdrkit software,
    and must be obsolete. It works, though, and I am inclined to
    keep them plus the opera and vivaldi browser packages.

    I almost never use the brave browser, so removing it and not
    putting it back would seem the way to go.

    More comments from anyone?

    Cheers!

    jim b.

    --
    UNIX is not user-unfriendly, it merely expects users to be computer-
    friendly.

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Sun Apr 18 16:37:45 2021
    On Sat, 17 Apr 2021 15:58:27 -0000 (UTC), Jim Beard wrote:
    At some point, an upgrade to a new version of Mageia offered to convert
    to UEFI and upgrade to gpt. I chose to do so for my main machine, but
    left my backup machine on MBR.

    It is running Mageia 7, and still using MBR. I am inclined to allow the Mageia version update offered by mgaapplet, but am unsure if that will
    work.

    I never use the mgaapplet. I download all rpms and if test reports success
    I then do the install. That assumes there is room for rpms. I also want
    a log of what happened. You can test as follows:

    script -c "urpmi --clean ; urpmi --downloader wget --wait-lock \
    --replacefiles --auto-update --auto --download-all --test" pull_updates.log

    To do the actual install:

    script -c "urpmi --downloader wget --wait-lock --replacefiles \
    --auto-update --auto --download-all " install_updates.log


    I am willing to let it upgrade from MBR to UEFI, if it will do that automatically. If all goes to Hotel, I can simply wipe the old disk,
    install from a DVD, and then update config files followed by backing up
    my main machine to this machine once again.

    Does anyone know what the attempt to automatically upgrade will do?

    I would defiantly do a / backup to another partition in case upgrade does
    not go well.

    Yes,
    I have read the Mageia website documentation but I am not entirely happy
    with my understanding of whether UEFI and/or gpt will be installed or not.

    Recommendations? (Yes, BitTwister, I do have an empty 80GB partition
    that I could install to, but what then happens with MBR vs UEFI and a few complete systems also on the same disk?)

    If you do a clean mga8 then the grub menu will have all installs for
    selection.

    My installs had a problem selecting UEFI/CMS Legacy type installs.

    Tracked it down to setting the Bios to boot CMS Legacy OS only.
    After that installs no longer asked UEFI question.



    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Sun Apr 18 16:56:03 2021
    On Sun, 18 Apr 2021 00:09:58 -0000 (UTC), William Unruh wrote:
    On 2021-04-17, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    On Sat, 17 Apr 2021 11:58:27 -0400, Jim Beard <jim.beard@verizon.net> wrote:
    ....


    So remove any third party rpm repos. The command "urpmq --list-media" should only
    show lines starting with Core, Nonfree, or Tainted. I.E. The Mageia 7 repos. >>
    Any packages shown by "urpmq --not-available" should be removed prior to starting
    the upgrade.

    Hmm? I show 69 packages.

    I do love a clean install:
    $ urpmq --not-available
    brscan4-0.4.9-1.x86_64
    hll2380dwcupswrapper-3.2.0-1.i386
    brscan-skey-0.3.1-1.x86_64
    zoom-5.6.13632.0328-1.x86_64
    hll2380dwlpr-3.2.0-1.i386

    Things like lib64digikamcore5-5.9.0-4.mga7.x86_64
    which surely should not need to be removed (it is a Mga package)

    If package/rpm have been upgraded it should be removed.

    If I misunderstand it correctly, if you manually install a package twice
    it will not automatically be removed during updates.

    I can not find the name of the file where the package/rpm name is removed
    when you "urpmi pkg" when pkg is already installed.

    If someone knows, I would appreciate a reply about its name.
    Thanks in advance.



    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Sun Apr 18 17:18:35 2021
    On Sun, 18 Apr 2021 11:24:26 -0400, Jim Beard <jim.beard@verizon.net> wrote:
    urpmq --not available shows:

    brave-0.22.669-1.x86_64
    brave-browser-0.69.132-1.x86_64
    brave-keyring-1.3-1.fc30.noarch
    vivaldi-stable-1.10.867.48-1.x86_64
    opera-stable-66.0.3515.72-0.x86_64
    lib64ass5-0.13.4-1.mga5.x86_64
    lib64cdio-paranoia1-10.2.0.90.1-7.mga5.x86_64
    lib64cdio15-0.92-3.mga5.x86_64

    The last three I think came from Jeorg Schily's cdrkit software,
    and must be obsolete. It works, though, and I am inclined to
    keep them plus the opera and vivaldi browser packages.

    Definitely remove the mga5 packages. I'd remove the others too, and then try re-installing them after the upgrade, if desired.

    Regards, Dave Hodgins

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

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Jim Beard@2:250/1 to All on Sun Apr 18 17:47:51 2021
    On Sun, 18 Apr 2021 12:18:35 -0400, David W. Hodgins wrote:

    On Sun, 18 Apr 2021 11:24:26 -0400, Jim Beard <jim.beard@verizon.net>
    wrote:
    urpmq --not available shows:

    brave-0.22.669-1.x86_64 brave-browser-0.69.132-1.x86_64
    brave-keyring-1.3-1.fc30.noarch
    vivaldi-stable-1.10.867.48-1.x86_64
    opera-stable-66.0.3515.72-0.x86_64
    lib64ass5-0.13.4-1.mga5.x86_64
    lib64cdio-paranoia1-10.2.0.90.1-7.mga5.x86_64
    lib64cdio15-0.92-3.mga5.x86_64

    The last three I think came from Jeorg Schily's cdrkit software,
    and must be obsolete. It works, though, and I am inclined to keep them
    plus the opera and vivaldi browser packages.

    Definitely remove the mga5 packages. I'd remove the others too, and then
    try re-installing them after the upgrade, if desired.

    Ok. The mga5 packages and the brave packages will be removed. Vivaldi
    has not been updated in a long while, so it goes too.

    That leaves opera. I'll trust it to not cause a problem.

    Cheers!

    jim b.

    --
    UNIX is not user-unfriendly, it merely expects users to be computer-
    friendly.

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From TJ@2:250/1 to All on Sun Apr 18 17:51:51 2021
    On 4/18/21 11:24 AM, Jim Beard wrote:
    The last three I think came from Jeorg Schily's cdrkit software,
    and must be obsolete. It works, though, and I am inclined to
    keep them
    Wow. Except for the occasional Mageia iso test, I haven't burned any
    optical media in years. There was a time when I was using optical media
    for backup, but I found that while commercially-burned media holds up
    well in storage, consumer-burned media isn't as reliable over time. I
    use external hard drives for that now. Faster, more reliable, less
    expensive, and takes up a LOT less physical space.

    I didn't even bother with an optical drive in the last desktop I built,
    and I replaced the DVD burner from my HP Probook's "Upgrade bay" with an adapter for a hard drive. I did buy a USB case for the laptop's drive,
    though, so I do have one on the very rare times when I need it.

    TJ

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Sun Apr 18 18:46:18 2021
    On Sun, 18 Apr 2021 11:56:03 -0400, Bit Twister <BitTwister@mouse-potato.com> wrote:
    If I misunderstand it correctly, if you manually install a package twice
    it will not automatically be removed during updates.
    I can not find the name of the file where the package/rpm name is removed when you "urpmi pkg" when pkg is already installed.

    The two points your referring to are orphans and version/release handling.

    When a package is selected for installation, all packages it requires that haven't
    already been installed, get installed and added to the list stored in /var/lib/rpm/installed-through-deps.list

    If the explicitly selected package is uninstalled, the packages in the deps.list
    become orphans, which can be uninstalled using urpme --auto-orphans.

    If one of those already installed dependencies is explicitly installed then it isn't re-installed since it's already installed, but is removed from the deps.list
    file. It will no longer be included in the list used by auto-orphans.

    When an update is being installed, if it's a new version, the old version will not be removed unless the packager has explicitly included it's removal in the scripts built-in to the rpm file.

    If it's a new release of an already installed version, the old release is removed
    when the new one is installed.

    Once a new version of Mageia is released, new versions of packages are not allowed
    (with some exceptions), just new releases of the already included version.
    The exceptions are documented at https://wiki.mageia.org/en/Updates_policy#Version_Policy

    The reason for the restrictions is to keep each stable release as stable as we can.

    Regards, Dave Hodgins

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

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Sun Apr 18 19:27:44 2021
    On 2021-04-18, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    On Sun, 18 Apr 2021 11:24:26 -0400, Jim Beard <jim.beard@verizon.net> wrote:
    urpmq --not available shows:

    brave-0.22.669-1.x86_64
    brave-browser-0.69.132-1.x86_64
    brave-keyring-1.3-1.fc30.noarch
    vivaldi-stable-1.10.867.48-1.x86_64
    opera-stable-66.0.3515.72-0.x86_64
    lib64ass5-0.13.4-1.mga5.x86_64
    lib64cdio-paranoia1-10.2.0.90.1-7.mga5.x86_64
    lib64cdio15-0.92-3.mga5.x86_64

    The last three I think came from Jeorg Schily's cdrkit software,
    and must be obsolete. It works, though, and I am inclined to
    keep them plus the opera and vivaldi browser packages.

    No. cdio is a separate program from the cdrtools package that is
    Schilly's. cdrkit is a different program again which has nothing to do
    with Schilly except that it is based on an old version of cdrtools.
    Anyway, in Mageai 7 it is up to version 18 not 15.
    libass is something else again.


    Definitely remove the mga5 packages. I'd remove the others too, and then try re-installing them after the upgrade, if desired.

    Regards, Dave Hodgins


    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Sun Apr 18 19:35:51 2021
    On 2021-04-18, Bit Twister <BitTwister@mouse-potato.com> wrote:
    If package/rpm have been upgraded it should be removed.

    The problem is that the various packages change the version number which
    is part of the name. Thus urpmi has no idea that this is a replacement,
    and you are left with two installations which are really the same functionality. Since I have about 4000 packages installed, there is no
    way I can search through them to see if there is a conflict.

    If I misunderstand it correctly, if you manually install a package twice
    it will not automatically be removed during updates.

    I can not find the name of the file where the package/rpm name is removed when you "urpmi pkg" when pkg is already installed.

    If pkg is already installed, urpmi will not reinstall it, unless you
    give the right flag to urpmi. However is package with name pkg6 in in
    the updates/newversion, and you have pkg5, then urpmi does not know that
    pkg6 is supposed to replace pkg5, because they have different names. It
    may complain about duplicate filenames, but also may not. rpm -Va may
    list the earlier one as having errors, because the later one replaced a
    file in the earlier one, and thus the hashes do not agree.


    If someone knows, I would appreciate a reply about its name.
    Thanks in advance.



    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Sun Apr 18 19:41:03 2021
    On 2021-04-18, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    On Sun, 18 Apr 2021 11:56:03 -0400, Bit Twister <BitTwister@mouse-potato.com> wrote:
    If I misunderstand it correctly, if you manually install a package twice
    it will not automatically be removed during updates.
    I can not find the name of the file where the package/rpm name is removed
    when you "urpmi pkg" when pkg is already installed.

    The two points your referring to are orphans and version/release handling.

    When a package is selected for installation, all packages it requires that haven't
    already been installed, get installed and added to the list stored in /var/lib/rpm/installed-through-deps.list

    If the explicitly selected package is uninstalled, the packages in the deps.list
    become orphans, which can be uninstalled using urpme --auto-orphans.

    That is quite likely to totally destoy your installation. Some of those
    orphans are fake rpms whose only purpose is to install/remove a whole
    pile of packages, and if it is in the orphans list, all of those
    packages are removed (not excepting the kernels).



    If one of those already installed dependencies is explicitly installed then it
    isn't re-installed since it's already installed, but is removed from the deps.list
    file. It will no longer be included in the list used by auto-orphans.

    When an update is being installed, if it's a new version, the old version will
    not be removed unless the packager has explicitly included it's removal in the
    scripts built-in to the rpm file.

    If it's a new release of an already installed version, the old release is removed
    when the new one is installed.

    Once a new version of Mageia is released, new versions of packages are not allowed
    (with some exceptions), just new releases of the already included version. The exceptions are documented at https://wiki.mageia.org/en/Updates_policy#Version_Policy

    The reason for the restrictions is to keep each stable release as stable as we can.

    Regards, Dave Hodgins


    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Sun Apr 18 20:20:16 2021
    On Sun, 18 Apr 2021 14:35:51 -0400, William Unruh <unruh@invalid.ca> wrote:
    The problem is that the various packages change the version number which
    is part of the name. Thus urpmi has no idea that this is a replacement,
    and you are left with two installations which are really the same functionality. Since I have about 4000 packages installed, there is no
    way I can search through them to see if there is a conflict.

    It's relatively rare for a package to change name. It does happen, and it's
    up to the packager to ensure that either both packages can be installed safely together, or the newer one removes the older one using scripts or the obsoletes rpm tag.

    If pkg is already installed, urpmi will not reinstall it, unless you
    give the right flag to urpmi. However is package with name pkg6 in in
    the updates/newversion, and you have pkg5, then urpmi does not know that
    pkg6 is supposed to replace pkg5, because they have different names. It
    may complain about duplicate filenames, but also may not. rpm -Va may
    list the earlier one as having errors, because the later one replaced a
    file in the earlier one, and thus the hashes do not agree.

    The rpm package manager does allow two packages to own/include the same file if and only if the two copies of the file are byte for byte identical.

    When they are not identical, that will cause which ever one is being installed second to fail with a file conflicts message. Any packages that happen to have been included in the same rpm transaction will also not be installed. Those types
    of errors are the ones that can cause cascading errors during an upgrade and potentially lead to a failed upgrade that may not even boot.

    It's finding those types of errors and getting them fixed that held up turning on the upgrading using mgaapplet for a month or so after Mageia 8 was released. I literally did dozens of upgrade tests with a very wide variety of Mageia packages
    installed, and with different combinations of packages installed, to try and find
    those types of errors and ensure they were fixed properly. I am just one of the many
    people who tested upgrading before turning on the mgaapplet upgrades.

    It's also because that type of error can have such severe consequences, that I strongly recommend removing any third party packages or packages shown by urpmq --not-available, since those packages were not included in our testing. They may
    not cause any problems, but if they cause file conflicts, the upgrade may fail. Recovering from a failed upgrade is always possible, but can be very difficult.

    One example where the package names do include the version in mga7 is python and python3. While they are both versions of python, the do not share any files, either by using different file names or different directory names. They are intentionally packaged that way to ensure they can both be safely installed together and will not cause file conflicts.

    Regards, Dave Hodgins

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

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Sun Apr 18 19:53:50 2021
    On Sun, 18 Apr 2021 14:41:03 -0400, William Unruh <unruh@invalid.ca> wrote:
    That is quite likely to totally destoy your installation. Some of those orphans are fake rpms whose only purpose is to install/remove a whole
    pile of packages, and if it is in the orphans list, all of those
    packages are removed (not excepting the kernels).

    Using "urpme --auto-orphans" must only be done with extreme caution as explained
    with an example at https://wiki.mageia.org/en/Removing_packages#Warning

    Regards, Dave Hodgins

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

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Jim Beard@2:250/1 to All on Mon Apr 19 00:43:43 2021
    On Sat, 17 Apr 2021 15:58:27 +0000, Jim Beard wrote:

    It is running Mageia 7, and still using MBR. I am inclined to allow the Mageia version update offered by mgaapplet, but am unsure if that will
    work.

    I used the mgaapplet upgrade, over the 'Net, and it worked.

    Upgrading by installing Mageia 8 over Mageia 7 was slow, though.
    There were over 3,100 rpm packages to install, and that was done
    in batches 450-600 packages each, even though I had clicked to
    download all first and then install all at once.

    It did take 2-3 hours for all the downloading-installing-
    verifying-removing old packages to complete. I could have
    downloaded a DVD iso and installed that in probably a half
    hour or so, but then all my configurations and tinkering
    would have remained, as well as copying over files I wanted
    to keep from Mageia 7. Plus, the DVD would not have had
    more than a basic install, not 3100 files including Gnome,
    KDE5, and another desktop or two that was on this machine
    from earlier times.

    There was some tinkering required. Opera crashed now and then,
    and though it reported it was up to date I went to the Opera
    web site and found a much later version. Downloaded the rpm
    install version (Opera gives you the deb version if you do not
    specify) and used rpm -U opera... to install that as an upgrade
    version. Some tinkering within opera required to get it the
    way I wanted, but that was an opera thing, not Mageia.

    The Mageia 8 installer did provide grub and a graphic screen
    for login. I decided to change to grub2. MCC provided that
    change and, and while I was at it selected grub2 - text which
    brought back my level 3 boot to a terminal window.

    Display resolution and colors had to be set specifically for
    my monitor to get it off on the right foot during boot.

    I expect minor tinkering to be needed here and there, but
    by and large I am quite happy with the upgrade.

    Cheers!

    jim b.

    --
    UNIX is not user-unfriendly, it merely expects users to be computer-
    friendly.

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Mon Apr 19 01:04:47 2021
    On 19/4/21 9:43 am, Jim Beard wrote:


    It did take 2-3 hours for all the downloading-installing-
    verifying-removing old packages to complete. I could have
    downloaded a DVD iso and installed that in probably a half


    FWIW Jim, installing from a USB stick is much faster.

    I have a few writable dvd's left and wonder is it worth getting some
    more stock. I have changed my mind about installing Blu-ray burner. I
    doubt that it would ever be used.

    Optical media seems to be going the way of floppies

    I have moved over to USB sticks mostly or even SC cards in a reader

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


    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Mon Apr 19 02:51:20 2021
    On Sun, 18 Apr 2021 18:35:51 -0000 (UTC), William Unruh wrote:
    On 2021-04-18, Bit Twister <BitTwister@mouse-potato.com> wrote:
    If package/rpm have been upgraded it should be removed.

    The problem is that the various packages change the version number which
    is part of the name. Thus urpmi has no idea that this is a replacement,
    and you are left with two installations which are really the same functionality. Since I have about 4000 packages installed, there is no
    way I can search through them to see if there is a conflict.

    If I misunderstand it correctly, if you manually install a package twice
    it will not automatically be removed during updates.

    I can not find the name of the file where the package/rpm name is removed
    when you "urpmi pkg" when pkg is already installed.

    If pkg is already installed, urpmi will not reinstall it,

    Very true, but

    unless you give the right flag to urpmi. However is package with
    name pkg6 in in the updates/newversion, and you have pkg5,

    You did not hear what I said. All I was talking about is what happens
    when you run urpmi to install the same package.


    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Mon Apr 19 16:56:30 2021
    On 2021-04-18, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    On Sun, 18 Apr 2021 14:35:51 -0400, William Unruh <unruh@invalid.ca> wrote:
    The problem is that the various packages change the version number which
    is part of the name. Thus urpmi has no idea that this is a replacement,
    and you are left with two installations which are really the same
    functionality. Since I have about 4000 packages installed, there is no
    way I can search through them to see if there is a conflict.

    It's relatively rare for a package to change name. It does happen, and it's up to the packager to ensure that either both packages can be installed safely
    together, or the newer one removes the older one using scripts or the obsoletes
    rpm tag.

    Well no, it is not rare. Almost all of the lib packages have their version number as part of the name.



    lib64isccfg163, lib64rpm8,...
    i---------------------------
    tunnel:0.0[unruh]>rpm -q lib64rpm
    package lib64rpm is not installed
    tunnel:0.0[unruh]>rpm -q lib64rpm8
    lib64rpm8-4.14.3-1.mga7
    ----------------------------

    I remember when gimp2 came out, having to clean up because gimp was left
    behind and there were conflicts (same filenames, but different files)
    and I had to remove gimp, and force reinstall of gimp2 just in case the
    erasure of gimp had removed some files of gimp2.





    If pkg is already installed, urpmi will not reinstall it, unless you
    give the right flag to urpmi. However is package with name pkg6 in in
    the updates/newversion, and you have pkg5, then urpmi does not know that
    pkg6 is supposed to replace pkg5, because they have different names. It
    may complain about duplicate filenames, but also may not. rpm -Va may
    list the earlier one as having errors, because the later one replaced a
    file in the earlier one, and thus the hashes do not agree.

    The rpm package manager does allow two packages to own/include the same file if
    and only if the two copies of the file are byte for byte identical.

    When they are not identical, that will cause which ever one is being installed
    second to fail with a file conflicts message. Any packages that happen to have
    been included in the same rpm transaction will also not be installed. Those types
    of errors are the ones that can cause cascading errors during an upgrade and potentially lead to a failed upgrade that may not even boot.

    It's finding those types of errors and getting them fixed that held up turning
    on the upgrading using mgaapplet for a month or so after Mageia 8 was released.
    I literally did dozens of upgrade tests with a very wide variety of Mageia packages
    installed, and with different combinations of packages installed, to try and find
    those types of errors and ensure they were fixed properly. I am just one of the many
    people who tested upgrading before turning on the mgaapplet upgrades.

    It's also because that type of error can have such severe consequences, that I
    strongly recommend removing any third party packages or packages shown by urpmq
    --not-available, since those packages were not included in our testing. They may
    not cause any problems, but if they cause file conflicts, the upgrade may fail.
    Recovering from a failed upgrade is always possible, but can be very difficult.

    One example where the package names do include the version in mga7 is python and python3. While they are both versions of python, the do not share any files, either by using different file names or different directory names. They
    are intentionally packaged that way to ensure they can both be safely installed
    together and will not cause file conflicts.

    Regards, Dave Hodgins


    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Mon Apr 19 17:05:33 2021
    On 2021-04-18, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    On Sun, 18 Apr 2021 14:41:03 -0400, William Unruh <unruh@invalid.ca> wrote:
    That is quite likely to totally destoy your installation. Some of those
    orphans are fake rpms whose only purpose is to install/remove a whole
    pile of packages, and if it is in the orphans list, all of those
    packages are removed (not excepting the kernels).

    Using "urpme --auto-orphans" must only be done with extreme caution as explained
    with an example at https://wiki.mageia.org/en/Removing_packages#Warning

    And yet every time I update, I get the message telling me that to remove
    the orphans, to just run the --auto-orphans. I know this has been
    discussed, and there is that warning ( which I suspect a miniscule
    percentage of Mageia users have read), but the advice that every user
    reads every time they update remains the same.
    You can force reinstall of every one of those orphaned packages to get
    rid of the message, but that is a real real pain. The auto-orphan
    message is useful for testers, I understand, who expect to have
    something destroy their installation ( that is why they are testing).
    For users it is nasty leg-hold-spring-trap.



    Regards, Dave Hodgins


    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From grimble@2:250/1 to All on Thu Apr 22 18:58:10 2021
    On 19/04/2021 01:04, faeychild wrote:
    On 19/4/21 9:43 am, Jim Beard wrote:


    It did take 2-3 hours for all the downloading-installing-
    verifying-removing old packages to complete.  I could have
    downloaded a DVD iso and installed that in probably a half


    FWIW Jim,  installing from a USB stick is much faster.

    I have a few writable dvd's left and wonder is it worth getting some
    more stock.  I have changed my mind about installing Blu-ray burner. I doubt that it would ever be used.

    Optical media seems to be going the way of floppies

    I have moved over to USB sticks mostly or even SC cards in a reader

    regards
    I have a new machine with solid state drives - Mageia 8 installed in
    less than 8 minutes from a USB stick. I have done two other upgrades,
    both of which went faultlessly. I was so pleased, I made a donation to
    the Mageia foundation.

    --
    Grimble
    Machine 'mozart' running Plasma 5.20.4 on 5.10.30-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Fri Apr 23 08:19:22 2021
    On 23/4/21 3:58 am, grimble wrote:

    regards
    I have a new machine with solid state drives - Mageia 8 installed in
    less than 8 minutes from a USB stick. I have done two other upgrades,
    both of which went faultlessly. I was so pleased, I made a donation to
    the Mageia foundation.


    Same experience here, in fact post configuration can seem to take longer
    than the install

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


    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Jim Beard@2:250/1 to All on Sun Apr 25 01:17:32 2021
    On Sat, 17 Apr 2021 15:29:13 -0400, David W. Hodgins wrote:

    On Sat, 17 Apr 2021 11:58:27 -0400, Jim Beard <jim.beard@verizon.net>
    wrote:

    At some point, an upgrade to a new version of Mageia offered to convert
    to UEFI and upgrade to gpt. I chose to do so for my main machine, but
    left my backup machine on MBR.

    Upgrades have never supported converting like that, and it likely would
    not work. That must have been a new install erasing the existing
    partitions.

    The Mageia tools that handle booting check to see if /sys/firmware/efi exists.
    If it does, the system was booted in uefi firmware mode, and the
    installer and boot configuration tools will work assuming only uefi
    firmware mode will be used.
    If /sys/firmware/efi does not exist, only bios firmware mode will be
    used.

    It is running Mageia 7, and still using MBR. I am inclined to allow
    the Mageia version update offered by mgaapplet, but am unsure if that
    will work.

    It will, assuming no file conflicts between packages occurs, which can
    happen if third party rpm packages require versions of packages only available in mga7, which then interfere with the installation of the
    mga8 packages.

    So remove any third party rpm repos. The command "urpmq --list-media"
    should only show lines starting with Core, Nonfree, or Tainted. I.E. The Mageia 7 repos.

    Any packages shown by "urpmq --not-available" should be removed prior to starting the upgrade.

    Remove any 32 bit devel packages. See
    https://wiki.mageia.org/en/
    Mageia_8_Release_Notes#Upgrading_from_Mageia_7

    *** Make sure any screensaver has been disabled. ***

    I am willing to let it upgrade from MBR to UEFI, if it will do that
    automatically. If all goes to Hotel, I can simply wipe the old disk,
    install from a DVD, and then update config files followed by backing up
    my main machine to this machine once again.

    Does anyone know what the attempt to automatically upgrade will do?
    Yes, I have read the Mageia website documentation but I am not entirely
    happy with my understanding of whether UEFI and/or gpt will be
    installed or not.

    Recommendations? (Yes, BitTwister, I do have an empty 80GB partition
    that I could install to, but what then happens with MBR vs UEFI and a
    few complete systems also on the same disk?)

    Cheers!

    jim b.

    For an iso boot, the uefi boot menu will show at least two options for
    the Mageia boot media. One for uefi mode, one for bios mode. The wording varies depending on the uefi manufacturer, and sometimes the firmware version.

    Which one on those options is selected determines whether or not the
    Mageia installer is running in uefi mode (/sys/firmware/EFI directory exists), or bios firmware mode, and it will set up any install it does
    on the hard drive to work in the same way.

    On an upgrade using mgaapplet or urpmi, Mageia will never change between
    uefi and bios firmware mode.

    Whether the disk drive uses a mbr or gpt style partition table has
    nothing to do with whether the boot is done with uefi firmware mode or
    bios firmware mode.

    A drive with a mbr partition table can be used with either uefi or bios firmware mode.

    A drive with a gpt partition table can be used with either uefi or bios firmware mode.

    Exception to the above, is that some really badly written uefi firmware
    will not boot from a mbr partitioned hard drive. While I've read about
    the problem, I'm not aware of any Mageia users who have been affected by
    it.

    If anything is not clear, ask before you start the upgrade.

    There's no such thing as a stupid question. :-)

    Last-minute questions before installing Mageia 8 on my laptop.

    The laptop was delivered with Windows 8 only, which was reworked to dual
    boot. At some point Win 8 was replaced witn Win10. At some point,
    /boot/EFI (empty) was created. /sys/firmware/EFI directory does not
    exist. The menu.lst in /boot/grub appears to control boot, but grub2 has
    been installed and there is a grub2.cfg in /grub2/ that has multiple
    instances of a line set root 'hd7,gpt' and the kernel loaded would be an
    old Mageia 7 kernel.

    When I go to setup boot in MCC, it shows me grub text.

    How can I determine definitely if gpt or uefi are involved?

    The Mageia 8 DVD installer offers a choice of UEFI or BIOS install.

    Can I install UEFI to a empty partition? If so, how will that affect
    using old partitions containing Mageia 6, Mageia 7, and Win 10 if they
    were installed under BIOS ???

    Ideas on what and how to check? How to install?

    Cheers!

    jim b.

    --
    UNIX is not user-unfriendly, it merely expects users to be computer-
    friendly.

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Sun Apr 25 02:21:08 2021
    On Sat, 24 Apr 2021 20:17:32 -0400, Jim Beard <jim.beard@verizon.net> wrote:
    Last-minute questions before installing Mageia 8 on my laptop.

    The laptop was delivered with Windows 8 only, which was reworked to dual boot. At some point Win 8 was replaced witn Win10. At some point,
    /boot/EFI (empty) was created. /sys/firmware/EFI directory does not
    exist. The menu.lst in /boot/grub appears to control boot, but grub2 has been installed and there is a grub2.cfg in /grub2/ that has multiple instances of a line set root 'hd7,gpt' and the kernel loaded would be an
    old Mageia 7 kernel.

    If /sys/firmware/efi (note lowercase) does not exist then the currently running system is using bios firmware mode. If the efi directory does exist it's using uefi firmware mode.

    When I go to setup boot in MCC, it shows me grub text.
    For a bios firmware mode, the boot menu may either be grub2 text or grub2 graphical
    from the grub2 package.

    For a uefi firmware system it can use grub2 text or grub2 graphical from the grub2-efi package. On uefi, there is also the refind boot manager that can be used
    instead of grub2-efi. I highly recommend it on uefi firmware systems.

    How can I determine definitely if gpt or uefi are involved?

    Two totally unrelated questions. A system is either running using uefi firmware mode
    or bios firmware mode. A hard drive is either using mbr style partition tables or
    gpt partition tables. Except for some badly written uefi firmware that will not boot from a mbr partitioned hard drive, which boot firmware mode is being used, and which style of partition table is being used on the hard drive are not related.

    If /sys/firmware/efi exists uefi firmware mode is being used. If it does not, bios
    firmware mode is being used.

    To find out if the hard drive has had a mbr or gpt partition table written on it,
    use the blkid command (as root).

    # blkid /dev/sda
    /dev/sda: PTTYPE="dos

    The above indicates it's using a mbr (aka dos) style partition table. If a gpt partition table were being used it would show PTTYPE="gpt".

    The Mageia 8 DVD installer offers a choice of UEFI or BIOS install.

    Can I install UEFI to a empty partition? If so, how will that affect
    using old partitions containing Mageia 6, Mageia 7, and Win 10 if they
    were installed under BIOS ???

    Ideas on what and how to check? How to install?

    Do not mix uefi and bios firmware mode installs on the same computer. It can be done but usually results in very hard to debug and fix problems.

    If you want to keep your existing installations, use the same firmware mode for the new installation.

    Let the installer or mcc/boot/setup boot system control setting up grub. It's much easier then figuring out which file to modify for what in /boot/grub2 (never edit manually), /etc/grub.d (only if you know what you are doing), and /etc/default/grub (which will be set up by mcc or the installer).

    Regards, Dave Hodgins

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

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Jim Beard@2:250/1 to All on Sun Apr 25 16:35:26 2021
    On Sat, 24 Apr 2021 21:21:08 -0400, David W. Hodgins wrote:

    On Sat, 24 Apr 2021 20:17:32 -0400, Jim Beard <jim.beard@verizon.net>
    wrote:
    Last-minute questions before installing Mageia 8 on my laptop.

    The laptop was delivered with Windows 8 only, which was reworked to
    dual boot. At some point Win 8 was replaced witn Win10. At some
    point, /boot/EFI (empty) was created. /sys/firmware/EFI directory does
    not exist. The menu.lst in /boot/grub appears to control boot, but
    grub2 has been installed and there is a grub2.cfg in /grub2/ that has
    multiple instances of a line set root 'hd7,gpt' and the kernel loaded
    would be an old Mageia 7 kernel.

    If /sys/firmware/efi (note lowercase) does not exist then the currently running system is using bios firmware mode. If the efi directory does
    exist it's using uefi firmware mode.

    When I go to setup boot in MCC, it shows me grub text.
    For a bios firmware mode, the boot menu may either be grub2 text or
    grub2 graphical
    from the grub2 package.

    For a uefi firmware system it can use grub2 text or grub2 graphical from
    the grub2-efi package. On uefi, there is also the refind boot manager
    that can be used instead of grub2-efi. I highly recommend it on uefi
    firmware systems.

    How can I determine definitely if gpt or uefi are involved?

    Two totally unrelated questions. A system is either running using uefi firmware mode or bios firmware mode. A hard drive is either using mbr
    style partition tables or gpt partition tables. Except for some badly
    written uefi firmware that will not boot from a mbr partitioned hard
    drive, which boot firmware mode is being used,
    and which style of partition table is being used on the hard drive are
    not related.

    If /sys/firmware/efi exists uefi firmware mode is being used. If it does
    not, bios firmware mode is being used.

    To find out if the hard drive has had a mbr or gpt partition table
    written on it, use the blkid command (as root).

    # blkid /dev/sda /dev/sda: PTTYPE="dos

    The above indicates it's using a mbr (aka dos) style partition table. If
    a gpt partition table were being used it would show PTTYPE="gpt".

    The Mageia 8 DVD installer offers a choice of UEFI or BIOS install.

    Can I install UEFI to a empty partition? If so, how will that affect
    using old partitions containing Mageia 6, Mageia 7, and Win 10 if they
    were installed under BIOS ???

    Ideas on what and how to check? How to install?

    Do not mix uefi and bios firmware mode installs on the same computer. It
    can be done but usually results in very hard to debug and fix problems.

    If you want to keep your existing installations, use the same firmware
    mode for the new installation.

    Let the installer or mcc/boot/setup boot system control setting up grub.
    It's much easier then figuring out which file to modify for what in /boot/grub2 (never edit manually), /etc/grub.d (only if you know what
    you are doing), and /etc/default/grub (which will be set up by mcc or
    the installer).

    My confusion factor increases.

    The laptop hard drive is gpt, per blkid /dev/sda. This much is clear.

    I found in the microsoft partitions EFI boot software for both windows
    and mageia. /system/firmware/efi does not exist. I think Mageia 7 is
    using grub, but it looks like grub2 has been used from the entries in configuration files, etc.

    rpm -qa |grep grub says Mageia 7 has rpms installed for grub, grub2, and grub2-efi.

    I think I am going to tell the Mageia installer gpt, grub2, and uefi if
    given the choice and see what happens. At worst, I will have to wipe the
    hard drive.

    Cheers!

    jim b.

    --
    UNIX is not user-unfriendly, it merely expects users to be computer-
    friendly.

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