1. New Install of the Classic Mageia 6 DVD x86_64. GNOME Desktop. 2. The boot manager is written to the disk. I do the requested reboot, see the boot manager, the Linux installation should continue now to the second part. 3. The booting starts and hangs after a while. Only some ACPI exceptions are shown on the screen. This happens on my notebook HP Elitebook 6930p on which I could successfully install GNOME by using the Xfce-LIVE-DVD Install feature without any change in the kernel options. Which information do you need to get this issue fixed?
Please try whether you can login in text mode, by appending " 3" (without "") to the kernel paramaters line in the bootloader screen. If that succeeds, then please log in, become root, and fetch /root/drakx/report.bug.xz and also log.txt that is the result of running, still as root: journalctl -b 1 > log.txt (compress with xz if log.txt is too large) please attach both files to this bug report. Thanks!
Keywords: (none) => NEEDINFOCC: (none) => mageiatools, marja11
Created attachment 9968 [details] /root/drakx/report.bug.xz
Created attachment 9969 [details] journalctl output
Comment on attachment 9969 [details] journalctl output (In reply to Franz Holzinger from comment #3) > Created attachment 9969 [details] > journalctl output Ouch, I've misunderstood you. I thought you had done a new install with a classical iso, but the log file starts with: -- Logs begin at ven. 2013-12-20 08:27:04 CET, end at ven. 2018-02-09 10:10:15 CET. -- déc. 20 08:27:04 ...... So you must have done an upgrade install. Can you please verify from which time and date the /root/drakx/report.bug.xz that you attached, was? Typically, when upgrading, report.bug.xz is not overwritten, but a not compressed report.bug created in the same directory. "journalctl -b 1" only works for the first reboot after install, so the attached log.txt shows nothing that we need, it is just the oldest piece of logs that hasn't yet been vacuumed. If you can reach a VT (e.g. with Ctrl+Alt+F3) when you get stuck when booting, then please run, as root: journalctl -b > log.txt If you see you can't reach a VT, then reboot and append a " 3" again to the kernel options line in the bootloader screen. Then, after logging in, run, as root: journalctl -b -1 > log.txt Thanks :-)
Attachment 9969 is obsolete: 0 => 1
This has been a new Installation of Mageia 6. There has formerly been a Mageia 4 on this notebook.Then I tried an upgrade installation to Mageia 6. However the computer hang. So I turned it off and restarted with a new Installation and formatting of the root partition. At the end the boot manager could not be written, because the installation DVD could not be found. So I made an upgrade installation from Mageia 6 to Mageia 6. Now the boot manager Grub could be written successfully. Then I make the reboot and it always stops. Nothing more than a black screen with white texts about exceptions shows up. So I did a Ctrl+Alt+F3 and generated the log.txt. However there is not entry from today. It only has entries from December, probably 2015 with Mageia 4.
Hi Franz, When you're stuck with the "black screen", try a [Ctrl][Alt][F2] break to get the login prompt, enter your ID/pwd and then (at the prompt) try to launch the graphical server by typing simply "startx" . Do you recover the graphical environment (GNOME in your case) ? If Yes, forget the "Classical" ISO and simply reinstall your system from the LIVE ISO .
CC: (none) => michel.autem
Hello Michel, yes, your solution brings at first a red screen. Then after a short time Mageia 6 starts and shows the desktop. However it did not ask me to login the user. And the desktop does not look like GNOME3. I have a menu on the top and not activity icons as I know this from GNOME. Will this be fixed in the next Mageia 7 or do you need more information? Is it possible to repair this without a new installation?
I am not a member of the Mageia development team, only an end user like you. I just made a report about more or less the same bug a few days ago. The red screen is just the GNOME warning when you're connecting as root . I think you are used to the GNOME "Classic Mode", with its "old" GNOME2 look, but "my solution" -just a poor by-pass- launches by default the GNOME3 standard interface, which has to be more or less personalized according to your tastes. Try first to meet Marja's request to help them to solve the problem and then REINSTALL from scratch your distribution from the LIVE ISO distrib. There is something wrong in the "classic" distribution : when installed, it seems to encounter sometimes some problem to launch the X server
(In reply to Franz Holzinger from comment #5) > This has been a new Installation of Mageia 6. > There has formerly been a Mageia 4 on this notebook.Then I tried an upgrade > installation to Mageia 6. Only upgrading from a previous Mageia version that was still supported when this installer's version was released, has been thoroughly tested. If you want to upgrade a Mageia version that had already reached its End Of Life when this one was released, then it is better to do a clean install while preserving your /home partition. If you've really tried to upgrade directly from mga4 to mga6, then this bug report is invalid. > However the computer hang. So I turned it off and > restarted with a new Installation and formatting of the root partition. At > the end the boot manager could not be written, because the installation DVD > could not be found. So I made an upgrade installation from Mageia 6 to > Mageia 6. Now the boot manager Grub could be written successfully. > Then I make the reboot and it always stops. Nothing more than a black screen > with white texts about exceptions shows up > > So I did a Ctrl+Alt+F3 and generated the log.txt. However there is not entry > from today. It only has entries from December, probably 2015 with Mageia 4. There is something I've never seen before with your partition table: /dev/sda1 * 63 88066047 88065985 42G 7 HPFS/NTFS/exFAT /dev/sda2 310472190 312576704 2104515 1G c W95 FAT32 (LBA) /dev/sda3 114398865 310472189 196073325 93.5G 5 Extended /dev/sda4 88066048 114397183 26331136 12.6G 83 Linux /dev/sda5 114398928 131170724 16771797 8G 82 Linux swap / Solaris /dev/sda6 131170788 209944575 78773788 37.6G 83 Linux /dev/sda7 209946624 272472063 62525440 29.8G 83 Linux /dev/sda8 272474112 310470655 37996544 18.1G 83 Linux I'm wondering whether it's ok that /dev/sda3 and /dev/sda4 aren't numbered the other way around.... CC'ing some more knowledgeable people
CC: (none) => mageia, pterjan
This is a clean install with a format of the root / partition.
(In reply to Franz Holzinger from comment #10) > This is a clean install with a format of the root / partition. That isn't the problem, the problem is in your Master Boot Record: there is a primary partition that has a higher partition number than the extended partition... I've never ever seen that before, and on IRC one of our developers commented: > I've _never_ seen such a layout before, and I've been doing computers for a > really long time Do you remember when and how you created your partitions? CC'ing David Hodgins, for advise on whether it's worth trying to fix your MBR, or better to just wipe all partitions and install Mageia 6 on a clean disk.
CC: (none) => davidwhodgins
Its actually a valid partition table even if it looks weird... slots 1-4 are all reserved for "primary partitions", of wich the "extended" needs to have one of the slots... then the rest from 5 and up are logical partitions that are part of the "extended" one... Having said that... I'm not sure all disk tools (and drakx for that matter) can will cope with it without hiccups... It could obviously be experimented with in vbox
CC: (none) => tmb
I think that the partitions must come from the installation of Mandriva 2009. All partitions are well detected. Everything did work fine after a Mageia 4 upgrade installation from Mageia 3, before Mageia 2 and before Mageia 1 and before Mandriva 2009.
I know drakx will create extended partition tables where the partitions are out of order, e.g. if you delete a partition in the middle then create two new ones in its place. I've not seen it with primary partitions before, but then drakx normally puts everything but the first partition in the extended partition.
I think I have used Gparted for the first partitioning.
(In reply to Thomas Backlund from comment #12) > Its actually a valid partition table even if it looks weird... Thanks, I hadn't managed to find that answer when googling :-) > > slots 1-4 are all reserved for "primary partitions", of wich the "extended" > needs to have one of the slots... then the rest from 5 and up are logical > partitions that are part of the "extended" one... > > Having said that... I'm not sure all disk tools (and drakx for that matter) > can will cope with it without hiccups... Probably not. Assigning. > > It could obviously be experimented with in vbox It's on my to-do list, but there is sooooo much on that list :-)
Assignee: bugsquad => mageiatoolsSource RPM: (none) => drakx-installer-stage2, drakxtoolsSummary: installation hangs after reboot => installation hangs after reboot, maybe caused by uncommon partition layout (sda3 extended, sda[124] primary)Keywords: NEEDINFO => (none)
Version: 6 => CauldronWhiteboard: (none) => (MGA6)
(In reply to Martin Whitaker from comment #14) > I know drakx will create extended partition tables where the partitions are > out of order, e.g. if you delete a partition in the middle then create two > new ones in its place. I've not seen it with primary partitions before, but > then drakx normally puts everything but the first partition in the extended > partition. Observed here too, mga7.1 classic installer: Had a /boot partition, then a LUKS partition. Removed /boot, and in its place created a much smaller /boot/EFI, and then a /boot in the space between it and the LUKS. Result: /boot/EFI sdb1 is a normal partition, while sdb2 is extended containing sdb5 /boot and sdb6 LUKS. Some thing did not work perfectly though: Bug 25533 - Installer partition stage created strange /boot/EFI partition
CC: (none) => fri