Description of problem:
Mageia 7Beta does not boot
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Installation of Mageia 7 Beta on IBM Thinkpad R50e 5 Intel pentium M processor) seems to work OK, grub is updated OK.
Booting, choosing the new install in grub menu results in a black screen, no disk activity. Left it there for 20 min.
Checked via M6 on same machine, no log in M7's partition is /root/drakx. All files untouched and pointing to the installation.
This might be a duplicate of bug 23431 (Similar issue with some 64bit-capable HP machines).
I fail to see the workaround Martin refers to in that report, or is that using a 64bit iso? Herman can't do that, because the ThinkPad R50e is incapable of running 64bit.
Mageia 7Beta does not boot =>
Mageia 7Beta i586 does not boot on Thinkpad R50e (real 32bit hardware)CC:
marja11, sysadmin-bugsSee Also:
RPM Packages =>
Release (media or process)Assignee:
I think it's different to bug 23431 - there Dick could not boot from the USB stick, here Herman has booted and run the installer, and it only fails when booting the newly installed system.
The odd thing is the lack of install logs in /root/drakx. Herman, could you rerun the install, and when it reaches the final screen, use Ctrl-Alt-F2 to switch to the command prompt, insert a FAT-formatted USB stick, and type
on the command line. That should copy report.bux.xz onto the USB stick.
I was not clear enough: I have the logs of the installation in /root/drakx, but there's no info whatsoever on the failed boots after installation.
Now do you want the reprt from the installation??
Yes, let's have report.bug.xz, in case it tells us anything. Also the output from
ls -l /path-to-mga7/boot
to make sure the kernel and initrd are there and look sensible.
Created attachment 10496 [details]
report from installation
ls -l boot
-rw-r--r-- 1 root root 219874 nov 16 12:54 config-4.19.2-desktop-3.mga7
drwxr-xr-x 2 root root 4096 nov 11 00:07 dracut/
drwxr-xr-x 6 root root 4096 nov 20 09:36 grub2/
-rw------- 1 root root 11127274 nov 20 09:25 initrd-4.19.2-desktop-3.mga7.img
lrwxrwxrwx 1 root root 32 nov 20 09:25 initrd.img -> initrd-4.19.2-desktop-3.mga7.img
-rw-r--r-- 1 root root 181496 nov 16 12:54 symvers-4.19.2-desktop-3.mga7.xz
-rw-r--r-- 1 root root 2966891 nov 16 12:54 System.map-4.19.2-desktop-3.mga7
lrwxrwxrwx 1 root root 29 nov 20 09:25 vmlinuz -> vmlinuz-4.19.2-desktop-3.mga7
-rw-r--r-- 1 root root 5261312 nov 16 12:54 vmlinuz-4.19.2-desktop-3.mga7
Yesterday I ran the boot without spash quiet during the QA meeting, and posted the last message there. tmb told me this is a kernel crash and advized to leave it alone til the next kernel comes around.
I see the installer has chosen to install the desktop kernel, whereas the ISO will be using the desktop586 kernel, which might be the important difference.
Beta2 has same problem. Took a picture of last screen of messages.
Although a discussion on the qa list seemed to blame nvidia for this problem and recommended to use the vesa driver, I gave this lat suggestion a try.
But this laptop has an Intel (810 and later) graphics chipset.
Reinstalled, choose the vesa driver, rebooted and the reboot is successfull.
The only defaults that I changed during installation are the language and the video driver.
Created attachment 10502 [details]
last messages on failed reboot of Beta2i586
Hm. Had a similar error (clean cauldron netinstall) - but with a little different text.
Seeing what I believe is the same thing on a Dell Inspiron 5100 (P4 Northwood core, 2GB RAM, radeon MV200 graphics) after an install of Xfce from the second-round i586 Classical iso.
The visual symptoms are different, but as with Herman, there is no evidence of any logs on that first boot. Nothing in /var/log/journal, no dmseg file, and all the logs that ARE there contain 0 bytes. The install.log file indicates that kernel-desktop was installed.
The round-2 i586 Xfce Live iso on a usb stick boots to a working desktop, and installing from that desktop is successful. That iso installs kernel-desktop586.
I am currently re-installing from the Live iso. Once that is finished, I will attempt to install kernel-desktop-latest, and reboot to see what happens.
Herman's CPU at least is a 686, so should work with the standard desktop kernel. Maybe there is some Spectre/Meltdown mitigation included in that version of the kernel that doesn't work on all 686 processors. Anyway, reassigning as this appears to be a kernel problem.
Just finished doing the re-install from the Live iso mentioned in Comment 11, set MCC up to use the math.princeton mirror, and after getting the 100 or so pending updates, I installed kernel-desktop-latest. I then used "update-grub," just to be sure grub2 was correct, and shut down. I booted again, making sure I was booting into kernel-desktop.
The boot was successful, perfectly normal, in fact. Everything acts normally. Firefox browses, vlc plays videos, etc.
So it would appear that, at least for the P4, the problem is not so much in the kernel as it is in the installation of it by the Classical iso.
(FWIW, I noticed that one of the updates I got before installing kernel-desktop-latest was dnf. No idea if that makes any difference.)
Changing this to a release blocker.
The Live ISO is created by the classical installer, so the installations should largely be the same. What would be different is the composition of the initrd. The initrd should be regenerated when you run the live installer, but with the current release it's not. However, TJ's test of installing the desktop kernel should have generated a new initrd for that kernel, so I doubt this is the problem.
Note to tmb: we still have early microcode loading disabled in the Live initrd. I guess we should revert that now VirtualBox is fixed.
(In reply to Martin Whitaker from comment #15)
> Note to tmb: we still have early microcode loading disabled in the Live
> initrd. I guess we should revert that now VirtualBox is fixed.
Yep. done in git
Created attachment 10517 [details]
Screenshot - boot after clean Netinstall - Kernel 4.19.5-2
Screenshot after successful clean net-install (today) and reboot with Kernel 4.19.5-desktop-2
LG F-222EG with Intel Core Duo T2250 and Intel 945GM.
I have reproduced this using qemu:
qemu-img create qemu.img 8G
qemu-system-i386 -cdrom Mageia-7-beta1-i586.iso -m 3G --enable-kvm -vga std -cpu qemu32 -drive file=qemu.img -boot order=d
I've tested with RAM size of 3GB, which causes the desktop kernel to be selected, and with a RAM size of 4GB, which causes the server kernel to be selected. Both show the bug. I've also reduced the CPU capabilities (by -cpu qemu32,-cmov), which causes the desktop586 kernel to be selected. That boots to the desktop without any problem.
I've also discovered that, on the buggy systems, if I remove both "nokmsboot" and "splash quiet" and add "3" on the boot command line, I can boot to a text login prompt (using ctrl-alt-F2 to get to a working tty). Then, if I delete /etc/X11/xorg.conf, reboot, and just remove "nokmsboot" from the boot command line, the system will then reliably boot to a working desktop.
There seems to be a weird bit of memory in this. After a failed boot, trying to boot to run level 3 as above will fail on the first attempt, but succeed on subsequent attempts. Suspecting service_harddrake, I disabled the mandriva-everytime service, but that made no difference.
Using qemu, replacing "nokmsboot" with "nomodeset" works around this bug.
Still the same in round 4 as my original report. Diiference is that when I change the configuration from Intel graphics to xorg/vesa and runlevel 3, the boot process goes further till "Started Command Scheduler" and at that point completly dies.
Problem is gone on my Inspiron 5100, as of the latest Classical i586 iso, dated (I think) 1 Dec.
I was able to install and boot into a working Xfce system that uses the free radeon driver. Later, I was able to install and boot into a working Plasma system, using the VESA driver as past experience tells me Plasma will not work on this hardware with the radeon driver.
(In reply to Herman Viaene from comment #20)
> Still the same in round 4 as my original report. Difference is that when I
> change the configuration from Intel graphics to xorg/vesa and runlevel 3,
> the boot process goes further till "Started Command Scheduler" and at that
> point completly dies.
Did you see the same kernel trace and all the coloured artefacts that psyca and you saw before? If you didn't see them, then please mount the root partition of the round 4 install that fails to boot.
There's a directory with a very long hexadecimal name in
please run, as root,
journalctl -D /path/into/that/hexadecimal/directory/ > journal.txt
and then attach journal.txt to this bug report.
(Compress the journal with "xz journal.txt" if it's too large to attach.)
Please do also attach your new /root/drakx/report.bug.xz from the root partition of that install, to replace your old report.bug.xz
(In reply to Marja Van Waes from comment #22)
> Did you see the same kernel trace and all the coloured artefacts that psyca
> and you saw before? If you didn't see them, then please mount the root
> partition of the round 4 install that fails to boot.
ah, run level 3, so probably no coloured artefacts... it would be nice to have the journal logs :-)
# journalctl -D /mnt/m7/var/log/journal/a983488fee1d4f2098c124f166272313 > journal.txt
Journal file /mnt/m7/var/log/journal/a983488fee1d4f2098c124f166272313/system.journal uses an unsupported feature, ignoring file.
(In reply to Herman Viaene from comment #24)
> # journalctl -D /mnt/m7/var/log/journal/a983488fee1d4f2098c124f166272313 >
> Journal file
> /mnt/m7/var/log/journal/a983488fee1d4f2098c124f166272313/system.journal uses
> an unsupported feature, ignoring file.
On the system from where you issued that command, what is the output of (as normal user):
What was that system, btw, a Mageia 6 install or a Mageia 7beta1 Live iso?
The system from where I issued that command is a Mageia 6 installation, and the requested output:
$ systemctl --version
+PAM +AUDIT -SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN
(In reply to Herman Viaene from comment #26)
> The system from where I issued that command is a Mageia 6 installation, and
> the requested output:
> $ systemctl --version
> systemd 230
> +PAM +AUDIT -SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
> +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN
The problem is probably "-LZ4". In my Mageia 7 here that is +LZ4, which means that in your Mageia7beta1 install most likely lz4 compression is used (instead of xz), but, going by the above output, your Mageia 6 install cannot uncompress that.
Do you have a working Mageia 7 install, or Mageia 7 Live iso, with which to try again?
(You could also copy /mnt/m7/var/log/journal/a983488fee1d4f2098c124f166272313/ and its contents to a USB stick and then plug it into a Mga 7 machine)
Created attachment 10532 [details]
journal of failed boot M7 i586 round 4
From the journal, it looks like the system has booted successfully. Does Ctrl-Alt-F2 get you to a text login prompt?
Ctrl-Alt-F2 gets me to a login prompt. I can login.
There "startmate" throws an error "Unable to init server: connection refused.
"startx" gives me an ICEWM session which works partly: I cann't start any application from the Mageia button - menus. I can start Firefox from the context menu, but not MCC. I have to start that one from terminal CLI.
Ctrl-Alt-F1 reamins all the time at "Started Command Scheduler" and I find no way to get it moving.
It may not seem like it, but we are making progress - the kernel bug has gone.
From a root login, what do
systemctl status display-manager
What driver is currently selected in the "Device" section of /etc/X11/xorg.conf?
Can you attach a copy of /var/log/Xorg.0.log after running startmate and also after running startx.
Does the 32-bit Live ISO still work on this machine? If so, which X driver is it using?
Sorry for all the questions, but I don't know a better way to debug X problems :-(
# systemctl get-default
# systemctl status display-manager
● lightdm.service - Light Display Manager
Loaded: loaded (/usr/lib/systemd/system/lightdm.service; enabled; vendor pre>
Active: inactive (dead)
Created attachment 10534 [details]
Xorg log after startx
Created attachment 10535 [details]
Xorg log after startmate
As far as the Live iso is concerned, I have no idea as I never try to run Live on this laptop, will be painfully slow.
If you really want it, it'll have to wait till monday to have time to download the Live etc....
Sorry, I was misremembering. It was TJ who reported the Live ISO worked but the classical install did not.
OK, so you are booting to the multi-user target (equivalent to run level 3). The lack of a login prompt on vt1 is bug 22620.
There aren't any errors reported in your Xorg log files. Have you already tried booting to the graphical target after selecting the vesa driver?
You could try replacing "nokmsboot" with "nomodeset" to see if that makes a difference. Alternatively, try setting the X driver to "modesetting" (and removing "nokmsboot" / "nomodeset" - they will stop the "modesetting" driver from working).
The "intel" driver should work of course, but that's beyond me to fix.
Booting to the graphical target after selecting the vesa driver: OK , gives working MATE desktop.
Other questions to investigate after reboot.
Remark: since my comment 20, a number of updates have been issued and installed on this laptop. Are we sure none of those impacted/improved on the issue at hand??
(In reply to Herman Viaene from comment #38)
Thanks for all your tests, Herman!
> Remark: since my comment 20, a number of updates have been issued and
> installed on this laptop. Are we sure none of those impacted/improved on the
> issue at hand??
No we're not, and more importantly: the _original_ issue of this bug report got fixed!
It would be better to open (a) new report(s) and close this bug report as fixed, while giving (a) link(s) to the new bug report(s).
For the intel Gfx driver a separate report will be needed, if it still doesn't work on this hardware.
Those updates (or more likely updates to those updates...) will of course be on the next set of ISOs we build.
Mageia 7 beta2 CI still has the same problem.
I can get it to boot and run (sort of) by selecting in boot menu Advanced - recovery mode.
I give the root password, then su -l to my normal user. Then only startx to ICEWM works OK, but there is no way I can run mcc - or drakconf - : authority file not found. i can run all of the drakxxxxx commands from the terminal.
Even stranger, when I select in boot menu Advanced - recovery mode, but do Ctrl-D to let it continu, it boots into a perfectly working (at first sight) MATE.
If you remove "splash quiet" from the normal boot menu entry, does it also boot to the desktop?
How far does the boot get?
Can you switch to a text login with Ctrl-Alt-F2?
- if so, can you attach the output from 'journalctl -b > journal.log' and /var/log/Xorg.0.log.
- if not, and if the boot didn't get stuck at a very early stage, can you reboot in recovery mode and attach the output from 'journalctl -b -1 > journal.log'.
Might also be useful to have the output from 'journalctl -b > journal.log' and /var/log/Xorg.0.log after you boot in recovery mode and Ctrl-D to get to the MATE desktop, for comparison.
Boot stops after fiddling with usb
Ctrl-Alt-F2 is not possible.
Uploading journalnoboot.log from failed boot , journalboot.log and Xlog from booted MATE.
Created attachment 10710 [details]
Failed normal boot (splash noquiet removed)
Created attachment 10711 [details]
M7beta2 recovery boot to MATE
Created attachment 10712 [details]
M7beta2 recovery boot to MATE, Xlog
Looks like the bad boot didn't get far enough to write the journal to disk :-(
Looking back through the previous comments, one more thing to try is to add nomodeset to the boot options (replacing nokmsboot if it's there).
Yeepeee, that did it. At boot replaced splash quiet with nomodeset, nokmsboot not being there, and that madz a successful reboot.
To be sure, changed grub2 with grub-customizer and rebooted without me intervening, all seems OK.
Great. Unless tmb has any better ideas, I think this will just have to go in the errata. You are probably better off using the desktop kernel with nomodeset than using the desktop586 kernel - the slowdown from the Spectre fixes in the desktop586 kernel is quite severe.
(In reply to Martin Whitaker from comment #53)
> Great. Unless tmb has any better ideas, I think this will just have to go in
> the errata. You are probably better off using the desktop kernel with
> nomodeset than using the desktop586 kernel - the slowdown from the Spectre
> fixes in the desktop586 kernel is quite severe.
That brings up another issue, a bit off-topic for the bug yet related. As a matter of course, the 32-bit Live DVD installs the desktop586 kernel, even when the desktop kernel might have been a better choice. It happens with my old Inspiron that has a 32-bit Pentium 4 processor, which works just fine with the desktop kernel.
I fully understand why this is so, but it still means that users who install Mageia that way are going to experience the "slowdown" you mention, when some of them wouldn't have to. Something about that should probably be in errata, too.
On a personal note, I dislike "putting things in errata," as I don't believe many who run into trouble, especially new users, will actually read it. Those users will simply condemn Mageia as "buggy" and "unusable," and move on to something else. Unfortunately, I don't see a viable alternative.
On M7 Beta 3, I inserted nomodeset at boot. This made the boot almost complete: at 71 sec. I get the output "Terminate boot screeen", but then nothing (although there is disk activity) till at 346 sec. there is a message "net-fw DROP IN=enp2s8 OUT .........." refering to the IP adresses I configured at installation time. And yes, the laptop has an ethernet cable connection. Such messages keep appearing roughly every 300 or 600 seconds for hours.
Rebooting with ethernet cable unplugged results in hanging without messages, but disk activity regularly showing up.
Tried to boot disconnected from ethernet cable, but about same: hangs after 71 seconds, no output anymore. As soon as I plug the cable in, the "net-fw DROP" messages start to appear as above.
I can again reproduce this in qemu, as per comment 18.
Two alternatives to try, both of which worked for me in qemu:
1. Remove the vga=... from the boot command line. (this stopped the boot splash screen from working, but allowed X to start)
2. Boot to run level 3 and change the X driver from "vesa" to "modesetting". In this case, remove nokmsboot/nomodeset from the boot command line.
Jipieee, the first suggestion (remove vga= ....) did the trick.
Now try this all over again with M7Beta3round2.
Me Too. I have only just found this bug report.
During bootup, there is a journal message that the nVidia driver is not the version the kernel is looking for, but installation doesn't stop there. What does stop it, is inability to start the display manager. When I switched to the nouveau driver, but left nokmsboot in the command line, I got a message about driver conflict. Removing nokmsboot allowed a normal startup.
The latest update fixed this problem, but now I can't get a proper display in 6.
Sorry Doug, that's a completely different issue. Your original problem just needed the initrd to be rebuilt to include the new nvidia driver. tmb has now modified the nvidia packages to do this automatically when they are updated.
If you still have problems, please open a new bug report.
I am aware that it is irrelevant to this bug. It seems to be on Xfce4 only. MATE loads properly, but even a default config for Xfce4 has problems. Since 7 with Xfce4 works, I might as well make it my default OS.
Just for completeness, the problem disappeared when I deleted all sessions files in ~/.cache/sessions. I will publish this on the newsgroup, although it is probably not new.
(In reply to Marja Van Waes from comment #39)
> (In reply to Herman Viaene from comment #38)
> Thanks for all your tests, Herman!
> No we're not, and more importantly: the _original_ issue of this bug report
> got fixed!
Also: issue raised after:
(In reply to Herman Viaene from comment #57)
> Jipieee, the first suggestion (remove vga= ....) did the trick.
> Now try this all over again with M7Beta3round2.
So closing this, fixed: adding 'nomodeset' and removing vga=XXX from kernel comd line.