Bug 22620

My Mageia 5 system has a /etc/systemd/system/getty.target.wants/getty@tty1.service that is probably responsible for the tty1 getty being created.  This symlink was created the day I installed Mageia 5.  I'm not entirely sure exactly what was responsible for creating it though.  I do see that the initscripts package was installed at the same time that the symlink was created.  I don't see anything obvious in the scripts of the package that would have been responsible for creating it, but I do know that the initscripts package in Cauldron has recently undergone significant changes, so I'd guess the problem originated there.

CC: (none) => ngompa13
Assignee: bugsquad => basesystem
Source RPM: guessing systemd-236-4.mga7.src.rpm => systemd-236-4.mga7.src.rpm, initscripts-9.78-5.mga7.src.rpm

Workaround:  systemctl enable getty@tty1.service

If you remove the quiet kernel option, the vty1 is unable to show the login prompt because the kernel messages shown in this vty because some kernels has the debug information enabled (showing the audit messages)

Please retry the boot with runlevel 3 and without remove these kernel options "splash quiet"

Please add the kernel booted up information too

CC: (none) => neoser10

Created attachment 10038 [details]
dmesg text

Keeping this report for the missing tty1 prompt, and bug 22593 for the other issue (the DM not starting).

We need to check whether this particular issue also happens in runlevel 3 in installs from last year.

CC: (none) => marja11
Summary: No gui login or runlevel 3 prompt => No runlevel 3 prompt in tty1, running "systemctl enable getty@tty1.service" fixes it.

(In reply to Marja Van Waes from comment #5)

> We need to check whether this particular issue also happens in runlevel 3 in
> installs from last year.

Installs from last year is a bit vague. If you mean mga6, we did not have the problems. I am always doing clean installs only and 6 did not have the problems.
Both problems are due to a missing systemd link because the workaround commands were not executed during install.

(In reply to Bit Twister from comment #6)
> (In reply to Marja Van Waes from comment #5)
> 
> > We need to check whether this particular issue also happens in runlevel 3 in
> > installs from last year.
> 
> Installs from last year is a bit vague. If you mean mga6, we did not have
> the problems. I am always doing clean installs only and 6 did not have the
> problems.

Too vague indeed, I should have said: cauldron installs from before systemd-236 and initscripts-9.78, that do run current systemd and initscripts 

> Both problems are due to a missing systemd link because the workaround
> commands were not executed during install.

The question was: package update install or Mageia install... if the latter, then the culprit is again stage2, like for bug 22593

It is the latter indeed, while writing this I booted an older Cauldron install (last updated last weekend, except for qt5) in runlevel 3. The prompt appears nicely in tty1. 

Reassigning

CC: (none) => alien, basesystem
Assignee: basesystem => mageiatools
Summary: No runlevel 3 prompt in tty1, running "systemctl enable getty@tty1.service" fixes it. => No runlevel 3 prompt in tty1 after fresh install, running "systemctl enable getty@tty1.service" fixes it.
Source RPM: systemd-236-4.mga7.src.rpm, initscripts-9.78-5.mga7.src.rpm => drakx-installer-stage2, systemd-236-4.mga7.src.rpm, initscripts-9.78-5.mga7.src.rpm

Just my 2 cents.

I always, by default, boot my system to init 3 verbose and I get the login prompt on TTY2 and when I launch the DM and X it occupies TTY1.
On the rare times when boot simply appears to stop I use Ctrl-Alt-F2 and there is
the login prompt.

CC: (none) => cae

I have the same issue here. Installed beta1 without graphical desktop. You don't get any tty after boot.

CC: (none) => mageia

After hacking the systemd meson.build script to make it build again, I've managed to debug this. There are two problems with the systemd package:

1. There is a circular dependency between systemd and systemd-units. If systemd-units is installed first, the call to systemctl in its %post scriptlet fails because /lib/systemd/libsystemd-shared-236.so hasn't been installed yet.

2. Both the %post and %triggerin scriptlets in systemd-units include console-shell.service in the list of units they pass to 'systemctl preset'. That service no longer exists, so the 'systemctl preset' command fails (without presetting anything).

I worked round (1) by changing the %post to %posttrans, although it might be better to do as Fedora have, and merge the systemd and systemd-units packages.

I won't push my fixes, as Neal said he was going to push a new version of systemd soon.

CC: (none) => mageia
Source RPM: drakx-installer-stage2, systemd-236-4.mga7.src.rpm, initscripts-9.78-5.mga7.src.rpm => systemd-236-4.mga7.src.rpm
Assignee: mageiatools => basesystem

*** Bug 23915 has been marked as a duplicate of this bug. ***

CC: (none) => smelror

Fixed in systemd-236-12.mga7.

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