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.
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.
On 4/17/21 11:58 AM, Jim Beard wrote:I think that TJ is right. Changing to GPT normally means wiping the
At some point, an upgrade to a new version of Mageia offered to convertI just did one yesterday, and there were no problems. The was no offer
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.
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
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.
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)
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?)
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)
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.
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.
The last three I think came from Jeorg Schily's cdrkit software,Wow. Except for the occasional Mageia iso test, I haven't burned any
and must be obsolete. It works, though, and I am inclined to
keep them
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.
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
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.
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
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 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.
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).
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 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
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,
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
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
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 new machine with solid state drives - Mageia 8 installed in
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
regardsI 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.
On Sat, 17 Apr 2021 11:58:27 -0400, Jim Beard <jim.beard@verizon.net>Mageia_8_Release_Notes#Upgrading_from_Mageia_7
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/
*** 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.For a bios firmware mode, the boot menu may either be grub2 text or grub2 graphical
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?
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).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 465 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 39:49:57 |
| Calls: | 9,400 |
| Files: | 13,569 |
| Messages: | 6,098,629 |