Description of problem: Install mageia 8 x86_64 without incident reboot, and system hangs during boot. Last line printed systemd[1]: systemd-hostname4.service: Succeeded. I reinstalled from scratch, and got the same error. This media has worked successfully to install mageia 8 on 3 other computers. Version-Release number of selected component (if applicable): 8 How reproducible: 100% Steps to Reproduce: 1. install 2. reboot 3. wait forever
Created attachment 12409 [details] screenshot from boot, showing last message printed sorry it is a bit blurry, but it is readable.
The laptop was running mageia 7.1 x86_64 without any issues before I did a fresh install of mageia 8.
That looks completely normal and the same as what I get on my system, if I press alt+ctrl+f12 during boot to view the log. Can you login at the prompt shown by alt+ctrl+f2 to get more info?
CC: (none) => davidwhodgins
I can log in using control-alt-f1. What logs do you want? On my other 3 installations, I get a login prompt, without having to press control-alt-f1 or anything else.
journalctl -b --no-hostname Are you booting to run level 3? If so, please use alt+ctrl+f1 to switch back to tty1. If that is still showing the log instead of a login screen, the question becomes why the service getty@tty1.service failed to start The command "systemctl status getty@tty1.service" may also have some useful info.
I am booting to the default run level. I just did a normal, boring install like the three other systems that work fine. The only thing is I am not starting the graphics server by default, so after booting finishes I get a text login prompt. I have enough history with graphics weirdness that I like starting from the command line. after pressing control-alt-f1 to get a login prompt, systemctl status getty@tty1.service says loaded and active
I know I've seen this problem before. Found it for Mageia 7 in bug 22620 Jeff, see if "systemctl enable getty@tty1.service" fixes it. Adding Martin to the cc list as the person who debugged it for Mageia 7, and Neal as the person who fixed it.
CC: (none) => mageia, ngompa13
Summary: fresh install of mageia 8 hangs during boot - direkt-tek DTLAPY116-2 => fresh install of mageia 8, getty does not start on tty1
I booted, and after I pressed control-alt-f1, I got the following: [Hardware Error]: CPU 0: Machine Check: 0 Bank 4: e6000000000 [Hardware Error]: TSC 0 ADDR fef5d340 [Hardware Error]: Processor 0:506c9 TIME 1614494501 SOCKET 0 APIC 0 microcode 40 <then the mageia login prompt> I logged in and did systemctl enable getty@tty1.service I rebooted, and still ended up with boot messages. The last line was systemd-hostname4.service: Succeeded. I still need to press control-alt-f1 to get a login prompt, but when I did that I did not get the machine check message, just the login prompt. The computer seems to be working fine with windows 10 and was working fine with mageia 7.1.
Hi, Can you please attach here the file generated by the following command: as root: # journalctl -b > /bootlog.txt > [Hardware Error]: CPU 0: Machine Check: 0 Bank 4: e6000000000 > [Hardware Error]: TSC 0 ADDR fef5d340 > [Hardware Error]: Processor 0:506c9 TIME 1614494501 SOCKET 0 APIC 0 microcode 40 This seems a hardware failure... Can you also provide: $ lspcidrake -v > ./hardware.txt
CC: (none) => ouaurelien
Created attachment 12412 [details] bootlog.txt
Created attachment 12413 [details] hardware
Added bootlog and hardware, as requested.
(In reply to jeff deifik from comment #10) > Created attachment 12412 [details] > bootlog.txt Feb 28 12:55:28 localhost systemd[1]: Started Getty on tty1. Feb 28 12:55:28 localhost systemd[1]: Reached target Login Prompts. Feb 28 12:55:28 localhost systemd[1]: Reached target Multi-User System. This is Mageia 8. All I see is a normal boot to a console login prompt and after you did startx to load Plasma session. I did not see any hardware error. Nevermind. But I really think this is similar to bug 22620. As this is a fresh install of Mageia 8, Could you provide the file /root/drakx/report.bug.xz as an attachment ?
Keywords: (none) => NEEDINFOComponent: Installer => RPM PackagesSource RPM: (none) => systemd-246.9-5.mga8.src.rpmSummary: fresh install of mageia 8, getty does not start on tty1 => fresh install of mageia 8, getty does not start on tty1 if targeted runlevel is mutli-users at install time
Keywords: NEEDINFO => (none)Status: NEW => NEEDINFO
Created attachment 12414 [details] new bootlog latest bootlog. last thing to show up on the boot console was Feb 28 14:46:56 localhost chronyd[777]: Selected source 144.34.193.110 (pool.ntp.org) Feb 28 14:46:56 localhost chronyd[777]: System clock wrong by -2.154770 seconds Feb 28 14:46:54 localhost chronyd[777]: System clock was stepped by -2.154770 seconds I added some blank lines where I used control-alt-f1 to get a console.
Created attachment 12415 [details] reportbug
I added reportbug and the latest bootlog. I got a different message as the last line from the booting console.
It still shows ... Feb 28 14:46:27 localhost systemd[1]: Started Getty on tty1. Feb 28 14:46:27 localhost systemd[1]: Reached target Login Prompts. Any chance the login did show up but was overwritten by log output on the console? If that is the case, just pressing enter should cause it to redraw.
Pressing enter has no effect.
This is not the same as bug 22620. There the getty service wasn't being started. Here it is. The problem is that the virtual console continues to show vt12, not vt1, so the login prompt is not visible. There are two possibilities: 1. Something is preventing the switch to vt1. 2. Something is causing the console to switch back to vt12. @Jeff, if you look at the boot log in a terminal, are any of the messages after "Started Getty on tty1" and before you log in shown in red?
CC: (none) => fri
There is nothing red after the starting getty.
Status of this?
I just ran an update. The problem still persists. Also the console output font is very small, even thought I set it to be large in /etc/vconsole.conf. This is a 11" laptop with a 1080p display. Any advice on increasing the console font size would be appreciated.
@Neal, can you look at this Bug Report to help this user, please? This is strange that booting to Console mode does not go to a login prompt in tty1.
What's the output of (as root) "grep -Ir tty1 /etc/*"? On my Mageia 8 install it's ... /etc/securetty:tty1 /etc/security/access.conf:# "/dev" (e.g. tty1 or vc/1) /etc/security/access.conf:# Disallow non-root logins on tty1 /etc/security/access.conf:#-:ALL EXCEPT root:tty1 /etc/security/access.conf:#+:root:cron crond :0 tty1 tty2 tty3 tty4 tty5 tty6 /etc/systemd/journald.conf:TTYPath=/dev/tty12
# grep -Ir tty1 /etc/* grep: /etc/grub2-efi.cfg: No such file or directory /etc/securetty:tty1 /etc/security/access.conf:# "/dev" (e.g. tty1 or vc/1) /etc/security/access.conf:# Disallow non-root logins on tty1 /etc/security/access.conf:#-:ALL EXCEPT root:tty1 /etc/security/access.conf:#+:root:cron crond :0 tty1 tty2 tty3 tty4 tty5 tty6 /etc/systemd/journald.conf:TTYPath=/dev/tty12 I have installed mageia 8 on 15 machines, and this is the only one with this issue.
(In reply to jeff from comment #25) > # grep -Ir tty1 /etc/* > grep: /etc/grub2-efi.cfg: No such file or directory > /etc/securetty:tty1 > /etc/security/access.conf:# "/dev" (e.g. tty1 or vc/1) > /etc/security/access.conf:# Disallow non-root logins on tty1 > /etc/security/access.conf:#-:ALL EXCEPT root:tty1 > /etc/security/access.conf:#+:root:cron crond :0 tty1 tty2 tty3 tty4 tty5 tty6 > /etc/systemd/journald.conf:TTYPath=/dev/tty12 > > I have installed mageia 8 on 15 machines, and this is the only one with this > issue. Really strange only one computer... perhaps a bad keyboard key? Assigning.
Status: NEEDINFO => NEWAssignee: bugsquad => pkg-bugs
The computer in question worked fine with mageia 7, so it seems unlikely to be a keyboard issue.Also it works fine with windows 10.