Bug 22546 - installation hangs after reboot, maybe caused by uncommon partition layout (sda3 extended, sda[124] primary)
Summary: installation hangs after reboot, maybe caused by uncommon partition layout (s...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard: (MGA6)
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-08 20:24 CET by Franz Holzinger
Modified: 2019-10-07 00:48 CEST (History)
8 users (show)

See Also:
Source RPM: drakx-installer-stage2, drakxtools
CVE:
Status comment:


Attachments
/root/drakx/report.bug.xz (38.60 KB, application/x-xz)
2018-02-09 10:28 CET, Franz Holzinger
Details
journalctl output (9.63 KB, text/plain)
2018-02-09 10:28 CET, Franz Holzinger
Details

Description Franz Holzinger 2018-02-08 20:24:09 CET
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?
Comment 1 Marja Van Waes 2018-02-09 09:35:57 CET
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) => NEEDINFO
CC: (none) => mageiatools, marja11

Comment 2 Franz Holzinger 2018-02-09 10:28:07 CET
Created attachment 9968 [details]
/root/drakx/report.bug.xz
Comment 3 Franz Holzinger 2018-02-09 10:28:45 CET
Created attachment 9969 [details]
journalctl output
Comment 4 Marja Van Waes 2018-02-09 15:49:56 CET
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

Comment 5 Franz Holzinger 2018-02-09 16:35:02 CET
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.
Comment 6 Michel AUTEM 2018-02-09 22:12:24 CET
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

Comment 7 Franz Holzinger 2018-02-09 22:30:35 CET
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?
Comment 8 Michel AUTEM 2018-02-10 21:49:59 CET
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
Comment 9 Marja Van Waes 2018-02-12 11:23:29 CET
(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

Comment 10 Franz Holzinger 2018-02-12 11:40:27 CET
This is a clean install with a format of the root / partition.
Comment 11 Marja Van Waes 2018-02-12 13:48:13 CET
(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

Comment 12 Thomas Backlund 2018-02-12 13:54:12 CET
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

Comment 13 Franz Holzinger 2018-02-12 14:14:07 CET
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.
Comment 14 Martin Whitaker 2018-02-12 14:57:48 CET
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.
Comment 15 Franz Holzinger 2018-02-12 15:38:30 CET
I think I have used Gparted for the first partitioning.
Comment 16 Marja Van Waes 2018-02-14 18:36:45 CET
(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 => mageiatools
Source RPM: (none) => drakx-installer-stage2, drakxtools
Summary: installation hangs after reboot => installation hangs after reboot, maybe caused by uncommon partition layout (sda3 extended, sda[124] primary)
Keywords: NEEDINFO => (none)

Marja Van Waes 2018-02-14 18:38:07 CET

Version: 6 => Cauldron
Whiteboard: (none) => (MGA6)

Comment 17 Morgan Leijström 2019-10-07 00:48:54 CEST
(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


Note You need to log in before you can comment on or make changes to this bug.