Bug 5668 - Graphical login forced even for console only install
Summary: Graphical login forced even for console only install
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal minor
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-29 02:28 CEST by Sebastian Blaziak
Modified: 2012-04-29 15:17 CEST (History)
2 users (show)

See Also:
Source RPM: systemd
CVE:
Status comment:


Attachments

Description Sebastian Blaziak 2012-04-29 02:28:05 CEST
Description of problem:
After a fresh install of M2b3, a minimal install without X so console only, after boot a graphical login is attempted. As the X hasn't been installed that fails with the display of message from display-manager-failure-message script. The error is benign as it drops to console, which it should do in first place.

System shouldn't assume a graphical login.

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


How reproducible:
Install system as console only
Comment 1 Manuel Hiebel 2012-04-29 11:13:14 CEST
I guess it's a duplicate of bug 2038, you can add manually "text" in the kernel command line

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

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

Comment 2 Sebastian Blaziak 2012-04-29 12:22:48 CEST
I've looked at the 2038, but that one it's specifically related to installer. The issue reported relates to system _after_ install. Then when booting, with framebuffer or not, system assumes graphical login. Addition of text kernel boot option to grub config didn't change the behavior.

So i doesn't look to be duplicate of 2038.

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

Comment 3 Manuel Hiebel 2012-04-29 12:33:05 CEST
ah sorry read to fast :/

CC: (none) => mageia, thierry.vignaud
Component: Installer => RPM Packages
Source RPM: (none) => systemd

Comment 4 Colin Guthrie 2012-04-29 14:47:35 CEST
Yeah this happens because systemd-units is installed by the installer before initscripts.

I've made systemd install default to multi-user.target for now and the installer should already take care to change that to the correct target if you configure the graphics during install.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

Comment 5 Thierry Vignaud 2012-04-29 15:06:40 CEST
Also you could add conflicts: initscripts < some_older_version to systemd-units to force package ordering
Comment 6 Colin Guthrie 2012-04-29 15:17:40 CEST
(In reply to comment #5)
> Also you could add conflicts: initscripts < some_older_version to systemd-units
> to force package ordering

Would that help in the installer for a fresh install. The problem was that systemd-units is installed *before* initscripts and thus /etc/inittab does not exist for us to base the default.target symlink on and we defaulted to graphical.target.

Adding a conflicts would (in my perhaps limited understanding) not help to get initscripts installed earlier? It would surely need a "Requires(post): initscripts" to achieve this? I did think to do this but as /etc/inittab will die off in mga3, I felt this was the cleaner solution.

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