Description of problem: having created a GPT disk in order to take advantage of the increased partition size. The installation from DVD went without any problems. However, at the end of the install. The system would not boot. Instead the machine appears to be going through all options before opening the Bios setup (UEFI), the last option. The Bios had not been changed from the previous configuration, where it worked fine. I found that by re-inserting the setup DVD, I could use the "Boot from hard drive" option to boot the system. This is not a satisfactory system, and there were further problems in that connection to the LAN could only be carried out using DHCP. The Mageia Forum did not come up with any useful, or workable ideas, and eventually, I fitted a spare, old 500MB drive and re-installed the OS onto that, using the whole of the GPT drive for /home. This worked fine, and is the current situation, so I shall not be able to respond to "try this" requests Version-Release number of selected component (if applicable): Mageia 5 on DVD How reproducible:Always Steps to Reproduce: 1.Turn on machine power and wait 2. 3.
Please try with Mageia 6
Component: Others => RPM PackagesVersion: unspecified => 5Assignee: sysadmin-bugs => bugsquadProduct: Infrastructure => Mageia
Having tried Mga 6, there a a number of issues with KDE which I'm not happy with. particularly the virtual destruction of konqueror, So I don't think that I'll be upgrading to Mga 6 anytime soon. I get the feeling that the initial boot sequence is not seeing the Grub system. That it works with a legacy bios system, on an x586 Thinkpad, and on the machine in question, when the OS is on an MBR disk is significant. I'm not really concerned with this issue, but thought that I should raise it.
just to speak about konqueror, this is an upstream decision, not ours.
CC: (none) => mageia
I quite understand that. I merely included it as the reason for not upgrading to mga6.
CC: (none) => trouducul
Status: NEW => RESOLVEDResolution: (none) => FIXED
Comments 5 and 6 were from a troll who decided to alter bug reports. So I hid them. Thanks for reporting your issue. We will probably not be able to work on it since we can't update Mageia 5's installation media. I'm glad that you found a working solution, though.
Status: RESOLVED => REOPENEDComponent: RPM Packages => InstallerResolution: FIXED => (none)CC: trouducul => mageiatools
Samuel, Thank you for your attention. I understand that being Mga5, it is not really worth doing anything about it, but I thought I'd raise the issue since it might reflect into Mga6.
(In reply to Rod Goslin from comment #8) > Samuel, Thank you for your attention. I understand that being Mga5, it is > not really worth doing anything about it, but I thought I'd raise the issue > since it might reflect into Mga6. @ Rod I understand you installed in legacy (non-UEFI) mode to a GPT disk. That means that a BIOS boot partition was needed, but it was neither automatically created by the Mageia 5 installer, nor did Mageia 5's installer tell you to create one manually. See also bug 18656 about this issue (which got fixed for Mageia 6). Next time when you file a bug report about installer, please tell which iso you used and get the installer logs as explained here https://wiki.mageia.org/en/Triage_guide#Installer-related_bugs Note that it has two sections: https://wiki.mageia.org/en/Triage_guide#Traditional_installer and https://wiki.mageia.org/en/Triage_guide#Live_installs Thanks :-) Without that information, there is usually nothing we can do. *** This bug has been marked as a duplicate of bug 18656 ***
Summary: machine will not boot after install of mageia5 => machine will not boot after install of mageia5 to a GPT-partitioned diskCC: (none) => marja11Resolution: (none) => DUPLICATEWhiteboard: (none) => (MGA5)Status: REOPENED => RESOLVED
a, this is not quite correct. The installation was to a UEFI bios installation as noted in my original posting (.....Instead the machine appears to be going through all options before opening the Bios setup (UEFI), the last option.). However the requirement for a boot partition may still apply. I have to admit to having long since abandoned the policy of multiple partitions in the OS area. At one time when I was the systems administrator for a UNIX system, I had to watch as the /usr partition available space shrank from a generous space to near zero as the software provider provided more and more 'features' to their product. In the end, since there was never time available to re-partition, I had to take out the bespoke printing software, and locate it in /home, linked back to its own space in /usr. I was rather surprised, going back to my later bug report (18656) to see the furore aroused by what I had assumed to be a minor matter. I may, yet, come back to abandoning my MBR disk get-around, and re-installing as GPT, since I seem to be having problems with machine to machine communications (ping, ftp and ssh) for which I've no rational explanation. Many thanks for your multiple attentions to this matter. Rod Goslin