Bug 23101 - No gnome ui launched automatically with netboot install from Mageia-Cauldron-all-nonfree-x86_64.img
Summary: No gnome ui launched automatically with netboot install from Mageia-Cauldron-...
Status: RESOLVED DUPLICATE of bug 22593
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2018-05-31 08:45 CEST by Mika Laitio
Modified: 2018-06-11 22:22 CEST (History)
5 users (show)

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


Attachments
report.bug.xz after gdm did not start automatically after boot. (187.32 KB, application/x-xz)
2018-06-02 11:10 CEST, Mika Laitio
Details
journalctl log file after gdm did not start automatically after boot. (112.56 KB, text/plain)
2018-06-02 11:11 CEST, Mika Laitio
Details

Description Mika Laitio 2018-05-31 08:45:14 CEST
Description of problem:

gdm does not start automatically after install. Needs to always switch with ctrl+f2 to tty console and launch "systemctl start gdm.service" manually as a root user.

Version-Release number of selected component (if applicable):

Latest Mageia cauldron installed on 29.5.2018. Kernel version is:
4.14.44-desktop-2.mga7

How reproducible:
Always (on every boot)

Steps to Reproduce:
1) flashed and booted Mageia-Cauldron-all-nonfree-x86_64.img
2) selected the gnome from install menu and installed the Mageia 7 (cauldron) succesfully over internet http mirrors
3) booted to Mageia --> Boot stops to black screen/no gdm login page is displayed
4) switch to another tty with ctrl+f2 and login to system via tty console
5) systemctl status gdm.service shows that the service is died
6) systemctl start gdm.service --> GDM login UI opens and I can login to gnome
Comment 1 Marja Van Waes 2018-05-31 19:51:51 CEST
Hi Mika, thanks for the report.


Please attach

 1.   /root/drakx/report.bug.xz

and also 

 2. log.txt that is the result of running, as root,

       journalctl -ab > log.txt

    right after reproducing the problem (so right after switching to tty2 when
    you don't get the GDM screen).

Thanks :-)

Source RPM: (none) => drakx-installer-stage2?, systemd? gdm?
CC: (none) => basesystem, gnome, mageiatools, marja11
Keywords: (none) => NEEDINFO

Comment 2 Mika Laitio 2018-06-02 11:10:41 CEST
Created attachment 10216 [details]
report.bug.xz after gdm did not start automatically after boot.
Comment 3 Mika Laitio 2018-06-02 11:11:31 CEST
Created attachment 10217 [details]
journalctl log file after gdm did not start automatically after boot.
Comment 4 Mika Laitio 2018-06-02 11:14:35 CEST
# systemctl status gdm.service
● gdm.service - GNOME Display Manager
   Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
Comment 5 Bit Twister 2018-06-02 15:49:47 CEST
see workarounds in bug 22620 and bug 22593

CC: (none) => bittwister2

Comment 6 Marja Van Waes 2018-06-04 20:23:50 CEST
(In reply to Mika Laitio from comment #3)
> Created attachment 10217 [details]
> journalctl log file after gdm did not start automatically after boot.

Indeed, it doesn't even attmmpt to start.

(In reply to Bit Twister from comment #5)
> see workarounds in bug 22620 and bug 22593

Bit Twister is right, it looks like the same issue as those bugs.

running as root:

   systemctl set-default graphical.target

should fix the issue. Please try :-)

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=22620, https://bugs.mageia.org/show_bug.cgi?id=22593
Source RPM: drakx-installer-stage2?, systemd? gdm? => drakx-installer-stage2

Comment 7 Marja Van Waes 2018-06-08 21:46:57 CEST
(In reply to Marja Van Waes from comment #6)

> 
> running as root:
> 
>    systemctl set-default graphical.target
> 
> should fix the issue. Please try :-)

And report here whether that works!
Comment 8 Mika Laitio 2018-06-11 10:46:46 CEST
Yes, the execution of

  systemctl set-default graphical.target

as a root fixes the issue.
Comment 9 Marja Van Waes 2018-06-11 22:22:22 CEST
(In reply to Mika Laitio from comment #8)
> Yes, the execution of
> 
>   systemctl set-default graphical.target
> 
> as a root fixes the issue.

Thanks :-)

So this is a duplicate of bug 22593

*** This bug has been marked as a duplicate of bug 22593 ***

Resolution: (none) => DUPLICATE
Status: NEW => RESOLVED


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