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.
RPM Packages =>
Release (media or process)Assignee:
Mageia 7Beta does not boot =>
Mageia 7Beta i586 does not boot on Thinkpad R50e (real 32bit hardware)CC:
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.