Description of problem: 7 dev0 No login prompt runlevel 3 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. clean Mageia-Cauldron-netinstall-nonfree-x86_64.iso, all group packages and xfce only de with tainted and nonfree enabled. 2. hit ESC at grub2 boot selection. 3. add " 3" (without quotes) to end of /boot/vmlinuz line and remove "splash quiet" 4. hit Ctrl+x Once terminal quits scrolling messages, Note there is no login prompt, nor does one show up after hitting Enter. bug 22593 has attachments for journal log and report.bug.xz Workaround: Hit ALt+f2 log into user account
Source RPM: (none) => guessing systemd-236-4.mga7.src.rpm
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) => ngompa13Assignee: bugsquad => basesystemSource 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
Summary: No login prompt runlevel 3 => No gui login or runlevel 3 promptSeverity: normal => major
Created attachment 10038 [details] dmesg text
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=23101
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) => marja11Summary: 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, basesystemAssignee: basesystem => mageiatoolsSummary: 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
Component: RPM Packages => Installer
Priority: Normal => release_blocker
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
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=23915
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) => mageiaSource RPM: drakx-installer-stage2, systemd-236-4.mga7.src.rpm, initscripts-9.78-5.mga7.src.rpm => systemd-236-4.mga7.src.rpmAssignee: mageiatools => basesystem
*** Bug 23915 has been marked as a duplicate of this bug. ***
CC: (none) => smelror
Fixed in systemd-236-12.mga7.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED